6000 CD SINGLE CD-KW2000

[alexics]

Does anyone have an unlocked eeprom dump for this set. Ford part number is 6S61-18C815-AJ. Must be this exact set, no other part number.

[Dunker]

If the stub data is different will the eeprom data from another set not work anyway? Check the data in the MCU near the serial number, half the time the part number doesn't match whats on the sticker anyway. What MCU is it?

I'll have a look when I get in and see if I have a dump.

[alexics]

The MCU is TMS470R1VF288PZA. In this case I only want eeprom data. The locking mechanism is strange on this one.

[alexics]

This model was a transition between M and V series. Early ones had an M serial number. I have seen M series with the TMS470 and completely different data on the eeprom.

[Dunker]

I have seen M series with the TMS470 and completely different data on the eeprom.

It will be. The V algo is pretty clever compared to the M - especially how the code is derived from 8 bytes from the eeprom and 8 bytes from the stub - thats without actually using the serial number. Generation of the 8 bytes that are in the stub is the key.

BTW I dont have a dump of a 6S61-18C815-AJ. Sorry.

[alexics]

Do you have a full dump of the ram with the code? I am putting together an intelligent arm disassembler. With reference to the user guide I can make a map of the ports. I do have one dump here which I am testing on but would like another to compare with.

I want to cover the i2c routines first and work backwards.

[alexics]

Have you found any thumb code in there at all?

[Dunker]

There's plenty of ARM(7) docs out there pertaining to I2C (things like I2C in ARM are very rarely custom written) and apart from the initialization the stuff we are interested in is all written using thumb.

[barbatecat]

Does anyone have an unlocked eeprom dump for this set. Ford part number is 6S61-18C815-AJ. Must be this exact set, no other part number.

You will look at your core, it can be corrected ?

[alexics]

There's plenty of ARM(7) docs out there pertaining to I2C (things like I2C in ARM are very rarely custom written) and apart from the initialization the stuff we are interested in is all written using thumb.

It is finding the calls to i2c and tracing backwards I am interested in. The calls to library routines will always be static.

[alexics]

You will look at your core, it can be corrected ?

I am wanting to use this set for testing only.

[Dunker]

Here's some V series data for you to check against when you get to the decryption. Its only decrypting code from EEPROM on a 288 MCU with the 8 bytes from the stub so nothing to shout about yet.

