MSS6x Flasher - Now released!

[terra]

That's a pretty big improvement! Hopefully that should prevent all those unaware / careless (even with the warning) still going ahead and flashing, then disabling their car because they 'weren't sure'.

Yep, I wish I knew the fix was so simple 6 years ago when I first wrote the application. Oh well

The ediabaslib firmware is definitely still better -- the write speed is much faster and I overall trust it more, especially for program writes. But for someone who's only flashing once, a standard cable is probably reasonable

[tdott]

Should be able to write to the DME safely.

That's a pretty big improvement! Hopefully that should prevent all those unaware / careless (even with the warning) still going ahead and flashing, then disabling their car because they 'weren't sure'.

[terra]

Does this mean the non-modified cables will be able to write to the DME safely? or just that they won't cause a brick scenario but still fail?

Should be able to write to the DME safely.

[tdott]

Version 1.1.0. Multiple updates since last release:

• Decreased size of flash blocks from 254 bytes to 252 bytes - this allows standard D-CAN cables to work without bricking

Does this mean the non-modified cables will be able to write to the DME safely? or just that they won't cause a brick scenario but still fail?

[terra]

I can confirm 170E requires an rsa bypass. Don’t know if there’s anything between 140e and 170e

[Martyn]

Works fine with 130E too, no RSA bypass required.

[terra]

terra
Do you plan to add a CPU lock/unlock feature to your software someday? In future updates?

At present no, I don’t think I quite have the skills to do so (well cpu lock I could add, would rather not).

As far as unlocking goes, imo not high priority to be able to do it over obdii. We can make a full backup without unlocking anything. And if you need to restore a bricked DME, you can just unlock it with the BDM device when the time comes. Pretty easy with the ulink nt device https://nam3forum.com/forums/forum/e...h-the-mss60-65

[MSSAddict]

terra
Do you plan to add a CPU lock/unlock feature to your software someday? In future updates?

[MSSAddict]

I just tested it with a 520E/160E program for the MSS65, and everything works perfectly. I also tested it with my MSS60 241E, and everything works perfectly. Great job!

[terra]

Thanks for testing all that- glad it works well for you! I’ll look into the 170e file shortly, thanks for sending that as well.
Reset DME is basically just rebooting it. Same as the steuergeraet reset job in tool32

[MSSAddict]

Hi Terra,

I tested your new version, and everything seems to be working perfectly.

I noticed that the full read speed is much faster: about 40 minutes compared to 1 hour before.

The RSA bypass is also much faster.

The Flash Tune feature works well after flashing the program section.

Adding files in BDM format is perfect.

The whole thing seems stable.

I was able to test the factory reset (RSA bypass removal) and it works: you just need to load the original full binary.


I sent you a 170E MSS60


Just one question, please: what does “Reset DME” mean?

[terra]

Application updated https://github.com/terraphantm/MSS6x...ses/tag/v1.1.0

Version 1.1.0. Multiple updates since last release:

• Updated Ediabaslib to newer release; .Net 4.8.1 now required
• Default port is now COM1 as EdiabasLib dropped support for D2XX on Windows
• RSA Bypass code is improved and notably faster
• Added ability to restore stock (i.e remove RSA bypass and patches)
• Tunes are now automatically flashed after flashing a program instead of having to click the "flash tune" button
• Reads are now done in "programming mode" and should be about twice as fast as before
• Full reads are now saved in both the combined format and in BDM format (separate files)
• If no VIN is found, VIN will be assumed to be AA00000 for file saving purposes
• MSS60 140E and older no longer require an RSA bypass for tune writes (also of note, if you have any software variants between 140E and 220E, please send them to so that I can determine where the exact cutoff is for the RSA bypass requirement)
• Detect if a "pseudo RSA" bypass used by some tuners is present, in which case the loaded file will be flashed without modification (i.e no checksum correction). Recommend manually correcting checksums or disabling checksums if this technique is used
• Decreased size of flash blocks from 254 bytes to 252 bytes - this allows standard D-CAN cables to work without bricking
• More safety checks implemented
• During the RSA bypass, the UC3F censorship routine is now disabled. This does not remove the censorship from the DME (need BDM or mpower32's software for that), but does prevent it from being set again.
• Added ability to request Level 3/4/5 security access to the Advanced Menu. Unclear if there are any uses for level 4/5, but makes it easier to test.
• Now display the "internal" software numbering (i.e v638 for 80E) if it is readable.
• Fixed a few UI issues

Probably more stuff that I'm not remembering. Let me know if you guys have any issues

[terra]

interesting, being able to flash the boot section without BDM would be nice.

So I did try just straight up changing the hardware reference and flashing (and also changing security access keys to the MSS65 ones). While it does accept the flash and respond to some INPA commands, it doesn't seem to boot completely as a lot of commands just don't work. Flashing back to MSS65 code from there worked fine, it wasn't bricked or anything.

That boot section does have a number of differences so I'm not sure replacing it is avoidable, though would have to study the differences closer.

I'm sure mpower32 would have the means to overwrite the boot sector given the other things his software can do (i.e clear censorship mode and restore the flash). I'm not skilled enough to write code to do that reliably myself.

[hobbit382]

interesting, being able to flash the boot section without BDM would be nice.

[terra]

So while I doubt most people will run into this (seems like no one else reported anything similar in the last 6 years) - for future reference if you have an RSA bypass'd DME and later on use WinKFPs expert mode to do some flashing and accidentally pick the wrong DME (i.e MSS60 file on MSS65 or vice versa), the DME will happily overwrite its bootloader with the new one. And this breaks a bunch of things... the DME doesn't actually want to run due to the hardware string not matching, and the RSA keys will no longer match what they should be, so security access is broken and the correct binaries will no longer have a valid signature as far as the DME is concerned. I was able to ultimately recover without BDM with a bunch of hacky changes to my app, but something to keep in mind. Unfortunately I don't think there's a fantastic way for me to protect against that sort of issues. From what I recall, other BMW DMEs would normally not copy the new bootloader if the hardware string doesn't match rather than complaining after the fact.

Good news is that might mean it's possible to crossflash MSS60 code to the MSS65 without BDM using a similar trick to what we do to get the CSL flash to work on non-CSL DMEs. I'll have to dig into the non-writeable code a little deeper to see if there's any major compatibility issues there.