Vida CEM swapping

[dikidera]

I always back up modules before flashing. And not just, I always have a spare module just in case. I have a spare TCM, spare ECM and spare L-shaped CEM for when reprogramming, you just never know. But module backing via B4 checksum command is essential to my toolset.

Anyway, since I have gained more or less total control of my TCM, I have begun development of an Android app and will use it as an experiment, I will use it's accelerometer to try and correlate when exactly the bad shifting happens during the shift process.
The android device will stream accelerometer data at 20hz over wifi to my RPI. The RPI is connected to my Android device via the hotspot.

Over time I may be able to build a correlation. As soon as I know where the bad shifting happens, I will at least focus my research on that aspect. There are technical difficulties and Android development is still hell...but...I do not want to find and program a separate accelerometer for my RPI.

Currently increased fill pressures do not produce the intended result for me as I had originally hoped. In the low to medium rpm range e.g between 2-3k RPM there is a bump when shifting. In the high torque range e.g 4500rpm it is better, in the sub-2000rpm range, 2-3 is almost imperceptible. For me it's still most likely sticky solenoids as the prime suspect and am hoping it's possible to at least partially offset it.

[vtl]

Okay, so I have resolved my borked CEM issue with VIDA basically by doing rain dances and offering prayers. But it makes me think that the CEM cloning discussion is a good one to have in case I ever need to do this.

I was helpfully directed to this thread, but it's hard to know where to begin.

- It is a good idea to pre-emptively dump the CEMs of my two cars, in case I ever need to restore to a new unit?
- Assuming I have one "brick" and one "L" CEM (2002 V70XC, 2007 XC70) can anyone point me to the simplest path ahead to get started dumping these to long-term storage?

Looks like https://www.drive2.ru/l/582381898370814757 for the "brick," yes? Is there anything similar for the "L"?

And also—I feel like I see two separate discussions going on in this thread, one about cracking PIN, another about bench reading/writing flash. I feel dumb, but I have been unable to (by skimming) figure out the significant of the PIN discussion, at least not in detail.

Presumably there are either code signing or encryption at issue and this is what the PIN is talking about. But then how does this relate to a simple dump? So is the PIN just for when you want to do edits to the image for tuning (and thus need to re-sign, or need to decrypt), or is this PIN used somewhere else?

Forgive me for wasting time. (But this thread is almost 400 pages!)

When CEM starts, it executes a Primary Boot Loader. It does hardware initialization and then jumps to the main program. When main program is broken, like was in your case, PBL is what allows to reflash over CAN. All that dancing around keeping it in programming mode was to convince CEM to stay in PBL.

Now, CEM does not have any code to do flash operations over CAN. This is the job for Secondary Boot Loader. SBL is transferred over CAN, PBL is instructed to jump into SBL then. Volvo keeps CEM SBL secret. Volvo also decided to bar owners from loading any code over CAN to their rightful property, not until they unlock this feature by sending a PIN code, which is 6 bytes for P1 and P2, and 5 bytes for P3. PIN is, of course, a secret, too.

There are a few methods how one can retrieve this PIN:

- spy on VIDA interacting with CEM when CEM config is changed or firmware is reloaded. Can look for PIN in memory, on disk or sniffer CAN-bus
- read flash chip directly and find PIN at known offset
- use BDM (CPU debug interface) to read it from flash
- use PBL and DiCE for bruteforce attack
- use PBL and a simple, but special hardware for performing a timing attack (send PIN with change in one byte and measure reply latency - the longer PBL replies, the more probability it was a correct byte)

Bruteforce attack can take up to tens of years. P3 and late P2s use a hash-based computational algorithm to check the PIN - PIN is not compared directly, rather a result of secret calculation with PIN as input argument. Volvo owners learned that secret, they found the hash algo is defective and produces many collisions (many PINs would give a positive signal) and discovered that though PIN is in BCD coding, this algo happily accepts shorter PIN in HEX coding, since the only thing CEM cares is the result of computation, so hash collisions are greatly improved. P3 and late P2s (2006+) can be broken over CAN and DiCE using this approach within a reasonable amount of time, up to a day.

Model year 2005 only supports a direct PIN comparison. 2006 and later P2s also support it, as well as P3-style PIN. For these CEMs a Teensy-based solution was born in this thread, it does a timing attack and finds the PIN anywhere from a minute to half an hour for most of the CEMs.

1999-2004 are brick-shaped CEMs, they don't compromise on security, the algorithm is implemented in almost constant execution time, the latency deviation is shadowed by other activity happening inside CEM and over CAN.

