Vida CEM swapping

[alevol]

Then check keep alive

[vtl]

99-04 brick-shaped P2 CEMs are not supported.

[urosm]

Hello to all!
I tried to crack CEM from the 2012 Volvo XC90, but I cannot for some reason.
Tried with OBD and on the bench. Same result. Also, I tried different shuffles, but without success.
So here are the logs if you find a problem, please fix it.

I have PIN from this CEM because I read it with SMOK and found a PIN. So if you need it, I'll send it to you.

Thanks!

2012_Volvo_XC90_CEM_PIN_not_OK.rar

(48.35 KiB) Downloaded 145 times

[RickHaleParker]

2012_Volvo_XC90_CEM_PIN_not_OK.rar

It looks like it is one of the stubborn ones that has trouble getting the third byte. You can set CALC_BYTES to 2 in the VTL:Master and brute force the last 4. You might try Sirlions interrupt branch or one of his other branches.

[vtl]

Hello to all!
I tried to crack CEM from the 2012 Volvo XC90, but I cannot for some reason.
Tried with OBD and on the bench. Same result. Also, I tried different shuffles, but without success.
So here are the logs if you find a problem, please fix it.

I have PIN from this CEM because I read it with SMOK and found a PIN. So if you need it, I'll send it to you.

Thanks!

2012_Volvo_XC90_CEM_PIN_not_OK.rar

What is the real third byte?

[urosm]

CEM PIN is: 15 52 29 21 65 26

[duzi]

I have PIN from this CEM because I read it with SMOK and found a PIN. So if you need it, I'll send it to you.

I thought smok" reads only P3 platform.. you use UDS option in smok ?

[vtl]

CEM PIN is: 15 52 29 21 65 26

Third byte (shuffled) should be 65, and it was indistinguishable in the very first pass and got filtered out. You can email me your dump, I may find time to load it into my CEM and try with my cracker, which seems to work fine in cases when others fail.

[vtl]

Hello to all!
I tried to crack CEM from the 2012 Volvo XC90, but I cannot for some reason.
Tried with OBD and on the bench. Same result. Also, I tried different shuffles, but without success.
So here are the logs if you find a problem, please fix it.

Here's your pin compare routine disassembled. Base address was set to 0, which is not the case in the real CEM, but the offsets remain correct, which suffices for our analysis.

cem-bad-3d-byte.png (84.03 KiB) Viewed 586 times

I draw a line through each cache line boundary. Don't know for sure whether it's a cache line, CPU frontend fetch unit , flash line or something else. But these 16 bytes is what executes in constant time from the cracker's point of view, while crossing the boundary is what yields latency that the cracker can detect. Each time CPU has to cross the line, add +1 to imaginary latency.

The cracker goes from byte 0 to byte 3 sequentially. 0-3 is called position. For each position the cracker enumerates the whole BCD range for the position itself and for the two following positions (that's the reason we can't crack more than 4 bytes). Going over 3 bytes/position accumulates enough discrepancy in latency to be noticeable for the algorithm.

In the picture above you can see an example of extremely unfavorable code placement: the boundary comes right through the conditional jump instruction.

When the cracker cracks positions 0 and 1, CEM's CPU does not cross the green line in case of mismatch. On bad cmp instruction it jumps to 0x4caf9, which is another cache line, and it adds +1 to latency, too.

When the cracker cracks position 2, it crosses the green line. After that, jumping to the "failed" branch, to 0x4caf9, adds no latency. The code executes in constant time and yields no good latency discrepancy.

This makes me think if the algo can detect such problem and switch to, say, +1 position enumeration?

[oscilloscope]

is codewarriror used too decompile the micro's ?