Vida CEM swapping

Post by **vtl** » 13 Sep 2021, 11:31

Strange things happen. Depending on position or, perhaps, some yet unknown factor, the latency may spike a bit for the matching byte value, while disassembly says it should go tad lower. Or it may be the lowest latency, but not always. I can't find a programmable approach that will do the trick. Only the first byte is detected reliably and I can't explain why - in my understanding it should not.

The only thing that is certain is that the algo has to iterate values for one position at a time only, without reaching to the next 2 positions, like it currently does.

Oh, and then there's a zero problem: 00 always yields outstanding latency, either lowest or greatest, depending on position. I had to start iteration from 01, not 00, risking to miss real 00 in the PIN.

Surprisingly, the most stupid and straightforward code is the hardest to crack. Like, what kind of a software developer you are if your loop does not terminate as soon as the "problem" is detected? Why waste CPU time? This is not optimal!

And the first to give up was the P3's complex hashing algo. For sure Volvo had a strike force group that was laying out that protection for weeks

Post by **RickHaleParker** » 13 Sep 2021, 16:27

vtl wrote: ↑13 Sep 2021, 11:31 Strange things happen. Depending on position or, perhaps, some yet unknown factor, the latency may spike a bit for the matching byte value, while disassembly says it should go tad lower. Or it may be the lowest latency, but not always. I can't find a programmable approach that will do the trick. Only the first byte is detected reliably and I can't explain why - in my understanding it should not.

Have you tried different fill byte weights? Perhaps 99 instead of 00.
Shot in the dark but different fill byte weight might produce a different behavior ...

The only thing that is certain is that the algo has to iterate values for one position at a time only, without reaching to the next 2 positions, like it currently does.

Always using 5 fill bytes and only one test byte?

Surprisingly, the most stupid and straightforward code is the hardest to crack. Like, what kind of a software developer you are if your loop does not terminate as soon as the "problem" is detected? Why waste CPU time? This is not optimal!

It is producing a bigger challenge than the "efficient" code. One could say it is more efficient at keeping people out.

And the first to give up was the P3's complex hashing algo. For sure Volvo had a strike force group that was laying out that protection for weeks

Did the crack algo give up trying or did the CEM give up the PIN number?
Will the P3 take less then 24 hours or will it take up to 249 hours?

Post by **RickHaleParker** » 14 Sep 2021, 17:48

vtl wrote: ↑08 Sep 2021, 13:33
RickHaleParker wrote: ↑08 Sep 2021, 13:20 mikeak2001 found it in DHA .. 50 B9 F5. Just change F0 to F5 in the hardware ID request and you got it.

The post is on page 83.
Also page 69 when I first got the block by trial with the version numbers.

You can figure out the responce format from this:

Tester -> CEM: 50 B9 F0/ B9-Read Data Block By Offset/F0-ECU identification
Complete Response: F9 F0 00 30 72 85 42 20 20 41 31 39 41 63 20 41 41
ECU Complete Part Number 0030728542 A
ECU Diagnostic Software number 31394163 AA

Tester -> CEM: 50 B9 F5/ B9-Read Data Block By Offset/F5-SW part no. and flash sector start address
Complete Response: F9 F5 00 31 37 64 79 20 41 41 00 FF 00 00 00 31 39 41 61 20 41 41 00 FB 00 00 00 31 39 41 66 20 41 41 00 FF 80 00
CAN Config Part Number 0031376479 AA
Flash Sector Start Address 00FF0000
Application Software Part Number 0031394161 AA
Flash Sector Start Address 00FB0000
Local Config Parameter Part Number 0031394166 AA
Flash Sector Start Address 00FF8000

Tester -> CEM: 50 B9 F8/ B9-Read Data Block By Offset/F8-ECU Serial Numbers
Complete Response: F9 F8 00 00 05 53 08 95 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CEM Serial number 000005530895
Serial number for SWM 000000000000
Serial number for SWS Cruise 000000000000
Serial number for SWS Audio 000000000000
Serial Number for BLIS LCM 000000000000
Serial Number for BLIS RCM 000000000000

Record Request needs to be appended with one of these 5 options:
00 ( Stop sending ).
01 ( Send the record once).
02 ( Repeat at slow rate until stop requested ).
03 ( Repeat at medium rate until stop requested ).
04 ( Repeat at medium rate until stop requested ).
Example 50 B9 F0 01 = B9-Read Data Block By Offset, F0-ECU identification, 01-Send the record once .

gooroo · Post by **gooroo** » 23 Sep 2021, 08:22

Hi guys, not having much luck with a USB TTL UART, with everything setup, when I ground the reset all I get is a little random data in the terminal window. Entering #00 or 00 in the top "send" box and clicking send, nothing happens. I have rechecked all my connections and even tried reversing TX/RX wires, still nothing, am I missing something?

5v and ground connected from USB device too VCC and GND
CNVss connected to 5v and BUSY to GND

