Pages: 1 [2] 3 4
Author Topic: VAG Seed - Key Algorithm Challenge Response via CAN bus  (Read 90226 times)
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #15 on: January 23, 2014, 11:24:12 AM »

Do you have a working flashing program now?
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #16 on: January 24, 2014, 02:18:06 AM »

LOL - still a long way away...

I have reached the next stumbling block! After Security Access comes the transfer of data.

The actual transfer of data between the flash tool and the ECU can be compressed + encrypted   Undecided

Looking at the traces of the interaction between the flash tool and my ECU simulator and between the flash tool and my actual ECU, reading from the ECU is in plain text, but writing to the ECU isn't  Sad

If you want to know what all the KWP commnds mean, they are described in the attachments posted in this thread. No big secrets there.

KWP Request Upload (read from ECU)

35 aa bb cc de ff gg hh

aa - memory address (high byte)
bb - memory address (middle byte)
cc - memory address (low byte)
d - compression method (high nibble)
e - encrypting method (low nibble)
ff - memory size (high byte)
gg - memory size (middle byte)
hh - memory size (low byte)

Example: 35 00 00 00 00 20 00 00 (from my log of ECU read by flash tool)

Start at address 0x000000 and read 0x200000 (2097152 bytes / 2048kb / 2mb)
Compression  = 0 (no compression)
Encryption = 0 (no encryption)

KWP Request Download (write to ECU)

34 aa bb cc de ff gg hh

aa - memory address (high byte)
bb - memory address (middle byte)
cc - memory address (low byte)
d - compression method (high nibble)
e - encrypting method (low nibble)
ff - memory size (high byte)
gg - memory size (middle byte)
hh - memory size (low byte)

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)

Reading from the ECU is OK, both encryption and compression are off and the contents of the .bin match what's transferred out from the ECU.

