GM ECU Simulator

[hjtrbo]

Success.
c# ppc parser loads the dids it can get on its own by static analysis of a provided bin file. The user can elect to then auto-fill missing fields with sensible dummy data. Or create on their own.
xps get module info -> utilising the home grown shim dll -> Successfully reads the module info. There are a couple of missing fields, but that is trivial now.

[hjtrbo]

Screenshot 2026-05-16 134638.png

[antus]

Winning! Well done!

[hjtrbo]

5 byte e92 algo reversed. Fuck AI is good.

Update - will commit the latest edits later tonight:

Virtual ecu - writing:
e38, e92 verified against xps acrhives including seed / challenge response validation (2 and 5 byte) & the post programming checks.
e67, t43 verified against the powerpcm & 6speed.t43.
If you're wanting to build a flash tool you can test against one these ecu's to get your bugs out before you start bricking a real one.
**** Please send me archives of the families above if you can, especially sps derived ones ****

Virtual ecu - data streaming
Pick an ecu, pick common pids with a basic waveform to output values or load your own streaming file. The ecu responds to $22 or $AA modes. If you're wanting to build your own data logger you can test it against this.

Virtual ecu - reading: todo

At all points adherence to gmw3110 has been a top priority.

[antus]

you mentioned earlier something about emulating powerpc to run the flash kernels. is that how you ended up doing it? as in, can this be used for kernel development before running on a real PCM?

[hjtrbo]

Short answer to your question: there is no emulation, only static analysis via a C# bytecode + bin parser. For PPC emulation, try out Renode - I had an E38 running on it last night after some AI-assisted patching to get it past the boot phase. The AI completed the whole setup, booting and subsequent iterative patching. It took maybe an hour or so to get it running to the point where I could send it a $27 can frame to trigger the security function crip walk.

The sim does two kinds of static analysis: SPS interpreter bytecode out of the utility file, and structured data tables out of the OS bin at known offsets. No PowerPC instruction decoding - that's Ghidra/Renode territory. With that said, an earlier version of this sim did do c# ppc parsing but I no longer need it as I better understand the XPS programming flow.

This is not what you asked, but I think now is a good time to explain why my simulator has to have a separate XPS mode, away from the normal hobbyist-grade flash tool mode.

Hobbyist tools (PowerPCM Flasher and similar) make loose assumptions about a target's behaviour. Declared block sizes are advisory, "validate download" is a single CRC at the end, and the conversation is one-tool-to-one-ECU. A sim that satisfies those tools only has to "respond plausibly." XPS is the opposite end of the spectrum:

Byte-exact verification. Based on the archives tested thus far, XPS executes a ~120-step SPS interpreter program where each Phase 4 $1A read is compared against a literal embedded in the bytecode. One wrong byte aborts the session. That changes the sim's job from "respond plausibly" to "respond with exactly the bytes this specific archive declares."

Archive-driven priming. Hobbyist tools don't care about the utility-file bytecode - they just push the flash payload. XPS mode has to ingest the archive ahead of time and prefill every DID/PID the bytecode is going to read, otherwise Phase 4 fails on the first compare.

So XPS mode is a different conformance level. Keeping it as a separate mode means a developer writing a hobbyist-grade flash tool gets a target ECU that's forgiving in the ways real-world ECUs are forgiving to those tools (declared sizes loose, single end-of-flash CRC, no archive required), while a developer writing an XPS-compatible flash tool gets a target with the byte-exact, archive-primed strictness XPS demands. Both still have to do real $27 seed/key - that's the ECU's job regardless of who's talking to it.

With that context, here's the XPS session itself:
An XPS programming session runs in roughly four phases:

Phase 1 - Init / auth. XPS broadcasts $28 (DisableComms), $A2 (ReportProgrammedState), then $1A B0 functional to enumerate modules, and unlocks the target with $27 seed/key. 2 & 5 byte are working.

Phase 2 - Kernel upload. XPS pushes a small bootloader/kernel into RAM via $34 / $36 / $37 and from its side considers the module "now running the kernel." We don't execute it. The sim treats the kernel upload as another block-transfer sequence and just keeps responding from the same handlers: Service34Handler accepts the requestDownload, Service36Handler accumulates each $36 block into a virtual-flash buffer, Service37Handler closes the transfer. Whatever XPS thinks the kernel will compute later, we compute directly on the host side from the buffered bytes. The canonical case is the 71 04 <crc_hi> <crc_lo> "validate download" reply, which is a CRC-16/CCITT-FALSE (poly $1021, init $FFFF) over the bytes XPS just sent us. From XPS's point of view it asked the kernel for a CRC and the kernel answered; from our point of view there is no kernel, just a buffer and an arithmetic check.

