Vida CEM swapping

[vtl]

Part Number: 30795115
Candidate PIN 94 53 06 -- -- -- : brute forcing bytes 3 to 5 (3 bytes), will take up to 640 seconds


first two ok, third - no

94 53 85 25 40 55

Thanks. Do you have a dump for that CEM?

ATTACHED

Yeah, I'm able to reproduce it. Funny, the right byte is 85 and it has the lowest STD.

best candidates ordered by latency:
0: 40 lat = 262719
1: 04 lat = 262702
2: 05 lat = 262699
3: 03 lat = 262698
4: 20 lat = 262660
...
95: 65 lat = 261929
96: 69 lat = 261899
97: 91 lat = 261887
98: 35 lat = 261879
99: 21 lat = 261851

best candidates ordered by std:
0: 42 std = 481.29
1: 01 std = 478.95
2: 11 std = 478.30
3: 97 std = 478.28
4: 35 std = 478.22
...
95: 30 std = 472.41
96: 02 std = 472.26
97: 90 std = 471.55
98: 80 std = 471.24
99: 85 std = 469.19

lat_k 0.01%, std_k 0.49%
pin[2] choose candidate: 42 based on std

[vtl]

Pushed new change to the "lowest_std" branch, check it out (@solitaire and @RickHaleParker).

CPU Maximum Frequency: 600000000
CPU Frequency: 600000000
Execution Rate: 600 cycles/us
PIN bytes to measure: 3
Number of samples: 30
CAN low-speed init done.
Can't find part number on CAN-LS, trying CAN-HS at 500 Kbps
CAN high-speed init done.
Putting all ECUs into programming mode.
CAN_HS ---> ID=000ffffe data=ff 86 00 00 00 00 00 00
CAN_LS ---> ID=000ffffe data=ff 86 00 00 00 00 00 00
Reading part number from ECU 0x50 on CAN_HS
CAN_HS ---> ID=000ffffe data=50 88 00 00 00 00 00 00
CAN_HS <--- ID=00000003 data=50 8e 00 00 30 79 51 15
Part Number: 30795115
Searching P/N 30795115 in 49 known CEMs
CAN HS baud rate: 500000
PIN shuffle order: 3 1 5 0 2 4
Putting all ECUs into programming mode.
CAN_HS ---> ID=000ffffe data=ff 86 00 00 00 00 00 00
CAN_LS ---> ID=000ffffe data=ff 86 00 00 00 00 00 00
Initialization done.

Calculating bytes 0-2
1000 pins in 640 ms, 1562 pins/s, average response: 86 us, histogram 43 to 129 us
us: 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
[ 00 -- -- -- -- -- ]: 0 0 0 0 0 0 201 0 1361 0 1259 0 179 0 0 0 0 0 0 0 : latency 260832; std 476.70
...
[ 99 -- -- -- -- -- ]: 0 0 0 0 0 0 133 0 1307 0 1395 0 162 0 0 0 0 0 0 0 : latency 261043; std 486.48
best candidates ordered by latency:
0: 94 lat = 261702
1: 97 lat = 261316
2: 85 lat = 261297
3: 68 lat = 261204
4: 98 lat = 261171
...
95: 40 lat = 260784
96: 07 lat = 260784
97: 36 lat = 260723
98: 14 lat = 260713
99: 18 lat = 260651

best candidates ordered by std:
0: 27 std = 496.15
1: 31 std = 492.40
2: 11 std = 492.07
3: 25 std = 491.74
4: 15 std = 491.58
...
95: 10 std = 479.10
96: 20 std = 477.69
97: 00 std = 476.70
98: 01 std = 471.08
99: 94 std = 464.33

