MSS6x Flasher - Now released!

[spinel00]

Hello, I need some help...
I encountered an error while flashing,
so the DME status is displayed as Unknown as shown in the image, and the writing process stops midway.
Recovery with WinKPF also fails.
I discovered using an acquaintance's BDM tool that the left CPU is locked.
I have purchased a u-Link NT and am currently waiting for it to be delivered.
How do I unlock the left CPU using the BDM tool?
I also hold fg-tech.
I need help.

[maicol76]

Hmm, well I did change the read function to put the DME in programming mode since the read is a lot faster that way. I'll see if I can replicate the crash.

This is an E9x I assume?

For reference, I'm providing this information. I tried the process again. It reached this point and stopped, and after waiting for about 10 min., I clicked on the “Download New Version” option at the bottom, which caused the program to close.
I have no way of knowing whether the reading had actually finished or not.
The error codes are still present on the dashboard.
I also compared the file size with the file that was previously downloaded using the older version, and they are both exactly 128 KB.

This is what I have been able to determine so far.

%update : When I uploaded the file read with the older ver. and the file downloaded with the new ver.to AI for comparison, it said that the data was identical in every respect.
The full read was completed successfully. As you mentioned, some fault codes remain after the read is completed. They show up both on the cluster and when scanning the car with a diagnostic tool.
After key off and back on, the fault codes can be cleared normally with the diagnostic tool.
I’m not sure why it didn’t work properly at first, but apart from the Read Tune function, the full read seems to work normally and quite quickly.

[maicol76]

Hmm, well I did change the read function to put the DME in programming mode since the read is a lot faster that way. I'll see if I can replicate the crash.

This is an E9x I assume?

Yes, my car is E92 M3 w/DCT.

[terra]

Hmm, well I did change the read function to put the DME in programming mode since the read is a lot faster that way. I'll see if I can replicate the crash.

This is an E9x I assume?

[maicol76]

First of all, I have great respect for the work you have done on the MSS6x Flasher, and I have been using it with great appreciation.

I believe it was around 2022 when I downloaded your flasher and successfully performed a full read of my ECU data.

This time, I have made some changes to the engine hardware, so I need to flash the ECU.
Before doing that, I wanted to make a backup of the ECU data that I had been using. I downloaded and installed the newly released v1.2.0.1 and connected to the car through the OBD port using a BimmerGeeks cable.

The ECU identification works correctly, but when I select "Read Tune" or "Read Full," dozens of error codes suddenly appear in the car, and the flasher program automatically closes.
Fortunately, I can clear all of the error codes using a diagnostic tool, and they do not seem to remain afterward.

Could you please let me know if there is something I am missing, or if there might be an issue with the setup or the new version of the flasher?

[ppm008]

Will you compile for 4.8 ?

[terra]

Net 4.8.1 requires > Win10
Net 4.8 would be available for Win 7
no chance anymore for Win7 ?

Hmm, I'll have to experiment and see. The ediabaslib dependency is also built for .net 4.8.1 and .net 10, but maybe can compile it for 4.8

[ppm008]

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

Version 1.1.0. Multiple updates since last release:

Net 4.8.1 requires > Win10
Net 4.8 would be available for Win 7
no chance anymore for Win7 ?

[terra]

Updated the program again, now version 1.2.0.1. https://github.com/terraphantm/MSS6x-Flasher/releases

Main changes:

