Vida CEM swapping

[yagger]

We use special algorithms for get access codes actually.

[vtl]

So it looks like the BUSY line in M32C is controlled from timer interrupt handler. The delay between last bit sent and BUSY lifted is 50 us with a very small jitter. The delay after ID sequence is fully sent is 500 us (well, 480 to 490 us). Going through all the permutations does not change anything significantly.

[RickHaleParker]

So it looks like the BUSY line in M32C is controlled from timer interrupt handler. The delay between last bit sent and BUSY lifted is 50 us with a very small jitter. The delay after ID sequence is fully sent is 500 us (well, 480 to 490 us). Going through all the permutations does not change anything significantly.

This is from somebody that did the M16C side attack. It pushes the delay to around 7500us. You can see smaller differences at a slower clock speed.

After running the measurements a few more times, we were quite sure that the timing was indeed different when the first byte of the key is 0xFF. I then disconnected the EC from its' 16MHz crystal to a signal generator, which I clocked down to a 666KHz square wave. With the chip now running slowly, I was able to quickly discern the time difference when measuring the time-until-not-busy for each possible byte of the key: [source]

[vtl]

Yeah, saw that. My latency detection threshold is about 170 ns.

[vtl]

As a Linux kernel engineer I was overthinking the problem. Not all software problems require a rocket science approach. Sigh...

With a kind help from Eastern Europe I've got a CEM dump where ID was found set to zero. Means, Renesas is unprotected. Also everyone there was surprised that I needed an ID to read the flash. Apparently Volvo does not protect M32C and you can freely read it with any BDM programmer that supports that chip. I have a cheap second-hand E8 from ebay and it works fine.

Once you solder the programmer to CEM and have the bin file read - pass it through CEM PIN decode sw, the one I could not understand, and here's your PIN! Which is purely a Volvo-thing applicable to CAN, not Renesas.

The link for pin decoding sw: https://www.digital-kaos.co.uk/forums/s ... -2005-2009

Because Renesas speaks through serial port in boot-mode, all you need is a FTDI adapter/chip to translate between serial and USB, and software like this: https://github.com/fightling/flash-renesas Not necessary to burn a fortune on $xxx BDM programmers like Smoke, or Orange or E8a.

[RickHaleParker]

Not necessary to burn a fortune on $xxx BDM programmers like Smoke, or Orange or E8a.

Good somebody got it all figured out.

The GitHub project looks like it flashes but does it read and make a binary file?

Would be nice if somebody would compile and make a installer for the non-coders and write a howto in plain English.

Redhat documentation for Serial mode 2 to program R8C, M16C, M32C, and R32C chips.

Redhat M32C project page.

[vtl]

Yeah, it does not read flash. Also, Renesas FDT programmer can read and erase flash, but can't write it back (timeouts). So my donor CEM is bricked. But I have a dump and will write my own programmer. The protocol is trivial.

[vtl]

Right now ebay has a couple of cheap Renesas E8 programmers. They price is about twice over Arduino board that still needs a software to be written (and it won't be a Windows one if I write it). I still will write the software because I need to unbrick my CEM, though.

[RickHaleParker]

Because Renesas speaks through serial port in boot-mode, all you need is a FTDI adapter/chip to translate between serial and USB,

USB = Universal Serial Bus. Can't the USB port be configured to communicate with the chip directly?

[vtl]

Short answer is: "No".