[hassmaschine]

I'm now at 8,489 parameters mapped out of ~8700.

The remaining ones will have to be done by hand - actually, some of them don't even have names, as they didn't exist in the original software version. I'm guessing few of them are of much use anyway.

edit: 8,592.. probably 80 of them are DTC codes (easy to do, just takes a bit of time).

I'll probably stop for a while and work on other projects.

[Terraphantm]

Originally Posted by hassmaschine

That doesn't work. the powerclass won't match and the DME will be in limp mode. Also, after so many hours (basically when the car is first produced) - you can't change the powerclass in the car either (it's locked). So unless they are unlocking the powerclass/hour counter, something else is going on.

and you can't just change it in the 0DA file either; unless they have BMWs 1024bit RSA private key to recalculate the hash, the flash will fail.

They may be flashing from a 2.5 liter to a 3.0 liter file, which may work - but you can't flash from a single stage to a 3 stage file.

However, you can flash an arbitrarily modified program as long as you change the pointers to match the parameter section (as long as the paramter space signature is still valid).

So assuming there isn't some sort of write protection going on, if you modify the code to clear the time counter (which I think is bszsi) instead of incrementing it, then you can change the power class with NCS Expert and flash a valid 3.0si tune - all over OBDII.

In fact, it looks like the routine that stores the internal powerclass is in the program space rather than the boot like I thought, so you can theoretically modify the routine to ignore the timer.

[hassmaschine]

yeah, it's possible to get around - but they were talking about just taking a specific WinKFP file and flashing it without issues. We know that doesn't work. If you are capable of modifying the program and moving stuff around, you probably don't even need to worry about messing with the power class or winKFP files.

[Terraphantm]

Originally Posted by hassmaschine

yeah, it's possible to get around - but they were talking about just taking a specific WinKFP file and flashing it without issues. We know that doesn't work. If you are capable of modifying the program and moving stuff around, you probably don't even need to worry about messing with the power class or winKFP files.

I was thinking more along the lines of distributing an 0PA (or an 0PA patch) that would allow one to change the power class, and then instructing them to just enter whatever ZB# in WinKFP.

[rjahl]

Originally Posted by Terraphantm

I was thinking more along the lines of distributing an 0PA (or an 0PA patch) that would allow one to change the power class, and then instructing them to just enter whatever ZB# in WinKFP.

Are you saying we could flash a custom 0PA file so long as the signature for the calibration file was still valid and you changed the pointers to look at the calibration file?

Care to explain how would you change these "pointers"

[hassmaschine]

I'm still not sure how it would work, because the program space is RSA encrypted too, and there are references hard coded all over the place.

[CobraMarty]

You guys are all way out there. I have been reading all this and usually have no idea WTF you're talking about but you sure know what your taking about. It's like reading a whole 'nuther language. Well done.

[Terraphantm]

Originally Posted by hassmaschine

I'm still not sure how it would work, because the program space is RSA encrypted too, and there are references hard coded all over the place.

Change these pointers and lengths to match the data section pointers (and 0 out the unnecessary ones) and change the actual signature that's stored to match the data section. So when the DME starts the RSA check, it will load the data that's being pointed to and hash it. Then it will decrypt the signature with the public key and compare that to the generated hash.

Since the signature will be from the data section and the pointers will be pointing to the data section, the hashes will match, and the DME will validate the flash.

[hassmaschine]

Ah, I see. You're not talking about moving the entire program or something - basically just copying the RSA section from the data to the program.

Then you could modify the program space any way you like - bypassing the variant coding check would be easy.

I don't think you could flash modified parameters though - it somehow checks the RSA hash before it flashes it (for example, you can't modify the code that deletes the RSA check in the boot sector, and flash that over OBD). rjahl verified this. Unless somehow you could do the same thing with the RSA hash in the parameter space (use the one from the boot sector instead?).

[Terraphantm]

Originally Posted by hassmaschine

