[Mik325tds]

Originally Posted by 808AWD325xi

I found the Linkedin profile of a former ZF engineer that developed a generic bootloader:
https://www.linkedin.com/in/alexey-andreev-6588a378

I like your "out of the box" thinking!

[_TB_]

Hmm According to the user prj on Nefarious - the 6HP does _not_ use an RSA enabled bootloader.

I have found out that WinOLS with the OLS816 plugin will do the checksums

..Also it seems that BMWscanner 2.1.0 will read the raw image of the TCU.

[Yozh]

Originally Posted by Mik325tds

Yozh, that would be great. Please ask him if he has any advice on how to replace the current bootloader of our tranny with a boot loader that doesn't check for the RSA signature. And, of course, if he has such a bootloader ;-).
Thanks!

Have to register for LinkedIn to get to contact him. Give me a few...

Update: will try in the evening, silly LinkedIn has a paid premium account to send an email to anyone, tried signing up but it is giving me an error trying to hook up with PayPal. Grrr.

[RBT-Tuning]

Originally Posted by Yozh

Wonder if he would be more receptive if approached in his native language. I can write to him, just need to know what we want to find out from him.

Derived from the time he was working there, his work must be based on the 8HP generation...

[DWR]

Originally Posted by RayBan81

Derived from the time he was working there, his work must be based on the 8HP generation...

Let's hope it is backwards compatible ...

[Yozh]

If you guys tell me what I need to find out. I work with a bunch of very good software and firmware engineers, may be I can ask them some direct questions?

[rjahl]

Originally Posted by _TB_

Hmm According to the user prj on Nefarious - the 6HP does _not_ use an RSA enabled bootloader.

I have found out that WinOLS with the OLS816 plugin will do the checksums

..Also it seems that BMWscanner 2.1.0 will read the raw image of the TCU.

I started to download my TCU bin with BMW scanner last week but the demo version is very slow. 20 minutes and I only had about 10-20 percent of the file. I did not have enough free time to finish. I'll try again soon but it's hard to find that much time this time of year.

I need to look at the ODA file again. It would be cool if there is no RSA protection.

[Mik325tds]

I find that surprising, that the EGS is supposed to not use a RSA signature. I have read it in the BMW specs somewhere. Need to look again and find out for which ECU those specs were applicable.
Maybe, if you write/read directly to memory without using WinKFP, the Signature is not checked? That would make more sense to me.
In any case, I'm feeling some hope emerging

[DWR]

Originally Posted by Yozh

If you guys tell me what I need to find out?

Assuming you will be able to contact Alexey Andreev, I think the first thing to ask is if he is familiar with the ZF6HP, since it looks as though he worked on the ZF8HP. I assume he is in principle, but perhaps there are significant differences that will limit the conversation.
What protections do we have to contended with? Checksums, RSA? How should these be handled by a capable group of enthusiasts? Does he have a bootloader patch that gets past the RSA?
Any other assistance/hints he could give to a group of enthusiasts that wish modify a BWM TCU calibration? He may know of techniques and tools we are not now using. Heck, invite him to the party we are have in this thread
Just my 2 cents.

[Yozh]

Ok Guys,

LinkedIn is no go, just would not let me send a message, but after a long search I was able to find him on Facebook. Sent him a message with all the important keywords, and had invited him to the party. I noticed that his last post was in 2013, so hopefully he at least gets an email and clicks on the link. Here is his fb: https://www.facebook.com/alexey.andreev.144

If anything, at least he is popular now.

Tomorrow, I'm bugging my firmware engineer...

[DWR]

I've seen the support you have given this forum over and over again. Your rep points in no way reflect your value to this community, had to add a few more.
Thanks.

[rjahl]

OK attached is what I think is a full memory dump from a 6HP19 using BMW scanner, demo. I've used this software in the past and the files matched the actual ECU contents. It's only going to provide data in the flash and I have no idea what else in on the TCU board.

ZB#7571102
HN#7574645
DF#7571103

I have also attached the matching ODA and OPA file for the BIN. Sorry I had to break the dump into two parts, exceeded the 419KB limit for the forum. I then had to rename the files so the forum would allow the split files.

To use these, You need to rename the EGS_00000-FFFFF-00 first(001).zip to
EGS_00000-FFFF-00 first.zip.001. Same for the second file. This is required for Winzip to recognize the split archive and unpack them as a single file.

I took a quick look at the ODA files and I'm not seeing anything that looks like an RSA signature. I'm looking for a large block about 100 bytes of data that is not a map an is completely different between ODA files. It's just not jumping out at me.

I guess the next step would be to build a BIN from the ODA and OPA file and compare them against the actual TCU BIN.

That's all the time I have to today.


Edit: I just realized that the OPA Was too large as well. It's 7564645A.OPa. I think you can find that in your Data files.

[_TB_]

I have done a quick import in WinOLS - and they "line up", but the *0da file is much smaller. I'll try and see what is missing in the *.0da file.

EDIT: 0->05FFFF is not in the *.0da file..

[rjahl]

Originally Posted by _TB_

I have done a quick import in WinOLS - and they "line up", but the *0da file is much smaller. I'll try and see what is missing in the *.0da file.

EDIT: 0->05FFFF is not in the *.0da file..

