[kg4kdn]

Was the 335d offered in Europe with a manual gearbox? I know that none of the NA models were. Man, now that would be a kick in the seat of the pants if it was. I know that reliability would be a possible concern but there are cars out there, that have more HP and torque than the d, with manual boxes out there.

[_TB_]

Just get Exedy to upgrade the auto gearbox - then it should hold 1000Nm just fine. (6hp26)

[DWR]

Originally Posted by _TB_

Just get Exedy to upgrade the auto gearbox - then it should hold 1000Nm just fine. (6hp26)

Yep, there is a good amount of upgrade parts, including torque converters. It is actually pretty strong in stock form. The Aussies have really made it perform in their Fords by remapping, without touching the internal parts. And the story gets better. Input shaft is the first upgrade needed, so you don't even need to open up the transmission. Of course, if you need to hold 1000Nm, then it needs to be opened up. Oh, to have that problem!

[rjahl]

Originally Posted by Hoooper

Well, FWIW its unlikely that the tune for the 3.0si has the converter locking up any lower than the 3.0i tune does or that the small difference in torque would have any influence on the torque converter clutch (the stock 335d clutch is holding as much as 225 lb ft more than a stock tune) unless the 3.0si uses a completely different transmission, in which case swapping the tunes would probably not even work. Have you checked whether there is even a difference between the torque converters for those two models?

Actually I am finding it near impossible to confirm the torque converter. Realoem no longer lists the converter on the 3.0i. Following cookie crumbs of information ,it seems that I have a B121 and the 3.0si has the A121. I think it's the same set up as the EU based 2.5si. I try to flash the 3.0si tranny file this weekend. I know the program is the same, only difference is some of the maps in the calibration file. Thanks for the help. I know you guys don't normally talk about N52s so I appreciate the space given.

[Mik325tds]

Originally Posted by rjahl

Actually I am finding it near impossible to confirm the torque converter. Realoem no longer lists the converter on the 3.0i. Following cookie crumbs of information ,it seems that I have a B121 and the 3.0si has the A121. I think it's the same set up as the EU based 2.5si. I try to flash the 3.0si tranny file this weekend. I know the program is the same, only difference is some of the maps in the calibration file. Thanks for the help. I know you guys don't normally talk about N52s so I appreciate the space given.

Good info is always appreciated. Keep posting!

[Unklejoe]

This is the best thread on this site, IMO. Decoding these maps is not a wasted effort, even if we currently lack a way to bypass the RSA check.

Originally Posted by Mik325tds

I was very surprised by that as well. From what I read so far, BWM creates a Hash value (fixed length) from all the data in the file and signs that hash value with their secret key using the RSA algorithm.
When the program or cal file is flashed, the bootloader checks the file by recalculating the Hash value and decrypting the signed hash value from the file using the public key stored in the bootloader. Those two hash values are then compared. If they match it's good to go, if they don't - stay in bootloader mode.

Spot on.

Originally Posted by rjahl

You are facing several different layers of protection;

1. ODA file integrity.
last two byes of each line are a checksum for that line
$CHECKSUMME Is a total file checksum

2. Ram based checksum
This is the data used by the processor to insure nothing is wrong with the ram, This is the 0DDC in your file.

3. File signature
This is the system used by BMW to insure no one gets creative and makes there own "tunes" and flashes them with ODB protocols.

BDM stands for Boot Diagnostics Mode. Many microprocessors systems can be accessed directly through a BDM port on the board. This allows you to manipulate the programs with direct control. I used this port to "clone" my MSV70 and install a custom file bypassing the ODB program that checks the File signature.


http://www.e90post.com/forums/showthread.php?t=1035058

Do you have any insight on how this RAM checksum works? RAM diagnostic tests usually don't rely on any external data in my experience (just walk the address/data lines). I'm just curious for educational purposes.

Thinking out loud from here on...

To summarize the options at this point:

- Crack the RSA signature and get the private key (not happening)
- Obtain the RSA private key from someone at BMW (likely not happening)
- Bypass the RSA check in the bootloader (best option)
- Find out where the public key is stored in the bootloader and overwrite it with the public key from our own generated private/public key pair (may be easier than the option above, but not as ideal)

I believe the best option is to completely disable the RSA check, considering we don't know over which data the hash is generated or which hash algorithm they use.

What we need to know:

1. Can we flash the bootloader at all? There is an option in WinKFP for this, but does it work? Does this allow us to flash any arbitrary image to that memory region? Or does WinKFP check the signature of the bootloader? I have no clue how this process works.
2. If so, can soneone point me in the direction of the bootloader binary?
3. Does the bootloader check the signature of the image before it commits it to flash?

