MSS6x Flasher - Now released!

[dpaul]

No idea. I don't have an MSS60 to compare the board to, though a friend said he'll try to get me good pictures tonight.

I know MSS60 uses EWS4 and MSS65 uses EWS3, and there are some component changes due to that (EWS3 uses unidirectional communication while EWS4 uses bidirectional). EWS4 is supposed to be able to fall back to the CAN-bus though so that in itself might not be a big issue

What I don't know is if there are hardware differences for things like the ionic module or if it's just purely software.

Really wish we could do something about the BDM access short of replacing the whole CPU.

.

I wonder if there is something that can be done about BDM access. The Freescale data sheet for the MPC56x clearly defines a mechanism for hardware censorship of the internal flash (UC3F) by setting censorship bits in the UC3F EEPROM Configuration Register. Censorship explicitly applies to debug modes (BDM or NEXUS), when booting from external memory or while under control of an external master. It seems like a simple mechanism that BMW might have employed to frustrate their customers. Perhaps you've already thought about this and could explain why it might or might not be a viable approach.

One technical problem is that in-circuit debugging tools are necessary to access and set bits, something like CodeWarrior and a PEmicro USB FX hardware interface. It's not clear to me from casual inspection of the data sheet but the shadow register censorship bits might not ever be accessible. In any case, I don't have such tools and their cost is not trivial. Second problem is that censorship cannot be cleared without loss of flash memory contents. So if you don't know your SK/ISN, and don't know how to retrieve it from the CAS3+ where it is encrypted (which I do not), you will never be able to start your car (unless you know how to defeat EWS, which I do not).

[terra]

I wonder if there is something that can be done about BDM access. The Freescale data sheet for the MPC56x clearly defines a mechanism for hardware censorship of the internal flash (UC3F) by setting censorship bits in the UC3F EEPROM Configuration Register. Censorship explicitly applies to debug modes (BDM or NEXUS), when booting from external memory or while under control of an external master. It seems like a simple mechanism that BMW might have employed to frustrate their customers. Perhaps you've already thought about this and could explain why it might or might not be a viable approach.

One technical problem is that in-circuit debugging tools are necessary to access and set bits, something like CodeWarrior and a PEmicro USB FX hardware interface. It's not clear to me from casual inspection of the data sheet but the shadow register censorship bits might not ever be accessible. In any case, I don't have such tools and their cost is not trivial. Second problem is that censorship cannot be cleared without loss of flash memory contents. So if you don't know your SK/ISN, and don't know how to retrieve it from the CAS3+ where it is encrypted (which I do not), you will never be able to start your car (unless you know how to defeat EWS, which I do not).

I believe it's doable. Take a look at the attachment (extracted from: https://www.nxp.com/downloads/en/dev...MPC56X_GMD.zip)

The change censor function is interesting. Said package include an s19 file that I believe can be uploaded directly via BDM using something like a PEMicro. Unfortunately the hardware and corresponding software is not cheap. This post (in the context of an MPC555, but close enough) states the ClearSensor function can execute from RAM. So I think that's the ticket.

Clearing censorship will wipe that internal flash. But between my app and my newly found ability to recover the EWS4 SK, that's fine.

[dpaul]

I believe it's doable. Take a look at the attachment (extracted from: https://www.nxp.com/downloads/en/dev...MPC56X_GMD.zip)

The change censor function is interesting. Said package include an s19 file that I believe can be uploaded directly via BDM using something like a PEMicro. Unfortunately the hardware and corresponding software is not cheap. This post (in the context of an MPC555, but close enough) states the ClearSensor function can execute from RAM. So I think that's the ticket.

Clearing censorship will wipe that internal flash. But between my app and my newly found ability to recover the EWS4 SK, that's fine.

That's interesting! I've been waiting for a used PEmicro multilink interface to appear on ebay or something but the MPC56x apparently needs the "FX" version which seem to be rare.

But even more interesting that you can recover the SK - will you share some information about that? Are you saying you can achieve a high enough level of authorization to read the SK from the DME via OBDII? Or that you know how to decrypt a CAS dump?

Edit: I can post some production model MSS60 pictures if you still are interested. I have to pull the DME to get them but it's a nice day in Boston and like most, I'm stuck at home and pretty tired of Zoom lectures and conferences.

[terra]

That's interesting! I've been waiting for a used PEmicro multilink interface to appear on ebay or something but the MPC56x apparently needs the "FX" version which seem to be rare.

But even more interesting that you can recover the SK - will you share some information about that?

Already posted it in another thread (look below this one) and sent you a PM as well.

And dammit, I didn't realize the 5xx needs the FX version. Thought the "Universal" would do it. Got the wrong one on eBay then. Oh well.

[Martyn]

Just an update on things i've tried on my bench MSS65 to 'break it' using MSS6x Flasher.
- Flash an MSS60 partial to it. It moans but is recoverable with a valid partial.
- Flash an MSS65 partial to it via a non modified K/DCAN cable over CAN multiple times, no brick so far.
- Power off the DME mid partial flash, flash fails obviously but is recoverable with a valid partial.
- Pull USB cable from laptop mid partial flash, this causes the flash to fail. The software will not then flash a valid partial until the DME is reset, partial flashing then works fine and DME is fine.
- Close the app during a partial flash. Once the app is re-launched it's not possible to connect to the DME again as it's detected as unsupported. A reboot of the machine fixes this, and flashing a valid partial means the DME is back to good health.

Seems pretty robust so far, although a warning about closing the app mid operation would be handy for those who don't understand the implications ;-)