I have the tables and the table and byte selection algos along with the crypto stuff replicated in Perl (dont ask - just trying Perl out) but I need to have a week off the beer and concentrate on this a bit more to get the serial to stub data part sorted (although I'm pretty sure I know what data is involved but how exactly I havent messed with yet).


Stub Data = 57 80 67 54 48 94 BA 08 EEPROM Data = 89 A6 D6 BF 7D 68 45 2C
57 80 67 54 48 94 BA 08 XOR 89 A6 D6 BF 7D 68 45 2C = DE 26 B1 EB 35 FC FF 24
DE 26 B1 EB 35 FC FF 24 initialization = 69 75 F3 5C 6D FE 69 4B
69 75 F3 5C 6D FE 69 4B \^?+* 82 02 BB 82 5B F4 = 6D FE 69 4B E1 C6 0E C3
6D FE 69 4B E1 C6 0E C3 \^?+* C3 8D 4A 39 44 32 = E1 C6 0E C3 C7 0F 07 54
E1 C6 0E C3 C7 0F 07 54 \^?+* 4C F4 21 38 FF 10 = C7 0F 07 54 B2 B5 50 83
C7 0F 07 54 B2 B5 50 83 \^?+* 42 2F 58 8A AE 68 = B2 B5 50 83 39 8B 4E EC
B2 B5 50 83 39 8B 4E EC \^?+* 8C 7C 04 D4 94 61 = 39 8B 4E EC B7 5A FB 12
39 8B 4E EC B7 5A FB 12 \^?+* 22 2A 78 14 D2 CA = B7 5A FB 12 73 8B 84 CE
B7 5A FB 12 73 8B 84 CE \^?+* 9C 18 0A EC 43 4E = 73 8B 84 CE CD 16 03 D7
73 8B 84 CE CD 16 03 D7 \^?+* 2A 82 BC EE 24 02 = CD 16 03 D7 F9 27 83 CC
CD 16 03 D7 F9 27 83 CC \^?+* 41 23 EB 26 1B D9 = F9 27 83 CC 42 06 2E 3D
F9 27 83 CC 42 06 2E 3D \^?+* 89 DD 01 C6 28 AF = 42 06 2E 3D BA 91 01 F3
42 06 2E 3D BA 91 01 F3 \^?+* 42 63 65 60 10 A7 = BA 91 01 F3 CC 02 14 9C
BA 91 01 F3 CC 02 14 9C \^?+* 84 5D 48 31 71 8C = CC 02 14 9C 70 AC 4A 3D
CC 02 14 9C 70 AC 4A 3D \^?+* 18 72 74 4B 23 1C = 70 AC 4A 3D 2F CA EC 93
70 AC 4A 3D 2F CA EC 93 \^?+* 82 1A C8 D3 0C 11 = 2F CA EC 93 04 F5 B9 6F
2F CA EC 93 04 F5 B9 6F \^?+* BD 12 24 11 8B B1 = 04 F5 B9 6F 92 87 E4 25
04 F5 B9 6F 92 87 E4 25 \^?+* 68 E2 83 CD 68 02 = 92 87 E4 25 FE 5E 5D 3C
FE 5E 5D 3C 92 87 E4 25 finalization = 26 F0 7F 55 D5 4B 5C E8
26 F0 7F 55 D5 4B 5C E8 XOR 57 80 67 54 48 94 BA 08 = 71 70 18 01 9D DF E6 E0
Code = 7170


or even...


Stub Data = 57 80 67 54 48 94 BA 08 EEPROM Data = 85 7F F0 B6 4A B8 B7 D3
57 80 67 54 48 94 BA 08 XOR 85 7F F0 B6 4A B8 B7 D3 = D2 FF 97 E2 02 2C 0D DB
D2 FF 97 E2 02 2C 0D DB initialization = 8B 87 66 C6 8F 2A E2 9F
8B 87 66 C6 8F 2A E2 9F \^?+* 82 02 BB 82 5B F4 = 8F 2A E2 9F 5D 0C 1C 93
8F 2A E2 9F 5D 0C 1C 93 \^?+* C3 8D 4A 39 44 32 = 5D 0C 1C 93 BC 4D 0F 94
5D 0C 1C 93 BC 4D 0F 94 \^?+* 4C F4 21 38 FF 10 = BC 4D 0F 94 FE D3 85 80
BC 4D 0F 94 FE D3 85 80 \^?+* 42 2F 58 8A AE 68 = FE D3 85 80 9C 19 5F EE
FE D3 85 80 9C 19 5F EE \^?+* 8C 7C 04 D4 94 61 = 9C 19 5F EE C9 2A 5A E6
9C 19 5F EE C9 2A 5A E6 \^?+* 22 2A 78 14 D2 CA = C9 2A 5A E6 10 CC 2C 7B
C9 2A 5A E6 10 CC 2C 7B \^?+* 9C 18 0A EC 43 4E = 10 CC 2C 7B C6 6C F5 49
10 CC 2C 7B C6 6C F5 49 \^?+* 2A 82 BC EE 24 02 = C6 6C F5 49 4D 58 C9 4A
C6 6C F5 49 4D 58 C9 4A \^?+* 41 23 EB 26 1B D9 = 4D 58 C9 4A 97 DF E9 32
4D 58 C9 4A 97 DF E9 32 \^?+* 89 DD 01 C6 28 AF = 97 DF E9 32 64 F2 76 E4
97 DF E9 32 64 F2 76 E4 \^?+* 42 63 65 60 10 A7 = 64 F2 76 E4 6C DB F0 DA
64 F2 76 E4 6C DB F0 DA \^?+* 84 5D 48 31 71 8C = 6C DB F0 DA 5D 90 2C 95
6C DB F0 DA 5D 90 2C 95 \^?+* 18 72 74 4B 23 1C = 5D 90 2C 95 23 DA D8 30
5D 90 2C 95 23 DA D8 30 \^?+* 82 1A C8 D3 0C 11 = 23 DA D8 30 20 5E E6 BC
23 DA D8 30 20 5E E6 BC \^?+* BD 12 24 11 8B B1 = 20 5E E6 BC 9E 45 FC 2F
20 5E E6 BC 9E 45 FC 2F \^?+* 68 E2 83 CD 68 02 = 9E 45 FC 2F 0B 66 4E 3D
0B 66 4E 3D 9E 45 FC 2F finalization = 63 D6 BF CF 89 1B 3C 88
63 D6 BF CF 89 1B 3C 88 XOR 57 80 67 54 48 94 BA 08 = 34 56 D8 9B C1 8F 86 80
Code = 3456


or even...


Stub Data = 74 2F 12 99 6F 22 33 AE EEPROM Data = 67 22 9D 67 37 47 A5 7C
74 2F 12 99 6F 22 33 AE XOR 67 22 9D 67 37 47 A5 7C = 13 0D 8F FE 58 65 96 D2
13 0D 8F FE 58 65 96 D2 initialization = B8 D9 6E 27 CC 28 1E CD
B8 D9 6E 27 CC 28 1E CD \^?+* 5C 0E A4 33 DD C3 = CC 28 1E CD 08 00 61 1C
CC 28 1E CD 08 00 61 1C \^?+* 50 64 0F E6 6C 2F = 08 00 61 1C 52 C2 F2 D5
08 00 61 1C 52 C2 F2 D5 \^?+* 08 AD CC 79 B1 A3 = 52 C2 F2 D5 44 F3 F5 92
52 C2 F2 D5 44 F3 F5 92 \^?+* 5B 78 00 33 77 DC = 44 F3 F5 92 3F 89 0C EA
44 F3 F5 92 3F 89 0C EA \^?+* 16 0E C9 DE AB 1D = 3F 89 0C EA 7B 95 35 4F
3F 89 0C EA 7B 95 35 4F \^?+* 8D 31 98 D3 0E E3 = 7B 95 35 4F DF 3F 6E D5
7B 95 35 4F DF 3F 6E D5 \^?+* 0B 4A 39 B5 D3 B5 = DF 3F 6E D5 A9 1F 6E E2
DF 3F 6E D5 A9 1F 6E E2 \^?+* AE 01 41 8A 7B DE = A9 1F 6E E2 E1 65 5F BD
A9 1F 6E E2 E1 65 5F BD \^?+* 06 D7 81 33 DE B2 = E1 65 5F BD 47 59 DC 22
E1 65 5F BD 47 59 DC 22 \^?+* E5 63 50 B8 FB 7D = 47 59 DC 22 46 0B E6 67
47 59 DC 22 46 0B E6 67 \^?+* 80 5C 73 CE 3E E8 = 46 0B E6 67 B1 61 93 77
46 0B E6 67 B1 61 93 77 \^?+* 20 B3 60 D5 D4 2F = B1 61 93 77 8B 4F BA 07
B1 61 93 77 8B 4F BA 07 \^?+* E0 5A 0E 78 D3 DA = 8B 4F BA 07 95 C2 04 5E
8B 4F BA 07 95 C2 04 5E \^?+* 88 86 66 EF 6F 4C = 95 C2 04 5E 87 A1 20 2C
95 C2 04 5E 87 A1 20 2C \^?+* D2 B0 28 CE A5 33 = 87 A1 20 2C 4C 12 C2 AB
87 A1 20 2C 4C 12 C2 AB \^?+* 61 8D 20 6E 3B DE = 4C 12 C2 AB 64 FA C1 D6
64 FA C1 D6 4C 12 C2 AB finalization = 06 3B C1 92 31 52 DD 1F
06 3B C1 92 31 52 DD 1F XOR 74 2F 12 99 6F 22 33 AE = 72 14 D3 0B 5E 70 EE B1
Code = 7214


If anyone from Ford / Visteon would like to comment ... Feel Free :bike:


No PMs on this please - life is just too short.

[alexics]

I haven't used perl in years. Very C like. I just couldn't hack all the mods you had to install. Life IS too short.

Do each set of 8 bytes get selected from the tables? If so how? Say you start with 71 70 18 01 9D DF E6 E0. Where does 26 F0 7F 55 D5 4B 5C E8 come from? How can you tell where to start from what you have in the eeprom?

[Dunker]

I haven't used perl in years. Very C like. I just couldn't hack all the mods you had to install. Life IS too short.

Do each set of 8 bytes get selected from the tables? If so how? Say you start with 71 70 18 01 9D DF E6 E0. Where does 26 F0 7F 55 D5 4B 5C E8 come from? How can you tell where to start from what you have in the eeprom?


Everything is in the dump of the MCU. It just needs reverse engineering / dissassembling.

My stub data for this radio is:

3FB0 02 04 05 01 30 36 4D 59 20 58 43 61 72 20 50 42 ....06MY XCar PB
3FC0 4C 20 76 30 32 2D 30 34 2D 30 35 00 46 44 56 32 L v02-04-05.
3FD0 30 30 37 56 31 30 30 30 34 32 00 00 57 80 67 54 007V100042..W.gT
3FE0 48 94 BA 08 36 43 31 54 2D 31 34 43 32 33 30 2D H.?.6C1T-14C230-
3FF0 41 47 00 00 00 00 00 00 00 00 00 00 7F FF FF FF AG...........???

(6C1T-14C230-AG is NOT part number, sticker reads 6C1T-18C815-AJ)

and the EEPROM data is obviously the 8 bytes starting @ 0x14C

[alexics]

Everything is in the dump of the MCU. It just needs reverse engineering / dissassembling.

My stub data for this radio is:

3FB0 02 04 05 01 30 36 4D 59 20 58 43 61 72 20 50 42 ....06MY XCar PB
3FC0 4C 20 76 30 32 2D 30 34 2D 30 35 00 46 44 56 32 L v02-04-05.
3FD0 30 30 37 56 31 30 30 30 34 32 00 00 57 80 67 54 007V100042..W.gT
3FE0 48 94 BA 08 36 43 31 54 2D 31 34 43 32 33 30 2D H.?.6C1T-14C230-
3FF0 41 47 00 00 00 00 00 00 00 00 00 00 7F FF FF FF AG...........???

(6C1T-14C230-AG is NOT part number, sticker reads 6C1T-18C815-AJ)

and the EEPROM data is obviously the 8 bytes starting @ 0x14C


I thought you didn't have the AJ variant.

[alexics]

What does the code at 0x4010 look like? Is that involved with the decryption? I haven't looked at it yet. I'm packing in for the night.

[Dunker]

Sorry about the AJ bit - I was looking at my dumps and not my notes - I'll post eeprom when I get in if the 6C1T will do instead of the 6S61.

[Dunker]

If anyone has some stub and eeprom data from a matching TMS470-689 and 24c16 I wouldn't mind taking a look. I only need the 8 bytes @ 0x3FDC from the stub and 8 bytes @ 0x14C from the eeprom as shown in the pics. I only need two or 3 pairs.

The AJ eeprom is also attached.

[mobilart]

Look PM....

[Dunker]

Thanks for that. They are 288 MCU's. Its the 689 I need.

Stub Data = 70 01 7C 73 98 0E EB D8 EEPROM Data = 48 A1 60 D9 2E 69 F5 D4
70 01 7C 73 98 0E EB D8 XOR 48 A1 60 D9 2E 69 F5 D4 = 38 A0 1C AA B6 67 1E 0C
38 A0 1C AA B6 67 1E 0C initialization = 20 55 F4 20 1A 3B CD 78
20 55 F4 20 1A 3B CD 78 \^?+* 99 31 23 2A 73 78 = 1A 3B CD 78 15 C2 B4 C4
1A 3B CD 78 15 C2 B4 C4 \^?+* EE 9C 81 2D 94 A3 = 15 C2 B4 C4 17 D9 BF 34
15 C2 B4 C4 17 D9 BF 34 \^?+* 57 27 3A 20 F5 DE = 17 D9 BF 34 6F 2A CE 67
17 D9 BF 34 6F 2A CE 67 \^?+* 8C EC 99 6E A8 4C = 6F 2A CE 67 86 76 FA 71
6F 2A CE 67 86 76 FA 71 \^?+* 6B 29 74 55 24 63 = 86 76 FA 71 A2 32 21 DF
86 76 FA 71 A2 32 21 DF \^?+* 26 5C 0B 35 93 92 = A2 32 21 DF 8E 5B 19 29
A2 32 21 DF 8E 5B 19 29 \^?+* 3C A3 5E B2 2B 5E = 8E 5B 19 29 80 29 7C AA
8E 5B 19 29 80 29 7C AA \^?+* CA D8 9A E6 2A 21 = 80 29 7C AA B5 7D 3D BB
80 29 7C AA B5 7D 3D BB \^?+* B1 99 79 29 6B D5 = B5 7D 3D BB DE 9B 54 74
B5 7D 3D BB DE 9B 54 74 \^?+* 48 53 A7 8E 2C B4 = DE 9B 54 74 BB D0 E6 BE
DE 9B 54 74 BB D0 E6 BE \^?+* A3 C7 4C 11 9C 27 = BB D0 E6 BE 3F 3F E4 37
BB D0 E6 BE 3F 3F E4 37 \^?+* DC 70 67 31 D2 F8 = 3F 3F E4 37 04 96 C5 54
3F 3F E4 37 04 96 C5 54 \^?+* 12 9F F0 CD 3A 5C = 04 96 C5 54 36 F9 75 F5
04 96 C5 54 36 F9 75 F5 \^?+* D5 72 84 C4 0C 3A = 36 F9 75 F5 4A C1 37 9D
36 F9 75 F5 4A C1 37 9D \^?+* A1 0E FD 71 D9 22 = 4A C1 37 9D 16 A9 6C 00
4A C1 37 9D 16 A9 6C 00 \^?+* 5B AA 4E CE 4C 63 = 16 A9 6C 00 39 E8 8C 98
39 E8 8C 98 16 A9 6C 00 finalization = 60 80 8C 7D C1 78 18 35
60 80 8C 7D C1 78 18 35 XOR 70 01 7C 73 98 0E EB D8 = 10 81 F0 0E 59 76 F3 ED
Code = 1081

Stub Data = 71 10 85 6C A0 9F ED EA EEPROM Data = 3F 3F 24 2B 71 23 B0 F1
71 10 85 6C A0 9F ED EA XOR 3F 3F 24 2B 71 23 B0 F1 = 4E 2F A1 47 D1 BC 5D 1B
4E 2F A1 47 D1 BC 5D 1B initialization = 59 F0 6B DE 34 26 E3 8B
59 F0 6B DE 34 26 E3 8B \^?+* 5A 71 2F AC 47 32 = 34 26 E3 8B 28 18 DC E1
34 26 E3 8B 28 18 DC E1 \^?+* E7 35 11 0B 13 3B = 28 18 DC E1 06 6D CE 4F
28 18 DC E1 06 6D CE 4F \^?+* 14 6F 3F E2 5C 99 = 06 6D CE 4F E1 B5 98 29
06 6D CE 4F E1 B5 98 29 \^?+* A8 E9 D0 48 A8 AD = E1 B5 98 29 BF A5 7E C2
E1 B5 98 29 BF A5 7E C2 \^?+* 73 58 6E 40 55 E4 = BF A5 7E C2 05 BE FE E8
BF A5 7E C2 05 BE FE E8 \^?+* 2C 96 CB 1F 91 0C = 05 BE FE E8 82 C1 28 A6
05 BE FE E8 82 C1 28 A6 \^?+* DB B3 1E 43 07 5B = 82 C1 28 A6 4D 25 AF D0
82 C1 28 A6 4D 25 AF D0 \^?+* CE CE A1 E7 88 91 = 4D 25 AF D0 79 13 23 5E
4D 25 AF D0 79 13 23 5E \^?+* 52 D9 3F E4 61 51 = 79 13 23 5E D4 34 6A CF
79 13 23 5E D4 34 6A CF \^?+* 4C C7 C4 1E 68 82 = D4 34 6A CF A0 72 FE C6
D4 34 6A CF A0 72 FE C6 \^?+* F3 74 5C 38 47 27 = A0 72 FE C6 F8 98 FE B5
A0 72 FE C6 F8 98 FE B5 \^?+* 1C 3E E3 BA B6 80 = F8 98 FE B5 A8 3C FD 4D
F8 98 FE B5 A8 3C FD 4D \^?+* B3 BB 90 81 A6 4D = A8 3C FD 4D 80 53 9A 42
A8 3C FD 4D 80 53 9A 42 \^?+* C5 4A AF D4 C0 D0 = 80 53 9A 42 CE BF 5E 6E
80 53 9A 42 CE BF 5E 6E \^?+* A9 85 79 1D 4A 46 = CE BF 5E 6E 2A F5 8C F1
CE BF 5E 6E 2A F5 8C F1 \^?+* 4F 8E E5 97 59 20 = 2A F5 8C F1 F8 EC DD B4
F8 EC DD B4 2A F5 8C F1 finalization = 26 80 3D DC 67 F3 76 7F
26 80 3D DC 67 F3 76 7F XOR 71 10 85 6C A0 9F ED EA = 57 90 B8 B0 C7 6C 9B 95
Code = 5790

[murat332]

Code 1234 and Code 2704 -689 two eeprom file for a processor
could work :giveup:

[alexics]

What happens to the data if the set is locked? Does it still produce the code?

[Dunker]

Code 1234 and Code 2704 -689 two eeprom file for a processor
could work :giveup:
Thanks, but I need the 8 bytes from the TMS470 / 689 @ 0x3FDC as well as the 8 bytes from the EEPROM @ 0x14C. If anyone has some just write them in a post - no need for attachments. I dont want any codes or serial numbers - people might think I'm cheating :stupido:

The code still computes if the timer is on or the set is locked. I've not gone into that yet but I assume thats what the other 4 bytes that change in the eeprom are for. I could be wrong though and that info could be in the other 6 bytes that are left over ???

Oh, and by the way. If the of the algo produces a 4 digit result that has letters in it (ie. a hexadecimal result so to speak) the set will display 'LOCKED' - it knows its the wrong eeprom data or the eeprom has been altered.

[alexics]

I think the other 4 bytes are more likely as these are after the timer lock byte.

When the eeprom data changes after a correct code entry do the 8 unencrypted bytes come out the same? Code + 6 extra bytes. Or do the six bytes change as the eeprom data changes? I hope this makes sense.

[mobilart]

Look PM...

[Dunker]

When the eeprom data changes after a correct code entry do the 8 unencrypted bytes come out the same? Code + 6 extra bytes. Or do the six bytes change as the eeprom data changes? I hope this makes sense.

Stub Data = 57 80 67 54 48 94 BA 08 EEPROM Data = 89 A6 D6 BF 7D 68 45 2C
57 80 67 54 48 94 BA 08 XOR 89 A6 D6 BF 7D 68 45 2C = DE 26 B1 EB 35 FC FF 24
DE 26 B1 EB 35 FC FF 24 initialization = 69 75 F3 5C 6D FE 69 4B
69 75 F3 5C 6D FE 69 4B \^?+* 82 02 BB 82 5B F4 = 6D FE 69 4B E1 C6 0E C3
6D FE 69 4B E1 C6 0E C3 \^?+* C3 8D 4A 39 44 32 = E1 C6 0E C3 C7 0F 07 54
E1 C6 0E C3 C7 0F 07 54 \^?+* 4C F4 21 38 FF 10 = C7 0F 07 54 B2 B5 50 83
C7 0F 07 54 B2 B5 50 83 \^?+* 42 2F 58 8A AE 68 = B2 B5 50 83 39 8B 4E EC
B2 B5 50 83 39 8B 4E EC \^?+* 8C 7C 04 D4 94 61 = 39 8B 4E EC B7 5A FB 12
39 8B 4E EC B7 5A FB 12 \^?+* 22 2A 78 14 D2 CA = B7 5A FB 12 73 8B 84 CE
B7 5A FB 12 73 8B 84 CE \^?+* 9C 18 0A EC 43 4E = 73 8B 84 CE CD 16 03 D7
73 8B 84 CE CD 16 03 D7 \^?+* 2A 82 BC EE 24 02 = CD 16 03 D7 F9 27 83 CC
CD 16 03 D7 F9 27 83 CC \^?+* 41 23 EB 26 1B D9 = F9 27 83 CC 42 06 2E 3D
F9 27 83 CC 42 06 2E 3D \^?+* 89 DD 01 C6 28 AF = 42 06 2E 3D BA 91 01 F3
42 06 2E 3D BA 91 01 F3 \^?+* 42 63 65 60 10 A7 = BA 91 01 F3 CC 02 14 9C
BA 91 01 F3 CC 02 14 9C \^?+* 84 5D 48 31 71 8C = CC 02 14 9C 70 AC 4A 3D
CC 02 14 9C 70 AC 4A 3D \^?+* 18 72 74 4B 23 1C = 70 AC 4A 3D 2F CA EC 93
70 AC 4A 3D 2F CA EC 93 \^?+* 82 1A C8 D3 0C 11 = 2F CA EC 93 04 F5 B9 6F
2F CA EC 93 04 F5 B9 6F \^?+* BD 12 24 11 8B B1 = 04 F5 B9 6F 92 87 E4 25
04 F5 B9 6F 92 87 E4 25 \^?+* 68 E2 83 CD 68 02 = 92 87 E4 25 FE 5E 5D 3C
FE 5E 5D 3C 92 87 E4 25 finalization = 26 F0 7F 55 D5 4B 5C E8
26 F0 7F 55 D5 4B 5C E8 XOR 57 80 67 54 48 94 BA 08 = 71 70 18 01 9D DF E6 E0
Code = 7170

Stub Data = 57 80 67 54 48 94 BA 08 EEPROM Data = DE F8 08 FD 4C 71 94 1C
57 80 67 54 48 94 BA 08 XOR DE F8 08 FD 4C 71 94 1C = 89 78 6F A9 04 E5 2E 14
89 78 6F A9 04 E5 2E 14 initialization = 26 82 F4 2D 29 6E 4F 44
26 82 F4 2D 29 6E 4F 44 \^?+* 82 02 BB 82 5B F4 = 29 6E 4F 44 04 5A E8 0D
29 6E 4F 44 04 5A E8 0D \^?+* C3 8D 4A 39 44 32 = 04 5A E8 0D 35 1F 11 13
04 5A E8 0D 35 1F 11 13 \^?+* 4C F4 21 38 FF 10 = 35 1F 11 13 FA 77 C3 E3
35 1F 11 13 FA 77 C3 E3 \^?+* 42 2F 58 8A AE 68 = FA 77 C3 E3 AB 76 FE 6C
FA 77 C3 E3 AB 76 FE 6C \^?+* 8C 7C 04 D4 94 61 = AB 76 FE 6C D3 29 6C 91
AB 76 FE 6C D3 29 6C 91 \^?+* 22 2A 78 14 D2 CA = D3 29 6C 91 2E 9F 5B 88
D3 29 6C 91 2E 9F 5B 88 \^?+* 9C 18 0A EC 43 4E = 2E 9F 5B 88 44 4A 25 AE
2E 9F 5B 88 44 4A 25 AE \^?+* 2A 82 BC EE 24 02 = 44 4A 25 AE 18 8C E3 6D
44 4A 25 AE 18 8C E3 6D \^?+* 41 23 EB 26 1B D9 = 18 8C E3 6D FF C4 2A 05
18 8C E3 6D FF C4 2A 05 \^?+* 89 DD 01 C6 28 AF = FF C4 2A 05 4D F1 F0 5B
FF C4 2A 05 4D F1 F0 5B \^?+* 42 63 65 60 10 A7 = 4D F1 F0 5B 12 1D 29 B9
4D F1 F0 5B 12 1D 29 B9 \^?+* 84 5D 48 31 71 8C = 12 1D 29 B9 F7 58 33 48
12 1D 29 B9 F7 58 33 48 \^?+* 18 72 74 4B 23 1C = F7 58 33 48 70 6E D1 5E
F7 58 33 48 70 6E D1 5E \^?+* 82 1A C8 D3 0C 11 = 70 6E D1 5E A8 88 54 43
70 6E D1 5E A8 88 54 43 \^?+* BD 12 24 11 8B B1 = A8 88 54 43 BA 93 B8 E5
A8 88 54 43 BA 93 B8 E5 \^?+* 68 E2 83 CD 68 02 = BA 93 B8 E5 36 8E 15 1C
36 8E 15 1C BA 93 B8 E5 finalization = 26 F0 57 99 ED CA 02 BA
26 F0 57 99 ED CA 02 BA XOR 57 80 67 54 48 94 BA 08 = 71 70 30 CD A5 5E B8 B2
Code = 7170

Stub Data = 57 80 67 54 48 94 BA 08 EEPROM Data = 1B 57 B3 50 D2 A8 69 A3
57 80 67 54 48 94 BA 08 XOR 1B 57 B3 50 D2 A8 69 A3 = 4C D7 D4 04 9A 3C D3 AB
4C D7 D4 04 9A 3C D3 AB initialization = 47 76 2F C2 D6 A0 B1 D2
47 76 2F C2 D6 A0 B1 D2 \^?+* 82 02 BB 82 5B F4 = D6 A0 B1 D2 7D 8A 0C EA
D6 A0 B1 D2 7D 8A 0C EA \^?+* C3 8D 4A 39 44 32 = 7D 8A 0C EA 60 68 48 80
7D 8A 0C EA 60 68 48 80 \^?+* 4C F4 21 38 FF 10 = 60 68 48 80 A2 35 29 BE
60 68 48 80 A2 35 29 BE \^?+* 42 2F 58 8A AE 68 = A2 35 29 BE A7 D7 88 AB
A2 35 29 BE A7 D7 88 AB \^?+* 8C 7C 04 D4 94 61 = A7 D7 88 AB 7E 91 27 80
A7 D7 88 AB 7E 91 27 80 \^?+* 22 2A 78 14 D2 CA = 7E 91 27 80 8A D4 74 5B
7E 91 27 80 8A D4 74 5B \^?+* 9C 18 0A EC 43 4E = 8A D4 74 5B 2E 43 BA 8D
8A D4 74 5B 2E 43 BA 8D \^?+* 2A 82 BC EE 24 02 = 2E 43 BA 8D 39 AC EE E0
2E 43 BA 8D 39 AC EE E0 \^?+* 41 23 EB 26 1B D9 = 39 AC EE E0 9C FB D9 1B
39 AC EE E0 9C FB D9 1B \^?+* 89 DD 01 C6 28 AF = 9C FB D9 1B 7E 7C B5 11
9C FB D9 1B 7E 7C B5 11 \^?+* 42 63 65 60 10 A7 = 7E 7C B5 11 96 7F 61 B1
7E 7C B5 11 96 7F 61 B1 \^?+* 84 5D 48 31 71 8C = 96 7F 61 B1 36 18 4A 74
96 7F 61 B1 36 18 4A 74 \^?+* 18 72 74 4B 23 1C = 36 18 4A 74 F9 B5 97 EC
36 18 4A 74 F9 B5 97 EC \^?+* 82 1A C8 D3 0C 11 = F9 B5 97 EC C0 DB 9B 02
F9 B5 97 EC C0 DB 9B 02 \^?+* BD 12 24 11 8B B1 = C0 DB 9B 02 52 4F 64 ED
C0 DB 9B 02 52 4F 64 ED \^?+* 68 E2 83 CD 68 02 = 52 4F 64 ED D6 1E 05 F4
D6 1E 05 F4 52 4F 64 ED finalization = 26 F0 7F 32 D1 0B EB 43
26 F0 7F 32 D1 0B EB 43 XOR 57 80 67 54 48 94 BA 08 = 71 70 18 66 99 9F 51 4B
Code = 7170

[Dunker]

And to mobilart, thanks for the 689 dumps, the results are:

Stub Data = AD A0 55 5C C8 20 D6 F8 EEPROM Data = 3E D4 C2 F1 A0 A9 E5 5E
AD A0 55 5C C8 20 D6 F8 XOR 3E D4 C2 F1 A0 A9 E5 5E = 93 74 97 AD 68 89 33 A6
93 74 97 AD 68 89 33 A6 initialization = 12 47 8E 6D AD DA 38 C5
12 47 8E 6D AD DA 38 C5 \^?+* D8 1F D3 C2 5C 50 = AD DA 38 C5 3D A5 3D 4F
AD DA 38 C5 3D A5 3D 4F \^?+* B6 90 CF 24 46 78 = 3D A5 3D 4F 68 3A F6 9A
3D A5 3D 4F 68 3A F6 9A \^?+* 6D 93 BE CC F9 02 = 68 3A F6 9A E3 5D E1 B2
68 3A F6 9A E3 5D E1 B2 \^?+* DB C6 13 2A 04 6A = E3 5D E1 B2 0C 1F 05 FF
E3 5D E1 B2 0C 1F 05 FF \^?+* F6 A5 E5 74 F5 01 = 0C 1F 05 FF DB 22 E8 F2
0C 1F 05 FF DB 22 E8 F2 \^?+* 65 7D B2 0A A2 CA = DB 22 E8 F2 82 42 CC 0F
DB 22 E8 F2 82 42 CC 0F \^?+* 11 EE 57 F4 05 45 = 82 42 CC 0F E9 C3 E8 F9
82 42 CC 0F E9 C3 E8 F9 \^?+* E0 B9 CD 16 A2 82 = E9 C3 E8 F9 8C 1C 56 BD
E9 C3 E8 F9 8C 1C 56 BD \^?+* 37 BA A8 67 0B 80 = 8C 1C 56 BD 69 FA 44 DE
8C 1C 56 BD 69 FA 44 DE \^?+* FD 0A 97 93 20 37 = 69 FA 44 DE 2A C3 8A 6C
69 FA 44 DE 2A C3 8A 6C \^?+* 83 85 BF 20 1B 91 = 2A C3 8A 6C F6 79 70 47
2A C3 8A 6C F6 79 70 47 \^?+* 7D E1 29 93 68 AC = F6 79 70 47 29 0A 04 A6
F6 79 70 47 29 0A 04 A6 \^?+* 7A 4D D7 48 12 35 = 29 0A 04 A6 82 6E DC 11
29 0A 04 A6 82 6E DC 11 \^?+* 07 F5 C6 91 5C 88 = 82 6E DC 11 11 69 E0 7D
82 6E DC 11 11 69 E0 7D \^?+* 75 FA 59 49 83 3C = 11 69 E0 7D D7 86 4D 2B
11 69 E0 7D D7 86 4D 2B \^?+* 3B 4A 72 D9 98 42 = D7 86 4D 2B 21 C2 95 D7
21 C2 95 D7 D7 86 4D 2B finalization = CF B3 AD 0A 85 42 99 B5
CF B3 AD 0A 85 42 99 B5 XOR AD A0 55 5C C8 20 D6 F8 = 62 13 F8 56 4D 62 4F 4D
Code = 6213

Stub Data = 7A F0 40 71 A0 B4 BD A0 EEPROM Data = FA 61 F5 A1 A1 9C FE 4C
7A F0 40 71 A0 B4 BD A0 XOR FA 61 F5 A1 A1 9C FE 4C = 80 91 B5 D0 01 28 43 EC
80 91 B5 D0 01 28 43 EC initialization = C8 0E 84 56 8F A4 A0 40
C8 0E 84 56 8F A4 A0 40 \^?+* DA AD BF 44 03 64 = 8F A4 A0 40 92 4C D2 AF
8F A4 A0 40 92 4C D2 AF \^?+* D7 A5 6D 19 03 42 = 92 4C D2 AF 44 F8 08 C4
92 4C D2 AF 44 F8 08 C4 \^?+* 5C 7D BD A6 07 10 = 44 F8 08 C4 83 ED FE 1B
44 F8 08 C4 83 ED FE 1B \^?+* 1B 6F D4 82 A8 03 = 83 ED FE 1B 8E B6 CE 4F
83 ED FE 1B 8E B6 CE 4F \^?+* B7 78 CD 20 40 E1 = 8E B6 CE 4F BB 88 FF 47
8E B6 CE 4F BB 88 FF 47 \^?+* 3D 1B FB 1C 70 84 = BB 88 FF 47 6D D8 81 05
BB 88 FF 47 6D D8 81 05 \^?+* 9B D3 9B 08 06 0E = 6D D8 81 05 53 C5 9C 03
6D D8 81 05 53 C5 9C 03 \^?+* EF C3 ED F1 84 00 = 53 C5 9C 03 5B 50 E7 21
53 C5 9C 03 5B 50 E7 21 \^?+* 4F F3 3B C0 02 59 = 5B 50 E7 21 2F CB CB F0
5B 50 E7 21 2F CB CB F0 \^?+* EE CF 55 C5 08 80 = 2F CB CB F0 BF 66 FA D1
2F CB CB F0 BF 66 FA D1 \^?+* E6 75 76 00 41 36 = BF 66 FA D1 F9 2D FA 44
BF 66 FA D1 F9 2D FA 44 \^?+* 34 FE 7A 2A 59 00 = F9 2D FA 44 75 9C FC CD
F9 2D FA 44 75 9C FC CD \^?+* F8 BA D6 0B 24 29 = 75 9C FC CD E4 3D F9 2A
75 9C FC CD E4 3D F9 2A \^?+* E3 9E AE 40 94 91 = E4 3D F9 2A 1E 40 3A C8
E4 3D F9 2A 1E 40 3A C8 \^?+* FD A6 2B 10 88 CC = 1E 40 3A C8 1B 25 39 88
1E 40 3A C8 1B 25 39 88 \^?+* CB CE A7 54 C0 00 = 1B 25 39 88 E5 4A CB 83
E5 4A CB 83 1B 25 39 88 finalization = ED 95 60 9E 88 68 54 47
ED 95 60 9E 88 68 54 47 XOR 7A F0 40 71 A0 B4 BD A0 = 97 65 20 EF 28 DC E9 E7
Code = 9765

That should do for the 689 for now.

Interestingly the no-code dump produces : B08D

I'll have to look into that one.

[alexics]

So Ford have been real F***ers then.

[Dunker]

Oh yes ...

The above three results are my original 7170 dump plus two consecutive code entries.

There are so many avenues to follow here. I'm gonna go for the opposite of what I've sussed so far and reverse the EEPROM data generation algo. I know how it all works now (bold statement) so a maybe another couple of days at it and I might have summat - when I do actually get a couple of days like ... But then again, beer is a marvellous chariot - and at this moment in time I am Ben Hur.

[alexics]

This weekend I am going to finish the arm disassembler. I will produce a full disassembly and try to add some comments.

[alexics]

In the 689 have you located the address of the buffer where the eeprom data is stored after being read in from the eeprom? On the other type the code can be deactivated and I want to see if it is possible to disable the code on this one.

[Dunker]

I've not got a 689 now - need to get another to mess with. But I'm sure it was very close to where it is on a 288 on the stack.

[alexics]

Got the disassembler so far and had to stop. I can configure it to disassemble in blocks and indicate which mode to use, Arm, thumb or auto detect.

[alexics]

I'm thinking of building in an emulator. I will have to see how much effort it would be. The trouble is you get into counting clock cycles and simulating interrupts. Then there is any external signals to worry about.

[Dunker]

I've had an hour or two tonight looking at what happens just after the eeprom is read. A lot of the data from the stub data section (including stuff from the sticker on the set) is sent through the same processing procedure as the eeprom data decryption. The only difference being that each 8 bytes produced is XOR'd with the new 8 bytes of data to be fed into the procedure (what I have previously posted in this thread is a single procedure). The stub data is as usual 57 80 67 54 48 94 BA 08.

0x3FCC 46 44 56 32 30 30 37 56 ("FDV2007V") processed with the STUB DATA produces 2D FD C4 37 B6 8A 35 07

the next data is 0x3FD4 31 30 30 30 34 32 00 00 ("100042.."), this is XOR'd with the previous result 2D FD C4 37 B6 8A 35 07 which gives:

1C CD F4 07 82 B8 35 07 this is then processed with the STUB DATA and produces F7 4B 61 41 0A A5 7B 5E

the next data is 0x3FE4 36 43 31 54 2D 31 34 43 ("6C1T-14C"), this is XOR'd with the previous result F7 4B 61 41 0A A5 7B 5E which gives:

C1 08 50 15 27 94 4F 1D this is then processed with the STUB DATA and produces DA A7 67 51 11 01 42 5E


This carries on a few times introducing other 8 byte values from the stub data section (including the rest of the part number "-230-AG.."). The overall process then jumps into decrypting the 8 bytes from the eeprom data and produces the code. Now I'm just thinking out loud here but I dont suppose anyone knows what data the bar code on the sticker holds before I build a bar code reader. I could do with knowing exactly what the bar code data on the sticker is.

[alexics]

I have the configuration options sorted.

[Dunker]

If anyones a bit bored and need something to chew on, here's a little info on the process that occurs before the code is decrypted from the data in the EEPROM

Data0, Data1 and Data2 are passed to a complex algorithm that contains lookup table key generation and table lookup and data processing functions that produce the Data3 result.

Stub Data in MCU:
3FB0 02 04 05 01 30 36 4D 59 20 58 43 61 72 20 50 42 ....06MY XCar PB
3FC0 4C 20 76 30 32 2D 30 34 2D 30 35 00 46 44 56 32 L v02-04-05.FDV2
3FD0 30 30 37 56 31 30 30 30 34 32 00 00 57 80 67 54 007V100042..W.gT
3FE0 48 94 BA 08 36 43 31 54 2D 31 34 43 32 33 30 2D H.?.6C1T-14C230-
3FF0 41 47 00 00 00 00 00 00 00 00 00 00 7F FF FF FF AG...........???

EEPROM Data:
0140 FF FF FF FF FF FF FF FF FF FF FF FF 89 A6 D6 BF ?????????????***
0150 7D 68 45 2C 4D 35 33 34 31 32 5F 5F 5F 5F 5F 5F }hE,M53412______
0160 5F 5F 5F 5F 5F FF FF FF FF FF FF FF FF FF FF FF _____???????????
0170 FF FF 00 00 00 02 AA 61 8D 29 74 8F FF FF FF FF ?? ?a)t??????
0180 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ????????????????

