Pages: 1 2 [3] 4
Author Topic: VAG Seed - Key Algorithm Challenge Response via CAN bus  (Read 97111 times)
technic
Full Member
***

Karma: +18/-5
Offline Offline

Posts: 227


« Reply #30 on: February 05, 2014, 02:26:34 PM »

This is the most interesting I've read in a long time... Very good work
Logged
Aurélien
Full Member
***

Karma: +4/-0
Offline Offline

Posts: 60


« Reply #31 on: February 06, 2014, 08:31:10 AM »

In fact IDA detect this as some code, I need to work more on this to find what's really going on.

It makes me a bit upset to have something used for decrypting the data you send in the code. How can you perfore a full update ( code + caldata ) if you use something at a place you are overwriting ? Does it means that " xor chain " is uploaded somewhere in ram during flash process ? That could match with your point that your flasher is only flashing the data. I will make some test too, very soon, to have more informations about this.
Logged
nyet
Administrator
Hero Member
*****

Karma: +607/-168
Offline Offline

Posts: 12266


WWW
« Reply #32 on: February 06, 2014, 12:56:54 PM »

In fact IDA detect this as some code, I need to work more on this to find what's really going on.

It makes me a bit upset to have something used for decrypting the data you send in the code. How can you perfore a full update ( code + caldata ) if you use something at a place you are overwriting ? Does it means that " xor chain " is uploaded somewhere in ram during flash process ? That could match with your point that your flasher is only flashing the data. I will make some test too, very soon, to have more informations about this.

I don't pretend to know much about motronic, but in the embedded designs i do, loader code almost always runs out of RAM (copied from the flash on boot, or before it is run) or out of OTP ROM.
Logged

ME7.1 tuning guide
ECUx Plot
ME7Sum checksum
Trim heatmap tool

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

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #33 on: February 07, 2014, 03:42:07 AM »

For those browsing, an explanation of where I’ve gotten to.

As explained earlier, the flash tool takes a binary file as input and writes an encoded version of this binary down to the ECU. I’ve monitored the KWP communication between the flash tool and ECU (simulator) and compared it against the input binary. Small changes to the input binary produce corresponding small changes to the encoded output binary.

I believe the encoding is an XOR obfuscation with a 10 byte repeating pattern

Encoded:   3E 3F 08 35 5A 05 72 74 DB 02 E6 A7 6A EF 62 9A EA F9 C1 AC
XOR:      64 65 52 6F 62 65 72 74 43 6F 64 65 52 6F 62 65 72 74 43 6F
Decoded:   5A 5A 5A 5A 38 60 00 00 98 6D 82 C2 38 80 00 FF 98 8D 82 C3

But although it’s ten bytes, because it repeats I’m unsure which is the first byte and which is the tenth byte Huh

Encoded:   3E 3F 08 35 5A 05 72 74 DB 02 E6 A7 6A EF 62 9A EA F9 C1 AC
XOR:      64 65 52 6F 62 65 72 74 43 6F 64 65 52 6F 62 65 72 74 43 6F
Decoded:   5A 5A 5A 5A 38 60 00 00 98 6D 82 C2 38 80 00 FF 98 8D 82 C3

Encoded:   3E 3F 08 35 5A 05 72 74 DB 02 E6 A7 6A EF 62 9A EA F9 C1 AC
XOR:      64 65 52 6F 62 65 72 74 43 6F 64 65 52 6F 62 65 72 74 43 6F
Decoded:   5A 5A 5A 5A 38 60 00 00 98 6D 82 C2 38 80 00 FF 98 8D 82 C3

Encoded:   3E 3F 08 35 5A 05 72 74 DB 02 E6 A7 6A EF 62 9A EA F9 C1 AC
XOR:      64 65 52 6F 62 65 72 74 43 6F 64 65 52 6F 62 65 72 74 43 6F
Decoded:   5A 5A 5A 5A 38 60 00 00 98 6D 82 C2 38 80 00 FF 98 8D 82 C3

