Vida CEM swapping

[stevedi]

I just popped in to this thread to show my appreciation and gratitude for this information, it's been a major help. Yesterday I was able to crack my CEM pin over OBD (despite the CEM problems my car has) which I think is just the coolest thing ever. Definitely some very talented brain-power being put to use to figure out the timing attack method. Thank you guys so much!

To add to the information repository here: My 2005 S60R had its CEM replaced at some point by the previous owner, with an L-shaped unit marked CEM-H from a 2007 XC90 (part no. 30786890). Despite being a 2007 unit, the UDS method wouldn't work (I assume because it was programmed with 05 software), but the teensy cracker nailed it first try, in 28 minutes.

I'm the kind of person to half-ass something and force things that shouldn't work to work in an effort to avoid buying more components, so believe me when I say my teensy and 2515 dual-can shield became a mess of solder and wires in an effort to get this pin cracked.

[dikidera]

I just popped in to this thread to show my appreciation and gratitude for this information, it's been a major help. Yesterday I was able to crack my CEM pin over OBD (despite the CEM problems my car has) which I think is just the coolest thing ever. Definitely some very talented brain-power being put to use to figure out the timing attack method. Thank you guys so much!

To add to the information repository here: My 2005 S60R had its CEM replaced at some point by the previous owner, with an L-shaped unit marked CEM-H from a 2007 XC90 (part no. 30786890). Despite being a 2007 unit, the UDS method wouldn't work (I assume because it was programmed with 05 software), but the teensy cracker nailed it first try, in 28 minutes.

I'm the kind of person to half-ass something and force things that shouldn't work to work in an effort to avoid buying more components, so believe me when I say my teensy and 2515 dual-can shield became a mess of solder and wires in an effort to get this pin cracked.

It's terrible, I want to avoid this mess.

Anyway, on Nefariousmotorsports, I was told that the main chip executes everything, CAN,D2, A6 commands it's all there in the dump(sorry rkam for being stuborrn xD) I already have. My observation from the static analysis was of course that, that wasn't the case, because there were no references, pointers, nothing beyond the PBL commands. Yet when you powered the device, it was sending periodic CAN data, yet I could see no way for other code to reach the functions I identified as those related to CAN communication, which is why I thought it was done by the other chip.

I was assured that the HCAN controller was called indirectly and I was on the wrong path, I did search the binaries for function pointers that I know end uo using the HCAN registers, but nothing came up.
There is a peculiarity of the GNU SH compiler I think(or the original Renesas compiler) where offsets, addresses are incremented to end up at other addresses(perhaps for space savings). This naturally makes the static analysis difficult.

Example



The register MSTCR(in pink) is mov'ed(copied) to register r2 and then incremented by 0x44, this equals the MMIO address of the Port F data register, called PFDR, simply by searching for references to this data register would never have yielded anything.

If most pointers/addresses are constructed like so, you can see how it would be almost impossible to follow the logic flow/data flow. In fact, the function in the screenshot is called by another function, that is stored as a pointer in a table in the external memory, but...there are no references to it directly.

[rkam]

Looks like a very annoying CPU.

It's hard to tell if it is a "smart" compiler, useful in anyway, done on purpose, or just bloated C-code.
I know my brother wasn't happy disassembling C-code back in the Amstrad and Atari days.
It was so much easier to look at programs that was written in assembly directly.

Another annoying thing is hardware design I guess:

Assembly command "mov.l 0xFFFFA402, r0" looks like "D0 17" in HEX

31CCC6: D0 17: mov.l 0xFFFFA402, r0

The 0 in D0 is 0 in r0, that's OK.
But to find the data for the command you need to do a few tricks.

Strip the last two bits in the program counter. Had to think a bit do do this in Excel2002 on 32bit XP.
31CCC6 & FFFFFFFC = 31CCC4

Then add 4 times the offset byte + 4
17x4=5C
31CCC4+5C=31CD20
31CD20+4=31CD24

There you find the data:
31CD24: FF FF A4 02

[dikidera]

Yep, terrible architecture. I have one last trick up my sleeve though.

[vtl]

This is called a "position independent code". You can get the same hell on x86 when compiling with -fPIC. Usually not a big deal in opensource project where you have access to debug info.

[dikidera]

It's better on x86, simply because you can very easily attach a debugger and step through the code and have a very good idea of what the values are on startup. Ahem, harder maybe for bare metal x86, but literally every emulator can allow you to step through the code via gdb for instance.

[vtl]

I'm certain SH can do even better with BDM debugger.

[dikidera]

Hehe, I am exploring just that, unfortunately not with the JTAG interface(for now), because the pins have no nearby pads to connect to.

[oscilloscope]

How many Registers are present in this ic?

[dikidera]

If we just count the general purpose ones, 15. If we count the whole IC's architecture, then prolly over a hundred.