lat_k 0-1 0.15%, lat_k 98-99 0.02%, lat_k 0-99 0.40%
std_k 0-1 0.76%, std_k 98-99 1.45%, std_k 0-99 6.85%
STD has more deviation than latency
STD[99] deviates more than STD[0]
pin[0] choose candidate: 94 based on std
us: 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
[ 94 00 -- -- -- -- ]: 0 0 0 0 0 0 116 0 1253 1 1305 0 325 0 0 0 0 0 0 0 : latency 261679; std 470.48
...
[ 94 99 -- -- -- -- ]: 0 0 0 0 0 0 145 0 1360 1 1214 0 280 0 0 0 0 0 0 0 : latency 261259; std 472.11
best candidates ordered by latency:
0: 53 lat = 262244
1: 07 lat = 261879
2: 90 lat = 261859
3: 88 lat = 261845
4: 30 lat = 261839
...
95: 87 lat = 261160
96: 17 lat = 261140
97: 65 lat = 261133
98: 95 lat = 261123
99: 91 lat = 261076

best candidates ordered by std:
0: 53 std = 478.79
1: 12 std = 476.90
2: 08 std = 475.75
3: 33 std = 475.22
4: 77 std = 475.17
...
95: 82 std = 461.33
96: 06 std = 461.10
97: 83 std = 461.06
98: 84 std = 458.68
99: 07 std = 458.33

lat_k 0-1 0.14%, lat_k 98-99 0.02%, lat_k 0-99 0.45%
std_k 0-1 0.40%, std_k 98-99 0.08%, std_k 0-99 4.46%
STD has more deviation than latency
STD[0] deviates more than STD[99]
pin[1] choose candidate: 53 based on std
us: 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
[ 94 53 00 -- -- -- ]: 0 0 0 0 0 0 0 1 1193 0 1377 0 429 0 0 0 0 0 0 0 : latency 262469; std 476.36
...
[ 94 53 99 -- -- -- ]: 0 0 0 0 0 0 0 0 1379 0 1190 0 428 0 0 0 0 0 0 0 : latency 261963; std 476.23
best candidates ordered by latency:
0: 60 lat = 262751
1: 40 lat = 262688
2: 03 lat = 262673
3: 01 lat = 262669
4: 04 lat = 262666
...
95: 43 lat = 261932
96: 69 lat = 261922
97: 76 lat = 261915
98: 61 lat = 261897
99: 21 lat = 261863

best candidates ordered by std:
0: 83 std = 480.02
1: 42 std = 479.67
2: 15 std = 479.30
3: 07 std = 478.97
4: 21 std = 478.73
...
95: 57 std = 472.65
96: 27 std = 472.17
97: 10 std = 472.04
98: 02 std = 470.45
99: 85 std = 470.03

lat_k 0-1 0.02%, lat_k 98-99 0.01%, lat_k 0-99 0.34%
std_k 0-1 0.07%, std_k 98-99 0.09%, std_k 0-99 2.13%
STD has more deviation than latency
STD[99] deviates more than STD[0]
pin[2] choose candidate: 85 based on std
Candidate PIN 94 53 85 -- -- -- : brute forcing bytes 3 to 5 (3 bytes), will take up to 640 seconds
Progress: 0%..5%..10%..15%..20%..25%..30%..35%..40%..45%..50%..55%..done

found PIN: 25 53 40 94 55 85
PIN is cracked in 934.58 seconds
Validating PIN
PIN verified.
done
Resetting all ECUs.
CAN_HS ---> ID=000ffffe data=ff c8 00 00 00 00 00 00
CAN_LS ---> ID=000ffffe data=ff c8 00 00 00 00 00 00

[RickHaleParker]

Pushed new change to the "lowest_std" branch, check it out (@solitaire and @RickHaleParker).

Tried the new change but it switched back to candidates based on latency. No success.

Now about this as an experiment: If a CEM fails to brute force crack using candidates based on one method. Try again using candidates based on the other method.

If we cannot get Frankenstein to crack don't loose any sleep over it. It is Frankenstein. The electrical system is not finished and Yagger has made modifications to the CEM software. Too many unknown variables.

T5Luke has sent me the instructions on how to extract the bin file. We have come to an agreement that I should not trust the USB to DB9 cable I have. No way of knowing what the logic level is. Frankenstein likes electrons but I don't want to give him an over dose. Going to order a FTDI USB-RS232 to TTL cable to be on the safe side. Scratch that I going with a FTDI USB to TTL Serial Adapter For Arduino. They cost less, more versatility and I can see the chip and detect if it a genuine FTDI or a counterfeit.

