[zackz]

Originally Posted by gini

Hi Mik325tds,
thanks, I appreciate

Thanks to Dave's initiative and contribution, I'm sure we can make something out of it
So, all the credits to him

Read & Write ECU function will be implemented in B015 once it passes all the tests
B015 will be released in one or two weeks

Many, many thanks for your huge work Gini!

[dave205t]

Originally Posted by gini

Thanks to Dave's initiative and contribution, I'm sure we can make something out of it
So, all the credits to him

Thanks, writing will be 'a tad' more tricky than reading.
Best regards, Dave

[zackz]

Originally Posted by ChrizLoud

Interesting! Please tell us now

Let's wait a little more

I want to bring facts and proofs only in order to close the JFA/JR gearbox remap subject definitely!

[gini]

Originally Posted by dave205t

Thanks, writing will be 'a tad' more tricky than reading.
Best regards, Dave

Hi Dave,
writing is almost done

This is my idea:
1. Full Ecu dump just in case (writing back is not a problem for me)
2. Combine Winkfp Program and data to generate a complete Bin file
3. Modify this Bin file
4. Separate the Program and the Data from the modified Bin file
5. Winkfp checksums
6. Flash with Winkfp in Expert mode

I can send you the OpaOdaToBin application if you like

[rjahl]

Originally Posted by gini

Hi Dave,
writing is almost done

This is my idea:
1. Full Ecu dump just in case (writing back is not a problem for me)
2. Combine Winkfp Program and data to generate a complete Bin file
3. Modify this Bin file
4. Separate the Program and the Data from the modified Bin file
5. Winkfp checksums
6. Flash with Winkfp in Expert mode

I can send you the OpaOdaToBin application if you like

This also sound so exciting but won't we need to correct the RSA signature as well?

[gini]

To make Winkfp happy, you just need to correct the 3 different checksum as far as I know

[rjahl]

Originally Posted by gini

To make Winkfp happy, you just need to correct the 3 different checksum as far as I know

I've done that, but many of the receiving modules such as the DME and TCU will not reboot if the new program does not have a valid RSA signature.

Still, your program looks really cool. I've downloaded but have not had time to install or run it. Spring time, too much yard work and too many hours in the office.

[dave205t]

Originally Posted by gini

Hi Dave,
writing is almost done

This is my idea:
1. Full Ecu dump just in case (writing back is not a problem for me)
2. Combine Winkfp Program and data to generate a complete Bin file
3. Modify this Bin file
4. Separate the Program and the Data from the modified Bin file
5. Winkfp checksums
6. Flash with Winkfp in Expert mode

I can send you the OpaOdaToBin application if you like

Hello Gini,

Thanks for the offer on the OpaOdaToBin, i am aware of that version; take care it only produces correct bin result on very specific 0da/0pa combinations (i wrote my own).
Don't want to pop your bubble here, but while the procedure might allow you to write a changed file to the module (passes Winkfp simple file checks), it will not pass the module's internal verification.
Anyway, keep up the good work.

Best regards, Dave

[ThatRWD]

If you guys can find a way to disable adaptions that would be great, in theory they sound great but in practice they almost always degrade performance. Infact if you test it out, the transmission is smoothest when it hasn't adapter also the quickest. This is true regardless of which flash you are running.

[gini]

Originally Posted by dave205t

while the procedure might allow you to write a changed file to the module (passes Winkfp simple file checks), it will not pass the module's internal verification.
Best regards, Dave

Hi Dave,
the ECU Authentication is already implemented in Dr.Gini B014

button with a key:


Many ECUs are already supported (kombi, cas, several engines, head units, ...)
EGS will be added in the next version

[ChrizLoud]

Originally Posted by gini

Hi Dave,
the ECU Authentication is already implemented in Dr.Gini B014

button with a key:


Many ECUs are already supported (kombi, cas, several engines, head units, ...)
EGS will be added in the next version

Have you already solved the EGS internal RSA-encyption check?

[DWR]

Originally Posted by ThatRWD

If you guys can find a way to disable adaptions that would be great, in theory they sound great but in practice they almost always degrade performance. Infact if you test it out, the transmission is smoothest when it hasn't adapter also the quickest. This is true regardless of which flash you are running.

Please share your data. I know some have said exactly the opposite of your position. Up to this point, lots of opinions have been shared and very little data. Thanks.

[ChrizLoud]

I have had many 535D and also 335D and when shifting from 2nd to 3rd (most present in manual mode) on high revs with no load it produces a giant jolt. Some cars had more some had less. When resetting adaptions this jolt has not been present for a couple of days (not the case with my current 335d, its always there and very annoying)

[gini]

Hi ChrizLoud,
yes EGS authentication is done

You have to know that this check is done by WinKfp any time you write an ECU
Without authentication, you cannot write an ECU at least via the OBD port

[dave205t]

Originally Posted by gini

Hi ChrizLoud,
yes EGS authentication is done