First using data from the Stub section in the MCU:

Data0 = 46 44 56 32 30 30 37 56 from 0x3FCC (stub)
Data1 = 00 00 00 00 00 00 00 00
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := 2D FD C4 37 B6 8A 35 07

Data0 = 31 30 30 30 34 32 00 00 from 0x3FD4 (stub)
Data1 = 2D FD C4 37 B6 8A 35 07 from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := F7 4B 61 41 0A A5 7B 5E

Data0 = 36 43 31 54 2D 31 34 43 from 0x3FE4 (stub)
Data1 = F7 4B 61 41 0A A5 7B 5E from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := DA A7 67 51 11 01 42 5E

Data0 = 32 33 30 2D 41 47 00 00 from 0x3FEC (stub)
Data1 = DA A7 67 51 11 01 42 5E from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := 9E 94 4C 7C 6C E6 55 56

Data0 = 00 00 00 00 00 00 00 00 from 0x3FF4 (stub)
Data1 = 9E 94 4C 7C 6C E6 55 56 from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := 3A 9E F9 36 9C A7 60 19 <<< important result for checksum generation

Now using data from the Stub and the EEPROM:

Data0 = 89 A6 D6 BF 7D 68 45 2C from 0x14C (eeprom)
Data1 = 3A 9E F9 36 9C A7 60 19 from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := FB 6B CA 84 32 64 75 A3

