Do you have a working flashing program now?

ecuwrite.log would be nice to see

Happy to oblige, here you go

Just remember, the log is between my ECU simulator and the flash tool, not a real ECU. I had to guess some of the ECU responses and also the serial buffer on the sim tool got hammered and dropped a few packets. You'll still get an idea of what's going on with KWP 2000 though.


RSA PKE? Aaargh, that’s just not fair!!!

Leaving that aside for a moment, there’s another little check at the end of the data transfer process. It’s described in the Corporate Group Requirement Specification For Programming Control Units with Keyword Protocol 2000 Transport Protocol 2.0 and this check also appears at the end of the write log between the flash tool and my ECU simulator.

After the data is transferred from the flash tool to the ECU, the flash tool instructs the ECU to calculate a checksum for a small part of the flash.

KWP StartRoutineByLocalIdentifier (CalculateFlashChecksum)

31 aa bb cc dd ee ff gg hh ii

aa - routine local identifier
bb - start address (high byte)
cc - start address (middle byte)
dd - start address (low byte)
ee - end address (high byte)
ff - end address (middle byte)
gg - end address (low byte)
hh - checksum of the data (high byte)
ii - checksum of the data (low byte)

Example: 31 C5 1F 00 00 1F FF FF 96 83 (from my log of ECU write by flash tool)

The ECU is instructed by the flash tool to calculate the checksum of a block of data starting at address 0x1F0000 and ending at address  0x1FFFFF (so block is 64k in size and happens to be at the end of the 2mb flash) and compare it to 0x9683. Now 0x9683 is the checksum calculated by the flash tool and sent down to the ECU and should match the checksum as calculated by the ECU, meaning the data transfer was OK (why only a small 64k block? Some processing constraint?)

So how is the checksum calculated? I did the write of the ECU sim by the flash tool several times, each time using a hex editor to change a few bytes within the last 64k of the 2mb flash file. Each time, I ALSO saved the last 64k of the modified 2mb flash file (containing my changed bytes) to a new file 64k in size.

Here were the KWP commands from those writes. Each time the checksum changes, which it should, since each time I changed a few bytes within this last 64k block.

31 C5 1F 00 00 1F FF FF 96 83
31 C5 1F 00 00 1F FF FF A8 05
31 C5 1F 00 00 1F FF FF 7E 4E 

