MSS6x Flasher - Now released!

[Da Jemster]

Just the standard Pro K+DCAN cable buddy.

Thx Martyn!

[Martyn]

Expert K+DCAN or the Pro K+DCAN?

Just the standard Pro K+DCAN cable buddy.

[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?

[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.

[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]

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.

[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]

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]

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).

[Martyn]

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).

[Dash1]

Cool - is he willing to sign up and get in touch with me?

Yes, I'll pm you when he's signed up

[terra]

Interested in testing too! I've got a MSS60 in the garage and have a good bit of experience with BDM flashing/recovery if necessary. I have a bench setup as well. Please PM me details!

Sent you a PM.

And for everyone who has the app, please give me some feedback as soon as possible.

[snowcarver]

Interested in testing too! I've got a MSS60 in the garage and have a good bit of experience with BDM flashing/recovery if necessary. I have a bench setup as well. Please PM me details!

[terra]

I have a friend with an e60 m5 who’s interested!

Cool - is he willing to sign up and get in touch with me?

[Dash1]

I have a friend with an e60 m5 who’s interested!