Vida CEM swapping

[vtl]

I think it is a fine idea. I am just suggesting a possible way to automate it. Can you figure out a way to store the top three candidates for each of the three bytes and call them as needed?

I'm not convinced it's a good idea. We know that with our amount of sampling CEM yields a good margin for the right byte. If the latency difference is almost indistinguishable - something is wrong. Either cracker hw is not perfect, or CAN-bus is not operational, or pin shuffle order is not right, or CEM code has some special peculiarity that hardens it against timing attack.

Brute-forcing 3 bytes takes 100*100*100/1600=1666 seconds, ~1/2 hour. By adding 3*3*3 top candidates you just have to wait up to 12.5 hours. That still would be acceptable in some cases, I get it, but in most cases something is not right with something, so waiting 12 hours is wasting 12 hours. I've had 2 or 3 CEM dumps flashed into my CEM, previously reported as uncrackable. The cracker was able to crack them. After all, my bench CEM is itself among those "difficult" ones, with the stubborn third byte.

It would be quicker to run the cracker 3-5 times on the first two bytes. Don't wait for the rest, just start over. If you see them detected correctly most of the times, with a good margin over the next candidate - let the user enter these two values and brute force the rest 4. It would take up to 100*100*100*100/1600= ~17-18 hours, usually much less, but the correct result will be granted.

The current algo does something similar: instead of judging the best candidate in just one pass, it does a few iterations, shrinking the candidates list in half and increasing sampling time on every pass. In theory, the right candidate will float up to the top. When it's not - something is, again, not right. When folks post their logs here for such cases and then confirm their pin, I don't remember seeing the right values in top-3 or so.

[Sh4rp]

It would be quicker to run the cracker 3-5 times on the first two bytes. Don't wait for the rest, just start over. If you see them detected correctly most of the times, with a good margin over the next candidate - let the user enter these two values and brute force the rest 4. It would take up to 100*100*100*100/1600= ~17-18 hours, usually much less, but the correct result will be granted.

This is basically what I was proposing. If you get value x and y over and over for your first candidates, why calculate them with every new run. Type them in and let the code focus on the last byte, see if you can find a pattern there, or just go for the bruteforce with 2 candidates.

[vtl]

It would be quicker to run the cracker 3-5 times on the first two bytes. Don't wait for the rest, just start over. If you see them detected correctly most of the times, with a good margin over the next candidate - let the user enter these two values and brute force the rest 4. It would take up to 100*100*100*100/1600= ~17-18 hours, usually much less, but the correct result will be granted.

This is basically what I was proposing. If you get value x and y over and over for your first candidates, why calculate them with every new run. Type them in and let the code focus on the last byte, see if you can find a pattern there, or just go for the bruteforce with 2 candidates.

I usually hard code a known part of the pin in this way:

Code: Select all

diff --git a/volvo-cem-cracker.ino b/volvo-cem-cracker.ino
index 5b2fe4f..f9c2570 100644
--- a/volvo-cem-cracker.ino
+++ b/volvo-cem-cracker.ino
@@ -826,8 +826,10 @@ void cemCrackPin (uint32_t maxBytes, bool verbose)
   memset (pin, 0, sizeof(pin));
 
   /* try and crack each PIN position */
