[rjahl]

Originally Posted by hassmaschine

Is that the galletto mod or is it one I made? I know I had a working one but I think I lost it, lol.

It's a blend from the geletto. I"ll send it tonight. It's only two four byte swaps + checksums.

[Terraphantm]

Originally Posted by hassmaschine

feasible, maybe - but following that code isn't easy, there's not an obvious compare where you could take a register and store it somewhere. I don't fully understand how RSA works, but I think it's likely you would need BMW's private key for it to work? I don't think it calculates the entire hash like it's stored in flash memory?

Obviously, galletto can do it with an OBD flash. So maybe it's possible to write directly to the boot sector, but probably not with WinKFP. I think it's the commands that are being used - I bet the flash routine for the program space/boot sector is slightly different from the flash routine for the parameter space (which is a direct write).

Would WinKFP flash a file with modified segments? Could you make an "0da" that would flash to 0x20000?

The way the RSA check works is:

1) DME computes the hash (I think MD5, might be SHA1) of the target ranges, and pads the data. Like a CRC, the hash can be done fairly rapidly by just loading x # of bytes at a time. Unlike a CRC, finding a hash collision is very difficult

2) The DME decrypts the RSA signature using the public key (which is a large composite number [the modulus] a long with a relatively prime exponent).

If the results of 1 and 2 match, the signature is validated. The signature is generated by encrypting the padded hash with the private key (a properly designed private key is a product of two large prime numbers).

Public modulus is the two prime numbers multiplied together. Current record for factoring an RSA-like number is 768-bits with a gigantic computing cluster. So the 1024-bit keys in these DMEs are probably uncrackable for another 10 years. 2048 and 4096 bit keys found in newer DMEs are going to remain impossible for quite some time unless quantum computers become a thing.

512-bit is doable in about 1-2 weeks with a modern quad core i7. Or about an hour on an Amazon EC-2 cluster. So MS45 is doable if I could figure out the hashing algorithm and the exponent BMW used.

Capturing the hash might help figure out the hash and pad algorithm, which would be useful on a DME where the key is small enough to be cracked. But it's pretty useless for the MS*70.

[rjahl]

RSA Delete that I have been using is the following

0x030580 2C 0C 00 FF Replace with
0x030580 7C 0C 60 00

and
0x0300D9 2C 0C 00 FF Replace with
0X0300D9 7C 0C 60 FF

Of course checksums as well.

I think it will work with just the 0X0300D9 change but I have not bothered to try.

[hassmaschine]

Yeah thats my original one. Strange, i tested it later and had issues. I'll try it again.

[rjahl]

Originally Posted by Terraphantm

The way the RSA check works is:

1) DME computes the hash (I think MD5, might be SHA1) of the target ranges, and pads the data. Like a CRC, the hash can be done fairly rapidly by just loading x # of bytes at a time. Unlike a CRC, finding a hash collision is very difficult

2) The DME decrypts the RSA signature using the public key (which is a large composite number [the modulus] a long with a relatively prime exponent).

If the results of 1 and 2 match, the signature is validated. The signature is generated by encrypting the padded hash with the private key (a properly designed private key is a product of two large prime numbers).

Public modulus is the two prime numbers multiplied together. Current record for factoring an RSA-like number is 768-bits with a gigantic computing cluster. So the 1024-bit keys in these DMEs are probably uncrackable for another 10 years. 2048 and 4096 bit keys found in newer DMEs are going to remain impossible for quite some time unless quantum computers become a thing.

512-bit is doable in about 1-2 weeks with a modern quad core i7. Or about an hour on an Amazon EC-2 cluster. So MS45 is doable if I could figure out the hashing algorithm and the exponent BMW used.

Capturing the hash might help figure out the hash and pad algorithm, which would be useful on a DME where the key is small enough to be cracked. But it's pretty useless for the MS*70.

Thank you for taking the time to explain this. I guess I over simplified the problem.


I did not think we could capture the private key, just the RSA of a single specific program. All we need is the validated signature for a program with RSA delete for the calibration file.

Just brainstorming....

[hassmaschine]

Yeah, thats what i was thinking too. It would be specific to the boot code modification only.

[Terraphantm]

Originally Posted by rjahl

Thank you for taking the time to explain this. I guess I over simplified the problem.


I did not think we could capture the private key, just the RSA of a single specific program. All we need is the validated signature for a program with RSA delete for the calibration file.

Just brainstorming....

Yeah, unfortunately with how asymmetric encryption works, the DME never actually generates a valid signature for anything. It's purely a verify function.


With that said, Kess V2 *is* able to correct the RSA signature right? That means it must have the private key. If we can recover that (along with the hashing algorithm), then we can sign anything.

[hassmaschine]

I don't think so. I had to do an RSA delete for somebody who was trying to flash a modified program with a real Kess V2 because it failed the signature check over OBD. Alientech customer support told them they couldn't flash outside the parameter space. I doubt BMW used a different key for the program and parameter space, so they are doing something else for the parameter signature. Maybe something like the Galletto, or the OFT, or any of the handheld tuners that are resold by places like AA.

If they do have a private key, then BMW uses a different one for the program/parameter spaces. But in the boot sector there's only one public key right?

[Terraphantm]

Originally Posted by hassmaschine

