Closed Feezex closed 1 year ago
2214423621 [01] level 07 (seed size 8 : key size 7) 80 5C 00 05 1D 74 44 F5 = 07 F4 0F 21 D7 FF FF [FD] level FD (seed size 4 : key size 4) CF 30 00 C0 = 3A 39 CB F9
2214422021 01 AE 72 B4 B1 00 69 27 96 = 07 2F 3E C7 95 FF FF
2214425021 01 8D 51 C6 74 92 B3 25 22 = 07 A7 28 7C 9C FF FF
07 04 0F 21 D7 FF FF
07 F4 0F 21 D7 FF FF correct key (from yt)
From yt: also 2214423621 [01] seed C0 1C 00 05 17 7E F2 43 key 07 54 6F 2A D3 FF FF [FD] seed EF 02 00 40 key 1A 4B CB 79
2214423621 FD:SEED xor f54acb39 = FE key 01 seems a bit tricky key seems have 07 + XX XX XX XX + FF FF format seed seems to be C0 1C 00 + XX XX XX XX XX
just for notice sw unknown
100A6701C01C00B2 // C01C00 + B2 2116379D9A1C00B2 // seed C01C00B216379D9A 10092702FFEBA0A7 // key FFEBA0A7 036702349A1C00B2 // 670234 accepted
1C 00 B2 seems to be some of SW identifier. In 2214423621 case it has to be 1C 00 05. Raw data shows the real situation thats why asked @jglim to modify trace window a bit
Just a small note, for the unknown sw key, it seems like there's a second frame that might be missed out:
10 0A 6701C01C00B2
21 16379D9A 1C00B2
-> 67 01 C0 1C 00 B2 16 37 9D 9A (OK)
---
10 09 2702FFEBA0A7
21 xxxxxx ..?
(missing continuation, first frame specifies 9 bytes, only 6 received; expecting 3 more bytes?)
-> 27 02 FF EB A0 A7 xx xx xx
---
03 670234 9A1C00B2 // 670234 accepted
-> 67 02 34 (OK)
Yes, missed 30 one unknown sw identified as 2219024702
05,877 60A 8 02 27 01 FF FF FF FF FF 05,884 481 8 10 0A 67 01 C0 1C 00 B2 05,897 60A 8 30 00 00 FF FF FF FF FF 05,945 481 8 21 EF CE 89 8E 1C 00 B2 05,962 60A 8 10 09 27 02 FF 7B EF A6 05,963 481 8 30 08 14 00 00 00 00 00 05,982 60A 8 21 F8 FF FF FF FF FF FF 05,985 481 8 03 67 02 34 8E 1C 00 B2
34,826 60A 8 02 27 01 FF FF FF FF FF 34,832 481 8 10 0A 67 01 40 9C 00 B2 34,845 60A 8 30 00 00 FF FF FF FF FF 34,892 481 8 21 EF CE 89 8E 9C 00 B2 34,912 60A 8 10 09 27 02 FF 7B EF A6 34,912 481 8 30 08 14 00 00 00 00 00 34,932 60A 8 21 F0 FF FF FF FF FF FF 34,942 481 8 03 67 02 34 8E 9C 00 B2
09,238 60A 8 02 27 01 FF FF FF FF FF 09,244 481 8 10 0A 67 01 00 DC 00 B2 09,256 60A 8 30 00 00 FF FF FF FF FF 09,305 481 8 21 01 20 54 53 DC 00 B2 09,324 60A 8 10 09 27 02 FF 9B 31 AB 09,325 481 8 30 08 14 00 00 00 00 00 09,343 60A 8 21 F4 FF FF FF FF FF FF 09,344 481 8 03 67 02 34 53 DC 00 B2
Thanks for the update, here's the iso-tp interpretation of the raw frames:
2219024702:
< 27 01
> 67 01 C0 1C 00 B2 EF CE 89 8E
< 27 02 FF 7B EF A6 F8 FF FF
> 67 02 34
< 27 01
> 67 01 40 9C 00 B2 EF CE 89 8E
< 27 02 FF 7B EF A6 F0 FF FF
> 67 02 34
< 27 01
> 67 01 00 DC 00 B2 01 20 54 53
< 27 02 FF 9B 31 AB F4 FF FF
> 67 02 34
---
05,877 60A 8 02 27 01 FF FF FF FF FF
< 27 01
05,884 481 8 10 0A 67 01 C0 1C 00 B2
05,897 60A 8 30 00 00 FF FF FF FF FF
05,945 481 8 21 EF CE 89 8E 1C 00 B2
> 67 01 C0 1C 00 B2 EF CE 89 8E
05,962 60A 8 10 09 27 02 FF 7B EF A6
05,963 481 8 30 08 14 00 00 00 00 00
05,982 60A 8 21 F8 FF FF FF FF FF FF
< 27 02 FF 7B EF A6 F8 FF FF
05,985 481 8 03 67 02 34 8E 1C 00 B2
> 67 02 34
34,826 60A 8 02 27 01 FF FF FF FF FF
< 27 01
34,832 481 8 10 0A 67 01 40 9C 00 B2
34,845 60A 8 30 00 00 FF FF FF FF FF
34,892 481 8 21 EF CE 89 8E 9C 00 B2
> 67 01 40 9C 00 B2 EF CE 89 8E
34,912 60A 8 10 09 27 02 FF 7B EF A6
34,912 481 8 30 08 14 00 00 00 00 00
34,932 60A 8 21 F0 FF FF FF FF FF FF
< 27 02 FF 7B EF A6 F0 FF FF
34,942 481 8 03 67 02 34 8E 9C 00 B2
> 67 02 34
09,238 60A 8 02 27 01 FF FF FF FF FF
< 27 01
09,244 481 8 10 0A 67 01 00 DC 00 B2
09,256 60A 8 30 00 00 FF FF FF FF FF
09,305 481 8 21 01 20 54 53 DC 00 B2
> 67 01 00 DC 00 B2 01 20 54 53
09,324 60A 8 10 09 27 02 FF 9B 31 AB
09,325 481 8 30 08 14 00 00 00 00 00
09,343 60A 8 21 F4 FF FF FF FF FF FF
< 27 02 FF 9B 31 AB F4 FF FF
09,344 481 8 03 67 02 34 53 DC 00 B2
> 67 02 34
2219024702 [01] known list
C0 1C 00 B2 EF CE 89 8E FF 7B EF A6 F8 FF FF
40 9C 00 B2 EF CE 89 8E FF 7B EF A6 F0 FF FF
00 DC 00 B2 01 20 54 53 FF 9B 31 AB F4 FF FF
00 DC 00 B2 1A 3B 54 53 FF 2B 30 AB F4 FF FF
80 5C 00 B2 C2 E3 B4 B3 FF AB 3D A5 FC FF FF
80 5C 00 B2 27 06 11 16 FF FB 63 AF FC FF FF
C0 1C 00 B2 FB DA 60 67 FF 3B 7E A8 F8 FF FF
00 DC 00 B2 EA CB 6C 6B FF 2B BF A8 F4 FF FF
also 2214423621 [01] seed C0 1C 00 05 17 7E F2 43 key 07 54 6F 2A D3 FF FF [FD] seed EF 02 00 40 key 1A 4B CB 79
here was a mistake with one symbol. in this case, [FD] seed xor f549cb39 = key
2214423621 [01] level 07 (seed size 8 : key size 7) 80 5C 00 05 1D 74 44 F5 = 07 F4 0F 21 D7 FF FF [FD] level FD (seed size 4 : key size 4) CF 30 00 C0 = 3A 39 CB F9
in this case, [FD] seed xor f509cb39 = key
It looks very similar to ki211. Seed 80 5C 00 05 1D 74 44 F5
key 221: 07 F4 0F 21 D7 FF FF key 211: 07 44 48 52 80 FF FF Format is the same so i guess there must be keys to KIAlgo1
I went to check if it was using KIAlgo1 as the format appears similar enough. Unfortunately it does not use KIAlgo1 that we have, or it uses a modified variant.
KIAlgo1 is partially reversible, leaving about 9 bits (or less) of uncertainty where information is lost during the root key rotation. 9 bits is a small enough keyspace to search through in reasonable time, so we can reliably recover a KIAlgo1 root key if a seed/key pair is known.
I've written a small application to extract the root key given a valid KIAlgo1 seed/key pair. It is unpacked, so curious folks can look at it via ILSpy or similar (KIAlgo1WF.MainForm.Reverse()
).
This application was tested with random values from our existing KI211 collection and has worked fine so far.
However, all 221 seed/key pairs will not generate a solution, which implies that 221 does not use the same algo (..or I am doing something wrong).
There are many possibilities for variations:
(x & 7) + 2
)I can't test these out, however I can at least confirm that the stock KIAlgo1 does not work with the 221.
Good! Amazing as always! Can i have source for minitool? Since its not a KIAlgo1, im going to bruteforce it, then after getting a K, need to decompile exact KSS to get that in code. Thanks for contribution!
First attempt to brute failed. Any changes to seed cause SVCI to stuck. All known keys goes perfect withought problems. Pairs 2,3,4 of seed is a suffix that specify calculation algo. C0 1C 00 B2 EF CE 89 8E Its used as marker in fist part of 2701 answer while "21" continuation message keeps the real seed and a suffix mark.
02 27 01 FF FF FF FF FF 10 0A 67 01 C0 1C 00 B2 21 EF CE 89 8E 1C 00 B2 10 09 27 02 FF 7B EF A6
Going to try other tools...
While checking out KI221.CBF, one particular compiled script referenced by DJ_Displaylight_write
is particularly unusual. The same script file also contains another function SecurityAccess
. This function takes a 2 byte parameter (access level), sends 2701
, parses 6701
, then generates and sends a 2702
key.
The script sets up a parameter that behaves like a root key at the start of the function (0xB16905DC
). The subsequent behavior is different from any of the algos that we have here.
When using the values from an earlier post for 2214423621
(seed 80 5C 00 05 1D 74 44 F5
), the output key is mostly identical, 07 F4 0F 21 D7 FF FF
vs 07 F4 0F 21 D7 00 00
. The only difference is the last 2 bytes, and I believe the ECU probably accepts any value for the last 2 bytes.
I've searched through the firmware files below to identify the root keys. There are only 2 unique values as far as I can tell:
0xB16905DC
0x0721B2DC
Firmware list:
I have created unique entries (KI221_xxxx_L7) for each variant above, and checked them with the seed/key pairs in this thread. With all of your feedback, if it is working correctly, we may be able to complete this issue.
As for the 27 FD
algo, turns out it was two operations, first the seed is xor-ed with a constant, then another constant is added to it. I've checked through all 16 CFFs above as well and there appears to be only one combination, being (seed ^ 0x78253947) + 0x83249272
. This is now available as KI221_Multi
.
if it is working correctly, we may be able to complete this issue
Thanks for the calc! idk about 221, but ki211 works and issue can be closed. How about ki164 algo?
For Unlock Ecu purposes - it's done. Bench issue still persisting. I will post here updates when get a solution. Great job!
Hooked up existing keygens to define versions for key generation. Possible levels 2701 (2702) / 27FD(27FE). SW definition done by "Functional software", another name is "KSS applikation" Here's main definition list:
2214420821_KSS_Appl_v19_30AMG 2214422021_KSS_Appl_v12_60 2214422121_KSS_Appl_v12_70 2214422321_KSS_Appl_v17_30 2214423621_KSS_Appl_v19_30 2214424021_KSS_Appl_v23_40 2214424621_KSS_Appl_v31_40 2214424721_KSS_Appl_v31_50 2214425021_KSS_Appl_v33_30 2219022402_KSS_Appl_v46_30 2219023000_KSS_Appl_v51_30 2219024702_KSS_Appl_v53_30 2219024902_KSS_Appl_v34_30 2219025301_KSS_Appl_v45_50 2219028901_KSS_Appl_v52_30 2219029600_KSS_Appl_v45_40
Each sw has its own key, and seems it uses "xor" for response. Abrites does 2701 in 97ms For now im not able to get response to 2701 request on bench, Cant figure out reason, i tried solo KI, KI +ZGW, KI+ZGW+EIS withought success. Vediamo connects aswell, but getting 7F response to 2701. CGMB and Abrites fails to read eeprom with "Security fault" Just for note : attached CAN tracer between OBD and Abrites on car - and got same "Security fault" - so..... thats maybe timing issue - but bench must work way faster ... Abrites sends 1092 X 3 times then 01 level unlock then read eeprom, full reading takes 13 seconds. Its might take some time to get all sw keys but if we wont start - we never finish. I think if we get couple keys then we will have hint to decompile all list. For now i can read EE from customer cars X-times each with logging, to get valid pairs. Lets do it