Data0 = 4D 35 33 34 31 32 5F 5F from 0x154 (eeprom)
Data1 = FB 6B CA 84 32 64 75 A3 from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := AE B7 7A 28 62 9F E0 C5

Data0 = 5F 5F 5F 5F 5F 5F 5F 5F from 0x15C (eeprom)
Data1 = AE B7 7A 28 62 9F E0 C5 from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := 3B 69 84 4F D9 60 4F B8

Data0 = 5F FF FF FF FF FF FF FF from 0x164 (eeprom)
Data1 = 3B 69 84 4F D9 60 4F B8 from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := C0 E0 F7 EC EB 34 78 52

Data0 = FF FF FF FF FF FF 00 00 (1st 6 from 0x16C eeprom then last 2 in seperate routine (why?) from 0x172 eeprom)
Data1 = C0 E0 F7 EC EB 34 78 52 from above
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := 7E AF 72 73 AA 61 8D 29

The last 4 bytes of Data3 now contain the 4 bytes from 0x176 in the eeprom. These are now compared and if they match then the 8 bytes @ 0x14C are used again with the stub data @ 0x3FDC in to produce the code, ie:

Data0 = 89 A6 D6 BF 7D 68 45 2C
Data1 = 00 00 00 00 00 00 00 00
Data2 = 57 80 67 54 48 94 BA 08
Data3 := 71 70 18 01 9D DF E6 E0