All the above give you the same result since the ten bytes repeat. But since I'm looking at a fragment, it's not obvious where it starts.
Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #34 on: February 07, 2014, 03:47:33 AM »

I'm going to take a guess and say the ten byte pattern is 0x52 6F 62 65 72 74 43 6F 64 65 (coincidently this reads "RobertCode" in ASCII)

Putting it all together neatly, here’s what it looks like.

Encoded KWPXORDecodeComment
0KWP length MSB (0x00)
F5KWP length LSB (0xF5)
36KWP operation (0x36) - download
415213Encoded data #1
4D6F22Encoded data #2
546236Encoded data #3
206545etc
207252
207454
204363
206F4F
206444
206545
205272
206F4F
206242
206545
1A7268
17475
7C433F
906FFF
3E645AFrom this position the decoded sequence
3F655Acan be found in the original input binary
8525A
356F5A
5A6238
56560
72720
74740
DB4398
26F6D
E66482
A765C2
6A5238
EF6F80
62620
9A65FF
EA7298
F9748D
C14382
AC6FC3
FC6498
8656D
D05282
AF6FC0
FA6298
E8658D
F07282

« Last Edit: February 07, 2014, 03:55:18 AM by Basano » Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #35 on: February 10, 2014, 02:19:31 AM »

Spent a bit of time looking through the trace of flash tool write to the ecu in more detail:

KWP Command Comment
(0x34)      download @ 0x20000 size 0x60000 (384kb)
(0x31 0xC4) erase flash start 0x20000 end 0x7ffff
(0x33 0xC4) erase flash results
(0x36)      transfer data
(0x37)      exit transfer
(0x31 0xC5) calculate flash checksum start 0x20000 end 0x7ffff = 0xACF9
(0x33 0xC5) results checksum

(0x34)      download @ 0x80000 size 0x20000 (128kb)
(0x31 0xC4) erase flash start 0x80000 end 0x9ffff
(0x33 0xC4) erase flash results
(0x36)      transfer data
(0x37)      exit transfer
(0x31 0xC5) calculate flash checksum start 0x80000 end 0x9FFFF = 0x2757
(0x33 0xC5) results checksum

(0x34)      download @ 0xA0000 size 0x120000 (1152kb)
(0x31 0xC4) erase flash start 0xA0000 end 0x1BFFFF
(0x33 0xC4) erase flash results
(0x36)      transfer data
(0x37)      exit transfer
(0x31 0xC5) calculate flash checksum start 0xA0000 end 0x1BFFFF = 0xAEFF
(0x33 0xC5) results checksum

(0x34)      download @ 0x1C0000 size 0x30000 (192kb)
(0x31 0xC4) erase flash start 0x1C0000 end 0x1EFFFF
(0x33 0xC4) erase flash results
(0x36)      transfer data
(0x37)      exit transfer
(0x31 0xC5) calculate flash checksum start 0x1C0000 end 0x1EFFFF = 0x510C
(0x33 0xC5) results checksum

(0x34)      download @ 0x1F0000 size 0x10000 (64kb)
(0x31 0xC4) erase flash start 0x1F0000 end 0x1FFFFF
(0x33 0xC4) erase flash results
(0x36)      transfer data
(0x37)      exit transfer
(0x31 0xC5) calculate flash checksum start 0x1F0000 end 0x1FFFFF = 0x7E4E
(0x33 0xC5) results checksum


