[hassmaschine]

Originally Posted by rjahl

Yep, that was my guess. Still flashing.

any luck? did it complete the flash, copy the boot sector, etc? or did it leave everything stuck at 0x60000-0x7FFFF?

[rjahl]

Originally Posted by hassmaschine

any luck? did it complete the flash, copy the boot sector, etc? or did it leave everything stuck at 0x60000-0x7FFFF?

No luck at all. I get the security violation at the end of the write. Tried a few times. I need to check my file for errors.

I can write a normal stock file but it's still slow 25 minutes. I increased the voltage on my power supply to 13.8 but it made no difference.

Did not have much time last night. I have something going on at work that has me leaving home at 3:00 AM today. Not amused......

[rjahl]

Ok, I must be doing something wrong. I've tried another four times and I still get a security violation.

Also flashing still takes forever, 30 minutes. Watching the blinking light , there are periods of constant data transfer then periods were things are pretty slow.

[rjahl]

OK, I found the bottle neck in my Winfkp flashing. I had the API and IFH trace settings too high. Turned them to zero and I can flash a complete program in 5 minutes and a calibration file in 35 seconds. Good enough for me. On the bench, I have not tried in the car yet.

Still no luck with the RSA bypass but at least I won't grow gray hair watching it flash.

[uzivatel]

hi, today i studying my engine parameter for reason one day my car going well but casually i feel less power and torque with more loud sound at 2000rpm.

I found out that at full load targeting valvetronic position is 209° and real showing 179° its mechanical limit.

it means that my dme was tuned by previous owner?

how i can know if i have stock original data? by ISTA/P i see have latest version DME program date 03.03.2008

[rjahl]

Originally Posted by hassmaschine

any luck? did it complete the flash, copy the boot sector, etc? or did it leave everything stuck at 0x60000-0x7FFFF?

Finally sorted out all of my flashing problems, If you just change the pointers and copy the RSA from the calibration file, the Winfkp does not see an error but your are left with artifacts near 0x60000. If you try to modify the boot sector you it leaves more than just a few bytes, it seems to leave the hole boot sector in place at 0x60000

Picture is of the first case, with just a few bytes left over.

[Terraphantm]

Interesting. I wonder if it's actually copying the bootsector from 60000 when it's leaving those artifacts. Guess when I get home I can test with one of the old boot sectors.

[rjahl]

After flashing several different types of files and studying the results I'm now thinking that the ODF flash processes has a little twist. I'm thinking that the pointers also tell the original program where the new program can be found.

Remember at some point the execution needs to jump to the new program in a temporary location to allow the original program to be overwritten.

If I'm correct the first pointer needs to be directed at executable code and not the calibration tables as we have been trying to do.

The galletto flash copies the original program to 0x40000 and then moves the first pointers to that location.

Somehow the new program written into 0x60000 is still moved to 0x20000. Presumably because the shift is hard coded into the program?

When the galletto flashes the calibration file the temporary program is overwritten.

Sound plausible?

I need to develop a test to prove this.

[Terraphantm]

Maybe we could just set the first pointer for 60000 -> 7FF7F, set the length to 0 (RSA routine doesn't actually look at the "end" pointer), then just set the next two pointers to check the range we want to signature check?

[rjahl]

Originally Posted by Terraphantm

Maybe we could just set the first pointer for 60000 -> 7FF7F, set the length to 0 (RSA routine doesn't actually look at the "end" pointer), then just set the next two pointers to check the range we want to signature check?

OK tried that, no luck.

Still flashes without a signature error report but the new program is left at 0x60000 with the original still sitting a 0x20000.

I took a quick look at the ediabas trace files for both a standard program flash and one of these custom files and the communication between the Winfkp and the DME is the same. Signature check and ECU status checks are reported good.

[hassmaschine]

Yeah the tansfer from 0x60000 to the final location is handled internally. It looks like the pointers are used for the RSA calc as well as the internal transfer from temp to permanent memory.

Are we sure we can't use the RSA key for the program space to flash modified 0da's? The only reason i can think of that it wouldn't work is if 2 segments are too long for it to factor the entire program hash.

Basically, 2 segments, first is 0x820000, second is 0x880000, and the 2 lengths are as required.

[rjahl]

Originally Posted by hassmaschine

Yeah the tansfer from 0x60000 to the final location is handled internally. It looks like the pointers are used for the RSA calc as well as the internal transfer from temp to permanent memory.

Are we sure we can't use the RSA key for the program space to flash modified 0da's? The only reason i can think of that it wouldn't work is if 2 segments are too long for it to factor the entire program hash.

That seems like a good idea, so we do the opposite procedure using the pointers at 0x40423?

[hassmaschine]

Yes. The parameter space gets flashed directly to the final location. Unless of course the pointers are used for that too..

[Terraphantm]

I don't think there's enough space. Parameter routine only checks upto 2 segments. For the program section, 5 segments are checked, and 4 of them are non-contiguous.

So since the program space gets written and does run... Would it be feasible to insert a subroutine does the 0x60000 -> 0x20000 copy?

Edit: Do we even know where in the boot sector the 0x60000 -> 0x20000 routine is? If not... Guess we have to find that and see what it's trying to do.

[rjahl]

OK here's another crazy idea from the hacking world.

What if we inserted a jump at the RSA comparison instruction leading the execution to a a new subroutine. The new subroutine would capture the hashed RSA bytes and store them in the NVR. Flash this into the DME via BDM and then run a Winfkp flash routine twice. First time to capture the hash values of the custom 0pa file and the second to restore the DME to a state where we could read the NVR with INPA.

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

[rjahl]

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?

I don't think the galletto is writing directly to the boot sector. Could be wrong,but it appears to go through the same cycle of placing the boot sector / program in 0x60000 first.

I traced the winfkp during a flash and the command messages used by winfkp appear to be the same regardless of the boot sector write. I can test this again to be sure. I think I can log the complete transmission between the devices but it will be very slow.

[rjahl]

No winfkp will not let me flash into 0x20000. I got a violation error.

[hassmaschine]

It must be hard coded in the msv70.prg.

I think the only realistic alternative would be to use KWP protocols like Galletto does to modify the boot sector in situ. Or maybe EDBIAS commands could work (maybe easier, since it's not so low-level). I dunno - it's sort of above my knowledge/skill level at the moment.

For now I'm going to focus on testing the RSA delete that I can flash via BDM, and modifying custom 0da files - getting ready for my wife's 3 stage swap (thinking maybe next week).

[rjahl]

Originally Posted by hassmaschine

It must be hard coded in the msv70.prg.

I think the only realistic alternative would be to use KWP protocols like Galletto does to modify the boot sector in situ. Or maybe EDBIAS commands could work (maybe easier, since it's not so low-level). I dunno - it's sort of above my knowledge/skill level at the moment.

For now I'm going to focus on testing the RSA delete that I can flash via BDM, and modifying custom 0da files - getting ready for my wife's 3 stage swap (thinking maybe next week).

Understand.

I have a working RSA delete that I push in with the BDM. Been using it for six months or more . Do you want that file? I thought I sent it some time ago.

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

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