PDA

View Full Version : 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


375764
375767
375768
375769

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


375764
375767
375768
375769

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

377931

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

bobolin4o
27th May, 2016, 08:18 PM
Nothing to lose, make BDM backup before any attempt...

BTW, did you saw my PM?

djwlindenaar
28th May, 2016, 11:37 AM
OK, I just went ahead and tried to write the 0da file again and then find some job in Tool32 to get the signature check to work.

Flashing with WinKFP went as usual and the same errors popped up; signature check failed and then security access denied.

Then I fired up Tool32 with the 06DDE509.prg which contains jobs to reset the SG and to request check of the signature.

1. ran job "flash_signatur_pruefen" on Daten area, which gave error signature check failed.
2. ran job "flash_programmier_status_lesen" which gave status 06, which means that the daten area has not passed signature checking
3. ran job "STEUERGERAETE_RESET", which said OKAY (so I guess it worked)
tried again 1 and 2, same result
turned off car, turned back on, ran 1 and 2, same result.

I'm beginning to suspect that in fact, the signature that is failing is the checksum inside the changed bin data. The one that got calculated by WinOLS. But I don't know how to verify that.

Could anyone with the latest version of WinOLS checksumming module or anything that is supposed to create valid checksums for this car and software version check that it is in fact correct (or provide me with a corrected checksum to verify writing the 0da file to the car actually works with changed values?)

Best regards
Daniel

Gbyleveldt
29th May, 2016, 05:01 AM
Sorry for not getting back to you yet bud.

im going to run a little experiment today with a modded 0da through WinKFP and the same mod through ktag and then compare the dumps to see what's going on.

ill do this on an edc16 so that the hardware is the same.

djwlindenaar
29th May, 2016, 08:30 AM
Sorry for not getting back to you yet bud.

im going to run a little experiment today with a modded 0da through WinKFP and the same mod through ktag and then compare the dumps to see what's going on.

ill do this on an edc16 so that the hardware is the same.
That's great. Sounds like the ultimate experiment to check if anything is changed. Looking forward to the result.

What kind of edc16 are you doing this on, i.e. what car/software?

Best regards
Daniel

djwlindenaar
29th May, 2016, 11:26 AM
OK, for those of you interested in the scripts I wrote to decode the 0da, here's the code and some instructions.

Install free/opensource jupyter notebook as per https://jupyter.readthedocs.io/en/latest/install.html

After installing run
jupyter notebook
Then your browser will open with a localhost address showing Jupyter logo and a local file browser below. Just navigate to the location you put the script attached and open it. That'll give you another browser window with two bits of Python code in so-called cells with a little bit of explanation. You should edit the files referred to at the top of the scripts and then select run cell from the menu at the top of the page.

Please note that the code assumes that this is a 0da file and that the data area referred to is exactly 1MB.

Also please note that not a lot of code is involved, so don't be underwelmed when looking at it :stung:

378274

bobolin4o
30th May, 2016, 07:06 AM
It is not so easy... for me...
Where must to be the .0da file - in the same location like .ipynb?

Gbyleveldt
30th May, 2016, 08:11 AM
Ok Daniel,

Time for some updates:

Firstly, I'm using an EDC16C31 - it's for the 2.0 Diesel. I'm assuming you're using an EDC16C35? Mine uses an MPC562 and yours is probably an MPC564. Anyway, I think the process and findings would be similar.

I've updated the ECU I'm using with the latest SPDaten. The zusb for the ECU is 7808884 and the data file is 7808900 in this case. For the purposes of this experiment, I've only gone and changed 3 bytes in the maps area; I did this change in a blank area of the maps as I wanted to make sure my experiments wouldn't interfere with the operation of the ECU in any way. The address I picked in my case was 0xC045D - I changed the first 3 bytes to 11, 22, 33 in the 0pa file. After I made the changes, I corrected checksums with NCSExpert; the two changes made were the line checksum and the file checksum.