• Uses .NET 10 now (primarily because the openfolderdialog apparently doesn't exist in .net 4.8.1). I had to make a couple small changes to avoid errors, but I think it should work ok.
• x64 and ARM64 binaries are now separate (x64 will generally work fine on ARM64, but not vice versa)
• Added support for 0pas and 0das. Loading an 0pa will immediately prompt you to load a corresponding 0da. The two are then combined into a bin internally and then everything works as if you loaded a normal binary. It shouldn't be able to load or attempt flashing an 0pa/0da that isn't an MSS6x format file, but I did not thoroughly test deliberately loading the wrong binaries.
• The program will now prompt you for a directory before reading / saving a file. You can also define the default directory in the .config file under the 'HomeDirectory' parameter. As it is now it will likely fail if you select a folder that you don't have write permissions to. I'll probably modify things to handle that better at some point

[apstuning]

Thanks Terra, confirmed on this end.
Quick experiment on a DDE626, swapped the vendor token 6436 for b 4242 and ran the full sequence. $31 07 challenge, $31 08 with MD5(user_id + serial_tail + challenge) signed with the same RSA-d 71 08 01 AUTH ACCEPTED. Erase, $34/$36/$37, full 227 KB cal-write all positive, byte-identical to a '6436' run.
So on DDE5/DDE6 too the user_id is genuinely arbitrary. The runtime $1A 89 tail I was using just happened to always pass because it's valid ASCII. Signed message layout from your excerpt also matches what I'm seeing: user_id(4B) + serial_tail(4B from $1A 89) + random(8B), MD5 little endian into RSA-d.
Really appreciate the pointer.

[terra]

Yea the full signed message from what I remember is the “serial number” (which I believe is the last 4 bytes of that 1a89 message), the “user id” which can be any 4 bytes, and then the random number that was previously requested from the dme.

Edit: Below is an excerpt of the logs I took when I was initially figuring all this out with my comments added

 #@30964;P00001900h;#
Job
"11MSD80"
"SERIENNUMMER_LESEN"
#@30965;P00001900h;#
Results:
[ 0 ]
OBJECT = "11msd80"
SAETZE = 1
JOBNAME = "SERIENNUMMER_LESEN"
VARIANTE = "11MSD80"
JOBSTATUS = ""
UBATTCURRENT = -1
UBATTHISTORY = -1
IGNITIONCURRENT = -1
IGNITIONHISTORY = -1
[ 1 ]
JOB_STATUS = "OKAY"
_TEL_ANTWORT = 15 Bytes:
0000: 8B F1 12 5A 89 30 38 31 ...Z.081
0008: 30 32 31 30 32 34 17 021024.
_TEL_AUFTRAG = 5 Bytes:
#@30966;P00001900h;#
0000: 82 12 F1 1A 89 .....
SERIENNUMMER = "081021024" //WinKFP gets DME serial number (which is 30 38 31 30 32 31 30 32 34 in hex)
#@30967;P00001900h;#
Job
"11MSD80"
"AUTHENTISIERUNG_ZUFALLSZAHL_LESEN"
"3;0x31653634" //WinKFP requests authentication level 3 and sends user id "31653634" as a part of the message (exact useid likely doesn't matter)
#@30968;P00001900h;#
Results:
[ 0 ]
OBJECT = "11msd80"
SAETZE = 1
JOBNAME = "AUTHENTISIERUNG_ZUFALLSZAHL_LESEN"
VARIANTE = "11MSD80"
JOBSTATUS = ""
UBATTCURRENT = -1
UBATTHISTORY = -1
IGNITIONCURRENT = -1
IGNITIONHISTORY = -1
[ 1 ]
JOB_STATUS = "OKAY"
ZUFALLSZAHL = 8 Bytes:
0000: 62 90 FE 5C 2B 5E 73 25 b..\+^s% //Random number 62 90 FE 5C 2B 5E 73 25 is sent by the DME
_TEL_ANTWORT = 14 Bytes:
0000: 8A F1 12 71 07 62 90 FE ...q.b..
#@30969;P00001900h;#
0008: 5C 2B 5E 73 25 34 \+^s%4
_TEL_AUFTRAG = 10 Bytes:
0000: 87 12 F1 31 07 03 31 65 ...1..1e
0008: 36 34 64
AUTHENTISIERUNG = "Asymetrisch"
#@30970;P00001900h;#
Job
"11MSD80"
"AUTHENTISIERUNG_START"
90 bytes:
0000: 01 00 00 00 0A 00 00 00 ........ //First few bytes are EDIABAS formatting stuff. Actual signed message (including length) starts at 0x15
0008: 00 00 00 00 00 44 00 00 .....D.. //Signature decrypts to: 9338596f6ce09c477f1dc08f4cb87151 - which is a reversed (stack order) md5 of 31653634313032346290FE5C2B5E7325
0010: 00 00 00 00 00 00 00 00 ........ //31653634313032346290FE5C2B5E7325 -> 31653634 == user ID; 31303234 == Last 4 bytes of serial number; 6290FE5C2B5E7325 == Random Number
0018: 10 5F 4B 1D 24 98 09 69 ._K.$..i //Same general process should apply to other modules and other levels of security access with the appropriate key
0020: 9D 06 44 80 83 72 53 CD ..D..rS.
0028: 76 45 90 24 0B EC E1 47 vE.$...G
0030: 14 B2 4D 4B C1 10 5C F5 ..MK..\.
0038: B2 81 94 83 FF D7 BC 5E .......^
#@30971;P00001900h;#
0040: 6A 29 04 B2 0A 05 E8 68 j).....h
0048: FA 68 57 C1 76 92 9E 5C .hW.v..\
0050: B8 8F C4 D4 0E 78 D8 3C .....x.<
0058: D0 03 ..
90​

