Using WinKFP to write tune on 525D BMW

**djwlindenaar** · 16th May, 2016, 01:56 PM

Hi tuners,
I'm looking into tuning my car and was expecting to be able to flash adapted data using the BMW standard tools WinKFP program. I am able to flash .0da files supplied by BMW without issue, but when I flash a changed file I get "security access denied" in WinKFP. After this I'm still able to flash back the original file, again without issue.
The changed file has been checksum corrected with 'checksum corrector' tool as well as WinOLS, both delivering the same checksum at the end of the file, so I'm guessing that's not the issue.

Procedure followed:

Generate a bin file based on the original .0da file, using my own written python code (DDE509/U7812338.0da)
Edit the bin file (in this test, changed the hysteresis map for the EGR actuation)
Fix the checksums
Generate a 0da file based on the changed bin file, again using my own written python code
Fix the 0da file checksum using NCSDummy
write to the car using WinKFP

U7812338.0da.zip
U7812338.0da.egroff2.zip
WinOLS EGR off2.zip
7812338.zip

Is anyone able to shed some light on what I might be doing wrong..?

Thanks
Daniel

**marek128** · 16th May, 2016, 04:52 PM

Why u dont use galetto kess mpps etc? I think is not able to wirite MOD file by WINkfp too many tests writing file....

**Babos** · 17th May, 2016, 12:54 PM

I think maybe software see ck is other not factory ck

**GolfmkI** · 17th May, 2016, 05:18 PM

I think must be a way, but....
Its worth the effort??

I think is safer, faster use other tools...

Lets WinKfp for simply reflash Ori or official update.

Some years ago (When havent Obd Chiptuning tools) tried in e60....

But should be a way !!

**djwlindenaar** · 18th May, 2016, 07:48 PM

Yeah, I know I could use the other tools. I do like a bit of hacking and already have experience with updating other modules on the car with WinKFP. And the necessary hw/sw.
I guess I was expecting it to be no big issue, given the fact that I was able to get the checksums working.

Apparently there's another step that WinKFP does not implement or something. Does anyone have a clue what that might be?

Sent from my SM-G901F using Tapatalk

**sundayHP** · 27th May, 2016, 12:49 AM

I realize this may be a little o/t, but I am interested in updating software in my '04 320d, I heard it is risky to do it on your own, could you pls provide some sensible advice on this how to diy safely? Thx.

**bobolin4o** · 27th May, 2016, 05:54 AM

Originally Posted by marek128

Why u dont use galetto kess mpps etc?

Because when you have prepared .0da files you will be able to tune all cars just by "update" them...
No matter which software is in the ECU, just with few clicks...
Good idea!

**bobolin4o** · 27th May, 2016, 06:20 AM

Originally Posted by djwlindenaar

Hi tuners,
I'm looking into tuning my car and was expecting to be able to flash adapted data using the BMW standard tools WinKFP program. I am able to flash .0da files supplied by BMW without issue, but when I flash a changed file I get "security access denied" in WinKFP. After this I'm still able to flash back the original file, again without issue.
The changed file has been checksum corrected with 'checksum corrector' tool as well as WinOLS, both delivering the same checksum at the end of the file, so I'm guessing that's not the issue.

Procedure followed:

Generate a bin file based on the original .0da file, using my own written python code (DDE509/U7812338.0da)
Edit the bin file (in this test, changed the hysteresis map for the EGR actuation)
Fix the checksums
Generate a 0da file based on the changed bin file, again using my own written python code
Fix the 0da file checksum using NCSDummy
write to the car using WinKFP

U7812338.0da.zip
U7812338.0da.egroff2.zip
WinOLS EGR off2.zip
7812338.zip

Is anyone able to shed some light on what I might be doing wrong..?

Thanks
Daniel

Mate, great job!
I think you did not do the highlited step correctly...
Look on the picture... the upper file is after NCSDummy

after NCS_Dummy.jpg

**Gbyleveldt** · 27th May, 2016, 07:02 AM

The ECU checks the updated file against an RSA key in the ECU. If the key is invalid, WinKFP fails with an error message like you've stated after flashing completes. As far as the actual file checksum is concerned, NCSDummy only fixes it in such a way to allow WinKFP to open it in the first place. It doesn't help with the required RSA key that the ECU checks after a write to flash.

**morfej** · 27th May, 2016, 07:17 AM

Gbyleveldt ... I would belive that RSA signature is checked by EDC17 ecus not the one that is talked about here Jetronic/Motronic M5.2.1.

**bobolin4o** · 27th May, 2016, 07:21 AM

Originally Posted by morfej

Gbyleveldt ... I would belive that RSA signature is checked by EDC17 ecus not the one that is talked about here Jetronic/Motronic M5.2.1.

I think... we talk about EDC16C31 here...
But WinOls don't tell that there is RSA in the file.

**Gbyleveldt** · 27th May, 2016, 08:42 AM

Aaaah I see. You are correct, my experiences is based on Tricore ECUs not the Motorola ones.

**Gbyleveldt** · 27th May, 2016, 08:47 AM

Come to think of it, doesn't WinKFP (or the ECU) check the new file against a signature on the older ECUs? There's a 'Flash_pruefen_signature' job for many of the ecus. I'm not in front of my PC to check this on an older ecu.

**djwlindenaar** · 27th May, 2016, 07:37 PM

Originally Posted by bobolin4o

Mate, great job!
I think you did not do the highlited step correctly...
Look on the picture... the upper file is after NCSDummy

AH, yes, it seems I've uploaded the wrong file; I've actually tried the flash with the correct file and the issue is the same. I guess the step with NCSDummy is not actually necessary if you disable checksum checking in WinKFP...

Thanks for looking into it, though.

**djwlindenaar** · 27th May, 2016, 07:50 PM

Originally Posted by Gbyleveldt

Come to think of it, doesn't WinKFP (or the ECU) check the new file against a signature on the older ECUs? There's a 'Flash_pruefen_signature' job for many of the ecus. I'm not in front of my PC to check this on an older ecu.

Interesting thought. I've had a look at the jobs in Ediabas for this ECU. I've found something called "Job: PRUEFSTEMPEL_LESEN" and "Job: PRUEFSTEMPEL_SCHREIBEN". Does this have anything to do with it? If so, how do I determine the parameters for the SCHREIBEN job?

Then there's this: Job: PRUEFCODE_LESEN ; Comment: Indentifikation, FS_Codes ShadowFS_Codes, ShadowFS_lang, AIF

Then there's a "special" SGBD called 09FLASH.PRG, which has this "Job: FLASH_SIGNATUR_PRUEFEN";

That last one looks like the one you were referring to, could that be it; just run that job for the ECU to start recognising the correct checksum?
- I'm a bit hesitant just to try, because if that blocks access, I've just got a big lump of metal... Confirmation would be great. -

Best regards
Daniel

Job: PRUEFSTEMPEL_SCHREIBEN
Comment: Beschreiben des Pruefstempels
Comment: Es muessen immer alle drei Argumente im Bereich
Comment: von 0-255 bzw. 0x00-0xFF uebergeben werden.
Comment: KWP2000: $2E WriteDataByCommonIdentifier
Comment: $1000 TestStamp
Comment: Modus : Default