Thought I'd add a little tutorial for the P2 vehicles.
For anyone who doesn't know me I'm an autoelectrician. I don't just play with wires like most, I dive deep into the inner workings of the flash files too for a better understanding.
I work on Volvo's quite a bit along with other manufacturers such and Jaguar/Land Rover/BMW/Aston Martin/Porshe, wherever I'm needed and when I'm needed.
So recently had a V70 2006 D5 Auto dropped off as a non start after being at the dealers for around 6 months and at my mates garage for roughly 2 weeks before it was passed to me.
Thought I'd do a walkthrough of what happened and how it was fixed for you all.
This vehicle was a non starter with "start prevented" on the instrument cluster with a DTC of CEM-6C49.
At the start of any diagnostics I always check the basics such as fuses, loose connectors or even damage to wiring, nothing was found.
Next I always start digging into live data, something a lot of people don't know how to interperate or don't understand.
Looking at the IMMO data we have the following:
Interesting..... The dealer had suspected the Antenna ring and changed it, however looking at the data, it shows the current key in the ignition is key 1 out of 2 keys.
The one think that is standing out is the key is authorised but the ECM is not happy.
Let's double check some things while I have my equipment out. Lets start with cheking the keys to double check if they are actually faulty.
Reading the key data several times show's the key is actually responding to requests and reporting a key number of CBDD0B31 - We'll note this for later.
After looking through ECM live data and CEM live data, theres obviously a communication error somewhere, but not the physical modules or wiring because we have communication.
Time to bring out some big guns and start deeper investigations.
Out comes the "Teensy Volvo Pin Cracker" built using this forum. Lets crack the CEM passcode and take a deeper look.
After retreiving the PIN Code we can now fire up IOTerminal, read out the CEM firmware, CEM Eeprom in both Encrypted and Decrypted format.
Lets start looking for some known data (from previous research)
Volvo tend to write in the processor binary files the security data multiple times, not sure why but possible for redundency.
I start by looking at the fixed EEprom security code. This is a 3 byte PIN.
Here we have 07 69 64
Let's also note this for later.
Let's move on and look at the key security.
I look for the Transponder Common Security Code.
This looks off
I have mismatched codes, from below you can see I have the following that do not match
Entry 1: 49 E3 BA 5B 14 6E 17 4A F3 A0 74 39
Entry 2: 48 E3 BA 5B 14 6E 16 4A F3 A0 74 39
This is not good, this code is used to decrypt the key when the communication takes place. So we now know the vehicle can read the keyID but not the contents of the transponder.
Let's move a little further, Let's check what KeyID is stored in the CEM.
Interesting, the keyID doesn't match but the secondary backup is correct.
Correct ID: CBDD0B31
Stored ID: CADD0B31
We are one HEX digit more than the stored value.
Let's try and confirm something, Let's read the ECM EEprom and confirm the security access code.
Hmmm..... Very odd, we appear to be one hex digit wrong here too.
ECM PIN: 076965
CEM PIN: 076964
Could this be the reason Volvo couldn't get anywhere, if the stored PIN on the Volvo server doesn't work how can they re add the keys. It would be impossible and the vehicle would require a new CEM, New Keys plus fitting and programming.
Not good news for the customer.
Time for a play, I changed the CEM EEprom pin to be what I think it should be. Reflash the EEprom data with IOTerminal.
Let's bring out Volvo DHA for some confirmations.
I load up DHA, open the correct database and connect to the vehicle.
I set up my logging for my own records but this is not required.
Time for security access. Althought this screen shot doesn't show it(my mistake), select CEM, select security access, select run, enter pin code and click ok.
No error's so we are good, we have security access. my hunch that the eeprom security data is corrupt was correct.
Let's read some block data and do some checks.
security code - immo = this is the encryption code used between the ECM and CEM, Checking the ECM eeprom this is correct.
PIN - IMMO = This looks good and must be correct now because we got security access.
Key ID 1 = CBDD0B31
Key ID 2 = CBDDE84D
Common Transponder Code = 00 00 00 00 00 00 00 00 00 00 00 00
Thats odd, in the file we have two corrupt Common Transponder Codes, Why is it showing all 00's? Maybe because they are different DHA just show's 00's?
Let's correct this:
Swap to Advanced mode, select CEM, Select write by block offset, select Common Transponder Code and enter the data, then run the routine.
Swap back to the basic mode and recheck the TP Common Code.
Looking good. However we don't know if this is correct anymore because the information is believed to be corrupt.
Let's delete all the keys and then attempt to reprogramme them, if the code is correct the keys will be reprogrammed, if not the key addition will fail because we can't decrypt the key.
Attempting to add the keys again several times after changing the Transponder Common Code keeps failing. The codes must be wrong. Worst thing is there is no other way to find the Common Code.
After trying multiple Common Code combinations from modifying the first and sixth byte (the ones that are different), I could not add the keys back into the system.
Time to pull out the key programming Autel kit.
I used the kit to unlock the key's, hoping in this instance I could add the key's again via DHA.
After multiple attempts DHA would not add the keys, as a test I programmed a third part ID48 chip, DHA added this chip with no issues and I got the vehicle started.
At this point I was pretty angry that DHA couldn't add the original keys, even though they were now blank and unlocked. I wasn't giving up though.
Now that the vehicle started, I read the EEprom data again with IOTerminal.
By pulling in the Encrypted EEprom data into my Autel programmer, I managed to add the keys back to the CEM Via a "Write key via dump" option.
After adding the keys i re wrote the EEprom data back to the CEM via IOTerminal. Tested the original keys and can confirm the vehicle is now up and running.
This success:
Things to further investigate - why the keys couldn't be reprogrammed to the vehicle after being unlocked, when the keys are unlocked they should wipe back to a virgin state.
I hope this was a good read for people, If anyone finds this info useful please add me some thanks and rep.