[apstuning]

Thanks Terra!
I was actually experimenting with this right now after reading your reply.Initially same conclusion here, the vendor pcaps had random looking tokens
(3aec, 4d85, etc.) so a tester side identifier seemed likely. But on EDC16C31 DDE it turns out to be derived ECU side from $1A 89:
DDE503: $1A 89 - 5A 89 30 30 30 30 30 36 33 30 32 39 ASCII 0000063029
DDE509: $1A 89 - 5A 89 30 30 31 30 37 36 34 35 33 ASCII 0010076453
The trailing 4 bytes are the exact $31 07 03 token. Same value also exists
in flash at 0x806029.Looks like a Bosch programming counter incrementing hex-style after each successful flash, which would explain the a-f characters seen in the wild. I switched the tool to runtime-query $1A 89 before each auth and it now
works on every DDE I've tested. That said, I actually suspect the DDE may also accept arbitrary values and not really care either. I just haven't tested random tokens yet because the counter derived value was consistently working from the captures

[terra]

That's the "user ID" I believe. At least on the DMEs I've worked on, none of them actually care what the value is. I just generate a random number.

[apstuning]

Hi.
Massive respect for the MSS6x Flasher work and the SGIDC.AS2 write-ups,
they helped me a lot getting up to speed.

I've been doing some EDC16 reverse engineering work and needed a RAM
dump tool for it, which then turned into a full flasher for EDC16
DDE5/DDE6 and the ZF 6HP TCU over a regular K+DCAN cable. Following
your posts, I got through extracting the 3DES master key from WinKFP,
decoding SGIDC.AS2, and pulling out the RSA-512 keys for level 3 auth.
The auth flow and full write process now match WinKFP captures
byte-for-byte, so I think I have the protocol side worked out.
One thing I still can't place is the 4-byte ASCII token in the
$31 07 03 request, the one right after the service ID.
A few examples I've captured:

6HP TCU: "18f0"
EDC16 DDE: "3aec", "4d85", "3029", and a few others

It doesn't appear to come from SGIDC.AS2, and I can't find an obvious
WinKFP-side lookup table for it either. The same RSA key seems to want
different tokens depending on the ECU and the flash context (full vs
cal-only), so it's clearly tied to some bootloader-side state.
Do you happen to know what this token is called, where the tester
gets it from, and whether it's derived or just a fixed table?
Right now the only reliable way I have to obtain it is sniffing WinKFP.
Thanks again for everything you've put out there - your write-ups made
all of this approachable.

Greetings from Hungary.

[armenh7]

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

Thank you for your continued contributions to many communities.