There are a number of ways flashing the bootloader can be implemented internally. Normally, the CPU boot straps to the bootloader in FLASH, which then copies itself to RAM and continues execution from there (where it then copies the main image to RAM and eventually jumps there). This is how the bootloader is able to seemingly overwrite itself. This also gives it the opportunity to check the signature of the complete bootloader image in RAM before it writes it to FLASH. This would be BAD. Ideally, the bootloader just copies block by block directly what it's fed from the OBD port

I would assume the bootloader itself has to be unencrypted at least during early boot. It may check a signature of itself during early init, so this would have to be bypassed as well if we modified the boot loader to bypass the main RSA check of the complete image.

The only way I could see any of this happening would be if we found out which CPU the thing uses and got access to a development board with a debugger. Not impossible, since I'm sure there are plenty of engineers here.

Then we could examine the loader and look for patters of where it's probably creating a hash (a read of an address that is far away).

Also, some devices already exist which can modify portions of the TCU's memory. The TCU which we use is the GS19 created by Bosch.

Device FRC3221S on this site:
http://www.evc.de/en/product/spiwizard/parts.asp
has the ability to program this, but it's for VAG cars, not BMW. I bet the boot loader is very similar...

EDIT: I see this device only supports "data area". I'm not sure what they mean by that, but DATA usually refers to things other than code. Code is usually referred to as TEXT or program.

Sorry for the rant.

[iaknown]

Originally Posted by Unklejoe

This is the best thread on this site, IMO. Decoding these maps is not a wasted effort, even if we currently lack a way to bypass the RSA check.



Spot on.



Do you have any insight on how this RAM checksum works? RAM diagnostic tests usually don't rely on any external data in my experience (just walk the address/data lines). I'm just curious for educational purposes.

Thinking out loud from here on...

To summarize the options at this point:

- Crack the RSA signature and get the private key (not happening)
- Obtain the RSA private key from someone at BMW (likely not happening)
- Bypass the RSA check in the bootloader (best option)
- Find out where the public key is stored in the bootloader and overwrite it with the public key from our own generated private/public key pair (may be easier than the option above, but not as ideal)

I believe the best option is to completely disable the RSA check, considering we don't know over which data the hash is generated or which hash algorithm they use.

What we need to know:

1. Can we flash the bootloader at all? There is an option in WinKFP for this, but does it work? Does this allow us to flash any arbitrary image to that memory region? Or does WinKFP check the signature of the bootloader? I have no clue how this process works.
2. If so, can soneone point me in the direction of the bootloader binary?
3. Does the bootloader check the signature of the image before it commits it to flash?

There are a number of ways flashing the bootloader can be implemented internally. Normally, the CPU boot straps to the bootloader in FLASH, which then copies itself to RAM and continues execution from there (where it then copies the main image to RAM and eventually jumps there). This is how the bootloader is able to seemingly overwrite itself. This also gives it the opportunity to check the signature of the complete bootloader image in RAM before it writes it to FLASH. This would be BAD. Ideally, the bootloader just copies block by block directly what it's fed from the OBD port

I would assume the bootloader itself has to be unencrypted at least during early boot. It may check a signature of itself during early init, so this would have to be bypassed as well if we modified the boot loader to bypass the main RSA check of the complete image.

The only way I could see any of this happening would be if we found out which CPU the thing uses and got access to a development board with a debugger. Not impossible, since I'm sure there are plenty of engineers here.

Then we could examine the loader and look for patters of where it's probably creating a hash (a read of an address that is far away).

Also, some devices already exist which can modify portions of the TCU's memory. The TCU which we use is the GS19 created by Bosch.

Device FRC3221S on this site:
http://www.evc.de/en/product/spiwizard/parts.asp
has the ability to program this, but it's for VAG cars, not BMW. I bet the boot loader is very similar...

EDIT: I see this device only supports "data area". I'm not sure what they mean by that, but DATA usually refers to things other than code. Code is usually referred to as TEXT or program.

Sorry for the rant.

Don't have a clue what jibberish you are speaking but I know the other guys here do and they will welcome it. Good to see some other ideas and that the project is still alive

[Mik325tds]

Originally Posted by Unklejoe

What we need to know:

1. Can we flash the bootloader at all? There is an option in WinKFP for this, but does it work? Does this allow us to flash any arbitrary image to that memory region? Or does WinKFP check the signature of the bootloader? I have no clue how this process works.
2. If so, can soneone point me in the direction of the bootloader binary?
3. Does the bootloader check the signature of the image before it commits it to flash?

