[hassmaschine]

yeah I wasn't sure about that either - I saw those patch/crack references.

MSD80 isn't that interesting to me ATM anyway - those guys have lots of support. It's MSV80 that has basically nothing..

[hassmaschine]

Originally Posted by hobbit382

So are we thinking it is the same?

no, unfortunately as Terra says, the public keys are different so the private keys also have to be different.

[hobbit382]

Originally Posted by hassmaschine

yeah I wasn't sure about that either - I saw those patch/crack references.

MSD80 isn't that interesting to me ATM anyway - those guys have lots of support. It's MSV80 that has basically nothing..

BBflash does msv80, msd80 and msd85, and from what I've been told, all use the same rsa

[Terraphantm]

Originally Posted by hobbit382

BBflash does msv80, msd80 and msd85, and from what I've been told, all use the same rsa

They're different. BBFlash seems to detect which DME it's dealing with and go from there.

MSD80 and MSD81 have same key. MSV80 and MSV80.1 have the same key. MSD85 is unique (and for that matter, MSD85.1 and MSD85.2 have different keys).

[hobbit382]

I see

[Terraphantm]

So it seems like BB Flash was supposed to be open sourced... did that never happen?

[hassmaschine]

It looked like it was but all the links I found were dead.

The OFT was also supposed to be open source and look how that ended.

[Terraphantm]

Sigh. This is one thing that's always sucked about the BMW community. Oh well, I feel less bad for disassembling it if they advertised the thing as open source.

Edit:

Well using some .NET specific decompilers, I found this:

public static byte[] MD5KeyMSD80 = new byte[]
		{
			161,87,165,68,115,58,2,199,104,170,238,224,9,136,40,62,
			101,111,55,16,135,182,192,2,165,185,9,94,124,0,111,216,
			168,213,64,238,122,32,98,241,140,204,219,139,84,84,181,73,
			182,101,94,27,177,255,150,63,40,68,156,18,94,225,198,24,
			43,175,235,84,221,215,19,117,100,93,215,152,212,205,117,76,
			197,200,158,108,24,103,31,78,21,73,193,3,241,42,240,1,
			74,44,61,249,253,90,249,155,98,210,32,206,164,139,105,99,
			10,249,180,0,31,152,67,147,231,111,162,168,201,82,143,39
		};

Which after converting to hex and rearranging, is the public key. Let's see if there's a private key somewhere.

Edit: I'm pretty sure they're patching out the RSA check. I'm not quite sure why the public key is there; maybe just to make sure you're starting from a stock binary. The only other large array is just a CRC32 table.

[drc38]

A similar approach on 512 bit factoring using Amazon cloud services link

Originally Posted by Terraphantm

I'm using GGNFS/Msieve. This should be enough to get started: http://gilchrist.ca/jeff/factoring/n...ers_guide.html

There are some newer/faster libraries than what he links to on that page out there.



It is different. Public keys for most of the newer modules can be retrieved from the 0PA files.



That last one is 4 different keys. I've formatted it below:

00 00 00 10 74 71 D0 01  8E 90 A7 1A 84 74 88 1C
AE 7E 57 07 03 1C AE 8C  91 51 7B EC D8 A8 BC E0
ED 17 9C 7A 8D 59 90 8E  CF 05 7F 67 75 88 3C CD
A8 6B 5F 1E 8B 27 CC 1B  7F AD 72 E8 E0 6E C2 36
A2 E2 46 E7 00 00 00 00  00 00 00 01 00 00 00 07

00 00 00 10 2D AB F6 B1  D9 0F 7F DF E3 7F FB 8B
6A E2 70 CE 79 FE B5 BC  E3 40 D8 BC C2 CE 16 B1
4E C2 9D 51 69 70 B0 23  15 3D 04 CE 76 55 96 01
B4 B2 8C 87 B5 90 E7 94  61 58 06 4A 9D 03 C9 25
A1 F4 DF 76 00 00 00 00  00 00 00 01 00 00 00 07


00 00 00 10 8D 6C 9F D3  99 63 86 34 27 25 34 2F
27 5D 72 1C F9 D4 30 44  4A FB A9 69 17 9A 3E 53
04 9C C0 CF B1 F8 FE 9E  2B D6 A0 B3 3F A8 DC 49
4C 9D B6 60 11 79 3E 3D  43 D6 D2 DF 36 29 0C 4B
9C C0 D7 D5 00 00 00 00  00 00 00 01 00 00 00 07


00 00 00 10 94 62 6F B3  3F 39 C2 DB 78 DA 3E 0B
44 76 FC 60 23 D2 6E 0B  87 67 60 AB 48 B2 1C 2D
5B A0 AD A2 BE F6 30 F6  AA 84 7B 00 1F 48 50 A3
3C 62 50 55 60 D0 F7 A6  EF 83 85 16 AD 5D DF 39
9B D7 45 76 00 00 00 00  00 00 00 01 00 00 00 07

The last one I believe is for verifying the tune/program. The other 3 seem to be for different levels of communication authentication.

That "00 00 00 07" is the public exponent.

To verify a signature, formula is:
(sig ^ e) mod n

Where sig is the signature, e is the public exponent (7 in this case; 3 on some DMEs), and n is the public key. Result should be a non-padded MD5 (at least it has been on the 3 modules I checked)

And remember, they're stored backwards. So that last key would be 9BD74576 AD5DDF39... 94626FB3

[Terraphantm]

Originally Posted by drc38

A similar approach on 512 bit factoring using Amazon cloud services link

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.

[PhaseP]

