Vida CEM swapping

[sjasliek]

Thanks for looking into this vtl!

I've just finished 'run 5'.
Default software, only samples increased to 100.
Again a different solution is found for the first two bytes.

I'll try to improve the power supply and do a few runs with ignition off.

Is it required to turn the ignition off/on between each run? After each run I just make changes to the software and start a new run; car remains on ignition in those cases.

[vtl]

That log is very noisy. At 500 Kbps the CAN cycle starts every 2 us, there should be very little entropy collected into 1 us buckets.

I've seen only one P1, it had the cracking going even without a key.

Also please check the CAN resistance in the OBD, you may need to remove termination in your cracker if it's already 60 Ohms in OBD.

[sjasliek]

Ok, so I've improved the HW and checked CAN bus termination:

- At the ODB connector, without anything connected, the resistance between CAN_H and CAN_L is 60 Ohms, for both the high speed and low speed CAN bus. So I don't need the 120 Ohms termination resistors on the hardware so I removed them.

- Also, I've built a power supply based on LM7805, some 100nF caps and some 47uF buffer capacitors. Pin 16 of the ODB connector provides power to the board. Pins 4 and 5 are GND.

- Close to the CAN transceivers I added 100nF on the 3.3V supply.
- Also 47uF capacitor added on the 3V3 supply.

The result is the same as run 1:
Candidate PIN 33 89 59 -- -- --
PIN is NOT cracked in 1334.46 seconds

How do you see how much noise there is.
Do you see any improvement compared to run 1?
Should I continue to do some runs but with more samples?

[RickHaleParker]

Thanks for looking into this vtl!

I've just finished 'run 5'.
Default software, only samples increased to 100.
Again a different solution is found for the first two bytes.

There is one other tunable parameter you can try. The clock speed.
Find this line: // set_arm_clock (180000000);
Un-Comment it by removing // : set_arm_clock (180000000);
This will change the clock speed from 600 Mhz to 180 Mhz.
Made a difference on one of mine that was not calculating the bytes correctly.

[sjasliek]

Thanks for looking into this vtl!

I've just finished 'run 5'.
Default software, only samples increased to 100.
Again a different solution is found for the first two bytes.

There is one other tunable parameter you can try. The clock speed.
Find this line: // set_arm_clock (180000000);
Un-Comment it by removing // : set_arm_clock (180000000);
This will change the clock speed from 600 Mhz to 180 Mhz.
Made a difference on one of mine that was not calculating the bytes correctly.

I'll try that, thanks! Any idea how lowering the cpu speed might give better results?

[vtl]

Do you see any improvement compared to run 1?
Should I continue to do some runs but with more samples?

No improvement.

Latency variation is very low here:

best candidates ordered by latency:
0: 33 lat = 430627
1: 43 lat = 430620
2: 51 lat = 430615
3: 87 lat = 430614
4: 57 lat = 430601

I wonder if the order is different than the code expects. Could you do 6 another runs with redefined shuffle_order like:

{ 0, 1, 2, 3, 4, 5 }
{ 1, 2, 3, 4, 5, 0 }
{ 2, 3, 4, 5, 0, 1 }
{ 3, 4, 5, 0, 1, 2 }
{ 4, 5, 0, 1, 2, 3 }
{ 5, 0, 1, 2, 3, 4 }

Just do the first byte and then load a sketch with the next shuffle order. You want to see a difference like that:

0: 02 lat = 872330
1: 94 lat = 870299
2: 33 lat = 870282
3: 31 lat = 870280
4: 00 lat = 870276

[RickHaleParker]

Any idea how lowering the cpu speed might give better results?

No idea whatsoever. VTL suggested it and it worked on that one.

[sjasliek]

No improvement.

Latency variation is very low here:

best candidates ordered by latency:
0: 33 lat = 430627
1: 43 lat = 430620
2: 51 lat = 430615
3: 87 lat = 430614
4: 57 lat = 430601

I wonder if the order is different than the code expects. Could you do 6 another runs with redefined shuffle_order like:

{ 0, 1, 2, 3, 4, 5 }
{ 1, 2, 3, 4, 5, 0 }
{ 2, 3, 4, 5, 0, 1 }
{ 3, 4, 5, 0, 1, 2 }
{ 4, 5, 0, 1, 2, 3 }
{ 5, 0, 1, 2, 3, 4 }

Just do the first byte and then load a sketch with the next shuffle order. You want to see a difference like that:

0: 02 lat = 872330
1: 94 lat = 870299
2: 33 lat = 870282
3: 31 lat = 870280
4: 00 lat = 870276

Okay, I edited the code a bit and performed 6 runs, where on each run the next shuffle order is selected.

Code: Select all

//unsigned char  shuffle_orders[4][PIN_LEN] = { { 0, 1, 2, 3, 4, 5 }, { 3, 1, 5, 0, 2, 4 }, {5, 2, 1, 4, 0, 3}, { 2, 4, 5, 0, 3, 1} };
unsigned char  shuffle_orders[6][PIN_LEN] = {
  // PIN order sequence to find out which digit responds best.
  { 0, 1, 2, 3, 4, 5 },
  { 1, 2, 3, 4, 5, 0 },
  { 2, 3, 4, 5, 0, 1 },
  { 3, 4, 5, 0, 1, 2 },
  { 4, 5, 0, 1, 2, 3 },
  { 5, 0, 1, 2, 3, 4 }
};