I did manage to brick my bench MSS65 by flashing the RSA bypass to it via the non modified K/DCAN cable though. The DME no longer responds to 'wake up' commands so will need to be BDM'd to repair.

[terra]

Just an update on things i've tried on my bench MSS65 to 'break it' using MSS6x Flasher.
- Flash an MSS60 partial to it. It moans but is recoverable with a valid partial.
- Flash an MSS65 partial to it via a non modified K/DCAN cable over CAN multiple times, no brick so far.
- Power off the DME mid partial flash, flash fails obviously but is recoverable with a valid partial.
- Pull USB cable from laptop mid partial flash, this causes the flash to fail. The software will not then flash a valid partial until the DME is reset, partial flashing then works fine and DME is fine.
- Close the app during a partial flash. Once the app is re-launched it's not possible to connect to the DME again as it's detected as unsupported. A reboot of the machine fixes this, and flashing a valid partial means the DME is back to good health.

Seems pretty robust so far, although a warning about closing the app mid operation would be handy for those who don't understand the implications ;-)

I did manage to brick my bench MSS65 by flashing the RSA bypass to it via the non modified K/DCAN cable though.

Good feedback. I'll have to see if I can implement a warning and then at least exit more gracefully if an exit is still requested.

So for the partial flash with the non-modified cable, I think the DME will still boot (especially with the way I implemented the RSA defeat on the MSS65), but there will be some junk data in that tune if you read it back. The DME doesn't actually seem to validate the checksums during the flash process (which is a flaw that allows my full RSA bypass to work in the first place)

And yes, the full RSA bypass with a non-modified K+DCAN will be a true brick - which makes me especially nervous about MSS60 people. I could implement the RSA defeat differently so that a bad cable would lead to a WinKFP recoverable brick (with an ICOM or EdiabasLib cable). But doing so would basically double the RSA bypass flash time.

[Da Jemster]

I've successfully read read out partial and fulls from my bench MSS65 with this with no issues. I have flashed back modified partials with no issues over CAN so far (using a Bimmergeeks cable).

Expert K+DCAN or the Pro K+DCAN?

[Martyn]

Expert K+DCAN or the Pro K+DCAN?

Just the standard Pro K+DCAN cable buddy.

[Da Jemster]

Just the standard Pro K+DCAN cable buddy.

Thx Martyn!

[terra]

Expert K+DCAN or the Pro K+DCAN?

Either should be fine. Pretty sure they’re running the same firmware regardless

[terra]

Okay, updated the application:
Safety changes:

• Added sanity checks for loaded files.
• Tunes
  • Check that SW reference is compatible with installed program
  • Check that injection and ignition tunes are of the same version
  • Check that injection and ignition tunes are in the correct order
• Full writes:
  • Check that Program Reference is compatible with DME hardware
  • Check that injection and ignition programs are of the same version
  • Check that a tune is loaded in the binary and passes above tune checks
• Added a warning if you attempt to close the application in the middle of a flash process
  • This SHOULD allow the application to keep running while the warning shows, but I did have one instance where the flash got interrupted anyway. Maybe I knocked my cable or something. YMMV
• Disabled all buttons (ident/read/write) during active flash process

New Features:

• Ram dumping - hold shift while you click Read DME, and the software will dump the RAM and save each side as two different files
• EWS4 SK Reading (MSS60 Only) - Reads the injection RAM, searches for the EWS4 SK using a pattern search.
  • If successful, the key is displayed in the application and a file with the SK is saved (file will include the appropriate header to be pasted in directly at 0x7948 of the injection dump)
  • When doing a full read on the MSS60, the DME will search for the SK at the end and add it to the dump before saving the file (I did not thoroughly test this due to the nature of how long full reads take, but I expect it will work fine).

The previous link I shared with everyone should point to the latest version of the app

Now I want to pose a question for everyone about how I should handle the safety of the RSA flashing:
The trick I currently use to defeat RSA has the potential to permanently / unrecoverably brick non-BDMable MSS60s if flashed with a non-EdiabasLib cable
I can change the method slightly so that the bricks will at least be recoverable via WinKFP when using an appropriate interface -- however this method will roughly double the time it takes to do the RSA bypass
So what do you guys prefer I do? As much as it pains me to lose the speed, I'm sorta thinking it would be more responsible to do it the slower way.
Even with the above change, if someone flashes the DME Program (or repeats the RSA bypass) with a non-EdiabasLib cable after an RSA bypass has already been installed, the DME will unrecoverably brick - I cannot get around that.

[heinzboehmer]

So what do you guys prefer I do? As much as it pains me to lose the speed, I'm sorta thinking it would be more responsible to do it the slower way.

Why don't you have the slower way be the default and include a hidden option to enable the faster way? You could also include a warning message explaining the risks of using the faster method.

[terra]

Why don't you have the slower way be the default and include a hidden option to enable the faster way? You could also include a warning message explaining the risks of using the faster method.

Hmm, yeah that's probably the best way to go about it. I'll work on patching that in. Or maybe a warning popup in general would be good enough. If people still don't listen at that point, it's not really on me.

[Obioban]

Hmm, yeah that's probably the best way to go about it. I'll work on patching that in. Or maybe a warning popup in general would be good enough. If people still don't listen at that point, it's not really on me.

Default to slow, have a toggle with warning to enable fast, and I think you’re in the clear.

[terra]

Updated the app again. Fixed some of the sanity checks, and implemented a check to make sure the external flash looks reasonably correct.

Added a popup warning before flashing the RSA delete. I elected not to implement a slow mode, because people with the right cable should not need a slow mode at all, and people with the wrong cable should not be flashing at all. May revisit that decision

Think I'm getting closer to general release in any case.