Vida CEM swapping

[tomasL]

Hello I found different kind of behaviour/problem with CEM cracker.
My setup is Teensy 4.1 (same CPU as 4.0),
2x chinese VD230 CAN and breadboard setup with twisted pairs.
Everything is powered up from Teensy so first I will try to change power supply, than I will try shorten twisted pairs which are currently about 30cm long and If it not help I will try to remove both onboard 120ohm resistors. However my problem is that sampling is loo long. I have only 20pins/s. Is that OK? Everyone has more than 1000pins/s Also I cant autodetect CEM PN and if I dissable autodetection I am getting random CEM PN so If I want to start sampling I need to bypass PN check by hardcoding PN inside sourcecode. My CEM PN is 30728542. I expect that this is noise/power/chineseIC related issue so I will try to fix that things first. However someone facing similar problem should find my post helpful. I cant find any evidence about slow sampling...

Unable to find PN with unmodiffied sourcecode:

Code: Select all

CPU Maximum Frequency:   600000000
CPU Frequency:           600000000
Execution Rate:          600 cycles/us
PIN bytes to measure:    3
Number of samples:       2
CAN low-speed init done.
Reading part number from ECU 0x40 on CAN_LS
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS <--- ID=03600028 data=00 08 f0 64 30 00 01 00
CAN_LS <--- ID=00e01008 data=03 e5 98 00 00 85 4c 00
CAN_LS <--- ID=01601422 data=00 00 00 01 34 90 02 b3
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS <--- ID=02202262 data=00 00 03 80 58 00 40 00
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS <--- ID=00c00402 data=83 10 00 00 00 00 00 16
CAN_LS <--- ID=0131726c data=00 8c d4 d2 80 00 00 3f
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS <--- ID=02c1302a data=01 84 00 b3 13 08 80 b7
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS <--- ID=01a0600a data=80 00 00 00 00 1e 40 00
CAN_LS <--- ID=01a0600a data=00 00 00 00 00 1e 40 00
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS <--- ID=01601422 data=00 00 00 01 34 90 02 b3
CAN_LS <--- ID=01a0600a data=80 00 00 00 00 1e 40 00
CAN_LS <--- ID=01e0162a data=40 01 00 00 06 00 00 30
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
CAN_LS <--- ID=0131726c data=00 8c d1 d2 80 00 00 3f
CAN_LS <--- ID=01e0162a data=c0 01 00 00 06 00 80 30
CAN_LS <--- ID=02202262 data=00 00 03 80 58 00 40 00
CAN_LS ---> ID=000ffffe data=cb 40 b9 f0 00 00 00 00
Can't find part number on CAN-LS, trying CAN-HS at 500 Kbps
CAN high-speed init done.
Reading part number from ECU 0x50 on CAN_HS
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=0042406c data=80 a8 00 00 e0 00 c0 0f
CAN_HS <--- ID=0042406c data=c0 88 00 00 e0 00 c0 0f
CAN_HS <--- ID=0062401e data=02 48 64 8b e1 ec 24 00
CAN_HS <--- ID=00224024 data=3b f8 00 00 13 ff d0 00
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=01600012 data=40 11 84 ba 2d 28 cb 9e
CAN_HS <--- ID=00c0402a data=1e e4 00 00 07 4a c7 ff
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=00c0402a data=1e e4 00 00 07 4a c7 ff
CAN_HS <--- ID=0042406c data=c0 8a 40 00 e0 00 c0 0f
CAN_HS <--- ID=11600002 data=d6 48 20 00 00 00 00 00
CAN_HS <--- ID=01a2402a data=00 6d 92 06 80 00 80 00
CAN_HS <--- ID=00c0402a data=1e e4 00 00 07 4a c7 ff
CAN_HS <--- ID=11600002 data=e6 48 20 00 00 00 00 00
CAN_HS <--- ID=0042406c data=c0 88 00 00 e0 00 c0 0f
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=00224024 data=3f f8 00 00 13 ff d0 00
CAN_HS <--- ID=00224024 data=3f f8 00 00 13 ff d0 00
CAN_HS <--- ID=10800006 data=00 77 00 6f 00 00 00 00
CAN_HS <--- ID=00e24026 data=00 01 60 e0 9f 00 00 00
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=11420006 data=00 00 00 1f 00 00 d2 00
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=0042406c data=80 e8 40 00 e0 00 c0 0f
CAN_HS <--- ID=00224024 data=3f f8 00 00 13 ff d0 00
CAN_HS <--- ID=00224024 data=3b f8 00 00 13 ff d0 00
CAN_HS <--- ID=00c0402a data=1e e4 00 00 07 4a c7 ff
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=00224024 data=3b f8 00 00 13 ff d0 00
CAN_HS <--- ID=00c0402a data=1e e4 00 00 07 4a c7 ff
CAN_HS <--- ID=0042406c data=c0 88 00 00 e0 00 c0 0f
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=0042406c data=40 88 00 00 e0 00 c0 0f
CAN_HS <--- ID=00224024 data=3f f8 00 00 13 ff d0 00
CAN_HS <--- ID=01a2402a data=00 9d 62 06 80 00 80 00
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=00c0402a data=1e e4 00 00 07 4a c7 ff
CAN_HS <--- ID=00224024 data=3f f8 00 00 13 ff d0 00
CAN_HS <--- ID=0042406c data=00 2a 00 00 e0 00 c0 0f
CAN_HS <--- ID=0042406c data=40 c8 00 00 e0 00 c0 0f
CAN_HS <--- ID=00e24026 data=00 01 60 e0 9f 00 00 00
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
CAN_HS <--- ID=01600012 data=80 11 94 ba 2d 28 cb 9e
CAN_HS ---> ID=000ffffe data=cb 50 b9 f0 00 00 00 00
Unknown CEM part number 0. Don't know what to do.
Resetting all ECUs.