There are five distinct writes down to the ecu (even though there's just one big 'write' button on the clone flash tool). Looks like everything except the first 128kb get written to the ECU.
Logged
Aurélien
Full Member
***

Karma: +4/-0
Offline Offline

Posts: 60


« Reply #36 on: February 10, 2014, 04:19:55 AM »

Ok so that's the 5 sectors or / block flash tools are talking about.
Logged
de_Fre
Jr. Member
**

Karma: +7/-2
Offline Offline

Posts: 25


« Reply #37 on: February 26, 2014, 10:02:05 PM »

Has anyone tested on an actual ECU what happens when you change "CodeRobert" in the flash to something else ? does it change the XOR ?
Logged
ddillenger
Hero Member
*****

Karma: +641/-21
Offline Offline

Posts: 5640


« Reply #38 on: February 26, 2014, 10:28:52 PM »

Very nice work
Logged

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!

Email/Google chat:
DDillenger84(at)gmail(dot)com

Email>PM
prj
Hero Member
*****

Karma: +1072/-480
Offline Offline

Posts: 6034


« Reply #39 on: February 27, 2014, 12:10:51 AM »

If you are clever, you can first checksum a block in the flash, then checksum the file going in, and if the checksum matches skip writing the block.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
daniel
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 3


« Reply #40 on: April 13, 2014, 04:38:52 AM »

Hi Guys,

i'm reading this post and i'm impressed, couse becaouse since last week I'm trying to find solution for the same problem about can bus seed/key challenge. i was trying to figure it out by myself and i also write some codes in c to make something like brute force searching or something like that. But i'm thinking that im walking circles and problem is more sipmle that I thinking.

i was listening on the bus and i have a lot of seed and keys positive answers and I'm 100% sure that there is some connection between bytes

seed 3B   2A   F4   DA
key  C0   2F   80   DD

like for exapmle when 1st byte of seed is 3B the 3d byte of key is always 80, and like that are also connected 2nd byte of seed with 1st byte of key and 3rd seeds byte with 2nd key byte. Last bytes are also always "connected".

Maybe some of you Guys know something about this problem if yes I can share more exapmles and my 'serching-key' codes.

 
Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #41 on: April 13, 2014, 01:58:17 PM »

Hello

What vehicle are you logging these seed/keys from?
Logged
Russell
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 3


« Reply #42 on: May 25, 2014, 02:19:54 AM »

Excellent reading Basano, please most more of your interesting work. Wink Wink
Logged
mattiasclaesson
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 1


« Reply #43 on: December 14, 2014, 04:08:31 PM »

Hi,

@Basano, excellent work indeed.

I am working on similar task, to find the seed-key algorithm of a ME9.6 hybrid ECU used in saab/opel.

This is what I found so far:

Luckily we have a complete BDM dump of a ME9.6, and 5F BD 5D BD actually is present in the binary.
Further more its refered to from this code, that looks a lot as a seed+key algorithm to me.

Code:
ROM:00015A20 # =============== S U B R O U T I N E =======================================
ROM:00015A20
ROM:00015A20
ROM:00015A20 sub_15A20:                              # CODE XREF: sub_15A68+44p
ROM:00015A20                 cmpwi   %r3, 5          # Compare Word Immediate
ROM:00015A24                 bne     loc_15A34       # Branch if not equal
ROM:00015A28                 lis     %r12, dword_5F80@h # Load Immediate Shifted
ROM:00015A2C                 lwz     %r3, dword_5F80@l(%r12) # Load Word and Zero
ROM:00015A30                 b       loc_15A44       # Branch
ROM:00015A34 # ---------------------------------------------------------------------------
ROM:00015A34
ROM:00015A34 loc_15A34:                              # CODE XREF: sub_15A20+4j
ROM:00015A34                 lis     %r12, dword_5F84@h # Load Immediate Shifted
ROM:00015A38                 addi    %r12, %r12, dword_5F84@l # Add Immediate
ROM:00015A3C                 slwi    %r11, %r3, 2    # Shift Left Immediate
ROM:00015A40                 lwzx    %r3, %r12, %r11 # Load Word and Zero Indexed
ROM:00015A44
ROM:00015A44 loc_15A44:                              # CODE XREF: sub_15A20+10j
ROM:00015A44                 cmpwi   %r3, 0          # Compare Word Immediate
ROM:00015A48                 beq     loc_15A60       # Branch if equal
ROM:00015A4C                 not.    %r12, %r3       # Complement Register
ROM:00015A50                 beq     loc_15A60       # Branch if equal
ROM:00015A54                 add     %r12, %r4, %r4  # Add
ROM:00015A58                 xor     %r3, %r3, %r12  # XOR
ROM:00015A5C                 blr                     # Branch unconditionally
ROM:00015A60 # ---------------------------------------------------------------------------
ROM:00015A60
ROM:00015A60 loc_15A60:                              # CODE XREF: sub_15A20+28j
ROM:00015A60                                         # sub_15A20+30j
ROM:00015A60                 li      %r3, 0          # Load Immediate
ROM:00015A64                 blr                     # Branch unconditionally
ROM:00015A64 # End of function sub_15A20

ROM:00005F80 dword_5F80:     .long 0x52A48911        # DATA XREF: sub_15A20+8o
ROM:00005F80                                         # sub_15A20+Cr ...
ROM:00005F84 dword_5F84:     .long 0x75775EB5, 0x5AEDFED5, 0x6B5F7DD5, 0x6F757B6B, 0x5FBD5DBD, 0x11111111

From the lookup table above:
0x0A221289,0x144890A1,0x24212491,0x290A0285,0x42145091,0x504822C1,0x0A24C4C1,0x14252229,
0x24250525,0x2510A491,0x28488863,0x29148885,0x422184A5,0x49128521,0x50844A85,0x620CC211,
0x124452A9,0x18932251,0x2424A459,0x29149521,0x42352621,0x4A512289,0x52A48911,0x11891475,
0x22346523,0x4A3118D1,0x64497111,0x0AE34529,0x15398989,0x22324A67,0x2D12B489,0x132A4A75,
0x19B13469,0x25D2C453,0x4949349B,0x524E9259,0x1964CA6B,0x24F5249B,0x28979175,0x352A5959,
0x3A391749,0x51D44EA9,0x564A4F25,0x6AD52649,0x76493925,0x25DE52C9,0x332E9333,0x68D64997,
0x494947FB,0x33749ACF,0x5AD55B5D,0x7F272A4F,0x35BD5B75,0x3F5AD55D,0x5B5B6DAD,0x6B5DAD6B,
0x75B57AD5,0x5DBAD56F,0x6DBF6AAD,0x75775EB5,0x5AEDFED5,0x6B5F7DD5,0x6F757B6B,0x5FBD5DBD

Whats the probability of finding those 1+5 dwords from a seed+key lookup table in a ME9.6 binary and that is NOT the seed+key algorithm?

I looked also in the attached MED9.1 binary that you posted in this thread and the subroutine is exactly the same, even at the same address.

The first seed variable seems to be different for your MED9.1 binary, but still part of the same lookup table:
ROM:00005F80 dword_5F80: .long 0x4A3118D1 # DATA XREF: sub_15A20+8o
ROM:00005F80 # sub_15A20+Cr ...
ROM:00005F84 dword_5F84: .long 0x75775EB5, 0x5AEDFED5, 0x6B5F7DD5, 0x6F757B6B, 0x5FBD5DBD, 0xFFFFFFFF

/Mattias Claesson
Logged
hurane
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 1


« Reply #44 on: April 30, 2015, 04:50:17 AM »

Well done!

Nice to be able to send any seed you want for testing Smiley

Hello
I'm working on diagnostic through K-line (between chrono tachograph and tester iSO14230)

I'm trying  to set cetrain parameters in chronotachographe but I failed!

actually the chrono send a seed 64bits but I didn't find the correct key ?

the seed1 0xE1 0x2F 0x63 0xD9 0x57 0x42 0xCF 0x40 -> key1: 0x4A  0x08 0x81 0x43 0x79 0x1F 0x31 0xC6
the seed2 0xE1 0x2F 0x63 0xD9 0x57 0x42 0xCF 0x40 -> key2: 0xE4 0x8E 0x49 0x4C 0xD0 0x56 0x89 0x93
Logged
Pages: 1 2 [3] 4
  Print  
 
Jump to:  

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