GM ECU Simulator

[hjtrbo]

Of course.

Does sps need anymore DID's than what I have so far? BTW, I'll have an import DID fields tool where you point it at a bin and it will pre-fill the DID's for you.

[hjtrbo]

It created a c# ppc parser to find the service dispatcher which then gets the service handler locations. In the case for $1A it then locates the DID table, then jumps to each supported DID. I ran it over the 6 bins I have (a mix of t43, e38, e67) and it found them all using the same parser.

Code: Select all

We're gold. All 6 bins follow one universal pattern.
Universal structure (every single bin)
service dispatcher
├── cmpwi chain on SID byte at request[2]
├── 9 SIDs supported: $1A, $20, $27, $28, $34, $36, $3E, $A2, $A5
│
└── $1A handler (small trampoline)
    └── lbz r3, 3(request) ; bl real_did_dispatcher
        │
        └── DID dispatcher (cmpwi chain on DID byte)
            └── 6 DIDs: $B0, $C1, $CB, $CC (supported) + $C9, $CA (explicitly rejected)

High level parser:

Code: Select all

What this means for your C# parser
The parser becomes firmware-revision-independent. It doesn't need to know the dispatcher offset for each family — it discovers it dynamically:

public sealed class GmDiagnosticBinParser
{
    public BinExtraction Parse(byte[] bin)
    {
        // 1. Hunt service dispatcher (find dense cluster of SID cmpwi)
        int dispatcher = FindServiceDispatcher(bin);

        // 2. Walk dispatcher's cmpwi/beq chain -> dict<SID,handler>
        var sids = WalkSidChain(bin, dispatcher);

        // 3. $1A handler is a trampoline -> follow bl to real DID dispatcher
        int didDispatcher = FollowTrampoline(bin, sids[0x1A]);

        // 4. Walk DID chain -> dict<DID, handler>
        var dids = WalkDidChain(bin, didDispatcher);

        // 5. For each DID, trace handler to find source
        //    - if (lis;lwz;mtctr;bctr) pattern -> indirect call
        //      follow to fetcher fn; if fetcher is (lis;addi;blr) -> flash addr
        //      read 4-byte BE uint32 at that addr -> wire response
        //    - else inline const handler
        return new BinExtraction { ... };
    }
}
~200 lines of C# handles all 3 families and any future revisions. No hardcoded offsets, no per-family parsers, no heuristics. The bin tells the parser where the DID data lives.

[antus]

Nice one. That's the sort of stuff that would be good to get in to universal patcher. Some of the P04 stuff in PCMHammer works like that seeking code as well, and I got the idea from UP's implementaion, though it's slightly different. I must say I like the grey box with the dark title and light data field app theme as well. Its real easy on the eyes.

[hjtrbo]

Thanks, the app has multiple themes to choose from.

Working on the flash capture module now.

Round 1 bootloader capture is done - but it's not a free lunch, it spits out every $34 into it's own bin. You end up with about 60 bins that are the individual segments. Those skilled in the art will recognise the bootloader blobs for inspection. I'm sure I can tighten this up to only keep the bootloader segments on round 2. It would probably be done by pattern matching.

[hjtrbo]

Getting closer...

[antus]

try making it a logger and then something to parse the logs and reconstruct the bin, or error out if a packet is missing. then you can log with any standard tool and an ai can go looking if you have multiple attempts and find the first one that is complete.

Looks like its a race and I'm going to have to release my e38 work sooner than planned Though I actually expected to be overtaken by someone else and kinda stopped.

[hjtrbo]

lol. You know I'm cheating. I still haven't written 1 line of code. The no reply frames are due to not yet implementing a 'kernel persona' to switch in a uds library whilst the ecu (this simulator) is in kernel mode. Not far off - hopefully tonight. Currently its strict GMW3110 only.

Logging is active. Both to screen and to csv. It's been an immense help!

[hjtrbo]

...to release my e38 work sooner than planned

I'm out of the loop, what have you being working on???

[hjtrbo]

Sick. Kernel-mode persona takes over for the programming session, switching the diagnostic handler from GMW3110 to UDS. CRC is computed over the actual bytes transferred and returned to the flash tool.

SPS would be the logical next step - that may reveal some additional UDS handlers I need to implement. I don't have a subscription. If anyone has a full wire transfer logged end to end they could send me that would be a massive help. Online repo is now updated with the current state of the project.

[hjtrbo]

For reference these are the DID's xps reads.

Code: Select all

Order	DID	Meaning (per GMW3110 §8.3 / dialog labels)
1	$90	VIN
2	$97	System Name or Engine Type
3	$92	System Supplier ID
4	$CB	End Model Number
5	$CC	Base Model Number
6	$95	Supplier SW Version Number
7	$9A	Diagnostic Data Identifier
8	$99	Programming Date
9	$98	Repair Shop Code / SN
10-20	$C0-$CA	Software / calibration part numbers (slots)
21	$DD	Software Module Identifier (the right-pane table)
22	$B5	Broadcast Code
23	$A0	Manufacturers Enable Counter
24	$B4	Mfg Traceability Chars
25	$28	Partial VIN
26	$9F	History: RSCOSN
27-30	$F1-$F4	(likely manufacturing / serial-number block)