|
|
|
|
|
|
BMW Garage | BMW Meets | Register | Today's Posts | Search |
|
BMW 3-Series (E90 E92) Forum
>
I cloned my MSV70 DME
|
|
12-29-2016, 01:43 PM | #1256 |
New Member
0
Rep 28
Posts
Drives: BMW 130i Manual
Join Date: Dec 2016
Location: NZ
|
I should have added... useful for those trying of us trying to follow what you're doing . Do you know whether the CAS module has similar RSA hash protection on the program code? It would be handy to jump the SVS RSA compare as it appears to be generated with a longer bit length.
|
Appreciate
0
|
12-29-2016, 01:51 PM | #1257 | ||
Captain
253
Rep 775
Posts |
Quote:
Funny how a lot of forums censor bimmerboost. M3forum does too. Must be some drama that went down. And yeah, "BBflash" is "BimmerBoost Flash" Quote:
Last edited by Terraphantm; 12-29-2016 at 02:00 PM.. |
||
Appreciate
0
|
12-29-2016, 04:04 PM | #1258 |
Colonel
1019
Rep 2,112
Posts |
The private key is triple des encrypted and des keys are in the keyexchange method of bbflash.
In flash.secureaccess method using a four byte seed and a couple of read requests and then using the private key exchange an authorization message is sent. This I assume is putting the ecu into "programming mode" or elevating the current session to super user mode or something. Then they write the file. Someone must have disassembled and analyzed winkpf or similar to arrive all this. Or leaked from inside bmw |
Appreciate
0
|
12-29-2016, 06:40 PM | #1259 |
Colonel
1000
Rep 2,287
Posts |
It looks like we have some really great talent looking into this issue and I'm not sure if this will help anyone here but I have posted some early Winfkp Source files or B2S files in my drop box account.
https://www.dropbox.com/sh/erq19glso...cJwegdsAa?dl=0 I guess the one that might interest you is the ECU.Zip. Inside is a file called Flash.std. This lists the external sources used. Unfortunately Flash.prg is compiled. / ************************************************** ***************** // // ! ! ! ! ! DIESE DATEI DARF N I C H T VERÄNDERT WERDEN ! ! ! ! ! // // ------------------------------------------------------------------- // Fashjobs BMW Fast und KWP 2000* // ------------------------------------------------------------------- // Gültig: // Lastenheft Diagnose Ausgabe 6 // Lastenheft Programmieren Programm/Daten 7 500 334 F // ------------------------------------------------------------------- // History: // 05.02.2002 rd V0.01 Erstellung // 06.02.2002 rd V1.00 Freigabe // 22.04.2003 rd V1.01 Versionskennung hinzu // ************************************************** ***************** // FLASH.STD @(#)@ V1.01 @(#)@ // ************************************************** ***************** #include "STD_SN_L.B2S" // SERIENNUMMER_LESEN #include "STD_ZI_L.B2S" // ZIF_LESEN #include "STD_ZB_L.B2S" // ZIF_BACKUP_LESEN #include "STD_PH_L.B2S" // PHYSIKALISCHE_HW_NR_LESEN #include "STD_HW_L.B2S" // HARDWARE_REFERENZ_LESEN #include "STD_DR_L.B2S" // DATEN_REFERENZ_LESEN #include "STD_2501.B2S" // FLASH_ZEITEN_LESEN #include "STD_2506.B2S" // FLASH_BLOCKLAENGE_LESEN #include "STD_3107.B2S" // AUTHENTISIERUNG_ZUFALLSZAHL_LESEN #include "STD_3108.B2S" // AUTHENTISIERUNG_START #include "STD_310A.B2S" // FLASH_PROGRAMMIER_STATUS_LESEN #include "STD_3109.B2S" // FLASH_SIGNATUR_PRUEFEN #include "STD_1101.B2S" // STEUERGERAETE_RESET #include "STD_FL_D.B2S" // FLASH_LOESCHEN #include "STD_FL_A.B2S" // FLASH_SCHREIBEN_ADRESSE #include "STD_FL_S.B2S" // FLASH_SCHREIBEN #include "STD_FL_E.B2S" // FLASH_SCHREIBEN_ENDE #include "STD_AI_L.B2S" // AIF_LESEN #include "STD_AI_S.B2S" // AIF_SCHREIBEN You can then pull out these files such as KWS_3207.B2S and see at least some of operations incorporated. Notice the four levels of authentication. result : AUTHENTISIERUNG; type : string; defrslt : ; comment : Authentisierungsart; comment : 'Keine' Keine Authentisierung; comment : 'Simple' Einfache Authentisierung; comment : 'Symetrisch' Symetrische Authentisierung; comment : 'Asymetrisch' Asymetrische Authentisierung; Some other interesting stuff, such as Excel VBA programs that run Ediabas functions. I've tinkered with these with some mixed results. Limited by my knowledge. Maybe something here will lead someone to a discovery. Also, don't forget that you can perform pretty detailed traces during a WinFKP operation. You need to increase the trace file size or manually capture the traces during the process. WinFkp / Ediabas over writes them when they hit the file size limit. |
Appreciate
0
|
12-29-2016, 08:03 PM | #1260 |
Colonel
1019
Rep 2,112
Posts |
The files you uploaded match with the BBFlash code.
BBFlash SecureAccess method first sends a 0x1A,0x89 request. In the files you supplied, this request corresponds to reading serial number job files ( BMW_SN_L.B2S, STD_SN_L.B2S and ..) Then sends 0x31,0x07 request, which is authentication type request, as you found. Corresponding job files *_3108.B2S Then sends 0x31,0x38 authentication start/check request, this corresponds to *_3108.B2S job files. The serial number and type of authentication request results are some sort of encrypted with the rsa key, and result is fed to 0x31,0x38 request. This explains why the method in BBFlash was named "KeyExchange". This is sort of a "challenge-response" authentication. ECU challenges the program to encrypt its serial number and authentication type string with a private key, whose public key it has I assume. If program can do this and provide the result (ECU can decrypt what program passed and get the serial number and authentication type back) it is authenticated, meaning it knows the secret key and has a pass now to program. I think the code of BBFlash all shows what needs to be done and how it can be done. Assuming (which probably would be true) the key exchange encryption is not different for MSV80, it should work for it too. MSV80 encrypted private key is available in SGIDC.as2 as 808AWD325xi posted. I wonder how they got the 3DES keys or even the details of the process ... |
Appreciate
0
|
12-29-2016, 08:17 PM | #1261 | |
Captain
253
Rep 775
Posts |
I imagine they were able to trace what WinKFP does along with disassemble ECU code to understand how the authentication works. No idea where they got the DES keys - I suppose it must be stored *somewhere* in WinKFP or the corresponding prg/ipo files. If I were interested in only a single ECU like they seem to be, I probably would have just tried factoring the public key myself since it's 512-bit.
Wish I had an MSV80 to play with. Quote:
Last edited by Terraphantm; 12-29-2016 at 08:24 PM.. |
|
Appreciate
0
|
12-29-2016, 08:37 PM | #1262 |
Colonel
1019
Rep 2,112
Posts |
That was a typo on my part, should have been:
"Then sends 0x31,0x07 request, which is authentication type request, as you found. Corresponding job files *_3107.B2S" 3107 just returns the type of the authentication as string from what the job file describes : "none", "simple", "symmetric" or "asymmetric" (german versions of course). The first call returns the serial number. The challenge is to encrypt the serial number plus what is retuned from 3107 (which kind of useless but they added that in, serial number is the important one because it is unique) with the corresponding key pair (asymmetric public private key). If program does and provides it in 3108 call it is authenticated. The BBFlash code is very clear on how it is making these. |
Appreciate
0
|
12-29-2016, 08:43 PM | #1263 | |
Captain
253
Rep 775
Posts |
Quote:
Send serial number + random #s Encrypt that and send it back to DME DME decrypts and compares to the original challenge If it matches, you're authorized to get in. If the random numbers weren't there, all someone would have to do is log the encrypted response and send that back. |
|
Appreciate
1
CarAbuser485.50 |
12-29-2016, 08:45 PM | #1264 | |
Colonel
1019
Rep 2,112
Posts |
Quote:
I decompiled flash.prg it with bestdis, and looking at it and doing some googling came across there is a thing called New Flash System (NFS) . It is included in the Tools32 I think, I have it. It talks about a COAPI for flashing by 3rd party developers etc. It is too much information right now for me, but looking at it. All initially I was interested actually to flash a 330xi tune on to my 325xi using BDM, which I had made it working and cloned a cpu. I haven't done the tune yet, other things I have to take care first... Now I am looking at all this.... curiosity kill the cat... |
|
Appreciate
0
|
12-29-2016, 08:48 PM | #1265 | |
Colonel
1019
Rep 2,112
Posts |
Quote:
|
|
Appreciate
0
|
12-29-2016, 08:49 PM | #1266 |
Captain
253
Rep 775
Posts |
Heh, funny thing is, right before this thread exploded, I figured out how to bypass the 10 hour limit for the power-class change, so you could theoretically flash to a stock 330xi without removing the DME from the car.
|
Appreciate
0
|
12-29-2016, 08:56 PM | #1267 |
Colonel
1019
Rep 2,112
Posts |
I may ask you about that, but what you, hassmachine have described to overwrite the powerclass byte a few hundred pages ago would be enough for me. Since I have a BDM functional it should be enough, and I don't mind removing the ECU at this point. I don't plan to keep making changes, a stock 330 would make me happy.
I want to first get some logging working to get some poor mans performance numbers without dyno. Then I need to replace the intake manifold with the 3 stage which is sitting for weeks waiting its time. At that time I will to do the stock 330xi flash. Thanks especially to hassmachine, you and whoever contributed in this. |
Appreciate
0
|
12-30-2016, 01:38 AM | #1269 | |
Colonel
1000
Rep 2,287
Posts |
Quote:
Be careful with straight conversions from an 0PA or 0da file. I think you will find two problems. 1. Not all of the data/program on the DME can be found in the Intel hex file 2. It appears that some of the information is flashed into one location and moved elsewhere after its validated. Case in point with the MSV70, OPA file , data range 0x60000 - 0x7FFFF is moved to 0x20000 - 0x3FFFFF when the flash is finished. There are RSA pointers to the temp location. We also have the address issue with the calibration file. 0x840000 is 0x40000 in the Bin. There seems to be some ambiguity in how that memory is addressed. Don't forget that 0x400000 upwards is not on the flash but instead in the Microprocessor. The data is in the 0pa file and I think the addressing is clear. |
|
Appreciate
0
|
12-30-2016, 04:11 AM | #1270 | |
Captain
253
Rep 775
Posts |
Quote:
What I'm still not really wrapping my mind around is how they're getting the program RSA check to pass when they're making a boot sector modification. In any case, I'm tempted to modify the code to 1) Work with more DMEs 2) Work with a standard D-CAN cable Easiest way to do the latter I think would be to just rip out the BT cable code and FCPD2XXstuff, and talk to the cable in serial mode. (D-CAN cable does also support D2XX, but I don't know the commands specific to the cable and I don't know if it's documented anywhere. Serial mode should be good enough since WinKFP is still quite reliable in that mode) |
|
Appreciate
1
rjahl1000.00 |
12-30-2016, 10:13 AM | #1271 | |
Major General
3980
Rep 7,212
Posts |
Quote:
The internal memory addresses on the MPC5xx are programmable - on MSS70 and MSV70, 0x0 = 0x400000 (MPC563 internal flash). From 0x6FFFFF-0x7F7FFF are internal things like ADC channels, timers, CAN buses, etc. From 0x7F8000-0x7FFFFF is internal RAM. The first boot code begins at 0x800000, with the part that's in the 0pa at 0x820000. And parameter space begins at 0x840000, 0x860000-0x87FFFF is the empty space used to validate the boot code. Main program at 0x880000. Technically, all the OBD reads that put the internal memory after the external flash are wrong, since the very first part of the memory map is the internal flash. That's part of what threw me off on disassembly for so long. I think they just have it that way because it appears from the 0pa that the MPC563 flash comes after the external flash when it's actually the opposite. Also, there's the serial EEPROM, which I still don't understand how it aligns in internal memory. there's some sort of external memory/ram at 0x1820000 but it's not the right size and none of the values that I already know line up with anything. if I'm not mistaken, I think your tool for re-creating the 0da/0pa files uses a stock file as a reference because of the memory mapping being unclear, but since we know the memory map I think it could be done without needing a stock file (just the headers, signatures etc). |
|
Appreciate
0
|
12-30-2016, 04:02 PM | #1272 | |
Colonel
1019
Rep 2,112
Posts |
Quote:
It is using FTD2XX at the low level, and that is the most commonly used USB serial windows driver library from FTDI. It sends CAN frames in that serial connection. I believe this is just standard way of doing it. INPA/EDIABAS uses COM port, but even in that case, the COM port is emulated by the same FTDI driver. So they are skipping over Win32 COM port API, and using the FTDI driver directly instead. The EBay INPA cables (at least mine does) have FTDI2XX chips on them that do USB serial communication. Although EBay cables have fake FTDI chips most often if not all . BBFlash people may be saying that the code, as it is, works well with INPA cables using genuine FTDI chips or the circuitry around it, and not very reliable with Ebay fake FTDI chip and circuitry boards. The BDM 100 clone I had bought from EBay also has a fake FTDI FTD2XX chip, they even scrapped off its surface not to show what it is or to hide that it is a fake clone. I think the code needs to be made a bit more robust for reliable communication with most Inpa cables. There are some timeout, etc code that may need revising, not sure, needs testing to find out what/why exactly fails. But again, I am not comfortable just using the source code like that unless there is permission to do so from owners. With all the reverse engineering, cracks, keys etc, it is already somewhat gray area. Speaking about crack, they are probably modifying if statement for the RSA signature checks, so if it fails it still continues. I think you eluded or wrote this in one of your posts above. So it would mean finding the check in MSV80 and modify that one. In MSV80, it may even be the same pattern of bytes that does this that BBFlash looks for to modify, if so it won't need no change there. I think starting point would be to replace the MSD80 RSA authentication key with the MSV80 key (or MSV70), recompile and test with MSV80 (or MSV70), and see what fails. |
|
Appreciate
0
|
12-30-2016, 04:12 PM | #1273 | |
Captain
253
Rep 775
Posts |
Quote:
I didn't say anything about distributing a complete binary (also worth noting that BBFlash was advertised as open source, so...). I don't think there would be anything unethical or illegal about me making my own code for comms, telling people to add a line calling it and/or replacing the existing file, add a couple signature blocks, etc. As far as the cracks, keys, etc. They're modifying the code in essentially the same manner rjahl, hass, and I have known about for years. I know other bypasses which would be trivial to implement as well. Already found the checks in the MSV80 before the source code was posted here. Where I'm still a little hazy is that the DME *should* verify the RSA before writing the boot sector to its final location, but maybe it doesn't do that. Starting point for me is to get reads to work with a normal cable, because I have no intention of paying $180+ for a Bavarian Technic cable Last edited by Terraphantm; 12-30-2016 at 04:17 PM.. |
|
Appreciate
0
|
12-30-2016, 04:29 PM | #1274 | |
Colonel
1000
Rep 2,287
Posts |
Quote:
Yes, my tool originally had a script that compared the location of each data block in the 0pa and 0da files to their actual location in the Bin. I used that output as a translation table. When I wrote the tool, it really did not matter where the data was initially located or how it was addressed, I just needed a translatetion table or map between the BIN location and the intel hex file. Now, the tool simply reads the source intel file line by line and then finds the corresponding information from source bin and builds a new Intel hex. There are no checks to catch any added or changed data blocks in the source bin. |
|
Appreciate
0
|
12-30-2016, 08:25 PM | #1275 |
Colonel
1019
Rep 2,112
Posts |
Question to knowledgeable and experienced guys, which pins on the ECU do I need to connect to which on OBD side of the INPA cable to be able to do bench testing? I have an extra MSV70 lying around and outside is cold to try it on the car.
Bentley is not much help, it shows pin 9 on OBD goes to ECU 21, but pin 7 goes to a junction box which I think this is the important one (K-Line?) and probably goes to ECU from that junction box too, but which pin at ECU?. Then there is pin 1 going to CAS, this may end up at the ECU too, but can't get such information from Bentley (or I don't know how to read those diagrams). 4 and 5 is grounded. pin 16 looks like battery power. |
Appreciate
0
|
12-30-2016, 08:54 PM | #1276 | |
Colonel
1000
Rep 2,287
Posts |
Quote:
|
|
Appreciate
0
|
Bookmarks |
|
|