MSS6x Flasher - Now released!

[Martyn]

Awesome!

I was going to suggest adding a voltage status of KL15 but I'm guessing the ECU won't accept job requests whilsts its in flashing mode or busy with a current job.

I'll have a think regarding the name.

[terra]

Another update



-Changed up the layout a bit.
-Eliminated the full binary checkbox, there is now a separate button to read a full program
-Read RAM and Read ISN / SK are now under the "Advanced Menu" -- shift+click no longer does anything
-Added current byte being read/written to the status text
-Added a status message noting if a read has been completed
-Progress bar is now colored #009ADA

Thus far the application feels pretty safe. Even when a flash does fail due to disconnected power or so, the DMEs are staying alive. So I'm feeling comfortable for a wider release soon.

Anyone have thoughts on a different name for the application? Also anyone have any ideas about a logo, icon, etc? Something that emphasizes the relationship to this forum would be preferable.

[hansbrix]

Sent terra a PM with the same info. I was able to successfully do a full and partial read of my MSS65 in my 2008 M5 SMG. I'm doing it in the car, I don't have a bench setup. The full read took about 2.5 hours. I have a K+DAN cable from one-stop electronics that I bought almost 2 years ago. I don't know how to flash the cable itself. (http://www.one-stop-electronics.com/...&product_id=16). I didn't try writing since I have no updated tune or file to write.

[terra]

Another update:

• Added patch to allow reading protected memory segments
  • This will be applied any time an RSA delete or Full Write is done
• Added ISN reading to the MSS65
  • It will prompt you to do an RSA Bypass if it can't be read
• MSS60 SK read will now attempt to read it directly before dumping RAM and searching for it. Should be a little faster if you've already patched an RSA delete
• Changed name/directory structure a bit

[terra]

Great work!

I'm sure a while back I read on the M5Board that Jim Colley had identified and defeated the second processor lock, it might be worth reaching out to him to see if he can point you in the right direction.

Sent him a PM - looks like he hasn't logged in for a couple months though, so we'll see.

[Martyn]

Great work!

I'm sure a while back I read on the M5Board that Jim Colley had identified and defeated the second processor lock, it might be worth reaching out to him to see if he can point you in the right direction.

[terra]

Figured out what to change in the program to read the SK from the true location. Same patch should work to read the ISN from the MSS65 as well. I'll update the app later today. But basically at this point we can make a full backup entirely over OBDII. Now if we can figure out how to reenable BDM on the MSS60, that means cloning these things and recovering from bricks will no longer be a problem.

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

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

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.

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

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.

[terra]

Expert K+DCAN or the Pro K+DCAN?

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

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