You have to know that this check is done by WinKfp any time you write an ECU
Without authentication, you cannot write an ECU at least via the OBD port

If you have authentication done and already can write several other units than why bother with Winkfp at all? Just open the binary and write it.

[335dsleeper]

You guys are incredible!

[gini]

Originally Posted by dave205t

If you have authentication done and already can write several other units than why bother with Winkfp at all? Just open the binary and write it.

Please note that I have absolutely no clue about chiptuning (eg: WinOLS)

Winkfp remains the safest and the most reliable writing tool accessible for all
So, using it seems to be the most logical choice

Add, Winkfp does many other things than just authentication. Like setting the ECU in programing mode and kick it out from this mode once the write is finished

Since u improved the OpaOdaToBin application, it's worth to continue investigating in this direction. What do u think?

[Mik325tds]

Originally Posted by gini

Please note that I have absolutely no clue about chiptuning (eg: WinOLS)

Winkfp remains the safest and the most reliable writing tool accessible for all
So, using it seems to be the most logical choice

Add, Winkfp does many other things than just authentication. Like setting the ECU in programing mode and kick it out from this mode once the write is finished

Since u improved the OpaOdaToBin application, it's worth to continue investigating in this direction. What do u think?

You probably already know this but for the others: Authentication and Signature check are two different things. Authentication is the authorization process for the test-tool to do restricted things like writing to memory. It "unlocks" the Ediabas jobs "speicher_schreiben", "flash_loeschen", "flash_schreiben" and others.
The signature check is something that is done after the flash process with WinKFP: The data section and program section are reduced to a fixed sized using a hash algorithm and then (I think) multiplied with the public key which is stored in the boot sector. The result is then compared to the "RSA signature" which has been appended to .0da and .0pa file using a "secret key" which is only known by BMW. If that doesn't match, the EGS stays in boot mode and doesn't run the Application program. The boot mode allows basic diagnostics and flashing (with authentication).
Since the signature check is most likely invoked by WinKFP, maybe we can circumvent it by writing to memory directly? As long as we don't touch the boot sector, it should be safe.

[gini]

Hi Mik325tds,
thank you for your detailed explanation

I could reproduce 100% all what Winkfp does. It's already implemented in Dr.Gini B014.

My tests were performed on non important ECUs like PDC (cheap ones)
I locked this function since I don't have the possibility yet to perform deep tests and to certify there is no risk at all

If you want to give it a try, make sure Winkfp is installed and updated
Then you can get your ECU information from its ZUSB Number (Programing function remains locked for now)

This ZUSB nummer:


Produces this result:

[PD330]

Hello all,

just found the thread and I'm glad that I'm not the only one who is sick of the behaviour of the transmission. Maybe I can help a little bit...I don't really have experience with the BMW transmissions but due to my job knowlendge of ECUs, flashing proccess and so on.

I think you understand I did not read the whole thread and only last pages. Summarizing, RSA and checksums can be calculated so what exactly is the next target? Find the best way to write modified software back to the TCU?

However, attached is a dump of my 330D built 2009 (N57).

[Mik325tds]

Originally Posted by Mik325tds

You probably already know this but for the others: Authentication and Signature check are two different things. Authentication is the authorization process for the test-tool to do restricted things like writing to memory. It "unlocks" the Ediabas jobs "speicher_schreiben", "flash_loeschen", "flash_schreiben" and others.
The signature check is something that is done after the flash process with WinKFP: The data section and program section are reduced to a fixed sized using a hash algorithm and then (I think) multiplied with the public key which is stored in the boot sector. The result is then compared to the "RSA signature" which has been appended to .0da and .0pa file using a "secret key" which is only known by BMW. If that doesn't match, the EGS stays in boot mode and doesn't run the Application program. The boot mode allows basic diagnostics and flashing (with authentication).
Since the signature check is most likely invoked by WinKFP, maybe we can circumvent it by writing to memory directly? As long as we don't touch the boot sector, it should be safe.

Correction: The signature check is a just a little bit different then described above. It is correct that the signature check is invoked by WinKFP after the SW download. The SW is appended with a signature that was created by BMW using the hash algorithm and their secret key. The TCU now takes this signature and decodes it with it's public key. The result is the hash value. It then calculates the hash value of the data section and compares it to the hash value that was was generated with the public key. If they match it's good to go, if not it stays in boot mode.

[DWR]

Originally Posted by Mik325tds

Correction: The signature check is a just a little bit different then described above. It is correct that the signature check is invoked by WinKFP after the SW download. The SW is appended with a signature that was created by BMW using the hash algorithm and their secret key. The TCU now takes this signature and decodes it with it's public key. The result is the hash value. It then calculates the hash value of the data section and compares it to the hash value that was was generated with the public key. If they match it's good to go, if not it stays in boot mode.

So, Mik325tds is it your position that we should try to find the piece of code that controls this internal check and bypass it?