MSS6x Flasher - Initial Release

I believe the app has been sufficiently proven itself to be safe at this point and am comfortable releasing it now. You can grab it here: https://nam3forum.com/forums/forum/e9x-2008-2013/e9x-coding-tuning/11026-mss6x-flasher-now-released



Functionality:

• Ability to read and write tunes and program code
• Ability to read the ISN (MSS65) / EWS Secret Key (MSS60) over OBDII
  • This means a full backup can be made entirely over OBDII
• Ability to dump RAM

Safety:

• The software will verify that binaries loaded are in the correct format and order
• The software will verify that programs being written match the hardware you’re trying to flash, and will verify all tunes being written match the software you’re trying to flash
• If the tune or program are not stock, the program will make sure you have an RSA delete before continuing (you can override this warning, but the flash will likely fail if you don’t have an RSA delete that I couldn’t detect
• The program will not let you flash an RSA bypass if the binary being loaded doesn’t match the software variant you are currently on

Performance:

• Backup tune in < 5 minutes
• Full backup 45-60 minutes
  • 2 hours in long mode
• Flash tune in approximately 1 minute
• Flash full program in ~12 minutes
• Flash RSA bypass in ~15 minutes

Who is building the maps after flashing?

Good job!

Good news~! great job~!

Amazing! You did incredible work in the MSS54 community that's been a huge help in the past for some of my custom ECU modifications.

Being able to do the same with the MSS65 would be a Godsend.

Curious, does anyone have MSS65 XDF repository for hex addresses for manipulating parameters in the ECU binaries?

6ixSpd wrote

Amazing! You did incredible work in the MSS54 community that's been a huge help in the past for some of my custom ECU modifications.

Being able to do the same with the MSS65 would be a Godsend.

Curious, does anyone have MSS65 XDF repository for hex addresses for manipulating parameters in the ECU binaries?

If there is one, I don't know if it's public.

I do have an A2L for what appears to be a pre-production MSS60 software variant. Only thing is I can't remember for the life of me if it's something I found scouring the internet or if it's something that was given to me with the expectation that it stays private.

Amazing work, I assume it will work for those who have the BMW ICOM?
I also have a K+DCAN (non-bimmergeeks) cable with the upgraded custom firmware without the bluetooth modification, it can sucessfully program many DMEs without bricking.

GORDON.M3 wrote

Amazing work, I assume it will work for those who have the BMW ICOM?
I also have a K+DCAN (non-bimmergeeks) cable with the upgraded custom firmware without the bluetooth modification, it can sucessfully program many DMEs without bricking.

No ICOM support. Right now I only support K+DCAN cables (and I suppose a regular K-line cable would work on a K-line car -- I don't think that applies to M3s). In theory I can support any interface that EdiabasLib supports, but I haven't tried anything other than the K+DCAN (and right now the program is basically hard coded to look for a COM port). No support for the ICOM there as far as I'm aware.

Updated the software:

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.

this is a huge deal Terra, thank you so much!

I feel comfortable releasing the application now. See first post.

Dunno if anyone is interested, but I managed to unlock the BDM port on a locked MSS60. Still trying to work out a way to make it easy for people to do, but at least it's been proven that they can be unlocked.

Do note that if you write/lock a new secret key through tool32 (rather than just writing it directly via BDM), that will relock the DME.

I wish I understood more of what you're talking about Terra! Where is the explanation for simple minded people?

SYT_Shadow wrote

I wish I understood more of what you're talking about Terra! Where is the explanation for simple minded people?

BDM = "Background Debug Mode" - basically it's a tool the engineers would have used while developing the ECU to see what the processors are doing as code executes. That mode can also be used to read/write flash directly to the ECU. Generally useful feature to have - you recover from flashes that make your DME unbootable, and you can use it to create ECU clones in case your original develops a hardware issue or something.

With the E9x M3, BMW started locking the port sometime in the middle of model year 2008. So we couldn't clone ECUs, nor was it possible to recover from bad flashes. It was also believed to make it impossible to recover the EWS data from the DME (though I figured out how to do that over the OBDII port with my app)

Now that the port can be unlocked, we've got basically full control of these things. If you have a bad flash, just restore a backup. If the ECU messes up for some other reason, just copy a backup onto a used one. Etc.

Terraphantm wrote

BDM = "Background Debug Mode" - basically it's a tool the engineers would have used while developing the ECU to see what the processors are doing as code executes. That mode can also be used to read/write flash directly to the ECU. Generally useful feature to have - you recover from flashes that make your DME unbootable, and you can use it to create ECU clones in case your original develops a hardware issue or something.

With the E9x M3, BMW started locking the port sometime in the middle of model year 2008. So we couldn't clone ECUs, nor was it possible to recover from bad flashes. It was also believed to make it impossible to recover the EWS data from the DME (though I figured out how to do that over the OBDII port with my app)

Now that the port can be unlocked, we've got basically full control of these things. If you have a bad flash, just restore a backup. If the ECU messes up for some other reason, just copy a backup onto a used one. Etc.

Sounds like a huge improvement. Thank you

Wonderful job Terra!

Good to see you on here Dunno if you remember me from the ZHP forums.

As someone that has spent countless weeks working on MSS6x DMEs, and I'm not referencing time tuning them as that would amount to years, I'm pretty impressed. Just curious if you are applying any type of patch in order to read the ISN? I had a lot fun nearly a decade ago identifying the Secret keys in both the DME and CAS. Those were the good times. Nice work terra.

The way I've got it setup, it'll try reading the ISN/SK from the real location first, and if that returns FFs (which it will if my patches haven't been written), then it'll dump RAM from the left / injection CPU and do a pattern search. I haven't had that fail on me yet, but maybe there's an odd program version I don't have access to where they actually do clear it from RAM.

I do patch the read routine to allow that section to be read out when doing the RSA bypass, so on an already patched DME it will read the ISN/SK directly rather than searching the RAM for it.

I left tuning after I popped my third set of turbos at Sebring. Terraphantm you’ve renewed my interest. Nice work.

Thanks terra! For now, just updated ecu software to 241E. Verified the before and after using your application. Will take a full read later on.

All over my head but Terra, you’re a a God! Great to see you over here, loved your contributions on M3F.

Fantastic job! Thanks Terraphantm