GM ECU Simulator

[ironduke]

I got it compiled on vs2022.
Small issue with the dll's being in the wrong folders for the simulator.exe to find them to the registry..
Haven't had time other than seeing something trying to connect and fail. Not the fault of the software, but I think I just need to build a pids.json file for the module(I just tried an ECM) so it can reply with vin number, OS, cal files, etc..

Trying to figure out the pid setup, I'm sure I'm just doing things the hard way, lol.. oh well, gotta pretend I'm working..
So far it looks pretty nice and possibly quite powerful once I get the hang of it.

So.. for the DPS build/config it looks like it needs the dps archive to then pretend to be the ecm for a dps programming event? I am kind of missing the point of this as if I had the dps archive I would simply use those files, lol.. This is kind of the same setup as flash tool write except it's getting the info from the archive folder?

[hjtrbo]

Grab the latest preview exe and source from here https://github.com/hjtrbo/GM-ECU-Simulator/releases

So.. for the DPS build/config it looks like it needs the dps archive to then pretend to be the ecm for a dps programming event? I am kind of missing the point of this as if I had the dps archive I would simply use those files, lol.. This is kind of the same setup as flash tool write except it's getting the info from the archive folder?

It's quite useful if you're building you're own archives from scratch with post flash verification routines. For 99.999% of us it's not needed. It's primary role for existence was to prove it could survive the programming session. That way I can stand behind it and claim if it survives dps then for whatever an end user is trying to develop, if it doesn't work then there's something wrong with their tool... I'll come back to eat my words on this soon

Haven't had time other than seeing something trying to connect and fail. Not the fault of the software, but I think I just need to build a pids.json file for the module(I just tried an ECM) so it can reply with vin number, OS, cal files, etc..

Make sure logging is enabled, you will see obviously when your software connects.

Not an obvious concept given its name and set-up, but worth remembering, what ever software is connected through the j-shim, it's connected to a virtual can-bus, not the ecu that's configured in the simulator.

The pids you create are actually mode 2D pids. In behind the scenes they're converted to mode 22. For example; if you create just a single pid (address can be whatever) it will be available on mode 22 at pid 0xfe38. Each additional pid is 0xfe37 ... 0xfe00.

You have identified some short comings. I ignored them as my use case is to poll addresses of interest identified during ghidra re sessions.
1. The ecu does not have a pre-built or user editable $1A table you can poll to get basic information like VIN etc. I had it, but then stripped it out. I'll put it back in.
2. It should have a small subset of mode 1 pids so people can test it easily out of the box.

[hjtrbo]

Haven't had time other than seeing something trying to connect and fail. Not the fault of the software, but I think I just need to build a pids.json file for the module(I just tried an ECM) so it can reply with vin number, OS, cal files, etc..

You have identified some short comings. I ignored them as my use case is to poll addresses of interest identified during ghidra re sessions.
1. The ecu does not have a pre-built or user editable $1A table you can poll to get basic information like VIN etc. I had it, but then stripped it out. I'll put it back in.
2. It should have a small subset of mode 1 pids so people can test it easily out of the box.

New PID editor. For you. It's not released yet so you won't see it till probably tonight.

Choose from OBD mode $01, GMW3110 mode $1A, UDS mode $22 or custom GMW3110 mode $2D. The simulator now implements the common services across those 3 communication stacks. Additional modes are easy, everything just plugs in as a module - it's pretty smart how the AI has done proper module / class segmentation across the entire code base which allows these additions and many others with minimal to no impact to the wider code base.

Screenshot 2026-05-19 113704.png

[Tazzi]

On a fucking roll!
This is exactly what I was talking about, amazing work!!!

[hjtrbo]

My laptop is not doing well. Its running really hot and context switching stutters. 16gb of ram ain't gonna cut it in this new AI world.

[hjtrbo]

New pre-release v0.2.0 on github. Starting to get this beast nailed down. Still not ready for prime time but good enough to play with. Out of the box any scan tool should be able to hook up to it and start polling data. Manuals are out of date so don't bother reading them.

Connection modes:
J2534
Raw can (direct connection to the simulators virtual can bus)

Supported ecu's:
GM e38, e67, t43, e92.

Functions:
Supports polling over mode 1, 22 and rapid packet over mode AA.
Supports user defined read by address over mode 2D.
Supports a full ecu flash sequence with kernel capture. Note: kernel execution is not simulated.
Supports dps post flash integrity checking

Supported protocols:
J2534 raw CAN & ISO 15765-2
Raw can

GM Modes:
$10 InitiateDiagnosticOperation
$1A ReadDataByIdentifier (DID)
$20 ReturnToNormalMode
$22 ReadDataByParameterIdentifier
$27 SecurityAccess
$28 DisableNormalCommunication
$2C DynamicallyDefineDataIdentifier
$2D DefinePidByAddress
$34 RequestDownload
$36 TransferData
$3E TesterPresent
$A2 ReportProgrammedState
$A5 ProgrammingMode
$AA ReadDataByPacketIdentifier (periodic UUDT push, Slow / Medium / Fast bands).

[kur4o]

The main issue you have to overcome about simulated flash write is the different responses pcm sends, for the same message type.

And there is also some timers where response changes, and it waits for trigger match, needed before it proceed.

[hjtrbo]

The main issue you have to overcome about simulated flash write is the different responses pcm sends, for the same message type.

And there is also some timers where response changes, and it waits for trigger match, needed before it proceed.

Are you saying I need to add some knobs you can turn to invoke $7F responses to exercise the flash tooling?

[kur4o]

Some modules always send 7f 78, indicating module is busy and wait, than send 73. Some even send 7f multiple times, before it proceed. The biggest issue is last message response from pcm[it changes response if write is good], so preset flash logic can proceed, otherwise it enters retry loop.

Not sure if you have dialed timings, wait time before response or it is immediate.

[hjtrbo]

It doesn't simulate real world. There is bus timing from memory. I'll have to dig back in. I probably won't do it but adding real world personality is certainly achievable.