Thanks for coming on board Unklejoe! You are asking the right questions and I appreciate your thoughts.
1. The bootloader files come as .bfa or .0ba files. I have not et seen a SP-daten distribution that contains a .bfa or .0ba for the GS19. Or I'm not looking at the right place...
2. Sorry, no clue.
3. If I was the developer of the TCU and had a signature on the program and data, I sure would include one for the bootloader as well. So flashing a modified bootloader over WinKFP would most likely not work.

However, your other idea is the most promising. If we get our hands on a used mechatronic unit we could take it apart, find out what micro it is using and get a debugger connected, read out flash, find bootloader signature check, disable and flash it back. Then we could connect that mechatronic unit to a car and try to flash it with a modified cal and see if it works without risking to brick a good transmission.

Anyone around with a broken transmission here?

[Hoooper]

The banned one should have a couple. Also I think nc335d said he has one sitting around

[Unklejoe]

Another hacky option is to figure out exactly what kind of CAN messages are exahcnged between the TCU and the rest of the car and make a translator so we can use the Ford TCU. Since the mechanical workings of the 6r80 are basically identical to the 6HP26, which is basically the same as the 6HP21, we may be able to have that TCU control the trans.

But I'm sure the interface between the TCU and the rest of the car is different.

I know I can make the translator, but figuring out what messages mean what is a pretty time consuming task (but it can be done, which is how devices like the JB4 exist).

[_TB_]

Originally Posted by Unklejoe

Device FRC3221S on this site:
http://www.evc.de/en/product/spiwizard/parts.asp
has the ability to program this, but it's for VAG cars, not BMW. I bet the boot loader is very similar...

EDIT: I see this device only supports "data area". I'm not sure what they mean by that, but DATA usually refers to things other than code. Code is usually referred to as TEXT or program.

Sorry for the rant.

That is really interesting! EVC makes som _really_ good remapping tools, although they are expensive. If they have a device that will read and write the data portion of the TCU - but on a VW, we are not far of getting a device that will read/write the BMW TCU.

I cannot see why we would want to read/write the program/code portion of the file - we just need to alter the maps in the data area.

..And on a sidenote, I talked a bit to JF Automotive about their gearbox remaps. They still have _no_ data to back up their claims about faster shifting and sooner lockup. I'm not impressed. But we could always buy one and snoop the data from it to see what it really is doing.

[Mik325tds]

Originally Posted by Unklejoe

Another hacky option is to figure out exactly what kind of CAN messages are exahcnged between the TCU and the rest of the car and make a translator so we can use the Ford TCU. Since the mechanical workings of the 6r80 are basically identical to the 6HP26, which is basically the same as the 6HP21, we may be able to have that TCU control the trans.

But I'm sure the interface between the TCU and the rest of the car is different.

I know I can make the translator, but figuring out what messages mean what is a pretty time consuming task (but it can be done, which is how devices like the JB4 exist).

Another nice idea! If I ask politely, I may be able to get the databases of both cars. Which carline is the 6r80 used in?
Gateways are easy to program - but which hardware would you use?

[Unklejoe]

Originally Posted by Mik325tds

Another nice idea! If I ask politely, I may be able to get the databases of both cars. Which carline is the 6r80 used in?
Gateways are easy to program - but which hardware would you use?

The 6R80 is the transmission used in the new 2011+ 5.0 Mustang GT.

As for the hardware, something like an Atmel AT90CAN128 might do the trick. It might require an external CAN transciever; I haven't looked in to the specific hardware much yet. I have used Atmel MCUs in the past, and they were always easy to get working. There are probably many example projects using a CAN controller.

This seems like a great project for a junior level Electrical/Computer engineering student. Maybe I can see if my school would be interested in helping out lol

[Chief Orman]

Originally Posted by Mik325tds

Thanks for coming on board Unklejoe! You are asking the right questions and I appreciate your thoughts.
1. The bootloader files come as .bfa or .0ba files. I have not et seen a SP-daten distribution that contains a .bfa or .0ba for the GS19. Or I'm not looking at the right place...
2. Sorry, no clue.
3. If I was the developer of the TCU and had a signature on the program and data, I sure would include one for the bootloader as well. So flashing a modified bootloader over WinKFP would most likely not work.

However, your other idea is the most promising. If we get our hands on a used mechatronic unit we could take it apart, find out what micro it is using and get a debugger connected, read out flash, find bootloader signature check, disable and flash it back. Then we could connect that mechatronic unit to a car and try to flash it with a modified cal and see if it works without risking to brick a good transmission.

Anyone around with a broken transmission here?

