[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!!!

[hassmaschine]

Ok so I think the reason my modified 0da write didn't work is because I used the wrong file to build my 0pa - it had the RSA key mods but not the RSA delete. :|

it's a comedy of errors..

[Terraphantm]

Originally Posted by hassmaschine

Ok so I think the reason my modified 0da write didn't work is because I used the wrong file to build my 0pa - it had the RSA key mods but not the RSA delete. :|

it's a comedy of errors..

Haha, I've made the same sort of mistake several times myself. But so far it sounds like it should work. In which case we've completely circumvented the security.

Would be interesting to see if we could use a similar method for the MSx80/1 (and newer?). Have to be careful with boot sector mods there though since BDM isn't an option - could result in complete bricks.

[hassmaschine]

I looked at it the other day and i think it will work there too.

[Terraphantm]

MSS6x is probably feasible too. Public key is present in the 0PA.

Looks to be the case in the MSD8x too (can't verify it's the public key without disassembling, but it's declared pretty much in the same format as all the other DMEs and the MD5/SHA1 table follows immediately after... so probably public key)

[rjahl]

Originally Posted by Terraphantm

MSS6x is probably feasible too. Public key is present in the 0PA.

Looks to be the case in the MSD8x too (can't verify it's the public key without disassembling, but it's declared pretty much in the same format as all the other DMEs and the MD5/SHA1 table follows immediately after... so probably public key)

No, no, next hat trick needs to be the ZF TCU.

[Terraphantm]

Well I picked a random GKE 0PA, and also found what appears to be a public key near MD5 tables.

Looks like pretty much all of the contemporary BMW units may have the same flaw. Ironically, the MS45, which was one of their first DMEs with RSA, is also more secure (ignoring the small keys) since the boot sector isn't writeable over OBD.

My next project will probably be to try and figure out how to generate a signature myself (512-bit keys which are in the early stuff are crackable with today's consumer hardware in 1-2 weeks)

[Terraphantm]

On another note, I've been taking a closer look at those values that I've been calling "keys", and I don't think they're keys directly. A good RSA key is a factor of 2 primes of about the same size. But I've just been doing some factoring, and nearly all of them have at least a few small factors (some are also even numbers, which means one factor is 2 by definition).

I don't think it is an endianness issue since I get bad keys when going to little endian too

What I do know is that changing even a single bit in those values does break the signature validation. So they're definitely related to RSA. But I suspect they're manipulated in some fashion before being used for decryption.

[rjahl]

Damm. Who has a spare megatronics unit from a first generation 6 speed ZF auto that they can donate for a good cause?

ZF 6HP19.

Don't need a functioning valve body just the ECU.

[dstrickland]

Originally Posted by rjahl

Damm. Who has a spare megatronics unit from a first generation 6 speed ZF auto that they can donate for a good cause?

ZF 6HP19.

Don't need a functioning valve body just the ECU.

I'm donating a 2nd gen to Hass when I get back in January. I've got a few EGS laying in a box, but I think their all 5hp from some older e53's.

[hassmaschine]

yeah, I thought that too. The trick is if there are 2 "keys" (or hashes, or whatever) that we can use to trick the security routine. I'm not sure if the EGS has a seperate parameter/program space like the DMEs do.

I have an OBD read I tried to disassemble but I'm not confident that it's a good file. Either that or there's way, way less code in an EGS than there is inside a DME (a good possibility).

Not out of the woods yet. Still need to have a successful 0pa write (done a few times now), followed by a modified 0da write. So far, I've only been able to write a modified 0da after flashing the RSA delete over BDM.

Also, I seem to have problems getting it to flash even after a clean write back to a stock file. I have to restart the DME/WinKFP several times before it will flash. I know immediately if it's going to work by how the DCAN cable lights blink (short flashes = sucess, long flashes = fail).

It's really frustrating because it will fail several times in a row, and then suddenly it will start - it's not at the end either, it's right at the beginning before it's even sent anything to the DME. Both 0pa and 0da files, stock and modified..

[rjahl]

Originally Posted by hassmaschine

yeah, I thought that too. The trick is if there are 2 "keys" (or hashes, or whatever) that we can use to trick the security routine. I'm not sure if the EGS has a seperate parameter/program space like the DMEs do.

I have an OBD read I tried to disassemble but I'm not confident that it's a good file. Either that or there's way, way less code in an EGS than there is inside a DME (a good possibility).

Not out of the woods yet. Still need to have a successful 0pa write (done a few times now), followed by a modified 0da write. So far, I've only been able to write a modified 0da after flashing the RSA delete over BDM.

Also, I seem to have problems getting it to flash even after a clean write back to a stock file. I have to restart the DME/WinKFP several times before it will flash. I know immediately if it's going to work by how the DCAN cable lights blink (short flashes = sucess, long flashes = fail).

It's really frustrating because it will fail several times in a row, and then suddenly it will start - it's not at the end either, it's right at the beginning before it's even sent anything to the DME. Both 0pa and 0da files, stock and modified..

Are you pulling power from the DME between flashes? Flash voltage?

[hassmaschine]

Typically yes, but it doesn't seem to matter (actually, I have better luck if I don't reset it). I have plenty of power - about 15v.

It's not like it starts flashing and then fails - it never begins at all. WinKFP does its file check, then it spends a few seconds trying to talk to the DME, and then it errors out.

[Terraphantm]

Originally Posted by hassmaschine

Typically yes, but it doesn't seem to matter (actually, I have better luck if I don't reset it). I have plenty of power - about 15v.

It's not like it starts flashing and then fails - it never begins at all. WinKFP does its file check, then it spends a few seconds trying to talk to the DME, and then it errors out.

What's the latency of your cable set to? And are you using CAN or K-line for comms?

[hassmaschine]

I never looked at it TBH. It's probably the issue.

Honestly, I don't know if it's using Kline or DCAN. it's a DCAN cable - but I have both hooked up to the OBD port so I can use PAsoft to make RAM dumps.

[Terraphantm]

Originally Posted by hassmaschine

yeah, I thought that too. The trick is if there are 2 "keys" (or hashes, or whatever) that we can use to trick the security routine. I'm not sure if the EGS has a seperate parameter/program space like the DMEs do.

I think they do since they have 0PAs and 0DA files. Things like the alpina tune are equivalent to changing the parameter space.

[hassmaschine]

Latency is already 1. Other ideas?

[Terraphantm]

Originally Posted by hassmaschine

Latency is already 1. Other ideas?

I would try temporarily disconnecting either the CAN lines or the K-line. And if you decide to use CAN, make sure the bus resistance is correct.

[hassmaschine]

I think that was my problem. I unplugged the K-line pin and it flashes every time.

Still haven't successfully flashed a modified 0da after the modified 0pa. I think I need to make sure I reboot the DME first - it looks like it doesn't move any of the data from the 0x60000 - 0x7FFFF block until after a reboot. Or at least, after my 0da write failed, I pulled a read with BDM and the RSA routine and boot sections were still unmodified.

However, flashing the modified file via BDM, it will take a modified 0da every time. So I'm close.

Edit: It isn't copying anything from 0x60000 - 0x7FFFF to the boot sector for some reason. I rebooted it several times and the original boot code is still there.

[rjahl]

Originally Posted by hassmaschine

I think that was my problem. I unplugged the K-line pin and it flashes every time.

Still haven't successfully flashed a modified 0da after the modified 0pa. I think I need to make sure I reboot the DME first - it looks like it doesn't move any of the data from the 0x60000 - 0x7FFFF block until after a reboot. Or at least, after my 0da write failed, I pulled a read with BDM and the RSA routine and boot sections were still unmodified.

However, flashing the modified file via BDM, it will take a modified 0da every time. So I'm close.

Edit: It isn't copying anything from 0x60000 - 0x7FFFF to the boot sector for some reason. I rebooted it several times and the original boot code is still there.

If you want more confusion, I posted another file in the Dropbox link I sent the other day. This time, I pulled the plug on the galletto ODB when it had finished about 90% of the write routine. A quick look at the bin tells me that a lot more then just the 0x60000 through 0,X7FFFFF is moved at the end of the flash.

[Terraphantm]

Originally Posted by hassmaschine

I think that was my problem. I unplugged the K-line pin and it flashes every time.

Still haven't successfully flashed a modified 0da after the modified 0pa. I think I need to make sure I reboot the DME first - it looks like it doesn't move any of the data from the 0x60000 - 0x7FFFF block until after a reboot. Or at least, after my 0da write failed, I pulled a read with BDM and the RSA routine and boot sections were still unmodified.

However, flashing the modified file via BDM, it will take a modified 0da every time. So I'm close.

Edit: It isn't copying anything from 0x60000 - 0x7FFFF to the boot sector for some reason. I rebooted it several times and the original boot code is still there.

Spitballing, but think that could be related to not having the BSU update in WinKFP enabled?

Edit: My MSV70 came in early. Just took a BDM read of it, and now I'll play around with RSA.

Edit 2: Well I got about as far as you. Can flash an arbitrary 0PA without tripping the signature check, but boot3 doesn't appear to actually be copied to 0x20000. Activating Boot Sector Update in WinKFP made no difference.

Maybe there's some sort of version check? If the new boot3 is newer than what's present, it'll copy it, otherwise it won't?

[Terraphantm]

Well here's an interesting one.

Operating under the assumption that there's a version string that dictates whether or not the boot sector actually gets copied, I went hunting for an 0PA with a different boot sector. There are in fact 3:

4496915A.0pa
4490559A.0pa
7546990A.0pa

I made the mistake of trying to flash a ZB# corresponding to 4496915A.0pa. The program section flashed (including boot sector), but then the signature check failed on the next step. Tried flashing back to stock, and signature check kept failing.

Turns out, that 0PA has a different public key, though apparently the signatures were generated for the real public key (hence why it copied that boot sector over in the first place). The other two appear to have the correct public key. So I'll have to recover via BDM and try again with a different 0PA.

Edit: Okay, after a lot of testing, I'm convinced there's an additional layer of verification somewhere. Flashed one of those old 0PA/0DA combos, then flashed to my modified one. Flash succeeds, but it doesn't copy over the boot sector. The real BMW boot sectors do copy over. Will have to look at it later.