Code = 7170

Obviously the stub data is the key and in particular the 8 bytes @ 0x3FDC

[alexics]

Got most of the ARM disassembly done. I will be sorting the thumb part this week.

[alexics]

The mechanism used to change the encryption sequence must be somewhere in the TMS. Are there any software interrupt calls in the decryption routines? Have you looked at the routines used to re-encrypt the data after entry of the code?

[alexics]

The mechanism used to change the encryption sequence must be somewhere in the TMS. Are there any software interrupt calls in the decryption routines? Have you looked at the routines used to re-encrypt the data after entry of the code?

The ideal solution would be to identify this data and start from there.

[Dunker]

There are no interrupts in the routines. As for the re-encryption, I need to see where the code entry routine is and see where a good code or bad code branches to. Although, hopefully it will use the same compare routine that the checksum part uses - that will give me a point of entry so to speak. The function call addresses are likely to be on the stack though but I know how that all works, so it (should) be just a matter of time (which is limited a bit for me at the moment).

I have the stub data/eeprom manipulation routines running under perl in linux and I'm gonna first add a little to that so I can feed any stub/eeprom data into it from a text file so I can compare the data it spits out all through the sequence. Just to see if theres anything that will give a clue about the stub bytes @ 0x3FDC.

[alexics]

The arm stuff is about 90% done but I'm still bug checking. Then I'll do the thumb stuff and take a proper look at commenting the code.

Here is a screenshot of progress so far.

[alexics]

This doesn't include the register write backs yet.

[alexics]

I am assuming that data1 in each process below is not actually all zeroes in reality?? Otherwise you would always get the same pattern.

Data0 = 46 44 56 32 30 30 37 56 from 0x3FCC (stub)
Data1 = 00 00 00 00 00 00 00 00
Data2 = 57 80 67 54 48 94 BA 08 from 0x3FDC (stub)
Data3 := 2D FD C4 37 B6 8A 35 07

Data0 = 89 A6 D6 BF 7D 68 45 2C
Data1 = 00 00 00 00 00 00 00 00
Data2 = 57 80 67 54 48 94 BA 08
Data3 := 71 70 18 01 9D DF E6 E0

[Dunker]

In those two iterations the data01 is all zeros. Both are set to zeros by the program and do not change.

I have sussed that the lookup tables must be in pairs as well. If you feed 8 bytes of data through the initialization process and then feed the result back to the same process using a different lookup table you get the initial bytes back. I need more time and less beer.

[Totaldecodes]

This ford radio's have been cracked icsystems in scotland so now no need to scratch our heads just follow the leaders.

[alexics]

When I get the thumb code done I can send you a full disassembly if it would help at all. It would help me if you could identify any bugs in the disassembler.

[alexics]

This ford radio's have been cracked icsystems in scotland so now no need to scratch our heads just follow the leaders.

This is just for fun! Its good to see how things actually work.

[Dunker]

Following Martech then :joyman:

[Totaldecodes]

But this can not only give you code but also remove the locked issue as Martech can only give you the code. At least that is a start not giving there customers run around saying its sorted.:party:




Following Martech then :joyman:

[Dunker]

Who said anything about it being sorted, although any halfwit with 50 quid to spend on a Segger can decode/unlock/change code on a TMS V series. I suppose quarterwits can spend more on other gear to do em though.

[alexics]

And of course it's soooo difficult to get a code via the serial number.

[alexics]

@DUNKER Have you tried saving an unlocked dump, locking up the set to say attempt 3 and then writing the unlocked dump straight back. On the ones I've tried this unlocks them. So the random data in the MCU must be linked to the lock level. If you write in the unlocked one it must re-initialise the process. What about when you have the 'LOCKED' state? Does writing the unlocked dump work then too? Can you put a set into LOCKED state yet?

[alexics]

BTW I should have my own version of JTAG finished soon. I have all of the bit patterns for the debugger (ICE Breaker).

[Dunker]

Basically you can write any dump back to eeprom and it will give you the state when the dump was taken.

IE. If you write a fully unlocked dump back to a set that now has a count of 3 it will go back to 0.

Also, if you have a wrong checksum (or generally incorrect code data) in the eeprom it will kill the set - IE. "LOCKED"

But as above, writing a previously unlocked dump to eeprom will unlock it.

(All eeprom dumps obviously have to be taken from that particular radio).

[alexics]

I will have my own JTAG done in a couple of weeks and I'll try a few experiments. Have you tried changing the 8 bytes in the stub between versions to see what happens? I'm not thinking it is going to work, just would like to know if you get LOCKED on the display.

[Dunker]

I havent changed the 8 bytes @ 0x3FDC in the MCU but I am 99.99% certain that it will be ok to do so if the eeprom data matches it. Obviously just changing the 8 bytes without altering the eeprom will give you locked. Although, I have the checksum part sorted so altering a branch instruction in the code would bypass locked I would imagine. I've looked at most of the code and there are no sanity checks on any data in the stub.

[alexics]

I think because of the separate 4 byte checksum you would need to copy all the stub data. What would be more interesting would be to find a point of origin for generation of the eeprom data. There must be a starting point. This will be the pattern first programmed into the radio to start the process off. Once this is found you would be able to generate the data for any code. I am assuming that the six bytes after the code would be in an 'unencrypted' format at that point.

What puzzles me is how the 4 byte checksum changes each time. I can understand why the 8 bytes change. Is it a random process? If so where is the random elements stored?

[alexics]

Do you know what the table at 43AE0 is for? It looks suspiciously like a conversion table for nibble values.

[Dunker]