Phase 3 - Calibration flash. The (conceptual) kernel erases the cal regions, then XPS streams the 8-or-so cal blocks via $34 / $36 / $37, each gated by a CRC check ($31 routines + $AE checkpoints). Same deal as Phase 2: the sim accumulates bytes into the virtual-flash buffer and computes CRCs on demand.

Phase 4 - Post-flash verification + traceability. XPS reads back a handful of DIDs with $1A, writes the session metadata DIDs ($90 VIN, $98, $99, $DF) with $3B, and closes with $AE 28 03. This is the phase that gates "Programming Successfully Ended" - if any $1A read returns the wrong bytes the session aborts.

Phases 1-3 are mostly mechanical handshakes the existing GMW3110 handlers cover by spec. Phase 4 is where the interesting work is - XPS is asking "prove you got programmed correctly," and it has byte-exact expectations for every DID it reads. Those expectations are not in our codebase, they're in the archive itself.

What I'm doing is reading the archive's utility file - the SPS interpreter bytecode XPS executes against the module - and statically resolving every value Phase 4 will ask for, before the session even starts. Two sources feed the primed dataset:

$53 COMPARE_DATA literals from the bytecode. Every Phase 4 $1A read in the script is paired with a $53 op whose routine payload holds the expected response bytes verbatim. UtilityFileParser walks the bytecode; PidResponseSolver follows the $54 CHANGE_DATA / $53 COMPARE_DATA cascade and emits a byte[] per DID the script reads. Those become the primed ECU's static $1A responses.
OS module bin scan (E38PidExtractor). For $22 PID sweeps XPS does outside the cascade, the parser signature-scans the archive's OS module for the 8-byte-per-record PID table (E38 lives around flash $145718, ~535 PIDs), pulls IDs + lengths, and stubs them. Cascade-derived values win where available; otherwise the handler returns the spec-correct NRC $31 (we deliberately don't zero-fill - that would be lying about "supported, value is 0").
Net effect: by the time XPS issues its first Phase 4 $1A, every DID it could ask for is already primed with the byte-exact value the bytecode says it should compare against.

The hard limit is anything that needs the flashed firmware to actually run to produce its answer (boot-ROM-derived CVN, an emissions self-test result, etc.) - those get flagged at prime time rather than failing mid-session. Pure arithmetic checks over the flashed bytes (CRC, sum-of-bytes) are fine: the sim keeps a virtual-flash buffer of every $36 block and computes on demand, same way the real kernel would.

[kur4o]

Anyone have a link to complied version to test.

Hjtrbo,


Do you think that AI can open the gm 12 byte seed/key, via reversing of bootblock code out of pcm.

I might have some bootblocks to share for testing purposes..

[hjtrbo]

I've got it up on github. https://github.com/hjtrbo/GM-ECU-Simulator

Question back to you - Is the challenge response to the ecm generated locally on the pc or from the server?

[kur4o]

I looked everywhere but couldn`t find precompiled version, only source code.

For sure key is calculated on some server[not sure it can be reversed from pcm bootblock, at least needs to verify it and also calculate key since seed is generated on the fly]. On VIP there is also some bus data authentications that is written to each module again sever calculated.

[hjtrbo]

I'm not sure to answer concretely yes or no. What you've got sounds very advanced. AI is a great help, but in cases like yours, you yourself still need to be advanced to drive it. But it will save you days of probing. My opinion is you fit into the advanced category, but you will need to feed it as much information about the topology and things already discovered. If you can get the chip number and a full dump and find a supported emulator AI will give it a good crack. For static analysis in ghidra it automates that too, but its not magic, static analysis only gets so far.

Preview build.
There is an issue with the shim sometimes where it won't accept a previously established connection. If you encounter the issue the work around is simple: J2534 -> Reset IPC Pipe.
Also note the user manuals in the docs directory are way out of date.
https://github.com/hjtrbo/GM-ECU-Simula ... tag/v0.1.0