[PhaseP]

Thanks!

Edit: On my version of INPA cable pin 5 was left empty, pin 4 was the only ground. It worked after connecting ground to 4 instead of pin 5. I can read DTC codes with INPA now

[Terraphantm]

Originally Posted by PhaseP

Thanks!

Also for what it's worth, any of those 4 pins on top will work as ground

[Terraphantm]

So just to update on my adventures of trying to get BBFlash to work with a standard cable -

I'm able to get it to send data, but I'm not getting a valid response back (just getting an echo back, which is usually indicative of the DME not accepting the command). I noticed that their KWP2000 format seems a little different than what Tool32 sends, so I wonder if the BT cable does some translation at some point downstream. Or if I'm missing some initialization to put the DME in a different mode (those K2CP commands may be doing some of that).

Edit: Well a little progress, but it's glitchy. If a new command comes too soon after a previous command, the DME seems to just ignore it.

Also I think the discrepancy between the command formats is because I'm hooked up directly to the DME rather than going through the JBE module (which I believe does all sorts of protocol translation).



I need to figure out how to
A) Get the DME to accept a baudrate of 115200 instead of 9600 and
B) Clean up some of the code

[Terraphantm]

So it occurred to me: Even if I get BBFlash working 100% with a normal cable and other DMEs, what's the point? We'd just have something that's not quite as reliable as WinKFP that might be ethically dubious to distribute due to a lack of a defined license.

So I decided to some experimenting with WinKFP and see how picky it is about the file format.
What I've found so far: It pretty much will accept a nearly standard Intel Hex format file, with a couple exceptions:

1) The $REFERENZ line in the beginning is mandatory - probably so WinKFP knows what kind of DME it's using, where to retrieve keys, etc.
2) At the end of each "segment", the last line has to have a record type set to "10" -- this is not defined in the Intel Hex standard, but WinKFP won't accept files without it.