But now remember, I’d also saved those little 64k blocks into a new file every time I changed it. So I took the files and ran them though a freeware checksum utility CHK (http://compressme.net) , referenced by Wikipedia in the article on checksums (http://en.wikipedia.org/wiki/Checksum)

Look at the checksums CHK gave me for the little files when I chose type CRC32:

4A019683
0328A805
DEAB7E4E

In each case, the last four numbers match what the flash tool (and presumably the ECU) use!

To be totally precise, this is CRC32b after I tried the same test with some other online calculators and did some reading

Not unless it's in test mode.

I would try a 10 86 session yes. Maybe you can try some read (un)encrypted/compressed in 10 86 mode !

Thanks all,

I did a bit of reading about the sgo files. It looks like this is the format that VAG use to deliver the software. There are descriptions of utilities that convert the sgo file to a bin file, then the bin file can be written to the ECU by a flash tool. However, I don’t need to convert from sgo to bin because I already have the bin file (2MB file from read of ECU).

Here’s what I’m seeing - the input to the flash tool is a bin file and the output from the flash tool down to the ECU is an encrypted-compressed version of this bin. I can see this encrypted-compressed data when I sniff the connection between the flash tool and my ECU simulator.

Question – is the entire 2MB bin file written down to the ECU?

I don’t think it is, I think just a portion of that 2MB is sent down. If I look at the KWP write command it’s saying write 0x60000 bytes to memory location 0x20000.

Example: 34 02 00 00 11 06 00 00  (from my log of ECU write by flash tool)

Start at address 0x020000 and write 0x060000 (393216 bytes / 384KB)
Compression  = 1 (compression method #1)
Encryption = 1 (encryption method #1)

That’s not 2Mb!

So what can I do to see how the flash tool encrypts/compresses the bin when it sends it down to the ECU? Assuming that the same encryption/compression is used for both writing and reading I tried asking the ECU for various reads. Any encrypted or compressed read request was unsuccessful (although I only tried in diagnostic mode 86). The only read request that’s accepted is plain text. Scratch that then.

I don’t have any options in the flash tool to control the write request either. It’s a chinese clone of a very popular ODB flash tool and the user interface has three big buttons – ECU ID, Read and Write That’s about it. You can’t tell it about encryption or compression, it must be hardcoded in.

So where does that leave me? I decide to try modifying the contents of the 2MB bin file and see what changes when the flash tool writes it down to the ECU (my ECU simulator). I put in some easy patterns (00 00 00 00, 11 11 11 11, 22 22 22 22 etc) to see what changes. But since I don’t believe the entire 2MB bin is sent down to the ECU, where should I put my changes? Beginning, middle or end? For want of a better starting place, I modified the contents of the 2MB bin starting at 0x20000 since that’s where the KWP write command starts.

2MB bin @ 0x20000 (original file)
5A 5A 5A 5A 38 60 00 00 98 6D 82 C2 38 80 00 FF 98 8D 82 C3 98 6D 82 C0 98 8D 82 C1 4E 80 00 20

2MB bin @ 0x20000 (modified file)
5A 5A 5A 5A 00 00 00 00 00 00 00 00 00 00 00 00 98 8D 82 C3 98 6D 82 C0 98 8D 82 C1 4E 80 00 20

2MB bin @ 0x20000 (modified file)
5A 5A 5A 5A 11 11 11 11 11 11 11 11 11 11 11 11 98 8D 82 C3 98 6D 82 C0 98 8D 82 C1 4E 80 00 20

Then I used the flash tool to write these down to the ECU simulator and snooped the connection between the flash tool and simulator:

orig.bin      5A 5A 5A 5A 38 60 00 00 98 6D 82 C2 38 80 00 FF            
R0   25821   740   8   29      0   F5   36   41   4D   54   20
R0   25823   740   8   2A      20   20   20   20   20   20   20
R0   25825   740   8   2B      20   20   20   1A   1   7C   90
R0   25827   740   8   2C      3E   3F   8   35   5A   5   72
R0   25831   740   8   2D      74   DB   2   E6   A7   6A   EF
R0   25834   740   8   2E      62   9A   EA   F9   C1   AC   FC
R0   25838   740   8   2F      8   D0   AF   FA   E8   F0   B5
                                    
mod0.bin      5A 5A 5A 5A 00 00 00 00 00 00 00 00 00 00 00 00            
R0   90813   740   8   29      0   F5   36   41   4D   54   20
R0   90815   740   8   2A      20   20   20   20   20   20   20
R0   90817   740   8   2B      20   20   20   1A   1   7C   90
R0   90820   740   8   2C      3E   3F   8   35   62   65   72
R0   90823   740   8   2D      74   43   6F   64   65   52   6F
R0   90827   740   8   2E      62   65   EA   F9   C1   AC   FC
R0   90830   740   8   2F      8   D0   AF   FA   E8   F0   B5
                                    
mod1.bin      5A 5A 5A 5A 11 11 11 11 11 11 11 11 11 11 11 11            
R0   18190   740   8   29      0   F5   36   41   4D   54   20
R0   18192   740   8   2A      20   20   20   20   20   20   20
R0   18194   740   8   2B      20   20   20   1A   1   7C   90
R0   18196   740   8   2C      3E   3F   8   35   73   74   63
R0   18198   740   8   2D      65   52   7E   75   74   43   7E
R0   18202   740   8   2E      73   74   EA   F9   C1   AC   FC
R0   18205   740   8   2F      8   D0   AF   FA   E8   F0   B5

Now I can see how the flash tool is changing the bin (encrypting/compressing) as it sends it down to the ECU 

Good job. The 00 00 [...] 00 trick was clever. 

I don't see anywhere in the code where the x62 65 72 74 43 6F 64 65 52 6F comes from though. I've been looking for almost everysubroutine with 0x62 with no luck.

Oooh, look at this!

So I opened up the 2MB bin and searched through it with a hex editor. Ten searches, one for each rotation of the data above.

I found this one inside:

43 6F 64 65 52 6F 62 65 72 74



Coincidence? I think not.

Does that match any routine you can see?