Flashing the MK60 with ZCP software

[heinzboehmer]

Worth having a read through this section of the facts.md as well https://github.com/cmg5461/mk60e5-fi...?plain=1#L1052

Yep! Should have given a bit more context.

On the MK60e5, the seed/key pair gets you "coding" access (security level 2). To get programming access (security level 5), you need to authenticate with a 128 bit keyed-MD5, which is fortunately stored in FW, so all you need is to read through a dump to find it.

The catch is that you need that FW dump to find the key that gets you programming access, but you also need programming access to get a dump from the MK60 non-destructively. If only BMW had given us a .0pa for it...

Then there's also the problem of signing a modified image. This part uses RSA, but it isn't super secure on the MK60e5, so you can find the private key by factoring. I'm guessing this step will be similarly trivial on the MK60.

It's looking like I'm probably going to have to get another MK60 unit to open up and read the flash directly from. But no sense in doing that if I can't first verify that the unit actually supports programming mode (or some other method of getting to the bootloader).

[terra]

If you share whichever keys you need factored, I should be able have my computer going at it. These days I can do them in under 24 hours each.

does your disassembly indicate whether the pre-BN2000 can communication and K-line mode exist at all in the code? I had hoped there would be a configuration switch since the Z4M Mk60e5 module does speak the old language.

I think it might be reasonable to poke at the modules with CCP and XCP comms anyway, not impossible for BMW to have left it in an older module. Someone I was corresponding with found the E60 dsc module did leave XCP open and allowed for a full dump

[George Hill]

heinzboehmer If you need an MK60 that can be sacrificed, I've got a few non-M here I will gladly send you.

[heinzboehmer]

If you share whichever keys you need factored, I should be able have my computer going at it. These days I can do them in under 24 hours each.

does your disassembly indicate whether the pre-BN2000 can communication and K-line mode exist at all in the code? I had hoped there would be a configuration switch since the Z4M Mk60e5 module does speak the old language.

I think it might be reasonable to poke at the modules with CCP and XCP comms anyway, not impossible for BMW to have left it in an older module. Someone I was corresponding with found the E60 dsc module did leave XCP open and allowed for a full dump

Awesome, will send some keys your way when I get to that point.

I'll need to check the disassembly for that when I get back home. I left the LLM to reconcile the work it had done in ghidra with the disassembly and symbol attribution work in that other repo. Hoping to have a nice and clean ghidra project to share soon, so that others can look through it too.

And good to know about XCP! I have a script to poke at the MK60 both via CAN and K line to try and get to the bootloader, but I haven't tested it yet. I've got an 817.3 module in my car and it would really suck to mess that one up

heinzboehmer If you need an MK60 that can be sacrificed, I've got a few non-M here I will gladly send you.

I'll definitely take you up on that!

I do think there's a lot to learn from the non-M modules, but I also fear that they're gonna be missing the flashing functionality in the bootloader. Getting a dump of the program would still be very valuable.

Internet lore says only 813.3/817.3 can be flashed, so unsure what the path is for the non-M modules. I would be surprised if the HW was limiting the flashing and instead expect that the 813.3/817.3 were the only ones that shipped with the FW routines for flashing.

Wouldn't be surprised if the non-M modules can be BDM flashed with the fully featured bootloader, but that involves both cutting the case open and having a binary to flash.

[Bry5on]

Awesome, will send some keys your way when I get to that point.

I'll need to check the disassembly for that when I get back home. I left the LLM to reconcile the work it had done in ghidra with the disassembly and symbol attribution work in that other repo. Hoping to have a nice and clean ghidra project to share soon, so that others can look through it too.

And good to know about XCP! I have a script to poke at the MK60 both via CAN and K line to try and get to the bootloader, but I haven't tested it yet. I've got an 817.3 module in my car and it would really suck to mess that one up



I'll definitely take you up on that!

I do think there's a lot to learn from the non-M modules, but I also fear that they're gonna be missing the flashing functionality in the bootloader. Getting a dump of the program would still be very valuable.

Internet lore says only 813.3/817.3 can be flashed, so unsure what the path is for the non-M modules. I would be surprised if the HW was limiting the flashing and instead expect that the 813.3/817.3 were the only ones that shipped with the FW routines for flashing.