Just for testing, I used srec_cat (from srecord: https://sourceforge.net/projects/sre...rd-win32/1.64/) to generate an 0da file for my MS45 (offset set to 0x2040000 which is what the MS45 uses for data writes) and made the above mentioned modifications. WinKFP happily accepted the file and flashed it. It doesn't even care about having a checksum at the end of the file (though you probably have to have test checksum disabled). Could do the same thing for all the other DMEs, just need the correct REFERENZ line in the beginning and the correct offsets.

Would not be difficult to make a program that takes in an MPC and Flash read, corrects checksums, corrects RSA (for MS45) and spits out a valid 0pa and 0da.

[rjahl]

With calibration files only, this probably is not that hard, you will need to know the offset between the BIN and the 0da file but with the MSV70 is the same for all of the data blocks, 0x800000 between the BIN and 0da.

The 0pa files are not at easy. The program section is has three offset values where the data in the BIN file does not match the Intel hex. Attached is a screen shot of the offset table I created for each data block referenced in both of the MSV70 intel files.

Left column is the location reference in the Intel hex file and the right is the difference between the Intel hex file and the BIN. I got lazy with the data found in the internal microprocessor ram and just flagged it with a value of "99".

[Terraphantm]

It's not too hard. Boot sector -> 0x60000 (offset 0x40000), Program in flash -> 0x80000 (no offset), MPC -> 0x400000. Data to 0x8040000 (though I suspect 0x40000 would also work)

Edit: Yep, just tested a binary I built from my BDM dump using this commands, it worked fine:

srec_cat flash.bin -binary -crop 0x20000 0x3FF80 -offset 0x40000 flash.bin -binary -crop 0x80000 0x1750e0 MPC.bin -binary -offset 0x400000 -o MSV70Prog.0pa -Intel

I did add the $REFERENZ line and edit those record types to "10" by hand, but it'd be really easy to write a script file that can do that.

[hassmaschine]

I agree that just using WinKFP seems like a better solution. I don't know that I would ever trust something like that with the code being so finicky - looking at the documentation, it seems a bit of a "hack" that works, but could leave you with a bricked DME. WinKFP won't really let you brick it. In fact I've heard more than one person say the BB Flash tool bricked their DME..

0da/0pa conversion is something I intend to build - actually, it would probably be one of the easiest/first features I could do for my tuning app - I don't even have to write code for the Intel hex/bin conversion, since there are already modules that do that. Also with the disassembly we know where the offsets need to be.

I wonder, is it necessary for example to write to the entire parameter space? or can we just write to specific blocks? 0x40000-0x4FFFF for example?

[Terraphantm]

Originally Posted by hassmaschine

I agree that just using WinKFP seems like a better solution. I don't know that I would ever trust something like that with the code being so finicky - looking at the documentation, it seems a bit of a "hack" that works, but could leave you with a bricked DME. WinKFP won't really let you brick it. In fact I've heard more than one person say the BB Flash tool bricked their DME..

0da/0pa conversion is something I intend to build - actually, it would probably be one of the easiest/first features I could do for my tuning app - I don't even have to write code for the Intel hex/bin conversion, since there are already modules that do that. Also with the disassembly we know where the offsets need to be.

I wonder, is it necessary for example to write to the entire parameter space? or can we just write to specific blocks? 0x40000-0x4FFFF for example?

If we can erase specific blocks, we can probably write to specific blocks. If it erases the whole parameter space, then you have to write the whole parameter space (well you could skip any bytes that are 0xFF).

With fast_baudrate enabled though, it's really not a big deal either way IMO.

[rjahl]

Originally Posted by Terraphantm

If we can erase specific blocks, we can probably write to specific blocks. If it erases the whole parameter space, then you have to write the whole parameter space (well you could skip any bytes that are 0xFF).

With fast_baudrate enabled though, it's really not a big deal either way IMO.

Flashing custom 0pa/0da files, I have run into a few "rules" but have not sorted them out. I had one 0pa file FF out the entire program space even though that specific hex file did not write to any of those blocks. I also think 0pa and 0da files are treated differently. Its will take some testing to sort it out.

If we are only talking about 0da files, who cares? we can write the whole parameter space in 35 seconds.

[Terraphantm]

I think WinKFP will just always erase the whole program space if flashing an 0pa, and always erase the entire parameter space if flashing an 0da. It may be possible for us to erase only certain blocks with another program that we make, but I don't think that's worth the effort.

[rjahl]

Originally Posted by Terraphantm

It's not too hard. Boot sector -> 0x60000 (offset 0x40000), Program in flash -> 0x80000 (no offset), MPC -> 0x400000. Data to 0x8040000 (though I suspect 0x40000 would also work)

Edit: Yep, just tested a binary I built from my BDM dump using this commands, it worked fine:

srec_cat flash.bin -binary -crop 0x20000 0x3FF80 -offset 0x40000 flash.bin -binary -crop 0x80000 0x1750e0 MPC.bin -binary -offset 0x400000 -o MSV70Prog.0pa -Intel

I did add the $REFERENZ line and edit those record types to "10" by hand, but it'd be really easy to write a script file that can do that.

Ya, I did it the hard way and wrote my own tool that creates the 0pa/0da file from the image of an original 0pa/0da file and a Source BIN. The tool also gives you the option to check all of the Checksums in the source bin, and write them to the bin before converting them to Intel Hex format.

The code is really crude and can be slow, but it's the first thing I have written for 25 years. I've used it for all my tuning for the last few months so it does work. You can create a new tune/bin in Tunerpro and this tool is all you need to create a working 0da/0pa file. Checksums in the Bin can be corrected and it automatically corrects each line checksum and the EOF checksum.

I've posted a copy in my drop box if anyone wants to look at it.

https://www.dropbox.com/s/htqbln8u1t...Copy.xlsm?dl=0


You need to select a source 0pa or 0da file, your original BIN, a Microprocessor file and finally your destination hex file. You can calculate the checksums but it will not change them in the bin file until you activate the Copy Checksums to Bin button.

Two rules for working with this file,

1. Don't laugh at it, I don't program for a living. I would certainly go hungry

2. If you improve it, please give me a copy before making a complied version.

Much of this was done the "hard way" with the intention that it could be expanded to other processors. I have left plenty of "comments" through out the code.

Just a reminder, your DME will not accept the modified BIN without a previously installed RSA bypass.

Someone mentioned it should be treated as a "proof of concept".

[hassmaschine]

BTW, it works well enough to be useful (sure makes testing custom files easier), but the boot checksum at 0x20014 doesnt calculate correctly - it includes the checksum at 0x20044, so you have to patch that first then run it again.

[Terraphantm]

Having not looked at the source code yet, couldn't that just be fixed by reversing the order in which the boot checksums are corrected?

[rjahl]

Originally Posted by Terraphantm

Having not looked at the source code yet, couldn't that just be fixed by reversing the order in which the boot checksums are corrected?

I thought I did that?

20044 is calculated before 20014.

[hassmaschine]

Yeah but i think you'd have to insert 0x20044 before calculating 0x20014.

[Terraphantm]

So. For the hell of it I built an 0pa using my script for with my RSA delete binary... and it flashed. Boot sector copied over. Tested it with a file where I deleted the RSA block, and that still verified.

Here's a zip with the 0PA and 0DA combo I used (initial flash requires a valid signature, so the RSA blocks in the 0PA are set to match the one in the included 0DA).

https://dl.dropboxusercontent.com/co...71NJ/file?dl=1

Try it out and let me know if it works. My DME should have been otherwise stock before this flash.

[rjahl]

Originally Posted by Terraphantm

So. For the hell of it I built an 0pa using my script for with my RSA delete binary... and it flashed. Boot sector copied over. Tested it with a file where I deleted the RSA block, and that still verified.

Here's a zip with the 0PA and 0DA combo I used (initial flash requires a valid signature, so the RSA blocks in the 0PA are set to match the one in the included 0DA).

https://dl.dropboxusercontent.com/co...71NJ/file?dl=1

Try it out and let me know if it works. My DME should have been otherwise stock before this flash.

Link does not work....

[hassmaschine]

Didn't work for me either..

[Terraphantm]

Oh, I guess I copied/pasted the wrong link. Anyway it's in the shared dropbox too.

Edit: Link is backup. I'm now thinking there wasn't anything specifically wrong with the old file -- I think my cable is just starting to crap out on me. Nevertheless, this file uses a different strategy. I tested this a few times and the bootsector does copy over. So I think we've officially got ourselves an OBD-writeable RSA delete. Oh and I forgot to mention, this 0PA also includes a trt bypass, because why not?

https://www.dropbox.com/s/0hg9xkjim5...elete.zip?dl=0

[Terraphantm]

In other news I've successfully factored the MS45 key.

Total factoring time was 162.49 hours
The sieving time was 155.10 hours
The linear algebra took 6.68 hours
A few minor steps took the remaining time.
CPU was an i7 4790k (4 cores + hyperthreading, 4.4GHz)

I guess next is the GKE key? I wonder if there's enough interest to setup a distributed computing project to solve the key. As you can see, the sieving step by far took the longest, and that happens to be the part that's "easiest" to do in parallel. Linear algebra phase would have to be done on one computer.

With say... 10 computers going at it, the key can be factored in about a day.

[HiggsBoson]

Maybe i could provide some XEON Server Cores.

How do you compute the keys? Is there some Linux progams that i could run?

[rjahl]

Originally Posted by Terraphantm

Oh, I guess I copied/pasted the wrong link. Anyway it's in the shared dropbox too.

Edit: Link is backup. I'm now thinking there wasn't anything specifically wrong with the old file -- I think my cable is just starting to crap out on me. Nevertheless, this file uses a different strategy. I tested this a few times and the bootsector does copy over. So I think we've officially got ourselves an OBD-writeable RSA delete. Oh and I forgot to mention, this 0PA also includes a trt bypass, because why not?

https://www.dropbox.com/s/0hg9xkjim5...elete.zip?dl=0

OK I've tried this three times starting with a stock program and calibration file. All three times the calibration S7623586 file would flash but the program file fails with the typical Authorization error. However, If I flash a calibration file afterwards, it's accepted. Custom or Stock.

It that what was happening to you?