I don't think so. I had to do an RSA delete for somebody who was trying to flash a modified program with a real Kess V2 because it failed the signature check over OBD. Alientech customer support told them they couldn't flash outside the parameter space. I doubt BMW used a different key for the program and parameter space, so they are doing something else for the parameter signature. Maybe something like the Galletto, or the OFT, or any of the handheld tuners that are resold by places like AA.

If they do have a private key, then BMW uses a different one for the program/parameter spaces. But in the boot sector there's only one public key right?

It's the same key for both (otherwise flashing w/ the pointers set to the parameter space wouldn't work).

It's possible Kess doesn't actually correct the program RSA because they didn't bother coding that in. But if it's able to correct the parameter RSA signature, then it must have the private key (or at least something along the lines of the "fakesigning" bug that was present on the Nintendo Wii)

[hassmaschine]

Yeah I'm not sure. I'd have to see a readout of a DME flashed with Kess. If the boot sector is not modified then they must have a key of some sort. The RSA checks are separate for the program/parameter space it could be they only modified the parameter space routine.

[rjahl]

Ok for the record, after I separate pin7 and pin8 on my cable and change both winfkp trace levels to 0, I can flash a full custom calibration file into the car within 35 seconds.

That's the time between pushing the program button until I get the program ok flash screen.

Hell, it take four times as long over BDM and I don't need to pull the DME. The BIN to ODA Converter program I have seems to be running really well, it's crude but it works.

[drc38]

I take it changing the winkfp trace and api levels has no effect unless you want to debug?

[rjahl]

Originally Posted by drc38

I take it changing the winkfp trace and api levels has no effect unless you want to debug?

Yes, Debugging is the only reason I reason for the trace.

[Slim125]

Good day
MILANSTEUERUNG
I to wert_02, and it after coding all the same remains to wert_01.
https://imgdepo.com/show/9618988

Originally Posted by hassmaschine

Ah, I read it as Milan Steuerung. Not MIL Ansteuerung (MIL control). oops!

I don't think you can change anything on the DME with "coding". It needs to be flashed.

There's a byte on the DME to disable the MIL. so you would turn that on. And instead of changing the speed selector (which isn't possible unless you reset the hours and I believe odometer), you can just max all of them out (FF or 255kph/158mph).

If you have a way to flash your DME I can probably help you change those settings.

I can lay out dump msv70

[hassmaschine]

Yeah i dont think you can change coding after the hour/km limit (i think its 10 hours /1000km or something). They are permanently locked. You have to flash it.

[Slim125]

What to do?

I was told need to reset the engine hours in EEPROM st95320 . What there to govern I don't know.

[hassmaschine]

You can't. Its not possible to reset engine hours.

Why not just flash it with the MIL control byte set to 0?

[rjahl]

Originally Posted by Slim125

What to do?

I was told need to reset the engine hours in EEPROM st95320 . What there to govern I don't know.

I would stop chasing wild geese. I have only read one series of posts where someone successfully changed their powerclass. It took him a year and he still bought a complete new DME. I'm sure it's doable but it's simply far easier to create a new high power class tune and flash it with the appropriate tool.

All the information required is written right here in this single post! It's a long read but there is no better source if information on this subject.

Maybe someone will create a new clean post with only informative details but I would not hold your breath.

[Slim125]

Originally Posted by hassmaschine

Why not just flash it with the MIL control byte set to 0?

How to do it? After I can change to wert_01 - MILANSTEUERUNG ?

[hassmaschine]

You have to flash a modified binary. NCSexpert cant help you.

[Terraphantm]

Originally Posted by hassmaschine

You can't. Its not possible to reset engine hours.

Why not just flash it with the MIL control byte set to 0?

This might actually be something we're able to tackle via the use of a modified 0PA. Looks like the routines that store the powerclass, et al are in the program space rather than boot sector. So I imagine it's likely a matter of telling the routine to ignore the time / mileage counter (and it might also be possible to craft a program that resets that counter to zero)

Could also be one of those things that the DME has no problems writing, but EDIABAS doesn't unless timer is 0.

[Terraphantm]

Well, I managed to change the "VMAXCODIERUNG" and "OLULCODIERUNG" on my DME.

This is the section of code that's relevant for the PowerClass config (there are other nearly identical checks for vmax, cat converter, MIL, etc).



Now in my case I have those AIF RSA delete bytes set, so my DME was receptive to changing the powerclass, etc. But you can just write a modified 0PA with those branches modified.

Coding with NCSExpert on the other hand is actually not as simple as it seems. FSW_PSW coding doesn't work; you have to do nettodata coding, and even then you can only edit a single parameter at a time.

Easiest way:
1) Load NCS Expert, read 6BMOT.
2) Load NCS Dummy, open the correct daten file (MSV70.C04 for me), and load your NETTODAT.TRC file
3) Check the boxes for the value you want to edit. In the example below, I'm changing OLULCODIERUNG to wert_02



4) Expert the Nettodata file (I just saved it as NETTODAT.MAN)

5) Back in NCS Expert, click on "Basic Functions" (F5)

6) Select coapiCodeSgByNettoData and hit Okay

7) Under Nettodatenliste, enter the file name of your nettodata file (nettodat.man in my case)

8) Hit okay

Wait a couple seconds and it should be done. Read back your FSW_PSW, and you should see the new setting take effect.