Vida CEM swapping

[oscilloscope]

Soon





Works with mongoose, but will likely work with DiCE as well. The Special Commands need quite some more work. The idea is to be able to implement custom dynamic records, more generic data etc. P3 is a placeholder, I don't really have any of that implemented.

Hopefully I can also make it work for dumping via B4 checksum, maybe even SBL upload.

Will there be coverage or scanmatic2 ?

[dikidera]

The tool uses the J2534 driver which implements an industry-standard API, in theory it should be universal for ALL scan tools, in practice, it depends on how the specific manufacturer implemented it. For instance are all J2534 drivers thread-safe? Do they all support protocol X, does either of these devices have special quirks which requires one to call PassthruIoctl with special params? Many unknowns.

[Yariy]

Hello. I have been studying CEMB until 2004. [...] If anyone is interested, I'm attaching an incomplete CEMB schema and the Ghidra script (splitting the dump into blocks, assigning register names to addresses).

Thank you for sharing the files. This must've been a tremendous amount of work already.
Unfortunately I can't really answer your initial question about the write proceduce, but since the Flashing procedure is quite slow, I would assume that the code will trigger the Software Watchdog Service Register (SWSR). The program has to periodically write 0x55 and 0xAA to that register, otherwise the processor is resetted.

The copy functions you already identified do exactly that, but so far I did not find another function that looks promising.


Some time ago I started digging into the CEM myself to try to reverse engineer the immobilizer algorithm. I would like to convert a P2 Volvo to EV, but with the immobilizer that is not really possible (you could keep the ECM and spoof the other signals, but that's annoying).

So far I did not reach the immobilizer code, it seems like it is either obfuscated or relocated...
I know that people have reverse engineered that, since you can buy immobilizer spoofing devices, but to my knowledge they don't work without an ECM.

Perhaps someone has some information about that they'd like to share?
I don't want to make any profit, in fact the routine will then be implemented in the ZombieVerter project (https://openinverter.org/wiki/ZombieVerter_VCU) and the knowledge would also help people who want to run standalone ECUs or do funky engine swaps.

Take a look at this project, you might be interested.https://s80ev.blogspot.com/

[Treur]

Soon





Works with mongoose, but will likely work with DiCE as well. The Special Commands need quite some more work. The idea is to be able to implement custom dynamic records, more generic data etc. P3 is a placeholder, I don't really have any of that implemented.

Hopefully I can also make it work for dumping via B4 checksum, maybe even SBL upload.

Work in Russian/English. Support Dice/Mongoose/Scanmatic
P3 Pin search/modules reprog/p3 coding/remote transfer p2/ICM, DIM test on bench.

[dwappertam]

Hai all, i have a question about reading cem-b bt28f400 with the nano bdm tool. I havr solderd the wires on the pads , checked it dubbel checked it even third time thats good . Yet when i open serial monitor on arduino ide and i press r for reading flash it only gives me 81kb when i put all code in hex editor and save it. Does anybody has a id what's happening?



Well I figured it out, The sketch provided for the nano ,did acually work after i made a litte ajustment ii am now a proud guy witch 1 correct .bin and must say after 3 CEM's from the scrpyard i finaly have my working cem back . I must say Volvo stuf , I really enjoy'd it . i am still learning and with baby steps i am learning to at least crack it with obd and k-line and mcp2515 all on nano Thanks dikkidera T5luke Kaev and if i am forgetting one or another THanks . u all spiked my intrest in uncrackable cemb's

[porcupine7655]

Continue on my journey in Denso ecu for a V70 BiFuel 2006
Now when I have the rommonitor working it is easier to test code running in the ecu.

Now with write support to external flash, eeprom and internal flash.

Please, note that it is very easy to brick the ecu when replacing flash content. If new combination of internal flash and external flash (eeprom aswell?) does not match it will not be able to start again. So then is needed other way to put in the content in memories. I have not tested to do flashing in car, only on bench.
Also note that it is not well tested so there is likely there is bugs and not function in some situations. I don't give any guarantee that it will work for you. SO USE ON OWN RISK!

[dikidera]

The bootloader on these is in 0x0-0x2000, so long as you do not delete that region, very easy to unbrick. Checksum also isn't needed(has it, just not enforced). I am running so much custom stuff in mine without issues.

External flash has IMMO codes, mileage and other stuff from CEM, if those are deleted(immo specifically), yeah will not start.

It is my personal experience after 20-30 flashes(in car), that verifying downloaded contents isn't always necessary(saves time).

[BlackLotus]

There is no problem cloning cem via bdm

Were you able to successfully clone through the USBDM interface, or were you referring to some other (commercial) tools?

I just got the USBDM interface (12 bucks on Aliexpress) and unfortunately reading out the flashes/EEPROMs with the associated (open source) "USBDM Memory Dump" tool fails completely. With the 4 lines (BKGD/RESET/5V/GND) connected the interface can't even "talk to" the CEM (P1, 2005 V50).

As the 5V power supply via the USBDM wasn't good (4.7V), I then powered the CEM (via 5V/GND) from an external lab power supply (Rigol DP832) and just kept the BKGD/RESET lines connected to the USBDM interface. While the interface could now "talk to" the CEM, the USBDM Memory Dump tool was still not able to readout flash/EEPROM. I was prompted to reset the chip manually via power cycle (which i did via the power supply) and then got an error message saying that the chip was unexpectedly reset, potentially from a watchdog

I then fired up UsbdmScript.exe, which basically is a kind of command line to the USBDM interface. After figuring out the correct commands and command order (settarget HCS12 / openbdm / reset s h / connect) to directly talk to the chip, i was still encountering quite weird issues. When reading the the various registers (commands: gs, rcreg, rdreg, rreg) and parts of the memory i got quite "random" results (e.g. the chip would return "unstable" values for the registers indicating the BDM status or the security status).

I also tried pulling the RESET line high (through a resistor, to try to override an external reset signal), but that also was not able to stop the (assumed) "reset loop".

Right now i don't even know if the chips (left one MC9S12DG128B, right one MC9S12DT256B) on my CEM are secured or not (as like i said, the related security status indication registers don't report stable values, likely due to the "reset loop")

