[PhaseP]

Take a look at the flash.txt file at the root of the solution of source code linked. It gives insight to what was done . Msv80 was never finished but could be. And that key exchange is not for the cable looks like , it is to get into "programming mode". This probably allows to write any section. But then during execution rsa md5 signature and certain checksums are checked, so the "crack" is to by pass this. Google shows This software is a result of *********** forum work you can probably get deeper info there in the threads or even contact flash guy user if still active there.
Edit: correct file name BMWflash.txt

[PhaseP]

That should be bimmer boost (I guess this forum considers them competition, didn't know)

[drc38]

Originally Posted by Terraphantm

Yep, that's what gave me the idea actually. I wouldn't know how to optimize the process for a cluster, I'm not quite as smart as those Ivy League guys . So I figured I'm better off just running the process on my own computer, even if it takes a week or two.

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.

[Terraphantm]

Originally Posted by PhaseP

Take a look at the flash.txt file at the root of the solution of source code linked. It gives insight to what was done . Msv80 was never finished but could be. And that key exchange is not for the cable looks like , it is to get into "programming mode". This probably allows to write any section. But then during execution rsa md5 signature and certain checksums are checked, so the "crack" is to by pass this. Google shows This software is a result of *********** forum work you can probably get deeper info there in the threads or even contact flash guy user if still active there.
Edit: correct file name BMWflash.txt

Yeah, I came to the same conclusion after looking at the code. DES stuff seems like it's used to generate the private key (which I guess is encrypted). I have to double check, but that encrypted form might be how WinKFP stores it. Guess the DME doesn't authenticate the boot code before it executes. Which works out great for us, but seems like a big oversight on BMW/Siemens' part. I think it should be fairly easy to implement MSV80 support. Might also be worth looking into supporting a standard D-CAN cable.

Funny how a lot of forums censor bimmerboost. M3forum does too. Must be some drama that went down. And yeah, "BBflash" is "BimmerBoost Flash"

Originally Posted by drc38

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.

I believe it does. Not sure what the key length is. CAS can be read off with a BDM interface too.

[PhaseP]

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

[rjahl]

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.

[PhaseP]

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

[Terraphantm]

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.

Then sends 0x31,0x07 request, which is authentication type request, as you found. Corresponding job files *_3108.B2S

0x31,0x07 would correspond to _3107. I think 31 07 requests a challenge and the response is sent w/ 31 08.

[PhaseP]

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.

[Terraphantm]

Originally Posted by PhaseP

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.

I don't think the added bit is useless. I think it's how the DME prevents a replay attack.
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.

[PhaseP]

Originally Posted by rjahl

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.

There are free source programs that decompile Ediabas compiled objects (*.prg files). One of them is Bestdis I had found somewhere and downloaded a few weeks ago. I don't remember where I found it but can be googled and found.

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

[PhaseP]

Originally Posted by Terraphantm

I don't think the added bit is useless. I think it's how the DME prevents a replay attack.
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.

You are right, I missed it, it returns a ZUFALLSZAHL (random number) and the string.

[Terraphantm]

Originally Posted by PhaseP

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

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.

[PhaseP]

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.

[PhaseP]

3DES key(s) are indeed defined in the winkfpt.exe. When you already know what they are it makes it easy to find them

[rjahl]

Originally Posted by PhaseP

Since BBFlash most probably emulating what winkfp is doing anyway for the flash, with the exception of moving references for RSA MD5 signature checks and the additional CRC check updates that are done at execution of the flash, if same modifications are done to a MSV80 flash file winkfp should be able to be used just as well.
If anybody gives me information what references are to be moved at what addresses on an MSV80 flash file, I could try to do the same BBFlash does and then give back the updated file to be tried out.
I don't have an MSV80, nor I have disassembler/decompiler for it to find such addresses.
I had looked at OPA/ODA file formats, they seem straight forward to convert into binary and back since they use well document intel binary format. I can do that part also if that is part of what needs to be done. Can't promise to do those fast though, life has other priorities, demands and ...

What about trying your ideas on a MSV70? Lots of information available for that DME.

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.

[Terraphantm]

Originally Posted by rjahl

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.

Seems like the MS*80 does something similar. The program RSA segments have pointers in the data section, and I think part of the boot sector sits there temporarily during the flash. I have not been able to generate the correct md5 signature, but it's possible that the MS*80 prevents some of the data from actually being read back with OBD reads. I should probably try converting a WinKFP file to a binary and verifying the signatures that way.

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)

[hassmaschine]

Originally Posted by rjahl

What about trying your ideas on a MSV70? Lots of information available for that DME.

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.

It's not really ambiguous - it's just how the memory is arranged on the MPC563 platform.

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

[PhaseP]

Originally Posted by Terraphantm

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)

The quickest and easiest way to get MSV80 working would be add the missing MSV80 support to BBFlash source code, I agree. But unless the author(s)/owner(s) of that code give permission I personally am not feeling comfortable doing so. There is no license file included in it.

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.

[Terraphantm]

Originally Posted by PhaseP

The quickest and easiest way to get MSV80 working would be add the missing MSV80 support to BBFlash source code, I agree. But unless the author(s)/owner(s) of that code give permission I personally am not feeling comfortable doing so. There is no license file included in it.

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.

It's using the D2XX driver to send commands that the MicroCAN (I guess BT cable is some variant of that) cable is designed to accept. I already tested on my own by forcing the cable to be recognized. The driver loads and the cable is recognized, but the commands don't work. I know the D-CAN cable can be used to read and flash stuff in D2XX mode, but honestly it'll be easier to just treat it as a real serial port like ediabas does. The cable will handle the rest as far as sending over K-line vs D-CAN, how to set frames, etc.

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

[rjahl]

Originally Posted by hassmaschine

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

Thanks for clearing that up,

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.

[PhaseP]

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.