I loaded my modified file using WinKFP expert mode. The data file loaded completely, after which WinKFP failed stating the same error you've received.

378360378361

As you can see, the DAF signature is a problem. Interestingly, in this state I couldn't read the flash anymore. I tried a test version of Dr Gini to try and read and I've tried to read it with KTag. In the case of the KTag, it read the flash, but failed at the end with a checksum error.

I then started over, flashing the ECU back to stock and then made changes to the actual BIN file and wrote it back using KTag and this was successful. Based on what I'm seeing here, there's a 3rd checksum that needs to be calculated as well, located at address 0xFDFF8 which is 3 bytes in length.

378362

So, the conclusion I've come to so far is that there's 3 checksums that needs to be corrected for when you want to use WinKFP to flash an ECU. The line and file checksums are done using NCSExpert. The 3rd checksum is an actual ECU checksum, and is not related to any checks that WinKFP would do to the actual file it reads.

The next step I'll try when I have a chance is to change the checksum in the 0da file as well and upload that using WinKFP again to see if it's successful - I have a suspicion this will work.

For your benefit, I've uploaded the 3 bin files as a .zip as well. The original file, the modded file I used to write to the ecu using ktag and then a 3rd file read back from the ECU showing the change in checksum. I've not spent any time as of yet trying to figure out how to calculate this last checksum.

I hope this will give you enough food for thought to have success with your project.

Ta,

Gert

Gbyleveldt
30th May, 2016, 08:14 AM
It is not so easy... for me...
Where must to be the .0da file - in the same location like .ipynb?

In order to flash custom 0da files you need to use WinKFP expert mode. You need to create a 'DEVELOP' folder under 'EC-APPS\NFS\DATA\' and store the modified files there. I wouldn't experiment using Expert mode on a working car ;)

djwlindenaar
30th May, 2016, 01:03 PM
Gbyleveldt

Wow, cool stuff. I'll have a look at the bins. I'd be really interested to see if writing with the corrected data at FDFF8 and 0da, will actually give you a working situation.
The files I've tried so far actually had corrected checksums at exactly this location, but were still not accepted. That's why I was suspecting that the checksum generated at that position in the file is actually not correct for my car. If now flashing with WinKFP works for you with the right data at FDFF8, I'll know for sure.

BTW its 4 bytes, starting from FDFF8

djwlindenaar
30th May, 2016, 02:25 PM
It is not so easy... for me...
Where must to be the .0da file - in the same location like .ipynb?

No it can be anywhere on the computer. You just need to point the script to it by filling out the whole path e.g. r'c:\here\there\myfile.0da'

On Windows you have to make sure there's an r before the first single quote. Maybe that's what you need...

Gbyleveldt
30th May, 2016, 05:08 PM
Wow, cool stuff. I'll have a look at the bins. I'd be really interested to see if writing with the corrected data at FDFF8 and 0da, will actually give you a working situation.
The files I've tried so far actually had corrected checksums at exactly this location, but were still not accepted. That's why I was suspecting that the checksum generated at that position in the file is actually not correct for my car. If now flashing with WinKFP works for you with the right data at FDFF8, I'll know for sure.

BTW its 4 bytes, starting from FDFF8

ok, I'll go try it to check and make sure. Hopefully I can play a little later tonight or tomorrow.

Gbyleveldt
30th May, 2016, 07:11 PM
I suppose I should check a little better before I open my big mouth :D

I applied the known correct BIN checksum to the DAF file and........ it didn't work. So this is a rather interesting problem. It's a pity I can't somehow read the ECU in this broken state in order to check what the actual BIN looks like.

Anyway, I've attached my modded 0da file here. If I understand my DAF file definitions properly, it should be the exact same as the resultant BIN data read by my ktag - which we know works.

The other thing I've been wondering is if there's 1 checksum for all flash in the ECU, or if there's more checksums - say for program and data memory. Also, you state that the checksum is 4 bytes but I only see 3 bytes affected in this ECU. It might be that I'm not making enough changes to affect all 4 bytes of the checksum.