Open up M16c beta, config information has been added to MCU.ini and M16C-Ctrl.cfg, correct device selected, correct port selected, baud rate set to 57600, open terminal, select 57600 in terminal window.

Power up CEM with 12V on connector D (grey 60pin) too pins 5 and 15V, GND connected to pin 6

12V GND on Pin 6 also connected to GND of USB device

Briefly apply GND to RESET, that's when I get a little random data in the terminal window.

Have I missed something?

Post by **vtl** » 23 Sep 2021, 09:29

Better use VCC from the board.

How many times did you send #00? It takes about a dozen or so before Renesas replies with B0.

gooroo · Post by **gooroo** » 23 Sep 2021, 09:48

Thanks, I took VCC and GND from board, from the points is this photo...

I have tried send over 50 times, I assume I don't need to reset each time?

Regards, Simon

Post by **vtl** » 23 Sep 2021, 12:39

gooroo wrote: ↑23 Sep 2021, 09:48 I have tried send over 50 times, I assume I don't need to reset each time?

You do.

Also try with starting at other baud rates. Mine is taking 57600 reliably, I had the cracker sw starting as Renesas flash pin cracker, not Volvo sw pin, and in one of designs it was doing hundreds of Renesas reset&connect in a minute, in a very reliable manner.

Post by **RickHaleParker** » 23 Sep 2021, 17:36

vtl wrote: ↑23 Sep 2021, 12:39
gooroo wrote: ↑23 Sep 2021, 09:48 I have tried send over 50 times, I assume I don't need to reset each time?
You do.

Probably why I could not get it to work.

I dug into the M16C flasher settings after I read this and found the settings below.

M16C flasher was designed for a real RS232 port. With a modern USB to TTL converter, I think you do not need the pull-up resistors and Zener diodes.

If you play around with this watch out for that AutoFlash. Don't want to wipe out what you are trying to read.

: 2021-09-23.png (47.59 KiB) Viewed 987 times

: 2021-09-23 (1).png (43.32 KiB) Viewed 987 times

sjasliek · Post by **sjasliek** » 24 Sep 2021, 06:51

Hi everyone! What a great thread!

I'm trying to get the PIN from a 2006 V50, but have not been able to decode it yet.

The hardware is build using the schematics on https://github.com/vtl/volvo-cem-cracker. (retrieved sep 24, 2021)
The Teensy 4.0 is soldered with two TI SN65HVD230 CAN transceivers boards on a small PCB using headers.
Short wires (10 cm) are used between OBD socket and transceivers.
120Ohm termination resistors are present on the PCB.
ODB connector pin 4 and 5 are connected to the circuit GND.
Power is provided over short micro-USB cable.

Everything seems to working fine, but the code is not able to crack the PIN
"PIN is NOT cracked in 1334.46 seconds".

Tried so far (based on reading through this great thread)
- run1: Default SW configuration, ignition off. Result: Candidate PIN 33 89 63 -- -- --, then the 'PIN is NOT cracked' message.
- run2: Default SW configuration, ignition on. Result: Candidate PIN 33 89 59 -- -- --, then the 'PIN is NOT cracked' message.
- run3: LAT_ONLY commented, ignition on. Result: Candidate PIN 69 20 83 -- -- --, then the 'PIN is NOT cracked' message.
- run4: Changed PIN order to 2, 4, 5, 0, 3, 1, ignition on. Candidate PIN 87 43 79 -- -- --, then the 'PIN is NOT cracked' message.

Find the log outputs for each run attached.

I've noticed that STD seems to have larger deviation compared to LAT, not sure if that means anything?
Part-no of the CEM is 30728906 so that seems fine.
As the part-no is read out correctly every time, I'm assuming the CAN bus is working as expected. Also, when the code is running I see that all ECU's are reset and return to normal after the attempt has finished, which also makes me believe the CAN bus / electronics are working fine.

I'm not sure what the next steps are.
Vary with samples? Change power supply? Try other PIN shuffle orders? Should I focus on standard deviation or stick with latency only?

Does anyone have a clue what might be happening here?

Post by **vtl** » 24 Sep 2021, 07:39

Ignition off seems to give you the cleanest signal.

I personally do not recommend using USB power. Too much variation.

Looks like 33 89 are your real first two bytes. However, the logs show that the confidence is very low. But in two runs these bytes floated up, which is a good sign.

Run with LAT_ONLY and with more SAMPLES. Do a few runs and post the logs here. No need to wait for the last 3 bytes, reset the Teensy after the candidate for the third byte has been found. If Teensy can't connect to the car after reset then comment out CEM_PN_AUTODETECT.

Alternatively, if the first two bytes are stable, but the third byte can't be found no matter what, you can set CALC_BYTES to 2 and have the rest 4 bytes brute-forced. It will take up to about 19 hours.

Vida CEM swapping

Re: Vida CEM swapping