Wouldn't be surprised if the non-M modules can be BDM flashed with the fully featured bootloader, but that involves both cutting the case open and having a binary to flash.

I wouldn’t be surprised if it were hardware-only, to the contrary. There are already hardware changes for the m-track pin, it might have a permanent pull down enable somewhere on the board.

[heinzboehmer]

I wouldn’t be surprised if it were hardware-only, to the contrary. There are already hardware changes for the m-track pin, it might have a permanent pull down enable somewhere on the board.

Yeah I guess that's a fair point. I'd still be surprised if the HW wasn't physically flashable, though. Lot more effort to implement HW fuses than it is to ship with a different bootloader or some extra populated component, like you suggested.

It sounds like you're gonna be opening up the unit either way, if you want to use one of the non-flashable ones. So cutting a trace or bridging some pads isn't too much extra work bs BDM flashing a new bootloader.

[liam821]

The SP_DATEN files do include the MK60e5 firmware, and different versions, so I'm going to assume there is a way to do a firmware update via CAN. Unfortunately, the files don't contain the e46 mk60 firmware.

[heinzboehmer]

The SP_DATEN files do include the MK60e5 firmware, and different versions, so I'm going to assume there is a way to do a firmware update via CAN. Unfortunately, the files don't contain the e46 mk60 firmware.

Yep, looking like KWP2000 over CAN is how the MK60e5 gets flashed.

does your disassembly indicate whether the pre-BN2000 can communication and K-line mode exist at all in the code? I had hoped there would be a configuration switch since the Z4M Mk60e5 module does speak the old language.