But writing is a mystery. The flash tool encrypts and compresses the .bin and this encrypted + compressed bit stream is piped down to the ECU. The bytes in the bit stream look nothing like the bytes in the bin :-(

I have no idea what algorithms are used to encrypt and compress the contents of the bin. At least with Security Access I had the example algorithms as a starting point, but here I don't have anything.

Grateful for any hints.
Logged
RaraK
Hero Member
*****

Karma: +58/-2
Offline Offline

Posts: 537


« Reply #17 on: January 24, 2014, 11:25:58 AM »

ecuwrite.log would be nice to see Wink
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12232


WWW
« Reply #18 on: January 24, 2014, 12:01:40 PM »

I have no idea what algorithms are used to encrypt and compress the contents of the bin. At least with Security Access I had the example algorithms as a starting point, but here I don't have anything.

Grateful for any hints.

Supposedly RSA PKE.

Going to need to find a RKA privkey, looks like.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #19 on: January 26, 2014, 02:24:28 PM »

ecuwrite.log would be nice to see Wink

Happy to oblige, here you go Grin

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.

Supposedly RSA PKE.

Going to need to find a RKA privkey, looks like.

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
Logged
Aurélien
Full Member
***

Karma: +4/-0
Offline Offline

Posts: 60


« Reply #20 on: February 01, 2014, 01:40:20 PM »

I think files are flashed in sgo format that was the standard encryption for non UDS ecu. ( Now it's FRF )

Can't you request a download uncompressed and unencrypted ?
Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5789


« Reply #21 on: February 02, 2014, 03:33:50 PM »

I think files are flashed in sgo format that was the standard encryption for non UDS ecu. ( Now it's FRF )

Can't you request a download uncompressed and unencrypted ?

Not unless it's in test mode.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #22 on: February 03, 2014, 01:09:27 AM »

Hi guys,

So from my logging of the ECU <-> Flash Tool communications, I saw the write to the ECU is encrypted/compressed and the read from the ECU was in clear text.

Write 34 02 00 00 11 06 00 00

Read 35 00 00 00 00 20 00 00

This got me wondering - could you request the read to be compressed/encrypted as well?

I was hoping to read the exact same segment of memory four times over (clear, compressed, encrypted, compressed and encrypted) and see if there are any discernable patterns.

So I tried some ECU reads with these compression/encryption bits set as well

35 00 00 00 01 00 00 40
7F 35 51 fail - improper upload type

35 00 00 00 10 00 00 40
7F 35 51 fail - improper upload type

35 00 00 00 11 00 00 40
7F 35 51 fail - improper upload type

35 00 00 00 00 00 00 40 ok
75 3F ok

Sadly they all failed except for clear text :-(

I think files are flashed in sgo format that was the standard encryption for non UDS ecu. ( Now it's FRF )

Can't you request a download uncompressed and unencrypted ?

Thanks very much, I'll look into that sgo stuff. Have you got any examples perhaps?

I was also thinking about trying a uncompressed and unencrypted write to the ECU, but I'm waiting to get my spare ECU prepared (not keen to experiment with the one in the car since it's my daily drive. OK to do reads though). I did try reading compressed and encrypted from the ECU but they failed as descibed above. Maybe what I can try is different diagnostic modes (10 85 / 10 86) and see if different operations are permitted withing each mode?

Not unless it's in test mode.

That's interesting and partially answers the question posed above. How do you put the ECU into a 'test mode'? Is it another KWP2000 command or something else? I'll have my spare ECU on the bench, so can attempt pretty much whatever is suggested. I'd be keen to here a bit more about this test mode  Grin

Thanks for the comments, it all helps.
Logged
Aurélien
Full Member
***

Karma: +4/-0
Offline Offline

Posts: 60


« Reply #23 on: February 03, 2014, 06:43:40 AM »

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

Karma: +903/-420
Offline Offline

Posts: 5789


« Reply #24 on: February 03, 2014, 04:37:43 PM »

That's interesting and partially answers the question posed above. How do you put the ECU into a 'test mode'? Is it another KWP2000 command or something else? I'll have my spare ECU on the bench, so can attempt pretty much whatever is suggested. I'd be keen to here a bit more about this test mode  Grin

Thanks for the comments, it all helps.

On ME7 you must mod the EEPROM, on MED9 no idea.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #25 on: February 05, 2014, 02:04:19 AM »

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 Grin 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  Shocked
Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #26 on: February 05, 2014, 02:42:09 AM »

So what algorithm is being used to encrypt/compress? It looks awfully regular and seems to repeat…

Playing around a bit (a lot) this is what I came up with. Quite proud of this actually Cheesy

XOR with 0x62 65 72 74 43 6F 64 65 52 6F [edit - I know it's these ten bytes, but not sure about the start byte and end byte since it repeats]

This repeats every ten bytes.

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

XOR with: 64 65 52 6F 62 65 72 74 43 6F 64 65 52 6F 62 65 72 74 43 6F 64 65 52 6F 62 65 72 74 43 6F 64 65 (note how it repeats every ten bytes)

Encrypted file: 3E 3F 08 35 5A 05 72 74 DB 02 E6 A7 6A EF 62 9A EA F9 C1 AC FC 08 D0 AF FA E8 F0 B5 0D EF 64 45

Perfect match to the enctypted/compressed data stream!

Gotta love XOR  Kiss

This leads to the next observation. I don't think it is compressed, just XOR'd.
« Last Edit: February 07, 2014, 03:50:11 AM by Basano » Logged
Aurélien
Full Member
***

Karma: +4/-0
Offline Offline

Posts: 60


« Reply #27 on: February 05, 2014, 03:49:28 AM »

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

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.
Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #28 on: February 05, 2014, 04:22:10 AM »

Ah thanks Cheesy

Try these:

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

It's the same ten bytes, but just rotated a bit. Not sure if I got the exact beginning of the file to start with! Basically I'm playing with the offset a bit.

Very curious to see how you get on.
« Last Edit: February 05, 2014, 04:28:40 AM by Basano » Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #29 on: February 05, 2014, 04:33:14 AM »

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?
Logged
Pages: 1 [2] 3 4
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.093 seconds with 16 queries. (Pretty URLs adds 0.001s, 0q)