I can't see anything @ 0x43AE0, but maybe you have a different software version to the MCU I'm messing with. The tables are definately the same between different MCU's (and in different places) so I would guess you are looking at the data that starts:

0E 04 0D 01 02 0F 0B 08 03 0A 06 0C 05 09 00 07

If so, then that is actually the 2nd one of a set of 8 separate lookup tables :s:

[alexics]

I can't see anything @ 0x43AE0, but maybe you have a different software version to the MCU I'm messing with. The tables are definately the same between different MCU's (and in different places) so I would guess you are looking at the data that starts:

0E 04 0D 01 02 0F 0B 08 03 0A 06 0C 05 09 00 07

If so, then that is actually the 2nd one of a set of 8 separate lookup tables :s:




Yes that's the one. I'm just finishing the thumb disassembler so I should be able to look into it more once that's finished.

[Dunker]

And just to muddy the waters a little more...

There's another checksum in the eeprom data. In addition to the first checksum I confirmed, I've found 30 bytes from the eeprom that are processed using two lookup tables and a bit of crypto to produce two further checksum bytes. I don't know the significance of these yet (so far it looks like its there to just check if the eeprom data has been altered - although I dont believe that for a second).

Anyway, the pink data has the light blue checksum. And now, the green data has the yellow checksum. See the attached image. I do wish I had more that an hour or two a week to look at this. Ah well...

[Dunker]

And if you're a gluten for punishment and fancy figuring it out...

4D, FFFF => 7899 35, 7899 => 0069 33, 0069 => 6F30 34, 6F30 => DB9E 31, DB9E => C264 32, C29E => 8B1F
5F, 8B1F => 94F9 5F, 94F9 => 9127 5F, 9127 => 1F82 5F, 1F82 => C4CA 5F, C4CA => 171C 5F, 171C => D5CC
down to the last 6 iterations:
FF, 17C8 => B426 FF, B426 => DFAF FF, DFAF => 8B62 FF, 8B62 => 5C13 FF, 5C13 => 9689 FF, 9689 => 748F

(the FFFF at the start looks like a constant provided by the MCU and is read from MCU memory).

[alexics]

And just to muddy the waters a little more...

There's another checksum in the eeprom data. In addition to the first checksum I confirmed, I've found 30 bytes from the eeprom that are processed using two lookup tables and a bit of crypto to produce two further checksum bytes. I don't know the significance of these yet (so far it looks like its there to just check if the eeprom data has been altered - although I dont believe that for a second).

Anyway, the pink data has the light blue checksum. And now, the green data has the yellow checksum. See the attached image. I do wish I had more that an hour or two a week to look at this. Ah well...

I have never seen the yellow checksums change. These are sometimes FF FF.

[Dunker]

I havent. I think its just a check to see if the eeprom data has been messed with unless its something on another algo - Z series? . I suppose it cant be implemented on the ones that have FFFF there.

[alexics]

The random element has to be in Data3

Data3 := 71 70 18 01 9D DF E6 E0

Excluding the code we are left with: 18 01 9D DF E6 E0

How does this change after code entry? Is there a particular sequence? Also what happens if you run the process backwards to produce the eeprom data with the pattern:

71 70 18 01 FF FF FF FF

I would assume the set would say LOCKED.

[Dunker]

You will struggle to run the process backwards as such. Its a kind of one way hash. Saying that I know that the initialisation table routine is reversible by feeding its result straight into the finalisation routine (missing out the stages in between) to get the initial data back out. Maybe the other tables are linked in the same way - there are an awful lot of permutations to work through. And maybe the corresponding tables are not in the MCU at all.

Someone somewhere thats into crypto will probably know what sort of thing this is - ie. like is it PGP type stuff or whatever. It would be nice to know. I've been reading up on various crypto stuff but nothing seems that similar - and there's no way this has just been invented for these V series radios.

[alexics]

Seems as though its an MD5 type hash.

[alexics]

I have found 17 table offsets stored in memory but not identified the points at which they are loaded yet. They point to what look like the encryption tables.

[alexics]

I've mapped out the 8 64 byte tables. I have also gone through all the arm code just to see what it might be doing and it gets very weird at some points. Blocks of arm code just appear within data or code sections and the subroutine returns are inventive to say the least.

[alexics]

I now have the disassembler distinguishing between data and code. I also have the stack instructions sorted but need to check the syntax for write backs etc.

[simplus]

to test the.

Model: SINGLE CD-KW2000
PART no: 6S61-18C815-AH
Serial no: V020367

PROC. TMS470AVF689APZA
EEPROM M520 (5pin) = 24C16

TMS470:
3FB0-02 02 02 30 36 4D 59 20 58 43 61 72 20 50 42 4C
3FC0-20 76 30 32 2D 30 32 2D 30 32 00 00 46 44 42 32
3FD0-30 30 37 56 30 32 30 33 36 37 00 00 6C 20 77 57
3FE0-38 AA B6 3B 36 53 36 31 18 0C 08 15 00 07 00 00
3FF0-36 37 00 00 6C 00 00 00 00 00 00 00 FF FF FF FF


24C16 COUNTER 00 :
0140-FF FF FF FF FF FF FF FF FF FF FF FF 17 97 27 28
0150-B0 41 66 BD 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0160-5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0170-5F 00 00 00 00 02 AC 55 69 95 FF FF FF FF FF FF

24C16 COUNTER LOCKED :
0140-FF FF FF FF FF FF FF FF FF FF FF FF 6C 9B CD 04
0150-5D 27 A6 A0 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0160-5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0170-5F 00 0A 00 00 03 15 65 33 E2 FF FF FF FF FF FF

[Dunker]

I've re-written a bit of code to load the stub and eeprom data sections from copy and pasted text. Here are the results of a few of the dumps I hve been working with:


# stub data @ 0x3FB0 OK
02 04 05 01 30 36 4D 59 20 58 43 61 72 20 50 42
4C 20 76 30 32 2D 30 34 2D 30 35 00 46 44 56 32
30 30 37 56 31 30 30 30 34 32 00 00 57 80 67 54
48 94 BA 08 36 43 31 54 2D 31 34 43 32 33 30 2D
41 47 00 00 00 00 00 00 00 00 00 00 7F FF FF FF

# eeprom data @ 0x140 OK
FF FF FF FF FF FF FF FF FF FF FF FF 89 A6 D6 BF
7D 68 45 2C 4D 35 33 34 31 32 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F FF FF FF FF FF FF FF FF FF FF FF
FF FF 00 00 00 02 AA 61 8D 29 74 8F FF FF FF FF

Checksum:
r1 Data := 7E AF 72 73 AA 61 8D 29
Compared with EEPROM: AA 61 8D 29

Code:
r1 Data := 71 70 18 01 9D DF E6 E0
Code = 71 70

================================================

# stubdata @ 0x3FB0 OK
02 04 09 01 30 36 4D 59 20 58 43 61 72 20 50 42
4C 20 76 30 32 2D 30 34 2D 30 39 00 46 44 56 32
30 30 42 56 30 39 31 38 39 39 00 00 A9 79 59 59
80 84 61 F9 38 43 31 54 2D 31 34 43 32 33 30 2D
41 42 00 00 00 00 00 00 00 00 00 00 7F FF FF FF

# eepdata @ 0x140 OK
FF FF FF FF FF FF FF FF FF FF FF FF 15 50 E6 EB
19 C2 86 2E 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 00 0A 00 00 03 0A 7B 29 70 FF FF FF FF FF FF

Checksum:
r1 Data := 2E 87 A0 1F 0A 7B 29 70
Compared with EEPROM: 0A 7B 29 70

Code:
r1 Data := 53 85 30 66 6D 5C 52 4C
Code = 53 85

================================================

# stubdata @ 0x3FB0 OK
02 04 05 01 30 36 4D 59 20 58 43 61 72 20 50 42
4C 20 76 30 32 2D 30 34 2D 30 35 00 46 44 43 32
30 30 38 56 30 39 33 31 38 36 00 00 71 10 85 6C
A0 9F ED EA 37 53 37 54 2D 31 34 43 32 33 30 2D
42 41 00 00 00 00 00 00 00 00 00 00 7F FF FF FF

# eepdata @ 0x140 OK
FF FF FF FF FF FF FF FF FF FF FF FF 3F 3F 24 2B
71 23 B0 F1 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 00 00 00 00 02 21 21 96 2D FF FF FF FF FF FF

Checksum:
r1 Data := 67 C9 2B B6 21 21 96 2D
Compared with EEPROM: 21 21 96 2D

Code:
r1 Data := 57 90 B8 B0 C7 6C 9B 95
Code = 57 90

================================================

# stubdata 689 @ 0x3FB0 OK
02 02 02 30 36 4D 59 20 58 43 61 72 20 50 42 4C
20 76 30 32 2D 30 32 2D 30 32 00 00 46 44 56 32
30 30 36 56 30 31 31 39 33 31 00 00 AD A0 55 5C
C8 20 D6 F8 36 43 31 54 2D 31 34 43 32 33 30 2D
41 46 00 00 00 00 00 00 00 00 00 00 7F FF FF FF

# eepdata 689 @ 0x140 OK
FF FF FF FF FF FF FF FF FF FF FF FF 3E D4 C2 F1
A0 A9 E5 5E 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 00 00 00 00 02 E6 30 11 EE FF FF FF FF FF FF

Checksum:
r1 Data := 40 F1 43 D7 E6 30 11 EE
Compared with EEPROM: E6 30 11 EE

Code:
r1 Data := 62 13 F8 56 4D 62 4F 4D
Code = 62 13

================================================

# stubdata 689 @ 0x3FB0 OK
02 01 08 30 36 4D 59 20 58 43 61 72 20 50 42 4C
20 76 30 32 2D 30 31 2D 30 38 00 00 46 44 43 32
30 30 36 56 30 31 32 35 33 33 20 20 7A F0 40 71
A0 B4 BD A0 36 4D 32 54 2D 31 34 43 32 33 30 2D
41 45 20 00 00 00 00 00 00 00 00 00 7F FF FF FF

# eepdata 689 @ 0x140 OK
FF FF FF FF FF FF FF FF FF FF FF FF FA 61 F5 A1
A1 9C FE 4C 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 00 03 00 00 02 74 07 58 20 FF FF FF FF FF FF