So I decided to comment //#define CEM_PN_AUTODETECT but cant start sampling because of random PN detected

Code: Select all

CPU Maximum Frequency:   600000000
CPU Frequency:           600000000
Execution Rate:          600 cycles/us
PIN bytes to measure:    3
Number of samples:       100
CAN low-speed init done.
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=00e24026 data=00 01 60 e0 9f 00 00 00
Part Number: 4219643968
Searching P/N 4219643968 in 54 known CEMs
Unknown CEM part number 4219643968. Don't know what to do.
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

With second attempt i've got different PN

Code: Select all

CPU Maximum Frequency:   600000000
CPU Frequency:           600000000
Execution Rate:          600 cycles/us
PIN bytes to measure:    3
Number of samples:       100
CAN low-speed init done.
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=00c0402a data=1e e4 00 00 07 4a c7 ff
Part Number: 7512865
Searching P/N 7512865 in 54 known CEMs
Unknown CEM part number 7512865. Don't know what to do.
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

So I decided to hardcode it somewhere around line 1060

Code: Select all

pn = 30728542;
//pn = ecu_read_part_number_prog(CAN_HS, CEM_HS_ECU_ID);

Finally I've successfully started sampling but on extremely low speed

Code: Select all

CPU Maximum Frequency:   600000000
CPU Frequency:           600000000
Execution Rate:          600 cycles/us
PIN bytes to measure:    3
Number of samples:       2
CAN low-speed init done.
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
Searching P/N 30728542 in 54 known CEMs
CAN HS baud rate: 500000
PIN shuffle order: 3 1 5 0 2 4
Initialization done.

Calculating bytes 0-2
1000 pins in 46254 ms, 21 pins/s, average response: 172 us, histogram 86 to 258 us 
                   us:   164   165   166   167   168   169   170   171   172   173   174   175   176   177   178   179   180   181   182   183 
[ 00 -- -- -- -- -- ]:     0     0     0     4     0     2     0     0     0     0     0     1     2     0     0     2     0     1     0     3 : latency     430369; std 606.98
[ 01 -- -- -- -- -- ]:     1     0     1    10     0     2     2     1     2     0     0     1     1     2     1     1     0     2     1     1 : latency     527620; std 584.61
[ 02 -- -- -- -- -- ]:     1     0     0     4     0     1     0     4     0     3     0     0     0     2     0     2     0     0     0     0 : latency     462291; std 595.59
[ 03 -- -- -- -- -- ]:     0     2     4     2     0     0     0     2     1     1     0     0     3     1     0     0     2     0     0     1 : latency     473535; std 583.28
[ 04 -- -- -- -- -- ]:     0     0     3     1     1     2     2     0     0     1     0     0     3     3     1     0     3     1     1     2 : latency     469260; std 585.81
[ 05 -- -- -- -- -- ]:

[vtl]

So I decided to comment //#define CEM_PN_AUTODETECT but cant start sampling because of random PN detected

It didn't go into programming mode. You can stop right here and start debugging your schematics. Looks like the modules on CAN bus(es) didn't see your messages, so the cracker reads random junk sent by modules on the bus.

[5ft24]

He has the design, gerbers etc back a few pages

[tomasL]

Hello thank you for suggestions. I am 100% sure that wiring is right.

1st I am electrical engineer
2nd I transferred wiring to the PCB according to the schematics from github.

I tried independent 3.3V power supply, also DCDC from on board 12V to 5V but without success. I measured current trought USB and Teensy is taking around 100mA. With independent 3.3V line its just 40mA so it wouldn't be power issue.

Interesting thing is that when I bypass CEM PN check and even if I am taking random communication as @vtl mentioned, there is one little difference. With Teensy 3.3V supply I have 20pins/s but with external its around 100pins/s. So with external powwer supply I am taking noise faster

Second interesting thing is that other users recommended to crack pin with key in 0 position. However in that position I have no activity on the both LS and HS CAN. So I always need to turn key into the II position.

