Vida CEM swapping

[vtl]

Best CEM protection is in brick shaped ones, from P2 -04. It is the dumbest code, which is resistant to timing attacks because of how dumb is it

Mine is a 2001. In a way I'm glad the security is resistant to a timing attack since there's less chance of an outside attack on it. However, with it being so secure it makes modifications harder to accomplish.

I'm good with math, and having an Algo to work with makes things easier. It also makes newer models easier to hack.

Do you mind if I fork your code and do my own tweaks on it? (I have a working theory in my mind and I want to see if it works for the models that use the Algo I've been working with. P3, P5, and P6? Please correct me if I'm wrong.)

The whole idea of open source is that anyone is free to fork whatever he wants to work on. Go ahead!

[gnalan]

The whole idea of open source is that anyone is free to fork whatever he wants to work on. Go ahead!

Thanks!

What all models does the Algo work on?

[vtl]

What all models does the Algo work on?

All Ford Volvos and up: https://en.wikipedia.org/wiki/Ford_EUCD_platform

[gnalan]

Also because Volvo's hash function is sort of lame, it makes the same set of PINs valid despite of different SEEDs. It is easy enough to modify the hash function slightly in order to define a unique set of matching PINs for the SEED. Brute force would become impossible, at least not in a way like it is done today.

If you're only interested in a valid key response for a seed request, any of the 65536 possible PINs unique to that ECU would give you a correct key. Hence my theory I want to try out that *should* speed up the cracking time after a timeout happens and a new seed is requested. (Assuming I didn't miss something in your code that I've read through so far.)

[vtl]

If you're only interested in a valid key response for a seed request, any of the 65536 possible PINs unique to that ECU would give you a correct key. Hence my theory I want to try out that *should* speed up the cracking time after a timeout happens and a new seed is requested. (Assuming I didn't miss something in your code that I've read through so far.)

CEM expects a new SEED for every unlock attempt. Thus, 860 pin/s instead of ~1500-1600, like P2 can do, because P3 has 4 CAN messages per unlock attempt.

[RickHaleParker]

I want to try out that *should* speed up the cracking time after a timeout happens and a new seed is requested. (Assuming I didn't miss something in your code that I've read through so far.)

The P3 does not have a timeout. P5 ( CMA ) & P6 ( SPA ) are the ones with timeouts.

What is your theory on speeding up the P5 & P6?

[RickHaleParker]

Best CEM protection is in brick shaped ones, from P2 -04. It is the dumbest code, which is resistant to timing attacks because of how dumb is it

I recall you saying someplace the latency difference starts to become sufficient when you step on 3 - 4 correct bytes. Sirlion was thinking that stepping on the correct bytes produces less latency not more. I keep thinking you said stepping on a correct byte adds 3 clock cycles of latency.

Could cracking for the first 3 -4 bytes simultaneously be a way to built up a latency difference enough to build up latency difference sufficient enough to detect the correct bytes?

Yea I know the memory requirements need to track that much data exceeds the memory of the Teeny but that could be off loaded to the host or lots of samples and shortlisting could be used to reduce memory requirements.

[vtl]

I recall you saying someplace the latency difference starts to become sufficient when you step on 3 - 4 correct bytes. Sirlion was thinking that stepping on the correct bytes produces less latency not more. I keep thinking you said stepping on a correct byte adds 3 clock cycles of latency.

That was said about L-shaped P2 CEMs running on M32C. I did a guesstimate about why we are able to crack M32C and why some of them are harder than others: viewtopic.php?p=571714#p571714

Sirloin's case (719/720 P1 CEMs) is a very special one. The chip needs to be put into a standby/low power/quiet mode before sending an unlock request, or it does not accumulate the latency right. This approach is either does not work well with other CEMs or reduces the crack rate severely, so the change is not merged.

There are a couple of read-only forum members out there, they run repair businesses and test all the changes ever mentioned in this thread, and report back in PM. I merge only the code that is confirmed to work and cause no regressions by others, as my testing abilities are not that great these days.

It looks like we need a separate code for just 719/720 CEMs. I've done some preparation work, but it has never left my local repo, as I need to test the new code on every CEM I have, it takes ages to wire them up correctly. Not to mention those adult life duties w/ 3 kids and ever going house renovation

Could cracking for the first 3 -4 bytes simultaneously be a way to built up a latency difference enough to build up latency difference sufficient enough to detect the correct bytes?

Yea I know the memory requirements need to track that much data exceeds the memory of the Teeny but that could be off loaded to the host or lots of samples and shortlisting could be used to reduce memory requirements.

It's not like that on M32C. It has 16 bytes something: cache line, flash line, etc. On these 16 bytes there's enough machine code to test 2 bytes, if the code is aligned to the beginning of the line (worst case for us). The latency of running the test via that line is not visible to the cracker, it is the transition to the next line is what yields enough latency to be seen over CAN. So you either test 3 bytes stride at once and get that 0.04% jitter back, or see nothing at all.

[gnalan]

The P3 does not have a timeout. P5 ( CMA ) & P6 ( SPA ) are the ones with timeouts.

What is your theory on speeding up the P5 & P6?

I haven't looked closely enough at vtl's code to see if he's already got the shortcut implemented. He seems to be ahead of me each time I think I find something new. When I was able to reduce my for loop as much as I did I didn't realize my value 0x909028 is the same value he already uses except bit shifted one bit to the left 0x1212050 using an extra nibble.

I'll work through it when I get a chance to, and if I don't see the theory in my head in his code I'll either do a rewrite on GitHub or post something here.

[RickHaleParker]

That was said about L-shaped P2 CEMs running on M32C. I did a guesstimate about why we are able to crack M32C and why some of them are harder than others: viewtopic.php?p=571714#p571714

This is what I was remembering viewtopic.php?t=85611&start=1700
This is the 4Mhz 68K ( CEM-B).

Particularly this:

- latency accumulation is very visible when the right subsequence is sent. 1 or 2 bytes don't make a difference, but 3 and, especially, 4 totally triggers it. Of course, CALC_BYTES=4 would be very slow on a 250 Kbps, but it is still better to leave the car overnight plugged into battery charged than taking the CEM out, cutting the tin box and soldering a programmer to the PCB or blowing the flash chip off