Checksum:
r1 Data := AA BB 62 D4 74 07 58 20
Compared with EEPROM: 74 07 58 20

Code:
r1 Data := 97 65 20 EF 28 DC E9 E7
Code = 97 65


In reply to the above post ...


# stub data @ 0x3FB0 "simplus" code 1218 checksum bad
02 02 02 30 36 4D 59 20 58 43 61 72 20 50 42 4C
20 76 30 32 2D 30 32 2D 30 32 00 00 46 44 42 32
30 30 37 56 30 32 30 33 36 37 00 00 6C 20 77 57
38 AA B6 3B 36 53 36 31 18 0C 08 15 00 07 00 00
36 37 00 00 6C 00 00 00 00 00 00 00 FF FF FF FF

# eepdata @ 0x140 "simplus" code 1218 checksum bad
FF FF FF FF FF FF FF FF FF FF FF FF 17 97 27 28
B0 41 66 BD 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 00 00 00 00 02 AC 55 69 95 FF FF FF FF FF FF

Checksum:
r1 Data := E8 19 4D 2F 67 8E E6 28
Compared with EEPROM: AC 55 69 95

Code:
r1 Data := 12 18 48 61 87 4B 5B 59
Code = 12 18

The checksum calculated from the stub data and both eeprom data sections don't match, that would produce "LOCKED" on the display. So I'll pass on that one.

[alexics]

But of course simplus could 'fix' his dump if the correct data could be generated for his eeprom. What if he just writes the 4 byte checksum that you generated?

[simplus]

Hello, friends!
This FORD I did last year.
The code was actually 1218. I experimented with the EEPROM, and perhaps somewhere
there is an inaccuracy. That's what I kept in the archive
But I have not changed the code. Machine code.
Sorry for my English.

[Dunker]

But of course simplus could 'fix' his dump if the correct data could be generated for his eeprom. What if he just writes the 4 byte checksum that you generated?

I would imagine that it should work - er maybe. The MCU would get that far to check the checksum and then immediately generate the code and put that on the stack. The next bit is the second checksum generation (on my MCU anyway). I'm half on with the timer part and re-encryption part but I'm struggling for time what with everyone dragging me to the beer tent nearly every night.

[simplus]

After each input the correct code in the data
EEPROM change.
These data are repeated again?

[Dunker]

If you enter the code enough times it has to. I need to totally finish replicating the encryption routine and run it in a loop to find out how many iterations it would take. Looks like my quad processor machine will be smoking when its done. If I get time over Xmas I'll have a go.

[simplus]

Your studies are very useful!
This will allow the return of radio LOCKED
without overwriting TMS470 Flash!

[Dunker]

Definitely. Although, at this point, the TMS will still have to be read as the checksum is generated partly from data in the stub section. Like you say, at least it will remove the chance of causing problems due to reprogramming the MCU.

[fabi]

This tool repair locked without overwriting TMS470 Flash.
Ford 6000CD by Visteon car radios decoding tool by OBDII (http://www.codecard.lt/car-radio/ford-6000cd-by-visteon-car-radios-decoding-tool-by-obdii/prod_570.html)

[alexics]

Why do the instructions say "Solder missing TJA1040 (or simmilar (sic)) CAN tranceiver"? So you have to buy in stocks of a component Ford have REMOVED? Not so easy eh?

Obviously you wouldn't want to be soldering and desoldering a component over and over. You could also lift tracks if it all goes wrong.

[alexics]

Also if it is ease of use this is suggesting, i.e not having to strip the set down in any way, this is counter productive as you need to mess with the set anyway. What advantage do you get?

[simplus]

More interesting: The device does not require data
FLASH,all calculations are performed using data
from the EEPROM. It possible?

[fabi]

I have this tool and tested it.
If I change TMS dump then tool readed wrong code.

"Solder missing TJA1040 (or simmilar (sic)) CAN tranceiver" need only with ford 1500RDS carradio. This carradio is without CAN BUS.

[Dunker]

fabi is right, the CAN transceiver bit is just for that model I think. It was implemented in design etc. but not needed in production. Obviously the other radios have the chip in there or its a built in function.

Easy enough to see whats going on if you have one of these and a CAN bus sniffer. I dont have the interface (not needed - we can do these radios for a lot less money than that) I use the Erlasoft CAN bus analyser - cheap and cheerful but it does what I need for now.

[Dunker]

If you enter the code enough times it has to. I need to totally finish replicating the encryption routine and run it in a loop to find out how many iterations it would take. Looks like my quad processor machine will be smoking when its done. If I get time over Xmas I'll have a go.

Had a quick look tonight. At first glance I can see that the initial data feed into the encryption process uses values from the RTI counter. Looks like that will make it pretty random with regard to the eeprom data replicating itself.

[alexics]

Had a quick look tonight. At first glance I can see that the initial data feed into the encryption process uses values from the RTI counter. Looks like that will make it pretty random with regard to the eeprom data replicating itself.

How many bytes from the timer are used? One byte gives 256 combinations, two bytes gives 65536 and four bytes gives 4294967295. I'd like to see a repeating pattern in that algo.

The last timer capture must be saved to enable decryption of the current pattern. Somewhere there must be a flag to tell the system to regenerate from the RTI next time it needs to rewrite the code pattern. So possibly all that is needed is STUB data, eeprom data and the last RTI capture value.

[fukukum]

This tool repair locked without overwriting TMS470 Flash.
Ford 6000CD by Visteon car radios decoding tool by OBDII (http://www.codecard.lt/car-radio/ford-6000cd-by-visteon-car-radios-decoding-tool-by-obdii/prod_570.html)
FORD SONY TOOL reads wrong codes.:call:
CODECARD.LT - advanced tools for car electronic repair. (http://www.codecard.lt/ford-visteon-sony-tool/topic_2490.html)

[Dunker]

How many bytes from the timer are used? One byte gives 256 combinations, two bytes gives 65536 and four bytes gives 4294967295. I'd like to see a repeating pattern in that algo.


At the start of the algo the code is placed at the first two bytes out ouf 8:

ie. 71 70 xx xx xx xx xx xx

then the RTI is read and the 32 bit value is shifted and the last byte is added:

ie. 71 70 YY xx xx xx xx xx

the RTI is read again - and again - and again etc. and the algo fills the 8 bytes up using further shifts or direct byte copies to give:

71 70 YY YY YY YY YY YY

What I will say is that when the first RTI read is done it is easy to work the other RTI bytes used out as its just a case of counting the clock cycles, (RTI decrements - it goes backwards), for each following instruction cycle. Although this is totally immaterial as the first read is purely random - 12mHz Xtal combined with how long it took you to put the correct code in from power up. I'm pretty sure that ANY set of random 6 bytes here will do, so the RTI is just used as a random seed.

Then theres the rest of the encryption algo. This I will sort and clone on the PC later on, I know how that part works now. There's just the "LOCKED" timer to finalize, but now I can see where everything is heading its just time thats needed.

The only hard part - and we're gonna be bolloxed with it, is the stub section generation. If that can be figured then the keygen is easy. It is boxing day so I will probably go out and get shite faced and then maybe have a 'moment of clarity' :D

[alexics]

It all makes sense now. It is only the eeprom data that is critical. Surely a method of retrieving the stub data plus the eeprom data is all that is needed. As long as the lookup tables are static and unchanging you can generate any code. The stub generation is irrelevant. Probably produced at the factory and based on the V serial number and or part number.

[fabi]

FORD SONY TOOL reads wrong codes.:call:
CODECARD.LT - advanced tools for car electronic repair. (http://www.codecard.lt/ford-visteon-sony-tool/topic_2490.html)


Do you try newest software or old from www?

[Dunker]

It all makes sense now. It is only the eeprom data that is critical. Surely a method of retrieving the stub data plus the eeprom data is all that is needed. As long as the lookup tables are static and unchanging you can generate any code. The stub generation is irrelevant. Probably produced at the factory and based on the V serial number and or part number.

Exactly.

The stub data generation would be nice to know then a calculator would be extremely simple to write knowing all the algos involved. Hopefully I'll at least be able to generate eeprom data to unlock 'LOCKED' sets soon. I'm gonna try to sort most of it today.

[Dunker]

Right then, can someone post me some matching STUB data and EEPROM data in the following format:


STUB DATA:
3FB0 02 04 05 01 30 36 4D 59 20 58 43 61 72 20 50 42 ....06MY XCar PB
3FC0 4C 20 76 30 32 2D 30 34 2D 30 35 00 46 44 56 32 L v02-04-05.FDV2
3FD0 30 30 37 56 31 30 30 30 34 32 00 00 57 80 67 54 007V100042..W.gT
3FE0 48 94 BA 08 36 43 31 54 2D 31 34 43 32 33 30 2D H.?.6C1T-14C230-
3FF0 41 47 00 00 00 00 00 00 00 00 00 00 7F FF FF FF AG...........???

EEPROM Data:
0140 FF FF FF FF FF FF FF FF FF FF FF FF 89 A6 D6 BF ?????????????***
0150 7D 68 45 2C 4D 35 33 34 31 32 5F 5F 5F 5F 5F 5F }hE,M53412______
0160 5F 5F 5F 5F 5F FF FF FF FF FF FF FF FF FF FF FF _____???????????
0170 FF FF 00 00 00 02 AA 61 8D 29 74 8F FF FF FF FF ?? ?a)t??????

or better still:

STUB DATA:
02 04 05 01 30 36 4D 59 20 58 43 61 72 20 50 42
4C 20 76 30 32 2D 30 34 2D 30 35 00 46 44 56 32
30 30 37 56 31 30 30 30 34 32 00 00 57 80 67 54
48 94 BA 08 36 43 31 54 2D 31 34 43 32 33 30 2D
41 47 00 00 00 00 00 00 00 00 00 00 7F FF FF FF

EEPROM Data:
FF FF FF FF FF FF FF FF FF FF FF FF 89 A6 D6 BF
7D 68 45 2C 4D 35 33 34 31 32 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F FF FF FF FF FF FF FF FF FF FF FF
FF FF 00 00 00 02 AA 61 8D 29 74 8F FF FF FF FF



And, give me a code of their choice if they want. I will post just the modified eeprom data - with the new code encrypted if desired. I would have thought that eeprom data from a locked set would also work - that's assuming the eeprom data's 2nd checksum is valid. I could do with another set with a 689 MCU to test with - well, a set with the 2nd checksum bytes that are FF FF anyway. Her in doors wants me to go shopping now, I'll have a go with the 2nd checksum later on.

As for now, Perl code is modified and I can now generate eeprom data for any code from matching stub data and eeprom data that's either locked or clear. So now there's no need to write re-write to TMS470 - its just the eeprom that needs writing to.

[Dunker]

to test the.

Model: SINGLE CD-KW2000
PART no: 6S61-18C815-AH
Serial no: V020367

PROC. TMS470AVF689APZA
EEPROM M520 (5pin) = 24C16

TMS470:
3FB0-02 02 02 30 36 4D 59 20 58 43 61 72 20 50 42 4C
3FC0-20 76 30 32 2D 30 32 2D 30 32 00 00 46 44 42 32
3FD0-30 30 37 56 30 32 30 33 36 37 00 00 6C 20 77 57
3FE0-38 AA B6 3B 36 53 36 31 18 0C 08 15 00 07 00 00
3FF0-36 37 00 00 6C 00 00 00 00 00 00 00 FF FF FF FF


24C16 COUNTER 00 :
0140-FF FF FF FF FF FF FF FF FF FF FF FF 17 97 27 28
0150-B0 41 66 BD 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0160-5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0170-5F 00 00 00 00 02 AC 55 69 95 FF FF FF FF FF FF

24C16 COUNTER LOCKED :
0140-FF FF FF FF FF FF FF FF FF FF FF FF 6C 9B CD 04
0150-5D 27 A6 A0 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0160-5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
0170-5F 00 0A 00 00 03 15 65 33 E2 FF FF FF FF FF FF

This eeprom data should unlock your radio (code 1218):


FF FF FF FF FF FF FF FF FF FF FF FF 24 6A B3 09
E0 65 AD 5C 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F
5F 00 00 00 00 02 25 70 35 75 FF FF FF FF FF FF

[alexics]

And, give me a code of their choice if they want. I will post just the modified eeprom data - with the new code encrypted if desired. I would have thought that eeprom data from a locked set would also work - that's assuming the eeprom data's 2nd checksum is valid. I could do with another set with a 689 MCU to test with - well, a set with the 2nd checksum bytes that are FF FF anyway. Her in doors wants me to go shopping now, I'll have a go with the 2nd checksum later on.



I would assume that either new or old code pattern could be written back to the set and work. They should be interchangeable.

[Dunker]

Yes, any code can be encrypted to work with any eeprom data for a given stub section.

I've just modified the 8 code bytes and corresponding 4 checksum bytes from a 689 eeprom with a different code and written that to my test 288 radio eeprom and it works like a charm. So in theory I may only need the stub section and I can code up from any eeprom.

So there's just the stub to guess at now then.


Right, if nobody minds too much I'm off back to the pub :D

[simplus]

Unfortunately, I can not test your new
Calculation of data EEPROM. I unlocked the radio and
returned to the owner.

[bubik]

small tip!

When Tms dump serial number change radio display on the Locked!

[Dunker]

Already sorted. I can code eeprom data to match TMS data containing any serial (or any other stub data).

[alexics]

I am testing my JTAG code over the weekend. Does the stub data always appear at the same address in memory? If so I'll try to get stub and eeprom data for a test. I might be mad enough to attempt an eeprom read via JTAG.

[Dunker]

0x3FB0 is the stub data start as far as I know. Its only 5 lines anyway ;)

I do like the arrogance of the timer though. No processing, no encryption as such. Just a counter that is ignored until the checksum is generated.

Maybe the serial number (excluding the "V" - which we know about) is just a 6 byte sequence tagged to the two byte code and fiddled with to get the magical 0x3FDC 8 byte Grail.

[alexics]

Maybe the serial number (excluding the "V" - which we know about) is just a 6 byte sequence tagged to the two byte code and fiddled with to get the magical 0x3FDC 8 byte Grail.

I think you'll find that Ford aren't that helpful. The number 6 is probably not coincidental either. On one of the 3000s Ford had actually locked themselves out, clever shites. :roflmao:

[alexics]

According to the documentation the I2C base address is 0xFFF7D800. I haven't checked for any accesses to the I2C address range yet. It may help to look for these (if they are visible) as the routines to write back the pattern will be found by breakpointing at those points.

[alexics]

Please excuse me if I am talking Martian but does anyone know if setting the breakpoint mask to all Fs is valid and will it cause an immediate break. I am talking about both data and address masks.

[Dunker]

Pass.

If you need to break on I2C then you want to be looking at setting a breakpoint in the IRQ handler or maybe in one of the programs SWI calls.

[alexics]

I am only getting 4V on TDI, and TMS. The JTAG isn't returning any output. I seem to remember reading that pullup resistors are needed. 10K I seem to remember. Can anyone confirm?

[alexics]

OOPS! It's 3.3V. Frying tonight ....

[simplus]

There are other options in which the radio VISTEON EEPROM data change value only in line
00000170: .....

[alexics]

Has anyone got a 470 bsdl file? I have stupidly deleted mine and can't find the download source. TI doesn't even list the 470 anymore and I can't find another site.

[alexics]

I have the base address for the I2C port but not the register definitions. Does anyone know where I can get header files for the development kit for the 470. If I can get these I should be able to read the eeprom via JTAG. Then both the STUB and eeprom data would be available via JTAG.

[alexics]

I now have the 3.3V interface sorted. :-)

