Vida CEM swapping

[vtl]

The problem is CEM P/N 8690720.

8690720 will not crack on 0 or 2?

Nope. Shuffle order is 2, as confirmed by disassembler, however it still does not crack.

viewtopic.php?p=592875#p592875

[RickHaleParker]

Nope. Shuffle order is 2, as confirmed by disassembler, however it still does not crack.

Has his dump been run on different hardware?
Anybody check out his cracker build construction?

[vtl]

Has his dump been run on different hardware?
Anybody check out his cracker build construction?

This is CEM problem, not his cracker. I've got a similar report from other person.

[RickHaleParker]

This is CEM problem, not his cracker. I've got a similar report from other person.

I got got reports from two others, one of which has two 8690720s.
We can bring the total of 8690720 that will not crack up to a count of 4 + your reports if they are from different people.

[vtl]

Despite the pin was not found, see how average response latency drifts right with every new position:

Code: Select all

13:19:33.232 ->                    us:   137   138   139   140   141   142   143   144   145   146   147   148   149   150   151   152   153   154   155   156 
13:19:33.232 -> [ 91 -- -- -- -- -- ]:     1  6952     0 16051     1 14549     0   674     0     0     0     0     0     0     0     0     0     0     0     0 : latency    5610230; std 1678.65
13:28:09.457 -> [ 91 95 -- -- -- -- ]:     0   107     0  1026     1  5562     0 15318     0 17172     0   809     0     0     0     0     0     0     0     0 : latency    5781523; std 1754.15
13:36:45.684 -> [ 91 95 89 -- -- -- ]:     0     0     0    18     0   277     0  2373     0  8916     1 16696     0 11203     1   510     0     1     0     0 : latency    5915132; std 1622.53

Apparently something is going on in the CEM code, the pin compare routine executes longer. Which makes me think it is still crackable, just don't know how yet. I would say, shuffle order is wrong, but AA2020 shared his CEM dumps and I found the code, and now we know what the shuffle order is for this P/N.

Hmm...

[vtl]

The order is 5, 2, 1, 4, 0, 3. Could you try it with shuffle order set to 2?

Not working.

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

Can you try replacing random(100, 255) with random(0, 99) in that line?

[AA2020]

Can you try replacing random(100, 255) with random(0, 99) in that line?

[sirloins]

It looks like I have both the 719 and 720.

A while back when Rick asked me to try his changes I thought I had damaged my hardware, but in reality, I had swapped in the 720 CEM which others have had issues cracking.

The code seems the same, I followed it at least from the function that calls the PIN verification code. I am not too much of a hardware guy and at first glance, the boards look the same, same can transceiver as well. If there are some ideas to check from a hardware side let me know.. I have already separated my CEM boards so they are just the CPU boards now.

[vtl]

It looks like I have both the 719 and 720.

A while back when Rick asked me to try his changes I thought I had damaged my hardware, but in reality, I had swapped in the 720 CEM which others have had issues cracking.

The code seems the same, I followed it at least from the function that calls the PIN verification code. I am not too much of a hardware guy and at first glance, the boards look the same, same can transceiver as well. If there are some ideas to check from a hardware side let me know.. I have already separated my CEM boards so they are just the CPU boards now.

What CEM P/N did you crack initially when you've added P1 support? I've unified the code base awhile ago, based on testing with newer P1 CEM I have, and it's not unlikely older one is regressed.

[sirloins]

Originally I was using a 8690719. I think when I last tried the code (over a year ago I think) I was using the 8690720 CEM.

I will be getting both of those CEMs wired up again to test with.