Ah, I see. You're not talking about moving the entire program or something - basically just copying the RSA section from the data to the program.

Then you could modify the program space any way you like - bypassing the variant coding check would be easy.

I don't think you could flash modified parameters though - it somehow checks the RSA hash before it flashes it (for example, you can't modify the code that deletes the RSA check in the boot sector, and flash that over OBD). rjahl verified this. Unless somehow you could do the same thing with the RSA hash in the parameter space (use the one from the boot sector instead?).

I think the boot sector validation is a little different. Seems to use a different subroutine altogether, and it may be the case that the boot sector is loaded into memory, validated, and then written since it would be important to verify the integrity of a boot sector before flashing it. Could be a different key altogether too.

Can't use this same trick for the parameter space since the parameter validation routine doesn't load enough pointers to substitute one of the other signatures. Unless there's enough unused space to just stick in a complete copy of the parameter space somewhere else in the flash (there isn't enough unused space in the MS45, but maybe there is in the MS*70)

What you probably could do is modify the code to edit any of the NVRAM variables to whatever you want.

[hassmaschine]

Another option would be to use the space at the end of the program space (there's lots) to move any maps that you want to customize. It's not quite enough for an entire copy of the parameters, but it's more than enough for everything that needs tuning.

Still, for me, it's easier/cleaner to just delete the RSA check with BDM and go from there. Although, I'm thinking this could possibly work on MSV80, where BDM is not an option at all (making program mods basically impossible).

[Terraphantm]

Originally Posted by hassmaschine

Another option would be to use the space at the end of the program space (there's lots) to move any maps that you want to customize. It's not quite enough for an entire copy of the parameters, but it's more than enough for everything that needs tuning.

Still, for me, it's easier/cleaner to just delete the RSA check with BDM and go from there. Although, I'm thinking this could possibly work on MSV80, where BDM is not an option at all (making program mods basically impossible).

Oh yeah, BDM is definitely cleaner, but it does limit mass distribution. Ideally we'd be able to figure out the hashing algorithm and factor the private key and just generate signatures for arbitrary data, but that's not happening with current technology (unless BMW / Siemens picked a key with > 2 factors, like they appear to have with the MS45..)

Definitely worth exploring the MSV80 as well.

Edit: I also noticed that the first segment that's RSA checked is 60000 -> 7FF7F (860000 - 87FF7F), which from the dumps I have seems to be empty. I recall someone (rjahl?) speculating that boot 3 is copied to that area and signature checked before it's written to its final area - there may be some merit to that. If that's the case, changing the pointers to the data section would allow you to modify boot 3 to eliminate RSA checking altogether. Would also explain why I can't actually find a signature field in boot 3 itself.

[rjahl]

Originally Posted by Terraphantm

Oh yeah, BDM is definitely cleaner, but it does limit mass distribution. Ideally we'd be able to figure out the hashing algorithm and factor the private key and just generate signatures for arbitrary data, but that's not happening with current technology (unless BMW / Siemens picked a key with > 2 factors, like they appear to have with the MS45..)

Definitely worth exploring the MSV80 as well.

Edit: I also noticed that the first segment that's RSA checked is 60000 -> 7FF7F (860000 - 87FF7F), which from the dumps I have seems to be empty. I recall someone (rjahl?) speculating that boot 3 is copied to that area and signature checked before it's written to its final area - there may be some merit to that. If that's the case, changing the pointers to the data section would allow you to modify boot 3 to eliminate RSA checking altogether. Would also explain why I can't actually find a signature field in boot 3 itself.

I'm reading but stuck in tragic and cant contribute right now

Very interested

[hassmaschine]

Originally Posted by Terraphantm

Oh yeah, BDM is definitely cleaner, but it does limit mass distribution. Ideally we'd be able to figure out the hashing algorithm and factor the private key and just generate signatures for arbitrary data, but that's not happening with current technology (unless BMW / Siemens picked a key with > 2 factors, like they appear to have with the MS45..)

Definitely worth exploring the MSV80 as well.

Edit: I also noticed that the first segment that's RSA checked is 60000 -> 7FF7F (860000 - 87FF7F), which from the dumps I have seems to be empty. I recall someone (rjahl?) speculating that boot 3 is copied to that area and signature checked before it's written to its final area - there may be some merit to that. If that's the case, changing the pointers to the data section would allow you to modify boot 3 to eliminate RSA checking altogether. Would also explain why I can't actually find a signature field in boot 3 itself.

That's a good point. I never really looked at the addresses for the RSA check in the boot code.

rjahl confirmed that it does copy the boot code into the empty space during the flash process. Basically, he flashed a file he knew would fail authentication, and then did a BDM read of it afterwards.

However, I think you still have a chicken and an egg problem. I think, until the RSA check authenticates and it moves it over, it's running the boot code from the original location - so even if you changed the offsets in the file you are writing, the actual code that is running is going to be looking at the original values and it will still fail. Probably worth trying, however.

[Terraphantm]

Originally Posted by hassmaschine

That's a good point. I never really looked at the addresses for the RSA check in the boot code.

rjahl confirmed that it does copy the boot code into the empty space during the flash process. Basically, he flashed a file he knew would fail authentication, and then did a BDM read of it afterwards.

However, I think you still have a chicken and an egg problem. I think, until the RSA check authenticates and it moves it over, it's running the boot code from the original location - so even if you changed the offsets in the file you are writing, the actual code that is running is going to be looking at the original values and it will still fail. Probably worth trying, however.

If I had to guess how it works:
1) Boot3 from serial buffer is written to 860000
2) Program is erased and flashed
3) RSA check is done (routine executed from boot3 that's at 820000, but the check done against 860000)
4) Boot3 from 860000 is copied to 820000

