Vida CEM swapping

Post by **vtl** » 18 Nov 2020, 11:26

The algo fills the bytes in a "natural" way (left to right, ha-ha) and then has the bytes shuffled in a way that will match the actual checking sequence in CEM in order to have the best latency overhead for the good PIN subsequence.

https://github.com/vtl/volvo-cem-cracke ... r.ino#L129

Post by **RickHaleParker** » 18 Nov 2020, 12:13

vtl wrote: 18 Nov 2020, 11:26 The algo fills the bytes in a "natural" way (left to right, ha-ha) and then has the bytes shuffled in a way that will match the actual checking sequence in CEM in order to have the best latency overhead for the good PIN subsequence.

The "natural order" is what a application will need to unlock the CEM .. right? If so the "natural order" is the CEM pin not the shuffled string. I'm trying to clarify which sequence one would need to pass on to say the application Vdash. Or is it that the sequence order does not matter, just need to get the correct six bytes to unlock the CEM?

My Teensy 4.0 is out for delivered today.

Post by **vtl** » 18 Nov 2020, 12:21

The "natural order" is positions 0 to 5 (or 1 to 6).

You need to use the "found PIN" pin.

Post by **RickHaleParker** » 18 Nov 2020, 13:14

vtl wrote: 18 Nov 2020, 12:21 The "natural order" is positions 0 to 5 (or 1 to 6).

You need to use the "found PIN" pin.

I think I sorted it out. Went back and looked at your dump and compared it to your "Natural order". You are finding the bytes in the order they are stored in Rom. That make your "natural" sequence the decrypted string. The shuffle crypters it into the encrypted CEM Pin.

sirloins · Post by **sirloins** » 18 Nov 2020, 20:26

Almost ready to submit a pull request to vtl for supporting the P1 platform. Thanks a lot for the project vtl!

There was some variability to the response times (two groupings). So my changes are as such:

Shuffle is not necessary since the CEM processes the key in the order presented (in-flash it is still out of order, but that doesn't affect time)
Calculate min/max/average while calculating the crack rate.
Only look at the window 5ms before and 9ms after the average (update average after each candidate key)
Calculate the average ms per key instead of the product/sum.

I was able to do my CEM with 5 samples (more the better of course).
I also did the first 4-bytes, then brute force the last two.

One improvement I would like to make is to have more precision in the buckets, but have less of them. You can see the ms is very close sometimes, so I think if I had more precision in the ms values it would be better (as sometimes it is just 1ms difference in the average, I think I will convert to 0.25ms or so buckets maybe? It seems to help the process go faster with not many samples (only 5 on this try).

The total time it took was 150 seconds.

: Screenshot from 2020-11-18 22-21-32.png (15.28 KiB) Viewed 2014 times

: Screenshot from 2020-11-18 22-23-39.png (14.05 KiB) Viewed 2014 times

Post by **RickHaleParker** » 18 Nov 2020, 21:13

sirloins wrote: 18 Nov 2020, 20:26 You can see the ms is very close sometimes, so I think if I had more precision in the ms values it would be better (as sometimes it is just 1ms difference in the average, I think I will convert to 0.25ms or so buckets maybe? It seems to help the process go faster with not many samples (only 5 on this try).

There is a ms timestamp in the J2534 standard. The DiCE units are J2534. If a ms resolution will do. One might be able to develop a app that cracks through a DiCE unit. Hardware may already have.

If a ms resolution produces a small number of byte candidates too close to call, it could be solved by brute forcing the short list.

Post by **vtl** » 18 Nov 2020, 22:01

sirloins wrote: 18 Nov 2020, 20:26 The total time it took was 150 seconds.

150 seconds, 5 samples only per sub sequence, that's awesome!

Motorola in P1 CEM must be working with a much slower base frequency.

Also, what is your CAN bus speed? At 500 Kbps one clock is 2 us, even at 125 Kbps the resolution stays in a single digit us range, not ms.

Post by **RickHaleParker** » 18 Nov 2020, 22:10

vtl wrote: 18 Nov 2020, 22:01 Motorola in P1 CEM must be working with a much slower base frequency.

Look at the P1 PC board on page 14. The oscillator crystals are 4.0 Mhz and 8.0 Mhz.

Post by **vtl** » 18 Nov 2020, 22:15

RickHaleParker wrote: 18 Nov 2020, 22:10 Look at the P1 PC board on page 14. The oscillator crystals are 4.0 Mhz and 8.0 Mhz.

Yeah, that makes sense. P2 CEM with Renesas needs ~10x more samples, and it runs at 30 MHz.

Post by **RickHaleParker** » 18 Nov 2020, 22:47

vtl wrote: 18 Nov 2020, 22:01 At 500 Kbps one clock is 2 us, even at 125 Kbps the resolution stays in a single digit us range, not ms.

Found this in the J2534 API: unsigned long Timestamp;/* receive message timestamp(in microseconds) */

Is it fast enough to do the crack?