Vida CEM swapping

[vtl]

Yes, as expected. I could not find how to disable speculation back then in 2020, but these days we have AI... Do a pull request, I'll merge.

You may also try to reduce the amount of samples per range and see how low we can go with the cracking sill being reliable: https://github.com/vtl/volvo-cem-cracke ... r.ino#L654

1. I have not touched git for for 4 - 5 years and I was not very good then. I will try to get it uploaded, then do a pull request.
2. All 5 got to the top in range 100 ( 10 samples ) or range 50 ( 20 samples ) 30 total.
Soo how about shorten ranges and samples to:

Code: Select all

uint32_t ranges[[b]3[/b]]  = { 100, 50, 25 };
 uint32_t samples[[b]3[/b]] = { 10,  20, 50 };

for (i = 0; i < [b]3[/b]; i++) {

    /* run through the range and exit if aborted */

to play it on the safe side?

AI can lead you through git/github process It is not difficult.

I don't have the cracker setup at the moment. Ask AI to come up with the testing methodology for that, it will be able to notice when the precision starts to worsen beyond being practical. This can be another commit in another pull request. Disabling the speculation is good on its own.

[Volvisti]

google says "On Volvo P1 platform vehicles (such as the C30, S40, V50, and C70), a 0x02 response during a security access or PIN brute-forcing operation indicates that the Central Electronic Module (CEM) has entered a security time-delay lock.This specific negative response code (NRC) surfaces when third-party tools or custom diagnostic scripts attempt to send incorrect security keys too rapidly while attempting to crack or unlock the module." thats why i am confused, since cracking worked.

[vtl]

Power cycle the CEM and send the pin again.

[Volvisti]

tried that, didnt help, i left the cem 1time 30 seconds, another time 5minutes off after successful pin verified. but as soon as i just restart and send the pin comman, rejected

[vtl]

tried that, didnt help, i left the cem 1time 30 seconds, another time 5minutes off after successful pin verified. but as soon as i just restart and send the pin comman, rejected

Show us your source code? Can paste on gist.github.com. Also a part of the cracking log, first 30 lines and at the end, where the PIN is printed.

[RickHaleParker]

1. AI can lead you through git/github process It is not difficult.

2. Ask AI to come up with the testing methodology for that, it will be able to notice when the precision starts to worsen beyond being practical.

1. GitHub desktop for Linux has gotten much better over the last 5 years. Its more push a button nowadays.

2. It would tell when my hardware starts to worsen. I am thinking about the other people with different cracker builds and different CEMs.
Do not want to push it too hard and break it for them.

[vtl]

2. It would tell when my hardware starts to worsen. I am thinking about the other with different cracker builds and different CEMs. Do not want to push it too hard and break it for them.

We have enough evidence that speculation is stepping in our ways. 180 MHz down clock, interrupt-driven one-pass P1 cracking by sirloins to mention a few. Share you code at least, people will test it.

[Volvisti]

not needed anymore

[Volvisti]

ok, i found it by puting up a loop for the last byte, not 10 but 20 - funny.

[RickHaleParker]

We have enough evidence that speculation is stepping in our ways. 180 MHz down clock, interrupt-driven one-pass P1 cracking by sirloins to mention a few. Share you code at least, people will test it.

Code is posted on a branch not pushed to main yet. Let have some people download and test it before pushing it to main and upstream.

The code is here.