[Pete.J]

If you're after upgrading from MSD80 to MSD81 read Part 1, otherwise if you're only after migrating from I8A0S (MSD80) or IJE0S/INA0S (MSD81) to IKM0S (1M bin) jump straight to Part 2.


Part 1: MSD80 -----> MSD81:

My car originally came with MSD80, it's a 2007 E92 335i, I've since upgraded to MSD81, I will discuss what's involved in the upgrade process in this part.

Starting the engine, how it actually works, a tale of a DME and a CAS:

There's a secret key called ISN Key, the DME and CAS (Car Access System) modules must have the same key stored in them. Without having a matching ISN Key, it's impossible to start the engine (remember this for now, we'll need it later).

For the engine to be started, a request and response procedure known as "Challenge-Response-Authentication" must first be carried successfully.

Those who work in the IT Security industry will be familiar with the challenge-response authentication technique. For those who don't know, briefly, a server (or a car module in this context) will send a challenge to a client (another car module), if the client successfully resolves the challenge, the challenger then grants access to the client to authorise it to perform a certain task.

To apply this to the context of our cars, as soon as you put the key in the key slot and the ignition turns on (also known as Terminal 15 state), the DME will challenge the CAS3 by sending it an random number, and asks the CAS3 to resolve it, and send back the result it came up with.

On the DME side:

The DME uses a random number generator each time the engine is started (also known as rolling-code). The DME will use the ISN Key (mentioned at the start) stored in its memory to hash both numbers together (random generated number + ISN Key), the DME uses a secret hash function to come up with a result value from these two numbers.

The DME will then send to the CAS3 that same random generated number, and challenges the CAS3 to hash it and send back the result value.

*Discussing hashing is off topic to this post, but just think of it that the DME solves the two numbers (random generated number + ISN Key) against each other via an equation or a secret function that no one knows about. The outcome of this hashing process will be saved temporarily in a volatile memory in the DME.

On the CAS3 side:

In the meantime, the CAS3 will receive that same random generated number from the DME, and it will do with it the same thing. It will use the ISN Key stored in its memory and use the random number it received from the DME, and hashes them together using the same hashing function that the DME used. Therefore, if the CAS3 has the same ISN Key stored in it as the DME, the final result value will be the same as what the DME came up with.

The CAS3 will send its answer to the challenge back to the DME, the DME will compare it to its own result, if they're both identical, therefore the CAS3 has responded successfully to the challenge that the DME proposed, so it must have the same secret ISN Key as the one stored in the DME, and authentication is approved, immobiliser is disabled, and the engine will fire up

The key point to take from this is, the DME and CAS3 must have the same ISN Key stored in them, otherwise the challenge-response authentication will fail. If the final result value that the CAS3 comes up with doesn't match the value the DME calculated, the immobiliser will remain active, and it's impossible to the start the engine. Even if you turn the engine manually, or power up the starter motor with an external power source, the DME will refuse to provide ignition and fuel (both coils and injectors are directly controlled by the DME), and the engine will stall immediately. So there's literally no way of starting the motor unless the above process succeeds.

The BIG Question:

You're probably thinking why doesn't the DME just straight up query the CAS3 about its stored ISN Key instead of all this challenge-response and hashing functions bullshit?! and if the CAS3 has the right key, authentication will be successful, if the CAS3 responds with the wrong key, authentication will fail.

Valid question, but the answer lies in two key points:

1- The ISN Key should never be broadcasted or sent across the CANBUS or any other communication channel within the car. It must only be stored internally in the DME and CAS3 modules themselves. If the ISN Key falls in the wrong hands, they can very easily steal your car!!

So for the security reasons, the ISN Key must NEVER be broadcasted outside the DME and CAS3 modules. The biggest benefit of the challenge-response authentication, it's a clever method to verify that the DME and CAS3 both have the same ISN Key stored inside them, but without having to actually broadcast this ISN key publicly, and without having to send messages to each other via the CANBUS to query if the other module got the same ISN Key or not... etc.

2- You might also wonder, if the random number initially gets sent publicly to the CAS3 by the DME on the CANBUS, and CAS3 responds back to the DME with the result value publicly via the CANBUS as well, wouldn't it just be very easy to use initially sent random number and the result to work out what is the secret ISN KEY value that the CAS3 used to resolve the challenge?

Logically it sounds like it's a security hole, but hashing functions got us covered . Hashing functions cannot be reversed. So if you know the random number generated and sent initially by the DME, and you also know the result value after hashing it with the secret ISN Key, you can never reverse engineer the hashing function to find out what's the secret ISN Key that the CAS3 used to come up with this result

Hash(Random number + ISN Key) = Result value

You can connect a listener device and use it to read all the data packets being sent through the CANBUS, this will get you the two numbers coloured in green, but you can never reverse engineer the hash function to come up with the one in red, which is the one that matters, the ISN Key.

Remember that the ISN Key is never ever broadcasted or sent via any of the communication channels in the car. It's kept totally secret inside the DME and CAS3.

Viola, that's it, that's how your car actually starts!

CAS-DME-EGS Diagram:

Here's a network diagram to see how all the modules involved in this process come to communicate with one another.



So how does BMW intend for faulty DME's to replaced?:

As discussed earlier the ISN Key must match between the CAS3 and DME, BMW AG has a large database of all the VIN numbers and the ISN Keys associated with each VIN. Identical ISN Key will be stored in each car's DME-CAS3 combo when it rolls out of the assembly line.

The way BMW intended for DME's to be replaced is, your local dealer orders on your behalf a brand new MSD81 DME from BMW AG in Germany using your VIN, BMW AG will get a brand new virgin MSD81 from Siemens/Continental and lookup your VIN in their database, to see what's the original ISN Key that is stored in your CAS3 module the day your car left the assembly plant. They'll upload the correct ISN Key to the new DME to match what your CAS3 got, and ship it to your local dealer. At this stage, it's just plug and play, and the car will start straight away.

So BMW AG never had the intention for the ISN Key to be changed on a secondhand DME, and they never had the intention to reuse a secondhand DME to replace a faulty one. The reason behind this, if they were to do that, then that means they'll have to allow the ISN Key to be publicly broadcasted on the CANBUS for the purpose of exchanging your faulty DME with another secondhand one. As mentioned earlier in the post, the ISN Key should never be broadcasted on the CANBUS, and there should never be a legit method to allow the ISN Key to be broadcasted on the CANBUS. For obvious security reasons mentioned earlier.

That's why, for any CAS module failure, or any DME failure, brand new modules must be ordered. Copying the ISN Key across from a DME to a faulty CAS, or from a CAS to faulty DME isn't permitted, and it's not an approved way to replace neither DME or CAS!

How we do it:

There are special ISN programmers that can be bought to copy the ISN Key from the DME to the CAS module.

To name a couple, Autohex II, BMW-Explorer, CGDI... etc.

Previously I contacted a couple of local electronics and Locksmith shops that specialise in European cars, and they had no clue what I was talking about

Eventually, one of those shops, referred me to speak with a company called "Injentronics". I called them up, I spoke to someone who seemed to know a little more about this than the Locksmiths I contacted earlier, but he still wasn't very familiar with the whole process. Eventually I asked him if they have an ISN programmer, he said yes, I asked for the model and looked it up online and it had the MSD81 and CAS3 listed as compatible!

Injentronics wanted $450 AUD for this, I thought it was a bit too much given that they didn't actually know what's going on, and I had to explain the process to them. So I am basically paying $450 to use their ISN programmer, but I am the one providing them with what needs to be done, no thanks hahah

Around the same time I bought my secondhand DME, my good friend vtl bought a CGDI Programmer to add to his arsenal of tools. CGDI is the cheapest out of all the ISN programmers mentioned above, but it does the job. So that was the ISN programmer I used for this.

How does the CGDI work:

Firstly, none of these tools are authorised by BMW AG, or developed by any of BMW partners. All these ISN programmers are developed by cracker/hacker to exploit security holes in the DME and CAS3.

-Preliminary task: open the DME box, swap the MSD80 with the new MSD81.

The way the CGDI works, is it flashed a dodgy DME software on my secondhand MSD81 DME. This dodgy software forced the poor MSD81 DME to spit out the secret ISN Key stored in its memory straight away.

As mentioned above, the DME and CAS3 are designed to absolutely never broadcast the ISN Key publicly on the CANBUS. But because the CGDI flashed a dodgy compromised software on my MSD81 DME, it compromised the DME security and forced it to spit out the ISN!

Now I have the secret ISN Key from the new MSD81 displayed on the laptop screen, all what's left now is to copy it to my current CAS3 module, that way the DME and CAS3 will have the same ISN and engine will start. But we faced major delays with this step, and spent two days trying to solve it

It turned out because I always keep all the software on my car up to date, I had flashed the latest CAS3 ZB number firmware that came in the V66 Daten a few months earlier. BMW has plugged a security hole that prevents writing an ISN Key to the CAS3, as mentioned earlier officially you're not meant to read or write ISN Key to neither the CAS3 or the DME.

The solution was very easy, I used WinKfp to downgrade my CAS3 to an earlier software version, and afterwards the CGDI programmer could successfully write the ISN Key from new MSD81 to my CAS3 with one click.

Before starting the car, I flashed my DME with the latest ZB number available for European WB72 E92 335i (Just the standard IJE0S for now to test), because I didn't trust starting the engine with the dodgy DME software from the CGDI flashed on it LoL , and also I updated the CAS3 again to the latest firmware found in V66 Daten (for security reasons due to the latest software being harder to read or write ISN Key to the CAS3 as proven already)

That's it, all done and all working perfectly, if you're in Australia, and looking to migrate from MSD80 to MSD81, I highly recommend vtl, I've known him for many years. My car was the first car we do this on, but after my car vtl has done a few, and there was absolutely no issues and all worked very smoothly. The only hiccup we faced when we did my car, was my CAS software was too new, that's about it. Btw I highly suggest you update your CAS software to the latest for security reasons.

Some pics of the process:

Shiny DME, I polished it with Autosol Metal Polish haha, why not?! I like everything clean and shiny, I wouldn't be surprised if I was the only person that ever polished a MSD81 metal case lmao :



CGDI connected to my car doing its thing:



My DME box was disgusting, I took everything out it and gave it a good clean, it had all this fabric tape that is used to bundle wires together in the DME box fallen at the bottom of the box.

There's also a suction fan to cool the DME where the red arrow is pointing, lucky none of that fabric tape got caught in it.



All cleaned up, I also put in new fabric tape to bundle the wires together like it was originally. I put small cable ties over each tape bundle so it never comes off again.



That was it, closed the DME box for good, and hopefully I never have to open it ever again!

Part 2: I8A0S, IJE0S, INA0S -----> IKM0S (1M):

DISCLAIMER: this goes without saying of course, but I am sure you all know you are responsible for any harm you cause to yourself or your vehicle following information and advice from this post

I thought about whether I am going to post this publicly or not, and eventually decided to post it to help push the platform develop. The issue with the N54 and other similar BMW platforms, is information hoarding! No one shares anything or any new discoveries, it's crippling the development of the platform, and I wouldn't want to play a role in that. I discovered how to flash the IKM0S myself with the help of two of friends, so I own the rights to the information you're about to read below, and I chose to post publicly to help others that are interested to head in the same paths.

Look at all other performance car platforms, JDM cars, EVO's, WRX's, Muscle cars... etc. they're all well developed and well understood, because people don't hoard information and they don't hide discoveries like the case on turbo BMW's platforms!

In the name of freedom of information for everyone

The DME has a coding parameter within it called "OLULCODIERUNG", which stands for "Power Class Coding".

All N54 cars, are Low-Power Class (hex data 00), except for the 1M which is Medium-Power Class (hex data 01), and the Alpina B3 is High-Power Class (hex data 02).

It doesn't matter how hard you try to change this coding data using standard tools like NCS Expert, it will never write to the DME memory the new data you entered.

Notice how on the screenshot below, it says to change the Power Class Coding in the DME, another parameter called "STAT_BSZ_WERT" must be equal to "0"?



STAT_BSZ_WERT is the number of working hours that the DME has worked since the day it was manufactured.

You can run a function in Tool32 called "STATUS_BETRIEBSSTUNDENZAEHLER", which will display the current working hours of the DME. The result of this function from my secondhand MSD81 DME is displayed below.



This is a screenshot with the description of the function for those interested:



There's also another function in Tool32 that can reset the working hours (STAT_BSZ_WERT) back to ZERO. And once the STAT_BSZ_WERT=0, then the DME Power Class Coding can be changed from Low (Data 00) to Medium (Data 01) using NCS Expert, as shown in that screenshot above.

But there's a problem, the DME working hours can't be reset to ZERO, unless the DME has done less than 10 hours of work only! And of course there aren't any secondhand MSD81 DME's that you can buy, that will have less that 10 hours on them.

So to recap:

1- You need to change Power Class from 00 to 01 in the MSD81 DME to be able to run IKM0S on your 135i/335i.
2- To do that, the working hours of the DME (STAT_BSZ_WERT) must be equal ZERO
3- To reset the working hours using Tool32 and a standard OBD or ICOM cable, the DME must have only worked for less than >10 hours since it was new.

Absolute mess!! And this is how BMW controls using the same DME across different car models with the same engine but with different power levels. The tune map loaded on the DME will check the Power Class Coding as soon as you put the key in the ignition, and if it finds a different Power Class stored in the DME than what it expects, it'll hit limp mode immediately, and remain stuck in limp mode indefinitely until it's sorted.

In the context of our cars, once you load up the IKM0S to your DME, it'll check the Power Class Coding of your MSD81, it'll find Low-Power Class (Data 00), and it'll be expecting to find Medium-Power Class (Data 01) like the 1M. So it'll enter limp mode and remain there.

This isn't exclusive to the N54, this is how BMW universally manages different power levels across the same engine using the same DME. A classic example is the N52 engine, the E60 5er exists in 523i, 525i and 530i forms, and all three use the same 3.0L N52B30 engine. All three use the same DME (MSV70 or MSV80 later on), the 530i has High-Power Class Coding in its DME which allows it to run a tune map that makes the most power out of the same motor, the 525i has Medium-Power Class Coding in its DME with a tune map to match it, and the 523i has Low-Power Class Coding in its DME with a tune to match to match it, If you flash a tune map that doesn't match the DME Power Class, the engine will enter limp mode and will stay there. (sometimes there are physical variations between the motors too, in case of the N52, the high power output versions had a 3 stage intake manifold that can vary the length of the intake runners to help with low end torque and top end power... etc. off-topic to this post).

The workaround:

A lot easier than you might think, there are two bits in the IKM0S bin, that toggle the Power Class checking on/off, by switching them off, the IKM0S will stop checking for Power Variant and Tuning Variant... etc. And it'll run on any MSD81 DME regardless, without interrogating or questioning the DME about its Power Class, Tuning Variant and Power Variant)

As easy as the fix sounds, finding it wasn't easy at all, the hardest part in this whole process, is to find out exactly which bits require changing, and that involved heaps of trial and error to get it right! Initially I had more bits defined on the XDF, and I had to try many different combinations until finally I hit the jackpot, and came to the conclusion that only these two bits require to be changed. I removed the others that didn't work from the XDF.

I have attached the XDF with those two bits defined at the end of this post, and I've explained in the steps below how to get there.

How to get IKM0S on your car:

1- You need to find out the correct ZB number for the 1M sold in your region, there's a few ways to do this, I prefer to look it up myself in the KMM.DAT file in the Daten folder. In my case, the 1M sold in my region will be European RHD with typschlüssel (type code) UR92. The correct ZB for Australian delivered cars and most likely all other European cars is: 8619148

2- Once you find out the correct ZB number, you'll need to use WinKfp with an ICOM cable or a trusted OBD cable and flash it on your MSD81. Follow the same instructions as flashing MHD, car on charge, don't open and close doors so you don't interrupt the CANBUS communication... etc.

I used an ICOM cable for this (BimmerGeeks OBD cable works fine for this too, can't comment on others)



3- Once it finishes flashing successfully, install MHD on Stage 0, and read the stock 1M bin with MHD and save it on your Android device. At this point, you'll have an error stored saying "2FA4 - DME: Incorrect data record". And if you take the car for a drive, it'll be in low power mode, and no boost. That's all expected at this stage.



4- Using the stock (Stage 0) 1M bin you saved from step 3, download the IKM0S XDF I attached to the end of this post and change the two bits; "Logical constant to disable check of power variant coding" from '00' to '01', and change "Logical constant to disable check of tuning variant via swt" from '00' to '01'. Save it and flash it back to the car, there will be no errors and the car will drive normally, just like a 1M, that's it! YOU NOW HAVE IKM0S FROM THE E82 1M RUNNING ON YOUR STANDARD N54 CAR

That's how it should look like before and after changing:

Stock 1M bin:



Modified 1M bin:



5- Change the diff ratio from 3.15 in the 1M tune to whatever your car has (3.46 for ZF auto, 3.08 for manual, 2.56 for DCT).

6- Port your custom tune across from your old IJE0S, I8A0S or INA0S. Remember that the memory locations are completely different between ROMs.

7- The 1M only came in manual, so the AT and DCT tables are populated with generic data from previous ROMs. Make sure you check them and compare them to your older I8..., IJ... or IN... bins, to make sure it's all alright.

8- This is the most important step, crack a cold one, stare at your car and admire all your hard work!



*Btw, this is only possible with a custom tune, unless you're happy to run with the stock 1M Power. The reason for this being that all MHD OTS maps are encrypted and cannot be modified using TunerPro, so you won't be able to change those two bits mentioned above using my XDF that I attached to this post. So if you flash MHD Stage 2+ on top of the 1M ZB number flashed using WinKfp in step 2, the car will still be in limp mode

Getting the ///M button on the steering wheel to work on your car:

You need to replace the steering wheel cluster with all the switches on it (one part) to the one from the 1M or the one from E9x M3. All 1M's had the correct part, however if you're getting this off an E9x M3, you need to make sure that it had ///M Drive. Because ///M Drive was optional on the early E9x M3's.
The 1M/M3 steering switch unit routes the signal differently than the standard part from non-M cars, hence why it has to be changed, cause that signal from the M button would otherwise go to the iDrive using the steering switch unit, but we need it to go to the DME.

The correct part no. is: 61319123060 (based on my car being a European RHD E92 335i with rain sensor... etc. Makes sure you perform your own checks before purchasing).



I managed to find a ///M button for my steering wheel, but even if you don't replace the button and kept your standard radio button (or whatever your car has instead), your old button will still function fine as a ///M button, it'll just have the wrong logo on it.



Lastly for the M Mode to work, you need to flash the 1M or M3 DSC software on your standard 135i/335i DSC module, I'll discuss this another time.

I also got a M3 cluster for my car, that way I can see the ///M symbol whenever ///M Mode is engaged. You don't have to replace the cluster, but that means you won't be able to tell whether M Mode is on or off. 135i owners will need a 1M cluster. The cluster programming is a completely different topic to all that, I'll discuss some time in the future.

That's how it all looks on my car atm: