[Terraphantm]

I was just double checking my MS45 program RSA bypass, and my format is essentially equivalent to what I posted earlier:

00000002 00840000 008400FF 00840240 0085EAFF 00000000 00000000 00000000 00000000 00000000 00000000 00000100 0001E8C0 00000000 00000000 00000000

So I would try just using the internal addressing scheme instead of the 008xxxxx, but if that doesn't work, there's probably something else going on.

[hassmaschine]

Makes sense. I think the key is to use expert mode.

[rjahl]

Originally Posted by hassmaschine

Makes sense. I think the key is to use expert mode.

Expert mode makes managing the custom files easy. Import what you want into the development folder and go for it. Comfort mode needs to be fooled by overwriting your original datem files with the custom stuff. If you want to test few different files comfort mode is just too cumbersome.

I was also looking at some of the command line scripting available for WinFKP. Perhaps a batch file could take make the process less prone to human error. There are both Command Line parameters and batch processing command scripts available.

[hassmaschine]

A batch file would be neat. Distribute it with the modified 0pa/0da files.

Would be nice if WinKFP didn't check "boot sector update" every time you start it. It's a pain to remember to uncheck it every time, and it wastes at least 40 minutes of time since the flash fails and then you have to reset it again.

[rjahl]

Originally Posted by hassmaschine

A batch file would be neat. Distribute it with the modified 0pa/0da files.

Would be nice if WinKFP didn't check "boot sector update" every time you start it. It's a pain to remember to uncheck it every time, and it wastes at least 40 minutes of time since the flash fails and then you have to reset it again.

Yep, The boot sector update resetting itself is a PITA. The Batch scripting allows you to set the WinFKP options.

I need to look at this again, the 100+ page manual for WinFKP is a horrible document to read

[rjahl]

Originally Posted by hassmaschine

Actually, experimenting a bit I think it would be very difficult to brick the DME. I even powered it down in the middle of a flash to see what would happen. basically, unless you did it at the very moment it is copying the new boot code over the original boot code, you can't brick it. and 0da writes are extremely safe, you could probably write a file full of garbage and you could still get it to flash again.

I've found the same thing, the DME flashing routine with WinFKP is really robust. You can screw it up to a point where Comfort Mode won't deal with it and you need to know how Expert Mode works to make the recovery. Not everyone knows how to pull up the ECU address, select the correct IPO files, 0pa files etc, to make a good recovery. If you are stressed out from crashing your only DME and your nerves are shot, it's even harder.

It took me a long time to get the process correct. Probably something that should be written up and posted.

[Terraphantm]

Originally Posted by hassmaschine

A batch file would be neat. Distribute it with the modified 0pa/0da files.

Would be nice if WinKFP didn't check "boot sector update" every time you start it. It's a pain to remember to uncheck it every time, and it wastes at least 40 minutes of time since the flash fails and then you have to reset it again.

Add "BsuActive=OFF" to the end of COAPI.INI (it'll be in the EC-APSS/NFS/CFGDAT folder)

[hassmaschine]

Cool thanks. that will save me some pain, lol.

[hassmaschine]

Notice anything familliar?
http://m.ebay.com/itm/BMW-DME-MSV70-...256?nav=SEARCH

[rjahl]

Any more progress with the RSA delete?

To save time testing and flashing over ODB I'm wondering if it is possible to capture a failed flash state of the DME via BDM, make the
Changes for the test , then re-flash via BDM. Would the DME reboot and rerun the ODB flash checks?

I guess it would be easy test.

[hassmaschine]

No bueno - I've tried setting the # of segments to 2 and 5, I've tried the segment addresses as 0x840XXX & 0x40XXX, I've tried with a non-modified file and just the signature/references changed - I get "security access denied" at the end of every flash. The good thing, again, is typically after a failed flash, I can just restart it again with a different file (I wrote the stock one again as I was leaving this morning).

The one thing I can think of is maybe it doesn't like segments 3-5 being set to 0. Do we suppose there's anything magical to the segment lengths? Could I just divide the last segment up and make 3 more? like, segments 3, 4 and 5 could be 16 bytes each, and segment 2 would be 48 bytes shorter?

Writing via BDM won't work, because the routine that checks the RSA is only run when activated with an OBD flash. That's why BDM writes don't have to worry about the RSA key matching.

BTW, one thing I never even tried to do was find the 0pa for the 730S A2L. Well, durrr, it's right in there with the Z4 daten files. So I'm going to flash that, pull a full memory read, and I'll have a complete disassembly of the A2L binary (my 921S IDA is basically complete anyway, but some things are fuzzy since MSS70 doesn't have valvetronic or DISA).

[Terraphantm]

Originally Posted by hassmaschine

No bueno - I've tried setting the # of segments to 2 and 5, I've tried the segment addresses as 0x840XXX & 0x40XXX, I've tried with a non-modified file and just the signature/references changed - I get "security access denied" at the end of every flash. The good thing, again, is typically after a failed flash, I can just restart it again with a different file (I wrote the stock one again as I was leaving this morning).

The one thing I can think of is maybe it doesn't like segments 3-5 being set to 0. Do we suppose there's anything magical to the segment lengths? Could I just divide the last segment up and make 3 more? like, segments 3, 4 and 5 could be 16 bytes each, and segment 2 would be 48 bytes shorter?

Writing via BDM won't work, because the routine that checks the RSA is only run when activated with an OBD flash. That's why BDM writes don't have to worry about the RSA key matching.

BTW, one thing I never even tried to do was find the 0pa for the 730S A2L. Well, durrr, it's right in there with the Z4 daten files. So I'm going to flash that, pull a full memory read, and I'll have a complete disassembly of the A2L binary (my 921S IDA is basically complete anyway, but some things are fuzzy since MSS70 doesn't have valvetronic or DISA).

Hmm. Does sound like there may be an extra layer of protection. I'll have to play around when I get my MSV70

This is one area where it would be nice to have a more generic BDM interface rather than one designed specifically for reading/flashing. Would be very helpful to setup a breakpoint when RSA stuff is loaded into memory and just see what's going on.

[Taskmaster]

Originally Posted by hassmaschine

Notice anything familliar?
http://m.ebay.com/itm/BMW-DME-MSV70-...256?nav=SEARCH

Service - Cervice? IS that HackenTT?

[rjahl]

Originally Posted by Terraphantm

Hmm. Does sound like there may be an extra layer of protection. I'll have to play around when I get my MSV70

This is one area where it would be nice to have a more generic BDM interface rather than one designed specifically for reading/flashing. Would be very helpful to setup a breakpoint when RSA stuff is loaded into memory and just see what's going on.

If you look at the data around 80500 in my post#1051. This flash does work, I've found this on my DME after a Galletto and a flash sent by another member.

Look at the first block of data 0x040000 to 0x05FF7F. Is this not part of the parameter section? Then the other blocks are a mix of temp locations for the flash data and the microprocessor? If I'm right, big if. The RSA protected blocks is a little more complicated.

[hassmaschine]

Originally Posted by TheAxiom

Service - Cervice? IS that HackenTT?

oh probably. lol. I kindly asked them to remove my pictures from the listing..

I mean, why wouldn't you trust them? Obviously they know what they're doing, look at that custom bench flash setup.

[hassmaschine]

Originally Posted by rjahl

If you look at the data around 80500 in my post#1051. This flash does work, I've found this on my DME after a Galletto and a flash sent by another member.

Look at the first block of data 0x040000 to 0x05FF7F. Is this not part of the parameter section? Then the other blocks are a mix of temp locations for the flash data and the microprocessor? If I'm right, big if. The RSA protected blocks is a little more complicated.

I've looked at it. It's similar to what we are trying to do. It looks like they've copied a second RSA key into the empty boot space (0x3F240).

Deleting the RSA check is pretty straight forward, what isn't is fooling the RSA check with a modified boot sector. I guess I should study what they did some more and see what I can come up with.

[rjahl]

Originally Posted by hassmaschine

I've looked at it. It's similar to what we are trying to do. It looks like they've copied a second RSA key into the empty boot space (0x3F240).

Deleting the RSA check is pretty straight forward, what isn't is fooling the RSA check with a modified boot sector. I guess I should study what they did some more and see what I can come up with.

I was looking at this again last night and I wonder if those new data segments were actually written high as in 0x40000 bytes high, and just brought down with everything between 0x60000 and 0x 80000 when the flash is finalized. So if written into the 0pa file the address would need to be + 40000 bytes from the binary?

[hassmaschine]

it looks like they changed the key reference to the parameter space to me.

actually, I don't think making an 0pa of that file will work - at least not without some more effort, since those are segments the 0pa file doesn't normally cover.

[Taskmaster]

Originally Posted by hassmaschine

oh probably. lol. I kindly asked them to remove my pictures from the listing..

I mean, why wouldn't you trust them? Obviously they know what they're doing, look at that custom bench flash setup.

It just struck me that it WAS your picture lol! Very trustworthy

[hassmaschine]

So I am a fool. All this time, none of my files worked - well, duh, the checksum for the program space covers the RSA key range. So, uh, I didn't correct it on any of the files I've tested. Durrrrrrrrr!

Off to try again..

[hassmaschine]

It works!

OK, so I'm a dumbass - and it was because I never corrected the checksum in the program space. Durrrrr. Anyway - it definitely worked to use the parameter RSA key & ranges. I set it as 2 segments and zero'd the rest.

I need to double check the file I used to create it (was in a hurry on my lunch break) because the 0da write didn't work (stock file did though). I think I just grabbed the wrong file when I made my 0pa.

[rjahl]

Originally Posted by hassmaschine

It works!

OK, so I'm a dumbass - and it was because I never corrected the checksum in the program space. Durrrrr. Anyway - it definitely worked to use the parameter RSA key & ranges. I set it as 2 segments and zero'd the rest.

Of course, I realized also that in my 0da test file, I neglected to correct the checksum there as well... so that one wouldn't work. I'll correct it and give it another go at flashing a modified 0da (which is the second step anyway).

Very cool!!!