Vida CEM swapping

[dikidera]

Here is a python script, that given a HW part number, will extract all diagnostic parameters with names and units(if applicable) from VIDA. It was written by AI yes. May contain bugs.

Thank you for the script! I played around with SQL requests and some Python parsing too, but your script is a lot nicer indeed.
My VIDA installation is stuck in an old 32-bit Windows 7 VM, so I'll probably have to get a newer Windows version to export the database to SQLite format and actually play around with the script.

What is still unclear to me: as far as I could tell the VIDA database only contains the diagnostic responses? At least the links that vtl posted were all based on diagnostic requests. What I'm interested in is the normal CAN bus communication, which does not include the diagnostic requests.
The goal would be to replace the ECM entirely and "pretend" to be the ECM, which would require replicating all the CAN messages it usually sends. Those aren't the diagnostic messages though.

Is that what the "status" category is for? Is that the data that's sent on the CAN buses during normal operation? (As I said, I haven't played around with your script yet, maybe the answer would be obvious from the output).

Decoding the IDs is the easy part. Knowing what the encoded data is a bit more difficult it requires reverse engineering of the module you wish to emulate.

The first step is extracting the ECM from the car and running on the bench. This allows you to isolate about 90% of the CAN ids the module will "use". Why 90%? Some CAN ids will appear only when IGN Key in POS II and likely communication between ECM<=>CEM and ECM<=>ABS, so some IDs may not appear(or they might).

Second step is extracting the ROM, you need this in order to find the area with the CAN signal configuration. Note, across modules e.g ECM,TCM,ETM the can signal configuration will be stored differently, in different ROM areas, in different structures etc, they dont always follow a clear cut single spec design. CAN IDs as I mentioned are serialized and depend on the MCU's CAN module memory layout.
Usually you have a structure for storing the data and/or encoding it, very simple functions, then for reading(this reads from already stored by the system data) and thirdly is the read/dispatch tables that the system iterates over to construct the ID and send the messages as well as receive.

[ghettob]

Grab everything you see on the teensy's console, end to end, paste to gist.github.com, drop a link here.

I have the pin already for this car and it's not even close. Terminal output is from a 15min session

Master branch does not even start the programming mode, so all the gists are from p3 branch

It is making progress. P3 CEM falls off the programming mode when punched hard, that's why it awakes and gets down again. The only way it stays in programming mode is if message rate is greatly reduced, to about what DiCE can do.

p3 code is not integrated into master, yes. I was thinking of integrating sirloin's one_pass and p3 branches (and now cem_b, too), but testing the code on at least 4 CEMs would kill me.

Ahaa... now i see the progress! That output was for 15-20minutes of calculation.

So basicly the P3 branch still takes hours to get the pin calculated and there's no "standalone" as the p3 branch does not have the screen setup

And oif i unplug the teensy from OBD and plug it back in, it Will start from 00 00 00 00 00 again i presume?

[vtl]

And oif i unplug the teensy from OBD and plug it back in, it Will start from 00 00 00 00 00 again i presume?

No. Because cem cracker, unlike two zillion of other companies, is fully open source, so you could make a note where you stopped and fix it in the source code: https://github.com/vtl/volvo-cem-cracke ... .ino#L1135

Say, last pin you saw in the log is 00 00 26 XX XX. To restart from pin 00 00 26 00 00 you would need to modify that line to

Code: Select all

for (int p2 = 0x26; p2 < 0x100; p2++) {

Because it is opensource, everyone has access to it for free, and can even improve the code, like Christian Molson did by adding support for P1 and Mark Dapoz adding comments for chatgpt and changing my Kernigan & Ritche blessed snake_code_style to camelCase, which I genuinely can't stand But whatever, we have a LCD with abort button, and chatgpt is well aware of what and how this project does now =)

[Treur]

And oif i unplug the teensy from OBD and plug it back in, it Will start from 00 00 00 00 00 again i presume?

No. Because cem cracker, unlike two zillion of other companies, is fully open source, so you could make a note where you stopped and fix it in the source code: https://github.com/vtl/volvo-cem-cracke ... .ino#L1135

Say, last pin you saw in the log is 00 00 26 XX XX. To restart from pin 00 00 26 00 00 you would need to modify that line to

Code: Select all

for (int p2 = 0x26; p2 < 0x100; p2++) {

Because it is opensource, everyone has access to it for free, and can even improve the code, like Christian Molson did by adding support for P1 and Mark Dapoz adding comments for chatgpt and changing my Kernigan & Ritche blessed snake_code_style to camelCase, which I genuinely can't stand But whatever, we have a LCD with abort button, and chatgpt is well aware of what and how this project does now =)

I'd also add that by slightly modifying the code and attaching a PC interface to it instead of a terminal, we can easily add a stop and continue brute force attack.

[vtl]

I'd also add that by slightly modifying the code and attaching a PC interface to it instead of a terminal, we can easily add a stop and continue brute force attack.

Teensy has EEPROM...

Also I made Teensy working only as a CAN interface and latency acquisition device in past. The math was done on PC, which has way more RAM, so the latency of every single pin could be stored in memory. Seeing data visualized always help. Like, here we see a uniform CEM-B latency when it is bombed with CAN requests vs latency after idle time, when a low power mode kicking in (this is how one_pass is possible):

2.png (98.17 KiB) Viewed 131 times

1.png (134.97 KiB) Viewed 131 times

[ghettob]

I managed to integrate the lcd display to P3 code and got the device to (hopefully) read the pin in under 7 hours on a car it took 18 hours on p3tool.

Only problem i faced was that the screen was left i "P3 resetting all ecus"

I Will try to solve this issue and share the code for P3 stand-alone operation to the creator

Is there a way to extract the found pin from latest session, so i could verify the found pin was correct?

[vtl]

I managed to integrate the lcd display to P3 code and got the device to (hopefully) read the pin in under 7 hours on a car it took 18 hours on p3tool.

Only problem i faced was that the screen was left i "P3 resetting all ecus"

I Will try to solve this issue and share the code for P3 stand-alone operation to the creator

Is there a way to extract the found pin from latest session, so i could verify the found pin was correct?

This line prints the pin: https://github.com/vtl/volvo-cem-cracke ... .ino#L1169
Perhaps the cracker needs to read address where the real pin is located and print the real pin instead of hash collision.

[radziuC30]

This is my reading after an hour

[Treur]

I managed to integrate the lcd display to P3 code and got the device to (hopefully) read the pin in under 7 hours on a car it took 18 hours on p3tool.

Only problem i faced was that the screen was left i "P3 resetting all ecus"

I Will try to solve this issue and share the code for P3 stand-alone operation to the creator

Is there a way to extract the found pin from latest session, so i could verify the found pin was correct?

The speed of detection depends solely on the PIN code itself and which side is being searched. On your block, you'll find it in 7 hours; on another, you'll find it in 18, 1, or even a minute. There are blocks where someone has already been, and the PIN is FF.

[Treur]

I managed to integrate the lcd display to P3 code and got the device to (hopefully) read the pin in under 7 hours on a car it took 18 hours on p3tool.

Only problem i faced was that the screen was left i "P3 resetting all ecus"

I Will try to solve this issue and share the code for P3 stand-alone operation to the creator

Is there a way to extract the found pin from latest session, so i could verify the found pin was correct?

This line prints the pin: https://github.com/vtl/volvo-cem-cracke ... .ino#L1169
Perhaps the cracker needs to read address where the real pin is located and print the real pin instead of hash collision.

This is an ideal way, but there are enough collisions.