Edit: I'm pretty sure they're patching out the RSA check. I'm not quite sure why the public key is there; maybe just to make sure you're starting from a stock binary. The only other large array is just a CRC32 table.

I took a look with ILSpy. Those MD5KeyXXX are not really used in the code. If not already using, use something like ILSpy (or dotPeek), which easily gives analyzes of what calls what member. With ILSpy "Right click -> Analyze" on any member.

As much as I can tell, they do patching (move chunks of bytes around update some bytes), but also calculate and I think write to the flash some checksum(s) based on a custom CRC32 table. It is in FlashModel.Flash.PrepareBinary method.

[PhaseP]

And what is more interesting to me is those patch/crack code looks like is independent whether ECU is MSD80, MSD85 or MSV80; since I couldn't see any specific code for such checks in that method (or the ones it calls). But I may have missed. I looked over from curiosity, I don't intend to figure out exactly what they are doing.

[Terraphantm]

Originally Posted by PhaseP

And what is more interesting to me is those patch/crack code looks like is independent whether ECU is MSD80, MSD85 or MSV80; since I couldn't see any specific code for such checks in that method (or the ones it calls). But I may have missed. I looked over from curiosity, I don't intend to figure out exactly what they are doing.

Just took a look at the patch.

They changed the parameter section RSA pointers to the program section RSA pointers. Very similar to the trick I described earlier for the MSV70. As long as the program section and boot sector are unmodified, that RSA check will always return a valid result.

Edit: Actually maybe not. I can't get the pointers they used to generate the correct md5 (I am able to validate the stock signature). I think the patch is a red herring. The code in "LocateModifyCrack" seems to modify the bootsector with a branch that will bypass the RSA check (basically identical to the bootsector RSA bypass in the MSV70). The patch is probably a remnant from before they were able to modify the boot code.

I suspect the DES stuff in "KeyExchange" is what's used to authorize the boot sector write

[PhaseP]

Originally Posted by Terraphantm

I suspect the DES stuff in "KeyExchange" is what's used to authorize the boot sector write

I have seen that but thought it is for communication authentication with the Bavarian cable they are using. They say it doesn't work with other inpa cables.

I didn't think they add the patch in vain or it is left over. Code is not very straightforward to follow but not too bad either. They move more than one block and check if flash file had already been patched if so give error etc.
I hadn't look well enough to determine but besides bypass I think they add Crc checks based on that custom crc table. If this is correct this may be what yours is missing.

[Terraphantm]

The patch doesn't work though. Even if it's added, it won't fix anything (there's even a typo in the patch).

The real magic is in the crack subroutine. It searches for a string of bytes which is in the RSA-verify part of the boot sector. Then after finding those bytes, it changes a nearby jump condition so that the RSA check always passes. It then changes a single byte in that string we found earlier - likely so the software can tell whether the patch was already made. CRC32 is likely to correct the DME's builtin checksums (In addition to RSA, the DME has CRC32s that it verifies every loop instead of only after a flash)

My understanding is that these tricore CPUs have a "password" that allows boot sector writes.

I think all the cable stuff is handled in the MicroCAN2.dll

[hassmaschine]

So at the very least, they have the password for boot sector writes? Or maybe the BT cable does, and that's why the flash tool only works with it.

[Terraphantm]

Originally Posted by hassmaschine

So at the very least, they have the password for boot sector writes? Or maybe the BT cable does, and that's why the flash tool only works with it.

I think so. I don't know how else they would be writing to the boot sector without either the password or the RSA private key (and if they had the RSA private key, why patch the boot sector?)

[hassmaschine]

ok, so we have an idea of how the BB flash / BT cable works - they have the password for the boot sector, and are writing an RSA patch (which also means somebody disassembled MSV80, MSD80, and MSD85, or at least the boot sectors are the same). So how does the OFT do it? The OFT also works on MSV70. I'm guessing it's similar.

If we can extract the proper boot code patch it seems like it might be worth trying a similar attack on MSV80 as we have on MSV70. Not sure if WinKFP has the "password" for boot sector access - but maybe that's where BB flash and the OFT got it from.

I just keep thinking MSV70 gets all the love because it's easier to hack, but most N52 powered cars are MSV80..

[Terraphantm]

MSV80 and MSD80 and MSD85 don't have identical boot sectors, but they're similar enough that simply searching for the right string allows them to make an equivalent patch (basically makes the comparison of RSA_Delete_1 return a valid result and bypass the RSA check). It does appear that the password (or however they're allowing a boot sector write) is the same for the 3 DMEs.

Not sure what OFT does. If the MSV70 also allows a boot sector write with some sort of password, I don't know how to invoke that. They could very well just be successfully doing what we've been trying to do with the RSA pointer trick (since we're apparently not the first ones to think of it)

Really wish the source code was available. Would not be super difficult to adapt the flash routines for the MSV70 and MS45. Granted ILSpy gets us pretty damn close to having the actual source.

[e90ftw]

Originally Posted by Terraphantm

So it seems like BB Flash was supposed to be open sourced... did that never happen?

Here you go

https://app.box.com/s/drrdhumw46vaystof2a9

.7z Link
http://flashguy.blob.core.windows.ne...ash.1.0.0.5.7z

[Terraphantm]

Awesome. Let's see what they did.

Edit: Seems like the MSV80 and MSD85 stuff is largely leftover from a time when they had planned to implement it, but didn't. Maybe we can fix that.

Still not seeing them doing anything crazy for the RSA bypass. Seems like they request security access (private key can likely be recovered from WinKFP -- if not 512-bit is easy to factor), and then just write the boot sector. If BMW allowed the boot sector to be written before the RSA check is done, that's sort of a fail on their part.

[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