So if you changed the pointers to something valid, step 3 should still pass, and then it will overwrite boot3 with your RSA-deleted boot3. And then it'll never be a problem again .

[rjahl]

Originally Posted by Terraphantm

If I had to guess how it works:
1) Boot3 from serial buffer is written to 860000
2) Program is erased and flashed
3) RSA check is done (routine executed from boot3 that's at 820000, but the check done against 860000)
4) Boot3 from 860000 is copied to 820000

So if you changed the pointers to something valid, step 3 should still pass, and then it will overwrite boot3 with your RSA-deleted boot3. And then it'll never be a problem again .

So, I have this tool that flashes over ODB and leaves this program section modified....

[rjahl]

On another note, It took me a while to figure out why boot 3 had a different location in 0PA file vs the flash.

The answer was simple, the location specified in the Intel Hex or 0PA file is the correct place to flash that data, its simply moved afterwards.

[Terraphantm]

Originally Posted by rjahl

So, I have this tool that flashes over ODB and leaves this program section modified....

Does that modification actually work? Seems a bit odd to me.

First pointer is changed from boot 3 to the parameter space and the rest are of regions that seem irrelevant to RSA. Unless your software changes the signature that's stored in the program section to match those new regions, I don't see how that would work.

I would try changing the pointers to

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

Would only work if the parameter space has a valid signature. But if this does work, you can use this method to flash a boot_3 that ignores the RSA check, and then modify the parameter section however you want after the fact.

[hassmaschine]

Why not change it to look at the original boot3 block? 0x20000?

The othe code does work - but its pretty messy. My mod is 4 bytes and the checksums.

[Terraphantm]

Originally Posted by hassmaschine

Why not change it to look at the original boot3 block? 0x20000?

The othe code does work - but its pretty messy. My mod is 4 bytes and the checksums.

Because the program rsa signature range covers the pointers themselves in segment 3. So simply changing the pointer invalidates the program signature.

[hassmaschine]

Right, makes sense.

I finally got around to making Winkfp functional - test flashing it right now. Now to dig out rjahl's guide on flashing arbitrary files.

[Terraphantm]

Should also mention that you have to copy the RSA signature from the parameter space as well