NefMoto

Hey everyone,

Have been working on my flashing protocol for multiple VAG ecus for the last few years as a bit of a challenge to myself. Through some digging/sgo decryption noticed that on some TP20 based MED17 ECUs the SA2 bytes (which are the bytes responsible for deciphering seed and key algorithms) were wildly different in some very specific cases. The ones of you who care have probably already seen the more generic seed and key algo that works for all me7/med9/most tp20 medc17 ecus but just thought I would share a snippet of what another algo looks like. I have checked this a few times over, however have no actual ECU with this specific software to actually request/challenge the response so take this with a grain of salt.

This would be the deciphering of the SA2 bytes and what they mean:

68-0B                 { FOR I = 11 to 1 (11 cycles)}
87-02-C1-1D-B7  { XOR/EOR 0x02C11DB7 }
93-01-C2-49-68  { ADD 0x01C24968 }
4A-03                 { BCC }
81                      { ROTATE TO THE LEFT }
6B-06                 { BRA }
82                      { ROTATE TO THE RIGHT }
87-13-A2-1D-B7  { XOR/EOR 0x13A21DB7 }
49                      { NEXT }
4C                { FINISH }

This is what I believe it to be in C, hoping to be able to check this sooner than later.

unsigned int seed = 0x12345678 //whatever the ECU sends you after you've asked for the challenge bytes

            for (int x = 0; x < 11; x++)
            {
                seed ^= 0x02C11DB7;
                seed += 0x01C24968;

                if (seed >= 0x80000000)
                {
                    seed >>= 1;
                    seed ^= 0x13A21DB7;
                }
                else
                {
                    seed <<= 1;
                }
            }

unsigned int key = seed; //your answer to the challenge

I did stumble across another unique SA2 byte array that looks different yet again. The hope is to be able to cover any case that comes up so that every challenge can be answered going forward.

Anyways, hope this helps someone someday.

-Christian

The best way to do this IMO is to just use the SA2 string out of the ODX and write your own SA2 runtime, like https://github.com/bri3d/sa2_seed_key .

Then you never need to worry about disassembly or reimplementing one off algorithms ever again. A quick database mapping ECU "families" to SA2 snippets is fairly easy to build out of the flashdaten.

I've considered this as well. When dealing strictly with a binary being passed back into my flash tool and no immediate access to the actual sgo file to acquire the SA2 snippets I would rely on creating a search pattern to find the stored SA2 bytes in the binary (which I did find to exist exactly as they are written in the sgo on MED17 tp20 at least). It's just a matter of figuring out how this byte array is referenced in disassembly and can likely achieve the same thing you're describing but with a non sgo/odx file.

I appreciate the feedback!

This particular SA2 string seems to be present in ME17.5.6 ecus.

Oh, 100% makes sense, you're way out ahead of the situation then and this is super nice work.

I just hate seeing people here asking for, painstakingly disassembling, or worse, paying! for "seed/key for XYZ VW control unit" when it's all in the flashdaten - which is far from your situation :)