Flashing the MK60 with ZCP software

[karter16]

Edit:

So chucking a quickly converted DSCM90 0PA into cpu_rec, I get a hit for "mcore" - while that could be a false positive, those microcontrollers look period correct? Example of one https://www.digikey.com/en/products/...CFCPU33/506191

Nice work! RISC processor (which would match with the TI chip if I'm right about it being the TMS470 series), onboard flash memory, correct pin count. Only thing is that the external clock pins don't seem right, but to be sure we'd need to trace a board to check.

[D-O]

This looks interesting.

[Bry5on]

This looks interesting.

Looks like that might just be the ABS flash on the Motorola MCU? From my understanding the Motorola handles ABS and the TI handles traction control. They don’t mention anything about traction control, steering angle sensor/ratio, wheelbase, track or the location of the accelerometer placement. Wonder if it’s deleted or untouched?

[terra]

I wonder if this is orderable https://www.schmiedmann.com/en/produ...4-50-8-298-264

[eacmen]

I wonder if this is orderable https://www.schmiedmann.com/en/produ...4-50-8-298-264

Was this a factory race mk60 for which car?

[sda2]

Back in 2021 I also tinkered around with the MK60 and started with simply checking the EEPROM. Turns out, that even that is encrypted. I changed the VIN from BV71030JZ45078 to BV71030JZ45079 and a lot of the memory content suddenly changed.

MK Motorsport Flash is the legitimate ATE/Teves Motorsport Flash, as the guy he sends it to was working for them back in the days. The unit is NOT opened during the flash, so it has to happen over CAN or K-Line.

I know that there was a Mini part number for a cable that came with those units to flash them.

Also there is a Discord for MK60e5 development, but lacking a racecar, i didnt bother to follow this in depth.

[terra]

Was this a factory race mk60 for which car?

I believe so. From the Z4 motorsport catalog

[D-O]

Back in 2021 I also tinkered around with the MK60 and started with simply checking the EEPROM. Turns out, that even that is encrypted. I changed the VIN from BV71030JZ45078 to BV71030JZ45079 and a lot of the memory content suddenly changed.

MK Motorsport Flash is the legitimate ATE/Teves Motorsport Flash, as the guy he sends it to was working for them back in the days. The unit is NOT opened during the flash, so it has to happen over CAN or K-Line.

I know that there was a Mini part number for a cable that came with those units to flash them.

Also there is a Discord for MK60e5 development, but lacking a racecar, i didnt bother to follow this in depth.

Does this mean the MK Flash is not just ABS, but stability control as well?

[Exclude3005]

Back in 2021 I also tinkered around with the MK60 and started with simply checking the EEPROM. Turns out, that even that is encrypted. I changed the VIN from BV71030JZ45078 to BV71030JZ45079 and a lot of the memory content suddenly changed.

MK Motorsport Flash is the legitimate ATE/Teves Motorsport Flash, as the guy he sends it to was working for them back in the days. The unit is NOT opened during the flash, so it has to happen over CAN or K-Line.

I know that there was a Mini part number for a cable that came with those units to flash them.

Also there is a Discord for MK60e5 development, but lacking a racecar, i didnt bother to follow this in depth.

Hey sda2, quick question.

I managed to modify the cruise control gear logic and successfully flashed it to the unit. The actual flash process completes just fine, but after the flash, when the pump's chip boots up and runs its self-verification, it throws an RSA signature error.

Did you ever pull a full BDM dump off that main Motorola MCU while you were tinkering with it? I need to dig into the base firmware to locate that exact RSA check routine and see if there's a vulnerability or a way to patch/bypass it.

If you have a raw dump you can share, it would be a massive help. If I manage to crack the bypass, I’ll definitely post the solution for everyone(BMW-ATE-MK60E5-8TH-gear-cruise-control-patch/readme-en.md at main · mem0rz/BMW-ATE-MK60E5-8TH-gear-cruise-control-patch).

[terra]

I don't think any of us have managed to figure out how to BDM the MCU, nor do we even know for sure what type of processor that MCU is.

I think most feasible strategy at this point would be to see if the MCU responds to any CCP protocol commands -- my suspicion is that is how the various guys who flash these things are doing so, since by all accounts the ones who know how don't open the things up, but the KWP2000 commands seem sufficiently locked down.

Since you managed to modify code, I guess you've figured out how to disassemble it? Any hints there?

[yuba]

I wonder if this is orderable https://www.schmiedmann.com/en/produ...4-50-8-298-264

MKRennsport can flash variants of this software to the 829.3 Z4 modules, I have one running in my car. It takes front and rear tire rolling circumference, 10 position ABS / stability setting, and a few other things over CAN.
I've also had a couple MK60E1 done by him.

I've poked around at them a fair bit and I have a fair idea on the tooling.

Does this mean the MK Flash is not just ABS, but stability control as well?

It is my understanding that the stability and ABS are intertwined. If you're asking about TC, I can tell you that mine takes high and low slip threshold over CAN but actual functionality isn't enabled in my variant of the software. There are other variants that do have TC, support for steering angle sensor, etc.

My assumption is those software variants output torque requests in a format that the Bosch Motorsport ECUs that were in the cars these modules were used in acted on.

[heinzboehmer]

Decided to throw some robots equipped with https://github.com/morluto/rea at this, just to see how far they would get. I still don't have a tool that lets me read/write to the MK60 over the OBD port, but I've learned a good amount of stuff.

I started the process by pointing the LLM to this thread and giving it an MK60e5 .0da to decompile. It got through a lot of it and eventually reached the flash read/write routines. When it had those figured out, it wrote a GUI to try reading from a real module.

At that point, I told it about EDIABAS and gave it access to the entire SP Daten folder, so that it could reference both the MK60 and MK60e5 .prg files. It compared its findings from the disassembly to what it learned from there and most of it was accurate. Honestly, pretty impressive.

I then spent some time trying to get the E46 MK60 to dump out the contents of its flash, but ultimately hit a wall. It looks like the module specifically denies the `ECUProgrammingMode` request over KWP2000. Think others in this thread have gotten to this same conclusion. Here's some logs from the probing tool:

EDIABAS initialised (SGBD 'dsc_mk60', interface from EDIABAS.INI); EDIABAS handle = 1
== FLASH-LOADER PROBE: entering ECUProgrammingMode via 07FLASH ==
(ABS will reset into its bootloader; power-cycle to recover)
== 07FLASH INITIALISIERUNG ==
JOB_STATUS None
== FLASH_PARAMETER_SETZEN auth=Asymetrisch;KWP2000* ==
JOB_STATUS OKAY
== 07FLASH DIAGNOSE_MODE ECUPM (-> 10 85, ECU resets) ==
JOB_STATUS ERROR_ECU_SUBFUNCTION_NOT_SUPPORTED__INVALID_FORMA T
_TEL_AUFTRAG b829f1021085
_TEL_ANTWORT b8f129037f10121e
== 07FLASH FLASH_PROGRAMMIER_STATUS_LESEN ==
JOB_STATUS ERROR_ECU_CONDITIONS_NOT_CORRECT_OR_REQUEST_SEQUEN CE_ERROR
_TEL_AUFTRAG b829f102310a
_TEL_ANTWORT b8f129037f31220f
== SPEICHER 010000;4 (flash addr) ==
JOB_STATUS ERROR_ECU_REQUEST_OUT_OF_RANGE
_TEL_AUFTRAG b829f106230100000304
_TEL_ANTWORT b8f129037f23310e
== SPEICHER 000000;4 (known-good addr) ==
JOB_STATUS ERROR_ECU_CONDITIONS_NOT_CORRECT_OR_REQUEST_SEQUEN CE_ERROR
== 07FLASH DIAGNOSE_ENDE (back to normal) ==
JOB_STATUS OKAY
_TEL_AUFTRAG b829f10120
_TEL_ANTWORT b8f129016001​

Hard to read, but the tool was able to boot the MK60 into programming mode (think NCS expert, not flash custom FW) and get a response from the `FLASH_PARAMETER_SETZEN auth=Asymetrisch;KWP2000` call. Unfortunately, the module errors out when the tool requests `DIAGNOSE_MODE` with `0x85` as the argument (this value corresponds to `ECUProgrammingMode` according to the MK60e5 disassembly).

So either the person flashing the race ABS has an alternate authentication method that does allow programming mode or the flashing is done over another interface. CCP was suggested in this thread and I'll probably mess with that next. Need to do more MK60e5 disassembly before that though.

Hard to condense so much info into one post, but here are some bullet points that the LLM spit out about things that have been learned:

• MK60e5 MCU is a Motorola SC550050 custom part; the core is M-CORE (big-endian, 32-bit, 16-bit fixed-width instructions), with on-die flash and a JTAG/OnCE debug port.
• MK60e5 firmware image stores at 0x48000 and runs at 0x40000 (a −0x8000 relocation); application code ends near 0xF691C.
• MK60e5 disassembly (Ghidra with a patched M-CORE SLEIGH module, 8514 functions) maps the KWP2000 service dispatcher at 0xB2B98/0xB2D8C, the per-service session/security masks, and a CAN + ISO-TP transport.
• MK60e5 M-CORE disassembly needed four fixes to the CUB3D SLEIGH module (github.com/CUB3D/ghidra-mcore): one-based addi/subi immediates, bmaski 32, mulsh, idly4, verified against binutils mcore-opc.h. Standard M-CORE bugs, not custom opcodes; afterward every undecodable site is reserved-encoding data.
• MK60e5 integrity model: the application CRC-sweeps its own regions but has no signature verifier; the signature is checked by the boot block, which is not in the shipped image.
• MK60e5 diagnostics run over D-CAN (KWP2000-on-CAN, IDs 0x6F1/0x629).
• E46 MK60 diagnostics run over K-line KWP2000: address 0x29, 9600 baud, 0xB8 explicit framing (working request B8 29 F1 02 1A 80).
• MK60 SPEICHER_LESEN is SecurityAccess-gated, limited to 4 bytes per request, and is one read per unlock. DIAGNOSE_ENDE relocks it, so each read is an ENDE→MODE→read cycle at about 3 bytes/sec.
• MK60 read ceiling is a ~512-byte NVM window (coding at 0x120, VIN at 0x150, DSC calibration at 0x190); addresses at or above 0x200 return out-of-range.
• ECUProgrammingMode (0x85) is not supported on the E46 MK60: StartDiagnosticSession 0x85 returns `7F 10 12` (subFunctionNotSupported), so there is no KWP2000 path into the bootloader.
• MK60 family’s programming authentication is asymmetric/RSA (confirmed on the MK60e5 SGBD DSC_89), which cannot be satisfied without BMW’s private key.

Repo is currently an absolute mess (cause LLMs), but I'll clean it up and upload to GitHub, so that at least the MK60e5 disassembly is captured somewhere.

Lastly, anyone have a dump of the MK60 flash? With the MK60e5 architecture figured out, I don't think the MK60 disassembly would be too hard.

[Bry5on]

Oh boy this is exceedingly exciting. Maybe we can hit the CAN bus directly to allow the MK60 to be programmed? It would seem almost trivial to add CAN messages and addresses that map to what the e46 expects if we get the MK60e5 decompiled for a full OEM-like retrofit.

[heinzboehmer]

Oh boy this is exceedingly exciting. Maybe we can hit the CAN bus directly to allow the MK60 to be programmed? It would seem almost trivial to add CAN messages and addresses that map to what the e46 expects if we get the MK60e5 decompiled for a full OEM-like retrofit.

Unfortunately, there doesn't seem to be any CCP functionality in the MK60e5 disassembly. So also highly unlikely that it's there on the MK60.

The people who flash the race ABS onto the MK60 seem to need have your unit in hand, so I wonder if they're doing something physically to boot it into the bootloader (grounding a pin, for instance).

Agreed about the messages though, that part seems super easy once it's fully disassembled.


And speaking of disassembled, looks like someone else had the same idea as me: https://github.com/cmg5461/mk60e5-firmware

They've had a few weeks head start, so their repo looks MUCH nicer than mine. They also got their hands on the bootloader section somehow (edit: not true, read too fast, they just have some assumptions in there), which might give some clues about how the one on the MK60 works. I need to spend some time going through all the info in there.

[heinzboehmer]

Man, that repo linked above has a ton of info. I'm pretty sure https://github.com/cmg5461/mk60e5-fi...ls/mk60_can.py can be adapted to work with the MK60, if we can figure out how to get it to boot into the bootloader.

Seed/key pairs I read from my car match the transform functions in the repo for the e5, so that means the encryption scheme is highly likely to be the same.

In theory, all I need now is an MK60 FW dump and the rest should be reverse engineerable.