Vida CEM swapping

[rp9]

It was said multiple times that a good power source is mandatory. I flashed my bench CEM with a few dumps that people claimed uncrackable and got the pin in the very first pass.

In my case it is somehow the matter of the pin itself. Can you please set the pin to this one and try if it will be cracked (not shuffled, as is in flash): 57 99 91 53 67 58

[vtl]

In my case it is somehow the matter of the pin itself. Can you please set the pin to this one and try if it will be cracked (not shuffled, as is in flash): 57 99 91 53 67 58

Does it have a checksum? I've never changed anything in the dump.

From what I saw, the crackability depends on how the pin verification code is placed withing the address space (how it is aligned to something, like cache line or flash page?).

[RickHaleParker]

Got a CEM-H on the bench. Cannot get it to communicate with the pin cracker. The cracker just sits and waits for the CEM CAN-LS to respond.

Power Supply: ( 13.8V 2.5A )
+13.8V => D:8 & D:15.
GND = D:6

CAN bus:
CAN-HS => D:33 & D:48.
CAN-LS => D:40 & D:55

Termination:
120Ω D:31 & D:46 ( CAN-HS )
120Ω D:34 & D:49 ( CAN-LS )

What am I missing?

PS: Found it. It was poor connections on the solderless breadboard.

[rp9]

In my case it is somehow the matter of the pin itself. Can you please set the pin to this one and try if it will be cracked (not shuffled, as is in flash): 57 99 91 53 67 58

Does it have a checksum? I've never changed anything in the dump.

From what I saw, the crackability depends on how the pin verification code is placed withing the address space (how it is aligned to something, like cache line or flash page?).

No, it does not have any checksum. I modified it multiple times in the flash - it just works. I am asking for that, because in my case it somehow have problems guessing byte on position 2 if it is close to 100. If it is less then 50 - there are no problems with guessing correct value. Also, I already checked this pin on two different CEMs with different (probably) flash versions - in the car and on the bench. Same result.

[vtl]

No, it does not have any checksum. I modified it multiple times in the flash - it just works. I am asking for that, because in my case it somehow have problems guessing byte on position 2 if it is close to 100. If it is less then 50 - there are no problems with guessing correct value. Also, I already checked this pin on two different CEMs with different (probably) flash versions - in the car and on the bench. Same result.

Try with SAMPLES == 100.

[vtl]

The way the cracker works - it sends a sequence of 3 meaningful bytes in 6 bytes pin and collects the the reply latency. Originally it was 2 bytes, but in most of cases more samples are needed to collect a statistically meaningful distribution. It is possible to send these 2 bytes over and over, but why not sending the third byte?

Now, going over all 100 values in all 3 bytes (BCD bytes, 0-99, not 0-255) is 100*100*100 pins, which takes quite a time even at 500 Kbps. So there's that SAMPLES value that limits the range for the last byte. SAMPLES thus serves two goals: collecting more samples and scanning through the third byte as well.

The problem with the SAMPLES less than 100 is that it may or may not hit the correct byte. When it does, the pin comparison routing in CEM goes to the next byte check and that increases the latency, quite significant on some CEM software versions. When it does not hit the correct byte, the latency anomaly detection may fail. All depends on the CEM software.

So in cases when quick pin scan with the default SAMPLES=30 does not do anything - set it to 100 and have a couple of beers while it is scanning through the whole range.

[RickHaleParker]

Try with SAMPLES == 100.

Got Frankenstein to bench crack at Samples = 100, Latency + high_std.

I'm thinking the default code should be:
1. Samples = 100, Calc_bytes = 3.
2. Pick two sets for B0 - B1. First set based on Latency + high_std. Second set based on Latency + low_std.
3. Brute force using set one if it fails then brute force using set two.

That should produce a reliable code base.
Reliability is a higher priority than speed.
Would drastically cut done on "Not working for me".

Might want to add a version number so we can look at the output and tell what code the end user is running. I would print it out at the end along with any other information that would be helpful.

[vtl]

Can you read your CEM dump with T5Luke's software now? Curious about the pin routine placement in memory.

[vtl]

https://d5t5.com/article/volvo-cem-pin-code

> P2 — (S60 / V70II / XC70II / S80 / XC90) 1/ For cars MY2005 — 2012 (except 3,2 6V and 4,4 V8) decode via OBD with VDD — VDASH Dongle in 30 minutes!

Aha...

[RickHaleParker]

Can you read your CEM dump with T5Luke's software now? Curious about the pin routine placement in memory.

Have not tried yet. If you think you maybe able to glean some useful information from it I'll bump it up on my priority list.

How much current does the 5V power supply need?