-
-  for (uint32_t i = 0; i < maxBytes; i++) {
+  pin[0] = X;
+  pin[1] = Y;
+  pin[2] = Z;
+  for (uint32_t i = 3; i < maxBytes; i++) {
     crackPinPosition (pin, i, verbose);
   }
 

[RickHaleParker]

I'm not convinced it's a good idea. We know that with our amount of sampling CEM yields a good margin for the right byte. If the latency difference is almost indistinguishable - something is wrong. Either cracker hw is not perfect, or CAN-bus is not operational, or pin shuffle order is not right, or CEM code has some special peculiarity that hardens it against timing attack.

Perhaps what we need is a quality check. How about: do 100 unlock requests using the same data set .. say 00 00 00 00 00 00 . Then look at the histogram. Grade the communication quality by the width of the spread or the standard deviation. Tight is good, wide is not good. Cut off point for a no go TBD ( To Be Determined ). If the grade is low, could inform the user and recommend they check their hardware. At least give them a warning that the probability of a successful crack is low. Perhaps an option to abort or continue.

Brute-forcing 3 bytes takes 100*100*100/1600=1666 seconds, ~1/2 hour. By adding 3*3*3 top candidates you just have to wait up to 12.5 hours. That still would be acceptable in some cases, I get it, but in most cases something is not right with something, so waiting 12 hours is wasting 12 hours. I've had 2 or 3 CEM dumps flashed into my CEM, previously reported as uncrackable. The cracker was able to crack them. After all, my bench CEM is itself among those "difficult" ones, with the stubborn third byte.

We did that math before. B2 being the stubborn one is the bases for my suggestion. If you look at the suggested perpetuation sequence you will see the first use B0 & B1 are the top candidates. They don't change unless you exhaust the B2 candidates.

It would be quicker to run the cracker 3-5 times on the first two bytes. Don't wait for the rest, just start over. If you see them detected correctly most of the times, with a good margin over the next candidate - let the user enter these two values and brute force the rest 4. It would take up to 100*100*100*100/1600= ~17-18 hours, usually much less, but the correct result will be granted.

That could be automated. Keep records of the top three candidates for each run. When you have three sets combine them into one set. Count the number of occurrences for each candidate. Three occurrences is a top candidate. Two occurrences is a runner up and one occurrence is a loser. Discard the losers and maybe the runner ups. From there we would need to work out a criteria to decide if it would be worthwhile while to proceed or not.

The current algo does something similar: instead of judging the best candidate in just one pass, it does a few iterations, shrinking the candidates list in half and increasing sampling time on every pass. In theory, the right candidate will float up to the top. When it's not - something is, again, not right. When folks post their logs here for such cases and then confirm their pin, I don't remember seeing the right values in top-3 or so.

The highlighted is a critical part. If B0 & B1 are not consistent in some way, continuing is futile.

In a previous post I suggested using consistent B0 & B1 then cycling a list of B1 weights that has been sorted by probability ( from the short lists ) . The idea is that it B1 should be near the top of the list. It should not take as much time to find the correct weight for B1.

[Sh4rp]

Well I gave it a few more tries but gave up due too the low temperatures around here.

It was actually kind of nice to have the dialogue and type in some numbers to shorten the time. However I think just as vtl said that I might still have a hardware problem.

Is there anything I can improve here? Of course I added the gnd between OBD and Teensy.

If not I will have to get some CF160. Maybe somebody here in Europe who got some laying around?

[vtl]

Do you still see/hear car glitches, like clicking relays?

[Sh4rp]

No not any more. The cracking process is running fine and the deviation is not so big anymore like I said but it’s still lacking the consistency. Pretty sure about 28 being the first but you all made me insecure about that again

[vtl]

Collect the logs the next time? 3 runs, up to and including third byte.

Also what's your VIN voltage on teensy?

[RickHaleParker]

If not I will have to get some CF160. Maybe somebody here in Europe who got some laying around?

If you cannot find some Bosch CF160s in Europe Look for NXP TJA1048 which is a third generation, 5V, dual high-speed CAN transceiver in a self contained package. You need only one. Data rates up to 5 Mbit/s. VIO input allows for direct interfacing with 3 V to 5 V microcontrollers.

I am think about getting some an build some plug and play CAN shields for the Teensy 4.0 then sell them. Might get some people that can code but cannot solder involved.

Don't upload you logs as Rich Text Format (.rtf ). It screws up the format when view in LibreOffice Writer and makes it hard to read.
A simple text file like the build in Windows Notepad works better.

[vtl]

I am think about getting some an build some plug and play CAN shields for the Teensy 4.0 then sell them. Might get some people that can code but cannot solder involved.

Do a PCB at easyeda.com. Then anyone can order them etched, soldered and shipped for like $10/piece (+ Teensy).