My guess from this is that the chip on the CEM is (by design) kind of "stuck" in an endless reset loop when powered "on the bench", potentially due to an internal watchdog (COP feature of the chip) or even an external watchdog (external chip connected to the RESET line and some other lines of the chip).

My further guess is that the commercial solutions (VVDI, X-Prog, etc.) are doing some additional things (likely timing resets and power cycles precisely, overriding external reset signals from a potential external watchdog chip by pulling the RESET line high, writing certain register values at the right time to disable the internal watchdog or initiate certain chip modes at the right moment, etc.) via the 4 connected wires, which the USBDM (which was built as a regular debug and programming interface but not for "chip hacking") is unfortunately not able to do.

Some literature research (Travis Goodspeed, Microcontroller Exploits, 1st Edition, 2024, No Starch Press, ISBN 978-1-7185-0389-2, page 350) indicates that for reading secured chips, the commercial tools are using a reset glitch to trick the chip into unsecured mode: "[...] they dumped the chip by pulling the reset line high with a very short pulse to confuse the HCS12 reset state machine". Another source (Chavez, Stephen, and Specter. 2017. From Robot Wheelchairs to Hacking Cars. 43rd Asilomar Microcomputer Workshop.) is also mentioned in that book. I then also found a related presentation by these two authors online at https://wikilab.myhumankit.org/images/7 ... ngV07B.pdf that on pages 42/42 shows the reset glitch on a logic analyzer.

But like i said, i don't even know if the chips are even secured or not (some other forums posts mostly suggest they are not, but i've also found someone claiming that only later P1 CEMs – IIRC post 2006 or 2008 – are unsecured), but my current problem is the "reset loop" anyway.

Any input, feedback or help would be appreciated. Are the chips on the P1 CEM (V50 2005) secured or not? Has one of you been able to successully clone such a CEM via the open source USBDM interface and how? What are the commercial tools doing differently (for getting around the "reset loop") for being able to clone this CEM?

[oeben]

2004 XC90 with water damaged and burnt CEM.
Car VIN YV1CZ796751160023.

31282455 CEM H
M32C / M30835FJVGP.

It's not communicating so I cant use diagnostics in car, although car starts with this and wipers run all the time etc.
Opened it and tried JTAG with Autel XP400, it will not read stating it needs login password.
Kind of hard to get the PIN when it does not communicate any more, I thought I should be able to read it directly anyways?

I have a spare 30786890, that one has M3030855FWUGP, not identical inside as it's missing components, that one reads fine with XP400.

What would be my best chance forward? Factory new CEM? I would attempt with Teensy but it would take me weeks to get the components, and as it was not communicating I have my doubts.

Autel instructions:

M30855FW Operation guide:
1. This chip need enter 7 bytes login password in the "SEC", and read or write data when the login password passed.
2. If the chip is blank any login password can pass.
3. The login password is the 7 bytes data in FLASH
byte address:
1. 0x4FFDF
2. 0x4FFE3
3. 0x4FFEB
4. 0x4FFEF
5. 0x4FFF3
6. 0x4FFF7
7. 0x4FFFB

M30835FJ Operation guide:
1. This chip need enter 7 bytes login password in the "SEC", and read or write data when the login password passed.
2. If the chip is blank any login password can pass.
3. The login password is the 7 bytes data in FLASH
byte address:
1. 0x5FFDF
2. 0x5FFE3
3. 0x5FFEB
4. 0x5FFEF
5. 0x5FFF3
6. 0x5FFF7
7. 0x5FFFB

[porcupine7655]

I can only say how I did read out flash on a CEM L with M30855FW cpu. Mine have all 0 in the key bytes.
Internal in chip there is a serial monitor that run over serial port when some pins are connected in special way.
(here Vcc is chip Vcc and NOT 12 VOLT)
CNVss => Vcc
P5_0 (CE/WRL) => Vcc
P5_5 (EPM/HOLD) => GND
P6_7 Tx (Connect to USB Serial converter RX Pin)
P6_6 Rx (Connect to USB Serial converter TX Pin)
RST => When power is applied GND, then switch over and connect to Vcc

Then I readout memory with attached python script.
NOTE: Needs to be adjusted to your chip and serial port. I run on Linux but it shall be possible to run in windows as well.

Code: Select all

krake:~/projects/Volvo BiFuel/cem/tools/python-serial-mode2$ python3 reader.py
ACK: Baud rate command accepted.
Bootloader version:b'VER.1.16'
[128, 100]
[128, 100]
[128, 108]
Read memory 0xfb0000 -- 0xffffff.
  0xfb0000................................................................
  0xfb4000................................................................
  0xfb8000................................................................
  0xfbc000................................................................
  0xfc0000................................................................
  0xfc4000................................................................
  0xfc8000................................................................
  0xfcc000................................................................
  0xfd0000................................................................
  0xfd4000................................................................
  0xfd8000................................................................
  0xfdc000................................................................
  0xfe0000................................................................
  0xfe4000................................................................
  0xfe8000................................................................
  0xfec000................................................................
  0xff0000................................................................
  0xff4000................................................................
  0xff8000................................................................
  0xffc000...............................................................
Done