Just looking at the picture of the Adapters on eBay I can see the $5.00 boards are counterfeit chips. Order one that has a genuine FTDI. Cost twice as much but, if it saves me hours and hours of trouble shooting it worth the extra cost.

The way to tell a counterfeit FTDI from the real thing is the same as telling a high end watch from a counterfeit. The real thing etches the writing, which cost more, the counterfeits stamps the writing, which is cheap. One buddy of mine can pick up a high end watch and without looking at it, tell its counterfeit by running his finger over the back of the case.

See how the real chip has 3D lettering and the counterfeit has 2D lettering.

[solitaire]

Pushed new change to the "lowest_std" branch, check it out (@solitaire and @RickHaleParker).
...

log attached

Candidate PIN 94 53 02 -- -- -- : brute forcing bytes 3 to 5 (3 bytes), will take up to 639 seconds
Progress: 0%..5%..10%..15%..20%..25%..30%..35%..40%..45%..50%..55%..60%..65%..70%..75%..80%..85%..90%..95%..
PIN is NOT cracked in 1221.23 seconds
done
Resetting all ECUs.


second
Candidate PIN 29 85 73 -- -- -- : brute forcing bytes 3 to 5 (3 bytes), will take up to 640 seconds
Progress: 0%..5%..10%..15%..20%..25%..30%..35%..40%..45%..50%..55%..60%..65%..70%..75%..80%..85%..90%..95%..
PIN is NOT cracked in 1218.41 seconds
done
Resetting all ECUs.

log: https://www.dropbox.com/s/lqvxmrf4xmcz1 ... 2.rar?dl=0

[vtl]

Pushed new change to the "lowest_std" branch, check it out (@solitaire and @RickHaleParker).
...

log attached

Candidate PIN 94 53 02 -- -- -- : brute forcing bytes 3 to 5 (3 bytes), will take up to 639 seconds
Progress: 0%..5%..10%..15%..20%..25%..30%..35%..40%..45%..50%..55%..60%..65%..70%..75%..80%..85%..90%..95%..
PIN is NOT cracked in 1221.23 seconds
done
Resetting all ECUs.


second
Candidate PIN 29 85 73 -- -- -- : brute forcing bytes 3 to 5 (3 bytes), will take up to 640 seconds
Progress: 0%..5%..10%..15%..20%..25%..30%..35%..40%..45%..50%..55%..60%..65%..70%..75%..80%..85%..90%..95%..
PIN is NOT cracked in 1218.41 seconds
done
Resetting all ECUs.

log: https://www.dropbox.com/s/lqvxmrf4xmcz1 ... 2.rar?dl=0

That the wrong code (Arduino code):

lat_k 0.04%, std_k 0.13%
pin[2] choose candidate: 02 based on latency

Should be like:

lat_k 0-1 0.02%, lat_k 98-99 0.01%, lat_k 0-99 0.34%
std_k 0-1 0.07%, std_k 98-99 0.09%, std_k 0-99 2.13%
STD has more deviation than latency
STD[99] deviates more than STD[0]
pin[2] choose candidate: 85 based on std

> Pushed new change to the "lowest_std" branch, check it out

[solitaire]

> Pushed new change to the "lowest_std" branch, check it out
download link
https://github.com/vtl/volvo-cem-cracke ... racker.ino

always freezing (hang)

[RickHaleParker]

always freezing (hang)

Mine too when the battery is low or the CEM is already in program mode.

You can get it out of program mode by interrupting the power supply.
Hard reset:
1. Remove negative battery cable.
2. Key in POS II.
3. Connect Negative battery cable.
4. Turn key off.

[RickHaleParker]

Pushed new change to the "lowest_std" branch, check it out (@solitaire and @RickHaleParker).

Ran it twice. Full logs attached.

PS: Never mind wrong code loaded.

[vtl]

> Pushed new change to the "lowest_std" branch, check it out
download link
https://github.com/vtl/volvo-cem-cracke ... racker.ino

always freezing (hang)

Does it hang with master?

[RickHaleParker]

Does it hang with master?

I got the impression you pushed the change in Master. Is Master or Rework where you pushed the Lowest_std change?