Vida CEM swapping

[RickHaleParker]

A histogram bucket.

The Histogram is a Bucket sort, also known as a Bin sort.

It sound like the old method was rounding the data more so then the new method.

[RickHaleParker]

Anybody know the actual pad size along the edge of the Teeny 4.0? I got some traces running close to then and without the actual pad size I cannot be sure they will clear.

[x119]

It's Seed and Key based..

Do you have any clue what the SPA/CMA challenge algorithm is?

If I recall correctly, it would take way to long to crack the SPA/CMA through the OBD connector because there is something like a 5 -10 second timeout after three failed attempts.

60/10 * 3 = 18 attempts per minute.

There is a rumor that the Keys can be calculated from accessible data but it just a rumor until somebody can prove otherwise.

Algorithm, yes I believe so. EESE_Common_Security_Algorithm,_V_100070 - I have the .DLL which it's contained in. Decompiled it, but frankly I do not know what I'm looking at / for...

Interesting RE failure lockout. I'll try this and see if I can override with the tool I have..

Also have a vida.log AND a CEM Pin. Should help with reversing that out.

[RickHaleParker]

EESE_Common_Security_Algorithm,_V_100070

Do you have a link to this?

[Power6]

EESE_Common_Security_Algorithm,_V_100070

Do you have a link to this?

Hi, I've been working with x119 and a few others, we are trying to figure this out. We are techy, but not devs or EE. The basis we have is that VDash, is able to get the CEM pin thus: If you run VIDA (online legit version), on a laptop, and run a software load on your car ("config test" is cheap and easy), then you open VDash and connect to your car shortly after closing VIDA, some magic happens and VDash now has your CEM PIN and you can use it to change configs on your car. As you probably know, they won't reveal your PIN though, for better or worse you are stuck within their system. We want to get our PINs, knowing something is possible but very puzzled as to how they have worked it out.

What we know: and excuse anything I am dumb about, I'm smart but clueless on this stuff

• The CEM PIN is 5 bytes hex, likely all modules use 5 byte hex PIN on SPA.
  
  PIN is combined as a constant with the random seed input into security algo (aforementioned proprietary Volvo EESE CSA)
  
  VIDA appears to send PIN up to Volvo cloud to get the key. Volvo has the PIN for the car/module of course. PIN is never sent down
  
  VIDA logs contain tons of info tracing. The lines with security access are encrypted, so you can't just see seed/key history. In fact software downloads, instructions etc. are all encrypted.
  
  You can sniff the VIDA DOIP connection easily with wireshark and see the seed/key exchange. 3 byte seed and 3 byte key response.
  
  If one may have obtained say an internal engineering tool for diag/software, that tool may have a standalone security DLL that contains the algorithms. You could maybe attempt to decompile that DLL to follow the algorithm. There is still the matter of reversing that totally, and even then you don't have the PIN! But possibly the PIN constant isn't implemented totally securely and can be reversed from a previous seed/key input, or worst case the PIN could be offline brute forced, if you have the algorithms figured out.
  
  Correct you can't brute force this on the ECU in question, I think I've seen the parameter for timeout is 5 sec between, and even then you have 2 inputs to derive, the algo AND the PIN constant, so that's basically not possible. I got no clue how it works on the older platforms, I'm just starting with how the SPA works.

So I am a bit baffled at how the VDash folks can do this. Seems possible but they would have had to reverse the encryption on the log entries (which I suspect is a common key to all VIDA installs), then they get a seed/key combo, then they send that up to their cloud, where they have reversed/reproduced the Volvo algo, and they brute force reverse the PIN from there?

That's where we are at, if you want to take a look at the engineering tool and that will have the security DLL, you could register on the forum x119 set up, over on v-spa.net it's posted there.

I'm a bit hopeful at the implications if we solve the challenge. I think Volvo is leaning on the PIN process, which is good as they are unique per car, per module. But once you have that PIN, the algo seems to be standalone, within the DLL it looks to handle variable length and multiple level of security access (3,5,11,17) key gen. There is further stuff with the ECM of course, 2019+ Denso not been cracked yet, there is more to that, AES-128 encryption. But changing CEM config and getting into other modules is quite possible.

Sorry for the book...just wanted to bring anyone up to speed who may be able to help us!

[x119]

^^ See lots of interest already in the form of new activations. I will activate users as appropriate once we've had a bit of a cleanup of some PID.

To date (couple of weeks) it's been closed with a handful of users. I want to make sure they are and remain protected.

This is a community project using items we have sourced across the internet through the kindness of others.

We don't host any tools on the site, let's be explicitly clear on that. Nor do we have an interest in doing so in the future. If you're registering in the hope of finding said tools you're going to be disappointed I'm afraid. You will however find lots of screenshots, logs and a handful of determined people looking to make a difference! If you have no interest in contributing to our - now seemingly growing - community then I ask you don't register.

I created the forum on the basis that SPA has a home, I don't really want to dilute others efforts around the P1-3 platformed cars. I hope you all can find use for it!

[RickHaleParker]

So I am a bit baffled at how the VDash folks can do this. Seems possible but they would have had to reverse the encryption on the log entries (which I suspect is a common key to all VIDA installs)

A lot of times you XOR a key string with the encrypted string. Easy to figure out once you have a encrypted and unencrypted pair.
There is a good chance the key string is some place in the VIDA database. It might be in the .dill . Look for 5 byte XOR operations.

[RickHaleParker]

You will however find lots of screenshots, logs and a handful of determined people looking to make a difference!

I finding nothing at all. Not a single post.

[x119]

You will however find lots of screenshots, logs and a handful of determined people looking to make a difference!

I finding nothing at all. Not a single post.

I'm approving registrations at the moment - I've now done yours so you'll see everything to date. Go easy on us

[vtl]

Regarding 719/720 P1 CEMs. I've got my new awesome 400 MHz analyzer and can attest that

- Teensy is very fast! CAN-L pin poll cycle is less than 40 ns, and that includes IO pin write for debug purpose!
- the cracker code does nothing wrong
- CAN bus has no unexpected glitches
- it is only a matter of quiet time between crack attempts. 1 ms does it, 2 ms does it even more reliably

I've looked through MC9SX brief description and found 3 (or 4? forgot) CPU instructions related to lower power mode. When the CEM's code has nothing to do, it probably goes into lower power mode. CAN interrupt wakes it up, from there the code path to handle the unlock message is mostly constant, and that allows us to see a minor glitches in match/no-match latency.

I've also noticed that CEM consumes about 0.11-0.12 A when cracking at full 1500 pins/s and only 0.07-0.08 when cracking at 500 pins/s. So this sort of confirms the theory, though could be just extra power needed to push electrons over CAN wires.

Now, I'm working semi-lazily on the code change that won't break other CEMs. It will work slower than sirloin's code, because I don't want to fork cracking routines for different CEMs and have to support them ever since. Anyways, for most of people, cracking their CEM is a one time in life effort.