I am sure this has already been proposed but what about contacting the Aussie's directly or even Alpina? Can we avoid reinventing the wheel? That said, I see no reason why an Alpina would provide us with any information. However, there has to be a German/Austrian version of this board. Any German speakers out there?

[iaknown]

Originally Posted by Chief Orman

I am sure this has already been proposed but what about contacting the Aussie's directly or even Alpina? Can we avoid reinventing the wheel? That said, I see no reason why an Alpina would provide us with any information. However, there has to be a German/Austrian version of this board. Any German speakers out there?

Well IF you contacted Alpina, say several months ago for example, you MIGHT get a reply like the following (totally hypothetically speaking of course):

"Thank you for your email and enquiry.

We develop, build and sell complete vehicles. In the USA for example the BMW ALPINA B7 and the BMW ALPINA B6 xDrive Gran Coupe, which are officially sold and marketed through BMW of North America.

As such, we do not engage in any tuning or similar after-market modifications. Our vehicles, engines, transmissions and chassis are developed over a 24 months period with vehicle testing according the manufacturer standards. Our corporation with BMW prevents us from passing on proprietary information.

We hope you understand we are not able to help in this matter - however, we appreciate your endeavour, there need to be more diesel enthusiasts in the USA.

On a sidenote, we do have an ALPINA specific transmission software, hardware changes are primarily required to deal with increased torque etc. In the current F3x based BMW ALPINA diesel models we actual use the 8HP70 tranmission from our V8 models to deal with the torque."

[Chief Orman]

Originally Posted by iaknown

Well IF you contacted Alpina, say several months ago for example, you MIGHT get a reply like the following (totally hypothetically speaking of course):

"Thank you for your email and enquiry.

We develop, build and sell complete vehicles. In the USA for example the BMW ALPINA B7 and the BMW ALPINA B6 xDrive Gran Coupe, which are officially sold and marketed through BMW of North America.

As such, we do not engage in any tuning or similar after-market modifications. Our vehicles, engines, transmissions and chassis are developed over a 24 months period with vehicle testing according the manufacturer standards. Our corporation with BMW prevents us from passing on proprietary information.

We hope you understand we are not able to help in this matter - however, we appreciate your endeavour, there need to be more diesel enthusiasts in the USA.

On a sidenote, we do have an ALPINA specific transmission software, hardware changes are primarily required to deal with increased torque etc. In the current F3x based BMW ALPINA diesel models we actual use the 8HP70 tranmission from our V8 models to deal with the torque."

Should have known you guys were way ahead of me on this one. BTW...thanks for nothing Alpina. I wonder how much BMW pays those guys to stay out of the US (would Alpina kill M series sales?) Then again maybe emissions regs keep them out. I assume that Dinan is printing money and would think Alpina could too.

[Mik325tds]

Originally Posted by iaknown

Well IF you contacted Alpina, say several months ago for example, you MIGHT get a reply like the following (totally hypothetically speaking of course):

"Thank you for your email and enquiry.

We develop, build and sell complete vehicles. In the USA for example the BMW ALPINA B7 and the BMW ALPINA B6 xDrive Gran Coupe, which are officially sold and marketed through BMW of North America.

As such, we do not engage in any tuning or similar after-market modifications. Our vehicles, engines, transmissions and chassis are developed over a 24 months period with vehicle testing according the manufacturer standards. Our corporation with BMW prevents us from passing on proprietary information.

We hope you understand we are not able to help in this matter - however, we appreciate your endeavour, there need to be more diesel enthusiasts in the USA.

On a sidenote, we do have an ALPINA specific transmission software, hardware changes are primarily required to deal with increased torque etc. In the current F3x based BMW ALPINA diesel models we actual use the 8HP70 tranmission from our V8 models to deal with the torque."

Hahaha. Funny as hell.

[808AWD325xi]

Originally Posted by Unklejoe

This is the best thread on this site, IMO. Decoding these maps is not a wasted effort, even if we currently lack a way to bypass the RSA check.



Spot on.



Do you have any insight on how this RAM checksum works? RAM diagnostic tests usually don't rely on any external data in my experience (just walk the address/data lines). I'm just curious for educational purposes.

Thinking out loud from here on...

To summarize the options at this point:

- Crack the RSA signature and get the private key (not happening)
- Obtain the RSA private key from someone at BMW (likely not happening)
- Bypass the RSA check in the bootloader (best option)
- Find out where the public key is stored in the bootloader and overwrite it with the public key from our own generated private/public key pair (may be easier than the option above, but not as ideal)

I believe the best option is to completely disable the RSA check, considering we don't know over which data the hash is generated or which hash algorithm they use.

What we need to know:

1. Can we flash the bootloader at all? There is an option in WinKFP for this, but does it work? Does this allow us to flash any arbitrary image to that memory region? Or does WinKFP check the signature of the bootloader? I have no clue how this process works.
2. If so, can soneone point me in the direction of the bootloader binary?
3. Does the bootloader check the signature of the image before it commits it to flash?

There are a number of ways flashing the bootloader can be implemented internally. Normally, the CPU boot straps to the bootloader in FLASH, which then copies itself to RAM and continues execution from there (where it then copies the main image to RAM and eventually jumps there). This is how the bootloader is able to seemingly overwrite itself. This also gives it the opportunity to check the signature of the complete bootloader image in RAM before it writes it to FLASH. This would be BAD. Ideally, the bootloader just copies block by block directly what it's fed from the OBD port

I would assume the bootloader itself has to be unencrypted at least during early boot. It may check a signature of itself during early init, so this would have to be bypassed as well if we modified the boot loader to bypass the main RSA check of the complete image.

The only way I could see any of this happening would be if we found out which CPU the thing uses and got access to a development board with a debugger. Not impossible, since I'm sure there are plenty of engineers here.

Then we could examine the loader and look for patters of where it's probably creating a hash (a read of an address that is far away).

Also, some devices already exist which can modify portions of the TCU's memory. The TCU which we use is the GS19 created by Bosch.

Device FRC3221S on this site:
http://www.evc.de/en/product/spiwizard/parts.asp
has the ability to program this, but it's for VAG cars, not BMW. I bet the boot loader is very similar...

EDIT: I see this device only supports "data area". I'm not sure what they mean by that, but DATA usually refers to things other than code. Code is usually referred to as TEXT or program.

Sorry for the rant.

Check out this thread from www.getriebe-forum.de:
Gearbox Software from old to new transmission transmitting 6HP

Originally Posted by yacooth

Hello Joelyn,

because you have absolutely right, if you do not live in the Frankfurt area, our solution is rather umständig. :?

For reading our tools and describe of 6HP-xx based on Taken development and will not be offered for sale. Perhaps in the future if something more customers interested in something, we will be offering this trend also being commercial. The operation of the prototype is very umständig, requires experience with Motorola HEX copyright contents and great knowledge with ECU structure. We program the 6HP ECUs quasi zero (pre-bootloader programming), provide to the balance data for calibration of Mechatronics, only basic program and actual flash is programmed. Depending on hardware and ZF project, the two-, three- or vierstüfig done with various validations between. I do not think that anyone can easily do it yourself at home ... :? We use such tools because it is sometimes necessary for gearbox repairs to flash a controller to sample besetigen to certain problems or simply for pure research purposes. In addition, the only way you can, for example, by tuning unprofessional interventions "downed" TCM's, revive

Look on the Internet - perhaps there are already any tuning tools which only read the wallet at 6HP and write. Would be much easier for your needs. Of course, the checksum calculation is important here. I know that it exists but Audis already something of BMW I have not heard anything. WinKFP can help you to flash software version original, if you have your modifications in the transmission sometime away please. Can read the WinKFP not.

Regards, Robert :geek:

Robert (yacooth) in Frankfurt is saying he has the tools to flash 6HPxx transmissions, inclusive of the bootloader and can even revive bricked TCMs. Apparently the TCM has a Motorola processor.

Sounds like he might be able to help.

[_TB_]

Originally Posted by 808AWD325xi

Robert (yacooth) in Frankfurt is saying he has the tools to flash 6HPxx transmissions, inclusive of the bootloader and can even revive bricked TCMs. Apparently the TCM has a Motorola processor.

Sounds like he might be able to help.

You just made my day!

I live in Denmark, not far from Frankfurt..

[iaknown]

Please keep us posted if anyone is able to get in touch with this guy! Would love to hear about his capabilities with the trans.

[Mik325tds]

I'll try to get in touch with him. Flying to Frankfurt tomorrow.

[rjahl]

A few quick questions and comments:

1. Are you sure the Boot loader is not part of the OPA file? It seems like most of the newer ECUs do not have a separate boot loader in the Daten folders.

2. I was digging through the OPA files yesterday and could not easily locate the sections that contain the RSA signature. It's easy to spot in the Parameter section ODA files.

3. If the ECU checks the RSA signature for the Parameter section, could Winfkp be part of the signature check for the boot loader? What other purpose would the authorization files in the Winfkp installation have? Last year, I did a quick disassemble on Winfkp itself and it seemed to be full of authorization routines. Winfkp being a small executable can probably be beaten. Pprobably not by me, but someone with more experience.

Just thinking,