unsigned char *shuffle_order;

struct _cem_params {
  unsigned long part_number;
  int baud;
  int shuffle;
} cem_params[] = {
// P1
  { 8690719,  CAN_500KBPS, 0 },
  { 8690720,  CAN_500KBPS, 0 },
  { 8690721,  CAN_500KBPS, 0 },
  { 8690722,  CAN_500KBPS, 0 },
  { 30765471, CAN_500KBPS, 0 },
  // MINE
  { 30728906, CAN_500KBPS, 0 },
  // END MINE
  { 30765015, CAN_500KBPS, 0 },
  { 31254317, CAN_500KBPS, 0 },
  { 31327215, CAN_500KBPS, 3 },
  { 31254749, CAN_500KBPS, 3 },
  { 31254903, CAN_500KBPS, 0 },
  { 31296881, CAN_500KBPS, 0 },

Results:
Shuffle order 0 { 0, 1, 2, 3, 4, 5 }
best candidates ordered by latency:
0: 51 lat = 430609
1: 87 lat = 430603
2: 33 lat = 430601
3: 43 lat = 430591
4: 57 lat = 430581

Shuffle order 1 { 1, 2, 3, 4, 5, 0 }
best candidates ordered by latency:
0: 61 lat = 428240
1: 27 lat = 428237
2: 89 lat = 428211
3: 95 lat = 428210
4: 19 lat = 428209

Shuffle order 2 { 2, 3, 4, 5, 0, 1 }
best candidates ordered by latency:
0: 53 lat = 432191
1: 91 lat = 432172
2: 61 lat = 432171
3: 99 lat = 432164
4: 63 lat = 432158

Shuffle order 3 { 3, 4, 5, 0, 1, 2 }
best candidates ordered by latency:
0: 79 lat = 428546
1: 67 lat = 428542
2: 13 lat = 428519
3: 33 lat = 428517
4: 21 lat = 428508

Shuffle order 4 { 4, 5, 0, 1, 2, 3 }
best candidates ordered by latency:
0: 85 lat = 430586
1: 91 lat = 430575
2: 99 lat = 430559
3: 87 lat = 430553
4: 89 lat = 430543

Shuffle order 5 { 5, 0, 1, 2, 3, 4 }
best candidates ordered by latency:
0: 91 lat = 431499
1: 92 lat = 431461
2: 85 lat = 431453
3: 95 lat = 431444
4: 89 lat = 431434

So if i'm looking at biggest variation, shuffle order 5 seems to be the most promising? (delta = 38).
Still this is nowhere near a difference of more than 2000.
Note I've used samples = 30 for the above runs. Logfiles are included. At the start of each logfile I pasted the modified code.
Wondering what I should try next?

[sjasliek]

There is one other tunable parameter you can try. The clock speed.
Find this line: // set_arm_clock (180000000);
Un-Comment it by removing // : set_arm_clock (180000000);
This will change the clock speed from 600 Mhz to 180 Mhz.
Made a difference on one of mine that was not calculating the bytes correctly.

Tried it with default SW and only un-commenting // set_arm_clock.
PIN is not cracked unfortunately, see also logfile.

Candidate PIN 51 57 79 -- -- -- : brute forcing bytes 3 to 5 (3 bytes), will take up to 703 seconds
Progress: 0%..5%..10%..15%..20%..25%..30%..35%..40%..45%..50%..55%..60%..65%..70%..75%..80%..85%..90%..95%..
PIN is NOT cracked in 1334.42 seconds

[vtl]

Larger latency difference comes from matching 3 bytes subset: the byte in the current position, plus in the next two.

Say, the first two bytes are 55 and 66. The algo does the full 3 bytes matching when SAMPLES is set to 100. It goes from 00 00 00 all the way up to 99 99 99 - that's 100^3 of samples/CAN messages. Every matching byte adds a tiny bit of latency that is almost always lost on its way to Teensy, but sometimes it deviates into the next CAN cycle. When the algo does sampling of the 55 66 XX subset, those 100 subset messages gets the highest latency. When it samples 55 XX YY subset, those 10000 messages get a higher than average latency. Of course, the difference is so negligible that it's hard to see it, but when the entropy is accumulated over a large number of samples, it gives you that fraction of a percent that the aglo now can see.

So, say, your shuffle order (the pin bytes order in which the CEM compares pin sent over CAN with what's in its own flash) starts from 5. For algo to fully work for the first byte you need to figure out the next 2 shuffle position. For the second pin byte you need to add one more shuffle position. And so on. I.e. shuffle order needs to contain +2 known positions on top of CALC_BYTES, which is 3 by default.

Also I'm not sure the order is different in your CEM. It could be something else in CEM code that rounds up the accumulated latency to the next CAN cycle, and the jitter is lost.