So the first thing you do is extracting your PIN number, then finding a software that can read the flash over CAN. Or go old school and solder some wires to CEM and read it directly.

[oscilloscope]

assemble BDM readers using this example https://www.drive2.ru/l/582381898370814757 / and then post it here, but don't program it yet

interesting piece of software , do you have a git for the code? for the BDM board?

if you meant do I have the code on github, then no, but I can share it here if it's interesting.

sorry i meant the BDM board i quoted the wrong reply i was referring too the stm32 board.

i'll be trying out that piece of software i have a test CEM here and see what its like later. also its abit of a pain i can't seem to find the Motorola BDM board that would make it much easier interfacing on the back.

[matthew1]

PIN is not compared directly, rather a result of secret calculation with PIN as input argument.

Is this a hash, or salt?

[avrorafrix]

Using the Android’s accelerometer to map the shifts is a brilliant workaround without needing extra hardware. Android development definitely still has its challenges, but it’s great seeing how creative solutions like yours come together.

[gavik]

Hello. Can anyone share vbf files for flashing cem h? I'm interested as an example

[vtl]

PIN is not compared directly, rather a result of secret calculation with PIN as input argument.

Is this a hash, or salt?

SW asks CEM for seed, CEM sends 3 random bytes, SW combines them and 5 bytes of PIN into 8 bytes of input vector, performs hash computation and sends 3 bytes of computed key to CEM. CEM compares this key to the key it computed itself. Reducing 5 bytes of PIN to 3 bytes of hash key is what produces so many collisions that are all matched as valid by CEM and let the brutforce attack finish in under 24 hours.

https://github.com/vtl/volvo-cem-cracke ... .ino#L1027

[vtl]

I always back up modules before flashing. And not just, I always have a spare module just in case. I have a spare TCM, spare ECM and spare L-shaped CEM for when reprogramming, you just never know. But module backing via B4 checksum command is essential to my toolset.

Anyway, since I have gained more or less total control of my TCM, I have begun development of an Android app and will use it as an experiment, I will use it's accelerometer to try and correlate when exactly the bad shifting happens during the shift process.
The android device will stream accelerometer data at 20hz over wifi to my RPI. The RPI is connected to my Android device via the hotspot.

Over time I may be able to build a correlation. As soon as I know where the bad shifting happens, I will at least focus my research on that aspect. There are technical difficulties and Android development is still hell...but...I do not want to find and program a separate accelerometer for my RPI.

Currently increased fill pressures do not produce the intended result for me as I had originally hoped. In the low to medium rpm range e.g between 2-3k RPM there is a bump when shifting. In the high torque range e.g 4500rpm it is better, in the sub-2000rpm range, 2-3 is almost imperceptible. For me it's still most likely sticky solenoids as the prime suspect and am hoping it's possible to at least partially offset it.

You have a spare transmission now, right? Rebuild it properly and all be fine. 2-3 is a mechanical problem.

Where's your B4 checksum backup program on github?

[dikidera]

It's on here back many pages But it relies heavily on Python, Python-can(SocketCAN wrapper) and a dual CAN shield from Waveshare or a Raspberrypi in general. So it doesnt work on Windows.

You input manually the name of the saved binary and the size to dump. I also think it has an off by one error I never fixed xD. However it works without fail.

As for the transmission, a proper rebuild requires a new VB and a new torque converter, among the other components likely worn out inside. Also there seems to be great deal of 'experience' required. I remember in the AW55 rebuild videos, a guy was installing a clutch pack and said it felt too tight, and it was. He had this insight that I lack.

But overall, its the price. At best I can clean the solenoids from the VB, new clutches but the tc is still the single most expensive part.

[vtl]

It's on here back many pages But it relies heavily on Python, Python-can(SocketCAN wrapper) and a dual CAN shield from Waveshare or a Raspberrypi in general. So it doesnt work on Windows.

Last time I had Windows on my personal computer was like in 2003.

As for the transmission, a proper rebuild requires a new VB and a new torque converter, among the other components likely worn out inside. Also there seems to be great deal of 'experience' required. I remember in the AW55 rebuild videos, a guy was installing a clutch pack and said it felt too tight, and it was. He had this insight that I lack.

HOWTO and all the mechanical specs (where and how to measure): https://www.ebay.com/itm/264000584152

Oh, look... The book in pdf: https://www.academia.edu/36418722/AW55_50SN_51SN

But overall, its the price. At best I can clean the solenoids from the VB, new clutches but the tc is still the single most expensive part.

Rebuilt TC is about twice cheaper than VB.