I would expect the actual ODA file to be missing the adaption tables.

You are ahead of me, I had to leave the house before looking at the bin.

[_TB_]

Originally Posted by rjahl

I would expect the actual ODA file to be missing the adaption tables.

You are ahead of me, I had to leave the house before looking at the bin.

Normally you do not store adaption values in the flash, those are normally placed in a separate eeprom, so I do not think the adaption values are stored in the flash.

The *.0da lacks 0->0x60000 and 0x80000 to EOF.

So two parts of the flash is missing in the *.0da.

0x80000 to EOF is purely code, no maps here. This is probably the program and perhaps bootloader.

SOF-> 0x60000 is a bit more uncertain. 0x40000 to 0x60000 could look like room for another datablock - like 0x60000 to 0x80000. (EDC15 uses multiple datablock for different "mappings")

That leaves SOF -> 0x40000 - it doesn't look like purely code, there *could* be some maps defined here as well, but I'm pretty unsure about that.

The good thing is that the *.0da file matches up perfectly with the fullread - apart from the code part missing. Now this is a good thing, that *could* mean the Alpine uses the same code - it is just changed in the lookup tables and/or configuration bytes.

EDIT: Is it posible to write only a given address span with WinKFP? If we could only manipulate the maps, not the code - we should be able to minimise the risk of bricking since we do not touch the actual code that runs the TCU.

[rjahl]

Originally Posted by _TB_

Normally you do not store adaption values in the flash, those are normally placed in a separate eeprom, so I do not think the adaption values are stored in the flash.

The *.0da lacks 0->0x60000 and 0x80000 to EOF.

So two parts of the flash is missing in the *.0da.

0x80000 to EOF is purely code, no maps here. This is probably the program and perhaps bootloader.

SOF-> 0x60000 is a bit more uncertain. 0x40000 to 0x60000 could look like room for another datablock - like 0x60000 to 0x80000. (EDC15 uses multiple datablock for different "mappings")

That leaves SOF -> 0x40000 - it doesn't look like purely code, there *could* be some maps defined here as well, but I'm pretty unsure about that.

The good thing is that the *.0da file matches up perfectly with the fullread - apart from the code part missing. Now this is a good thing, that *could* mean the Alpine uses the same code - it is just changed in the lookup tables and/or configuration bytes.

Did you get winols to recognize the checksum?

[_TB_]

Originally Posted by rjahl

Did you get winols to recognize the checksum?

I do not have the OLS816 plugin - which is the checksum for "Bosch EGS". I'm unsure if this will correct our files, but it should..

The Checksum _must_ be in the *.0da file..

A funny thing is that the *.0da for the Alpina is much bigger than the *.0da posted here.. :/

[rjahl]

Originally Posted by _TB_

I do not have the OLS816 plugin - which is the checksum for "Bosch EGS". I'm unsure if this will correct our files, but it should..

The Checksum _must_ be in the *.0da file..

A funny thing is that the *.0da for the Alpina is much bigger than the *.0da posted here.. :/

OK, your making more progress then me today.

Checksum might be identified on the line near the end of the ODA file

$CARB_MODE_9_CVN 0000653B B


Search for the hex strings 65 3B in the Bin. The values will be found in the same location on each ODA file.

I'm 100 percent certain this references the Checksum for the MSV70. Don't know how to calculate it, but locating is a step forward.

[Mik325tds]

Originally Posted by _TB_

EDIT: Is it posible to write only a given address span with WinKFP? If we could only manipulate the maps, not the code - we should be able to minimise the risk of bricking since we do not touch the actual code that runs the TCU.

Good work guys. Thanks for the research. I guess it'll make sense to get a dump from my 335d as well so we can compare the bins with each other.
As far as writing given address spans with WinKFP: That is not possible. But it should be with the Ediabas jobs if we can figure out how they work.
At least now it seems we have a way of reading back of what we changed which will be a huge help.

[_TB_]

Originally Posted by rjahl

Edit: I just realized that the OPA Was too large as well. It's 7564645A.OPa. I think you can find that in your Data files.

What car du you have?

The Grundprogram (0pa) is for a 6HP19, whereas mine is a 6HP19/TÜ.
(It seems like 6HP26 and 6hp32 uses the same Grundprogram, but 6HP19 and 6HP19TÜ are different)

I'll try to compare the files, would be interesting to see the differences between the two.

[rjahl]

Originally Posted by _TB_

What car du you have?

The Grundprogram (0pa) is for a 6HP19, whereas mine is a 6HP19/TÜ.
(It seems like 6HP26 and 6hp32 uses the same Grundprogram, but 6HP19 and 6HP19TÜ are different)

I'll try to compare the files, would be interesting to see the differences between the two.

Sorry I thought you guys knew, I drive a 2007 E85, Z4 3.0I.

I have a three stage manifold and a complete 3.0SI tune that I spliced into my DME. While the current tune is more of a hack than a tune, I've been learning to make my own tune for a while. It's slow going but I'm not in a hurry. Car just runs a little better each time I change something.

At some point I am going to get fed up with the transmission. Shift point are not bad but horribly soft along with torque reduction requests to the DME that last forever.

[rjahl]

On another note I read some place that BMW referenced the 6HP21 as a 6HP19 in some applications. Can't remember where I saw that but it could explain the difference.