djwlindenaar
30th May, 2016, 07:43 PM
I suppose I should check a little better before I open my big mouth :D
Don't worry; it happens to me all the time :stung:.


I applied the known correct BIN checksum to the DAF file and........ it didn't work. So this is a rather interesting problem. It's a pity I can't somehow read the ECU in this broken state in order to check what the actual BIN looks like.

Anyway, I've attached my modded 0da file here. If I understand my DAF file definitions properly, it should be the exact same as the resultant BIN data read by my ktag - which we know works.

The other thing I've been wondering is if there's 1 checksum for all flash in the ECU, or if there's more checksums - say for program and data memory. Also, you state that the checksum is 4 bytes but I only see 3 bytes affected in this ECU. It might be that I'm not making enough changes to affect all 4 bytes of the checksum.

Thanks for the work, this really clears up some stuff. Now we now beyond a doubt that there's actually something the KTag tool does that WinKFP does not. And that in fact the checksum in the file is probably fine. I've crosschecked your work and you've made no mistake in the bin files or 0da files.

Now to figure out what happens after the file is programmed...

Just a guess here... Could it be that this is related:
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?

Could you run PRUEFSTEMPEL_LESEN job with both the original and the modified flash (by Ktag) and see if there's a difference..?

Best regards
Daniel
p.s. sorry to be asking all this help from you, but I can't help being excited since we seem to be getting closer.

Gbyleveldt
31st May, 2016, 06:20 AM
^^^ I've been thinking of doing just that exactly. If I have a little time today I will play with that.

What ECU are you using? If it's an EDC16C35, I have some of those here as well. Might make things easier if were working off exactly the same hardware. That way, I can test your tune files on ktag if you wish...

djwlindenaar
31st May, 2016, 07:23 AM
I believe it's a edc16c31 as well. If you're looking for daten files, I'd need to check the numbers, don't have them here. Software version is 390905.
It's a DDE5.09, which can be found in the e60 Daten in the folder DDE509.
I think the edc16c35 is only used on the later generation engines with the piezo injectors (post 2007), but not absolutely sure.

Looking forward to the results.

Sent from my SM-G901F using Tapatalk

djwlindenaar
2nd June, 2016, 07:13 PM
^^^ I've been thinking of doing just that exactly. If I have a little time today I will play with that.

What ECU are you using? If it's an EDC16C35, I have some of those here as well. Might make things easier if were working off exactly the same hardware. That way, I can test your tune files on ktag if you wish...
Hmmm just checked what the current result is for pruefcode_lesen on my current flash, but it reads three times 0x0000. I guess that's back to the drawing board.

Sent from my SM-G901F using Tapatalk

Gbyleveldt
4th June, 2016, 05:58 AM
Heh, tried it this morning and results are the same. When the ecu is 'broken', it returns the function with an error.

djwlindenaar
4th June, 2016, 08:29 AM
Heh, tried it this morning and results are the same. When the ecu is 'broken', it returns the function with an error.

That's too bad, thanks for trying, anyway.

Do you do these tests on a bench or installed in your car?
I was wondering whether maybe WinKFP fails to do a proper reset / power cycle. I've found some code which shows there's a number of levels of resetting this ECU; soft reset, key on/off and hard reset. If you're doing this on the bench, did you try to power cycle the ECU after flashing?

Daniel

Gbyleveldt
5th June, 2016, 04:57 AM
Hey bud,

yes, I do all of these tests on my bench. That being said, I do flash a great many modules on my bench this way and I've never had issues with legit files.

looking at the wiring to these cars, there's no hardware reset outside of the wake up KL15 line that is the ignition line. I would imagine that WinKFP does a software reset. In other words, it sends a reset command through the can bus. I'm not sure how 'hard' this reset is although I can confirm the ecu does a reboot, if you like, after such a reset.