I will definitely order original SN65HVD230 from mouser because I think that these Chinese clones are responsible for all issues.

I will update my progress. However I dont understand why others successfully cracked pin in 0 key position because my CAN is only active on II.

[RickHaleParker]

Second interesting thing is that other users recommended to crack pin with key in 0 position. However in that position I have no activity on the both LS and HS CAN. So I always need to turn key into the II position.

Check the always on voltage sources to the CEM. Fuses 11B/9, 11B/16, 11B/17 & 11B/20. See attached file.

Note: Fuses 11B/X Engine compartment.

[tomasL]

Check the always on voltage sources to the CEM. Fuses 11B/9, 11B/16, 11B/17 & 11B/20. See attached file.

Thank you @RickHaleParker for advice. All fuses are checked. However I think it has nothing with that. My car including CEM is working without problems and I think any blowed fuse would produce some warning, DTC or not operating component which I don't have.

I am just thinking that it could be part of volvo security which is not a part of every CEM SW version. I mean I dont know how many of us used this great project (thank you @vtl) but cracking CEM pin is not very common task. This means that such kind of attack is tested only on limited number of CEM's and cars. I am just thinking that some CEMs could have different SW with disabled CAN activity in 0 position. There is definitely good reason to that because with access to the CAN you can control many things including doors, windows etc... FIAT has a problem with that in their first CAN equipped cars. They exposed CAN into the side mirrors which means that wiring is easier but car thefts with Arduino knowledge can build universal "keychain for keyless entry" to the car So I am thinking that if it is possible that volvo disabled CAN as a part of SW improvements during years...

I will definitely try to change these Chinese CAN transceivers however TIs SN65HVD230 are currently out of stock so I ordered TLE7251VSJ which looks like good alternative. I will submit update in few days when they come.

[Alucard666]

Should I reprogram CCM?

Not so fast. Go to Diagnostics/Network. Is VIDA showing any communication with the CCM?

I think hardware communication is OK, in VIDA I see green CCM and can read HW, SW numbers. Also I can read FAN speed and internal temperature.

[vtl]

So I am thinking that if it is possible that volvo disabled CAN as a part of SW improvements during years...

They actually made it easier, it was "no CAN until K-Line activity is detected".

The algo works in any key position where CAN is alive. I shared my thoughts on why some CEMs are harder to crack a few (dozens) pages back. I think it is related to the alignment of the pin comparison code in the flash.

The code basically consists of 6 pairs of "compare and jump if not equal" sequences. In my observations, when the sequences crosses 16 byte region, the latency spikes significantly. Maybe Reneses has to fetch the next flash memory line via a slow protocol like SPI, which is rather expensive in terms of CPU time. Or the machine instruction crossing the 16 bytes boundary causes terrible CPU stall, and we might be seeing that.

The direct latency of a longer correct sequence, say 3 correct bytes out 6, is not that greater than 1 out of 6. Teensy 4.0 running at 600 MHz has all the guts to detect that latency difference, however it is masked out by a much-much slower CAN-bus operating at 0.5 MHz (Renesas is 30 MHz), plus there's a few frequency domain transitions, so the direct comparision difference is definitely lost. As said, there's some other factor affecting the latency that we can see programmatically.

Older, brick-shaped CEM does not suffer same problem - may be it is because of a parallel flash chip, which has no such delay problem, or the CPU is dumb enough to always run slow and linearly - and the algo can't detect any discrepancies while cracking the PIN.

So, in CEM-L I saw 3 various displacements of the code. The probability of the successful PIN crack is based on that displacement. First version of algorithm was able to crack only the easiest case. With the most recent changes it also cracked those "hard" CEMs, but I did that using other CEM dumps on my own hardware, and the signal-to-noise ratio was marginal. So the crack was not guaranteed in fact.

It may be the algo and/or hw could be further improved, someone with digital oscilloscope, basic C language and mathematical statistics can do it

[RickHaleParker]

I am just thinking that it could be part of volvo security which is not a part of every CEM SW version.

It is possible one of voltage sources is just a CEM Stay Alive. If a SA went out there may not be any symptoms other then no response from the CEM in POS 0.

Here is a fact you can use as a diagnostics tool. VIDA/DiCE needs the key in POS II so all the control modules are active. However the CEM will respond to to VIDA/DiCE in POS 0 and read the VIN Number. At least my 2005 XC90 CEM-H will.

Take a DiCE unit or some other J2534 interface and see if you can get a response out of the CEM with the key in POS 0.

[RickHaleParker]

I think hardware communication is OK, in VIDA I see green CCM and can read HW, SW numbers. Also I can read FAN speed and internal temperature.

What is the Volvo Part Number on the CCM?
Also get the chassis number. Which is the last six digits of the VIN number ( Vehicle Identification Number ).
Post both here.

CCM ( AKA E.C.C. ) Celsius .
VPN 8691950 Chassis -314999
VPN 8691876 Chassis 315000-425139
VPN 30782694 Chassis 425140-