[radioman]

What interface is good for reading tms470? Wiggler is good or only JLink? Thanks

[Dunker]

If I were going to buy one now I'd be looking at the clone J-Link.

[ficho]

Hi,
Can sombody produce such data as Dunker did in he's post :
http://www.digital-kaos.co.uk/forums/f176/6000-cd-single-cd-kw2000-238144/index3.html#post1348446, the radio has it's eeprom content corrupt, so the radio displays locked.

MyData in MCU:

00003FB0 02 02 02 30 36 4D 59 20 58 43 61 72 20 50 42 4C ...06MY XCar PBL
00003FC0 20 76 30 32 2D 30 32 2D 30 32 00 00 46 44 42 32 v02-02-02..FDB2
00003FD0 30 30 37 56 31 32 38 33 35 37 00 00 51 60 68 6D 007V128357..Q`hm
00003FD0 A8 04 A8 DA 36 53 36 31 18 0C 08 15 00 07 00 00 ....6S61........
00003FF0 35 37 00 00 51 00 00 00 00 00 00 00 FF FF FF FF 57..Q...........

I want to check some functions that I have written:
sub_60044528(Dat1);
sub_60044536(0x3FCC, v4, 0x3FDC);
sub_60044536(0x3FD4, v4, 0x3FDC);
sub_60044536(0x3FE4, v4, 0x3FDC);
sub_60044536(0x3FEC, v4, 0x3FDC);
sub_60044536(0x3FF4, v4, 0x3FDC);

regards ficho

[Dunker]

Post the bin files for the MCU and corrupt eeprom.

[ficho]

Post the bin files for the MCU and corrupt eeprom.
Hi, I'm not shure which one of the flash file was the correct one ( maybe the second one), so I have attached 2 flash files and one eeprom content.

Regards ficho

[Dunker]

I think its the second flash file. Code is 0455. Try one of the attached eeprom files. If the 1st one works dont bother with the 2nd because it definitely wont.

[ficho]

Hi, Dunker

FlashHash : 65C05F68703CB357
EEpromHash: 15F163167E478CA5
EEprom CheckSum @ 0x176 D53B2AE3 OK!
Error Counter: 3
DeCrypted Code 0455.

FlashHash : 65C05F68703CB357
EEpromHash: 15F163167E478CA5
EEprom CheckSum @ 0x176 1F4CCBA1 OK!
Error Counter: 0
DeCrypted Code 0455.

FlashHash : 65C05F68703CB357
EEpromHash: 41F7A5CEDAFE6DE0
EEprom CheckSum @ 0x176 8D7B066D OK!
Error Counter: 0
DeCrypted Code 0455.



What will happen if ONLY Error Counter is reset to 00 and eeprom check is repaired at 0x176 will radio work normally ?? or data @ 0x178 must be changed also ?
when a invalid code entry is made normally counter should be increased and eeprom content at 0x178 changes and check is updated.

Regards Ficho

[Dunker]

The data at 0x178 is another checksum that doesnt appear to be used although it is calculated in the TMS program. Resetting the counter and generating the checksum @ 0x176 is all thats required. The TMS uses a totally randon set of bytes to start the hash for the 8 bytes @ 0x14C.

[ficho]

The data at 0x178 is another checksum ...
.
That was my mistake, I was thinking on 0x103078 in ram, copy of eeprom content from location 0x14c.
FlashHash + EEpromHash + ErrorCounter -> eepromcheck.
What happens when an invalid code or correct code is entered?
Error Counter should be reset or incremented then eeprom content @ 0x14C updated and checkData Updated.
This should go thru some sub but I havent found it out yet.

Regards Ficho

[Dunker]

To be fair I only went as far as I needed to go with it. Being able to generate a valid eeprom dump for a given locked set was all I was trying to do. What the second checksum is for I never went into at all. I reversed that algo for the fun of it but never took it any further. It all did take a bit of time and effort to reverse but it is do-able. A lot harder than just sniffing the TMS memory for the code and counter...

If it was a part of Calcgen it would be nice but thats up to carradio2001 I suppose.

[ficho]

Hi,
Dunker could you please check attached eeprom dumps if they fullfill criteria for a valid eeprom content related to the FlashStub I have attached.

Regards ficho

[Dunker]

EEPROM content is valid for that stub. Looks like you've cracked it :D

What we really need to do is figure out how the 8 bytes in the stub are generated. I would hope that algo is part of what we already have. I'm just too limited on time now.

[ficho]

EEPROM content is valid for that stub. Looks like you've cracked it :D

What we really need to do is figure out how the 8 bytes in the stub are generated. I would hope that algo is part of what we already have. I'm just too limited on time now.
Hi,
Thanks Dunker, yes that part would be interesting to see if it can be found. Also reading needed content via CAN BUS, but it's time consuming. Will let you know if any info pops up.

Regards ficho