Vida CEM swapping

[ObliviousOrange]

Hi everyone, hopefully this is the correct place to ask. I have my CEM PIN and have done basic things like install heated seats with VDASH.
What I want to get next is global window open/close for my 2011 C30 (US-market C30s past 2008 do not let you close the windows with the key fob, only open them). There exists a VIDA procedure for this(https://charm.li/Volvo/2012/C30%20T5%20 ... agnostics/), and in VDASH it is an option for P3 cars. But nothing on P1s. And despite the process clearly existing, VIDA 2014D doesn't want to show me the option to make the change for this in the CEM, I assume it's only available for european market cars or older USDM ones. It acknowledges that global close is deactivated in the information tab, at least.

With what you guys all know, is there a way to find out the parameter for global window controls, and then program it to a different value and enable it for a USDM car? Maybe with some DID or something. Apologies if this is the wrong place to ask. Thanks for any help.

[RickHaleParker]

If ARM code execution gives a lot of jitter then what may help is turning off the speculations in ARM core, so it would execute the code slower, but with linear timing. Speculative execution and power saving.

Speculation = OFF makes a huge difference in Byte calculations reliability.
With Speculation On, CALC_BYTE = 3 is the best I can do.
With Speculation OFF, CALC_BYTE = 5 is the best I can do.

Not saying CALC_BYTE = 5 is the way to go. Just testing for changes.

All 5 bytes reached the top of the list in range 100 or 50.

Code: Select all

Candidate PIN 55 20 00 85 47 -- : brute forcing bytes 5 to 5 (1 bytes), will take up to 0 seconds
Progress: 0%..5%..10%..15%..done

found PIN: 85 20 47 55 20 00
PIN is cracked in 2389.30 seconds
Validating PIN
PIN verified.

Code: Select all

#define DISABLE_ARM_SPECULATION    /* comment out to re-enable ARM speculation 
#if defined(DISABLE_ARM_SPECULATION)

  /* Turn off the Cortex-M7's speculative/dual-issue behavior via the
   * Auxiliary Control Register (ACTLR, ARMv7-M Architecture Reference
   * Manual, also documented in the Cortex-M7 TRM). This is not the
   * "ACTLR" defined anywhere in the Teensy core headers, so we poke
   * the memory-mapped register directly at its fixed address.
   *
   * Bits disabled here:
   *   DISBTACREAD (13) - stop speculative reads driven by the branch
   *                       target address cache; a mispredicted branch
   *                       can otherwise let the core fetch/read past
   *                       a not-yet-taken branch
   *   DISFOLD      (0) - disable dual-issue instruction folding
   *   DISWBUF      (1) - disable the store (write) buffer, so writes
   *                       retire in program order instead of being
   *                       queued
   *   DISDEFWBUF  (14) - disable the default write buffer used for
   *                       AHBP (peripheral) writes
   *
   * None of this changes what the code computes -- it only removes
   * sources of cycle-to-cycle jitter in the ARM core itself, so the
   * TSC-based latency measurements this sketch relies on are more
   * repeatable. Expect a modest drop in raw execution speed while
   * this is enabled. */

  #define CEM_ARM_ACTLR (*(volatile uint32_t *)0xE000E008)

  CEM_ARM_ACTLR |= (1u << 13) | (1u << 0) | (1u << 1) | (1u << 14);

  printf ("ARM core speculation disabled (ACTLR = 0x%08lx)\n", (unsigned long)CEM_ARM_ACTLR);

#endif*/

[Volvisti]

hi,
i think this problem has been discussed before, but i cannot find it,
PIN is cracked in 3127.10 seconds
Validating PIN
PIN verified.

i tried it several times, i get the same (nearly, first4 are same) pin, teensy at 180mhz
but if i want to enter the cem, i get pin invalid. its a 31254317, anyone an idea?

[Volvisti]

@RickHaleParker eg. you cannot log onto the cem? as its not accepting the pin after verifying it. i only figured out, since i have the same cem in my car, that this one has a different software revision, which is older.

[RickHaleParker]

@RickHaleParker eg. you cannot log onto the cem? as its not accepting the pin after verifying it. i only figured out, since i have the same cem in my car, that this one has a different software revision, which is older.

What are you using to login to the CEM?

[Volvisti]

i wrote my own script, not working on this one, so i deleted everything from the cracker script, except the confirming part, and send the can request but does not work. on this cem, on the one in the car fine. hm

[Volvisti]

Unlocking CEM on HS CAN...
TX ID=000FFFFE DLC=8 DATA=50 BE 04 80 28 67 36 10
RX ID=00000003 DLC=8 DATA=50 B9 02 00 00 00 00 00
PIN rejected, status = 0x02
PIN UNLOCK FAILED

[vtl]

Unlocking CEM on HS CAN...
TX ID=000FFFFE DLC=8 DATA=50 BE 04 80 28 67 36 10
RX ID=00000003 DLC=8 DATA=50 B9 02 00 00 00 00 00
PIN rejected, status = 0x02
PIN UNLOCK FAILED

IIRC code 2 is "already unlocked".

[vtl]

If ARM code execution gives a lot of jitter then what may help is turning off the speculations in ARM core, so it would execute the code slower, but with linear timing. Speculative execution and power saving.

Speculation = OFF makes a huge difference in Byte calculations reliability.
With Speculation On, CALC_BYTE = 3 is the best I can do.
With Speculation OFF, CALC_BYTE = 5 is the best I can do.

Not saying CALC_BYTE = 5 is the way to go. Just testing for changes.

All 5 bytes reached the top of the list in range 100 or 50.

Code: Select all

Candidate PIN 55 20 00 85 47 -- : brute forcing bytes 5 to 5 (1 bytes), will take up to 0 seconds
Progress: 0%..5%..10%..15%..done

found PIN: 85 20 47 55 20 00
PIN is cracked in 2389.30 seconds
Validating PIN
PIN verified.

Code: Select all

#define DISABLE_ARM_SPECULATION    /* comment out to re-enable ARM speculation 
#if defined(DISABLE_ARM_SPECULATION)

  /* Turn off the Cortex-M7's speculative/dual-issue behavior via the
   * Auxiliary Control Register (ACTLR, ARMv7-M Architecture Reference
   * Manual, also documented in the Cortex-M7 TRM). This is not the
   * "ACTLR" defined anywhere in the Teensy core headers, so we poke
   * the memory-mapped register directly at its fixed address.
   *
   * Bits disabled here:
   *   DISBTACREAD (13) - stop speculative reads driven by the branch
   *                       target address cache; a mispredicted branch
   *                       can otherwise let the core fetch/read past
   *                       a not-yet-taken branch
   *   DISFOLD      (0) - disable dual-issue instruction folding
   *   DISWBUF      (1) - disable the store (write) buffer, so writes
   *                       retire in program order instead of being
   *                       queued
   *   DISDEFWBUF  (14) - disable the default write buffer used for
   *                       AHBP (peripheral) writes
   *
   * None of this changes what the code computes -- it only removes
   * sources of cycle-to-cycle jitter in the ARM core itself, so the
   * TSC-based latency measurements this sketch relies on are more
   * repeatable. Expect a modest drop in raw execution speed while
   * this is enabled. */

  #define CEM_ARM_ACTLR (*(volatile uint32_t *)0xE000E008)

  CEM_ARM_ACTLR |= (1u << 13) | (1u << 0) | (1u << 1) | (1u << 14);

  printf ("ARM core speculation disabled (ACTLR = 0x%08lx)\n", (unsigned long)CEM_ARM_ACTLR);

#endif*/

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

[RickHaleParker]

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 3  = { 100, 50, 25 };
 uint32_t samples 3 = { 10,  20, 50 };

for (i = 0; i <  3 ; i++) {

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

to play it on the safe side?