Just checked and there is no evidence of either, unfortunately. There's PT-CAN and F-CAN handlers, but nothing else. There's also a serial module (think it's for the wheel speed sensors), but there's no KWP handler that interacts with it.

Also, am kinda struggling to figure out how to share what I have. Ghidra project is looking pretty good (as in "correct", not as in "pretty"), but I hesitate to just throw it on GitHub cause the code is technically copyrighted. Open to suggestions.

[sda2]

{
"modulus_hex": "9EE558C73FF1D536B45D1E937C23477EA045F58060E2CD61D 9EC1A230C31E5BC35EF58A793F67AD3276E021921C2CDFEC2C 69114E0911EA6852D1FBDE6283C43",
"modulus_decimal": "8322052808596025508326157183733671757052436790813 95895883919766525405312676943056814429207257201070 70709144430836815530528571385272195789157838393667 90211",
"public_exponent": 7,

"private_exponent_hex": "2D66195D7FFBF3C67CACE42A2377CB48C013FD001BAE83D2D 08C99C0DEE9AF59E389A6DD615E67C1CC40C32982CC225ECF3 9247101640C305422323A71F13147",
"private_exponent_decimal": "2377729373884578716664616338209620502014981940232 55970252548504721544375050549866344731433848255494 10394227053677900019995584746882853348436645897453 69415",

"factors": [
{
"bits": 256,
"hex": "A955E1C9CCD6A88516F567ABFC157BDE00A07227C2620C7AE 46B7224548DBE97",
"decimal": "7659261174452750307244839539085462040917502079224 9448068162092966868633370263",
"probable_prime": true
},
{
"bits": 256,
"hex": "F037AED6F2556727C595EF5BDBE2D9D4ECDE1F619950E7827 A49FDCD02CE5135",
"decimal": "1086534669473603799959650375441196760073710336102 27670152744869990906624626997",
"probable_prime": true
}
],

"prime_factors_verified": true,
"product_verified": true
}​

I found this on the internet the other day. Maybe it helps for E5

[heinzboehmer]

{
"modulus_hex": "9EE558C73FF1D536B45D1E937C23477EA045F58060E2CD61D 9EC1A230C31E5BC35EF58A793F67AD3276E021921C2CDFEC2C 69114E0911EA6852D1FBDE6283C43",
"modulus_decimal": "8322052808596025508326157183733671757052436790813 95895883919766525405312676943056814429207257201070 70709144430836815530528571385272195789157838393667 90211",
"public_exponent": 7,

"private_exponent_hex": "2D66195D7FFBF3C67CACE42A2377CB48C013FD001BAE83D2D 08C99C0DEE9AF59E389A6DD615E67C1CC40C32982CC225ECF3 9247101640C305422323A71F13147",
"private_exponent_decimal": "2377729373884578716664616338209620502014981940232 55970252548504721544375050549866344731433848255494 10394227053677900019995584746882853348436645897453 69415",

"factors": [
{
"bits": 256,
"hex": "A955E1C9CCD6A88516F567ABFC157BDE00A07227C2620C7AE 46B7224548DBE97",
"decimal": "7659261174452750307244839539085462040917502079224 9448068162092966868633370263",
"probable_prime": true
},
{
"bits": 256,
"hex": "F037AED6F2556727C595EF5BDBE2D9D4ECDE1F619950E7827 A49FDCD02CE5135",
"decimal": "1086534669473603799959650375441196760073710336102 27670152744869990906624626997",
"probable_prime": true
}
],

"prime_factors_verified": true,
"product_verified": true
}​

I found this on the internet the other day. Maybe it helps for E5

Woah cool! Those keys fit what I have in my disassembly and work with the signing script in the other repo. Nice find.

Do you happen to still have the dump from when you were trying to read the MK60 EEPROM?

[sda2]

Yes, added to this post. But I ended up finding out that its XOR 0xFF in the VIN, so nothing really encrypted.

[heinzboehmer]

Okay, this feels way less illegal: https://github.com/heinzboehmer/MK60...sembly-Process

You should be able to clone the repo, point the robot of your choice at it, let it work and come back to a clean Ghidra project. I've tested this with the E9x M3, 1M and E9x 335i .0pa files (DSCM90, DSCM80, DSC90) that are typically distributed with INPA/WinKfp/etc. Hopefully this process translates pretty seamlessly over to an E46 MK60 dump.

Fable 5.1 (way, way overkill for this work) can go from absolutely 0 context to the clean Ghidra state in ~10 min (in a single turn!). You might trigger cybersecurity safeguards with these more capable models, though. I've tested Opus 4.8 and it works too.

You'll need to point whoever is doing the work for you at a local DSC .0pa file that you want disassembled. They're not included in the repo for copyright reasons.

Also, have continued chasing the CCP/XCP/other possible flash routes in the disassembly. Will update on that when I have concrete details.

[heinzboehmer]

Yes, added to this post. But I ended up finding out that its XOR 0xFF in the VIN, so nothing really encrypted.

Thank you! I'll run that through the disassembly workflow as soon as I'm back at my computer.

[heinzboehmer]

Thank you! I'll run that through the disassembly workflow as soon as I'm back at my computer.

Well, unfortunately looks like that EEPROM only holds the calibration data (what you can change with NCS) and things like the VIN.

We can still learn something from it, though. The e5 disassembly expects most of those fields in the offsets that they're in and also does the XOR 0xFF, which gives credence to the idea that the e5 shares a FW base with the MK60.

Back to trying to find a way into the bootloader!

[heinzboehmer]

Quick update on the leads I have for getting into the bootloader.

1. ECUProgrammingMode KWP Command

This is what WinKFP uses and is appears to be officially supported on the e5 only. Mentioned in a previous post, but I tried sending the same KWP commands that the e5 expects and got nowhere.

2. UART

This one is a cool new find. There's a serial handler that can respond to commands sent to its RX buffer. If you catch it early enough in boot (maths out to 1.8s after power on) and send the correct handshake + command, it'll trigger a function that sets up some CAN mailboxes (PT/F?), then jumps directly to the bootloader. Promising, but unfortunately there does not seem to be any path into the UART parser besides a write on the RX line. There's no way the line is exposed on the MK60 connector, so this will be useful for bench testing an opened unit only.

3. CCP

I haven't found an obvious CCP handler/mailbox like I have for PT-CAN and F-CAN, but I did find a singular function that is reachable from KWP (over CAN) service 0x31 with routine 0x31. All this function does is toggle a single bit flag that gets stored in the EEPROM. The flag looks to be present on the E46 dump as well. I'm hoping this means that there's either an `#ifdef e46_ccp` somewhere in the MK60 source or that the CCP handler lives in the bootloader.

George Hill is sending me an MK60 to test with (thanks again!), so I'm hoping to answer the CCP question soon.

If nothing else, I'll be able to talk to it via UART and see if I can get it to reveal some secrets that way.