HPtuners for BMW, Mercedes-Benz???

[DWR]

3lli0t 06-22-2015 03:27 AM
Quote:
Originally Posted by Mik325tds (Post 18128253)
Yes, that'll probably a single value in the cal file different from the standard cal file. Probably impossible to find unless it is in a field of same values.
What do you mean, with "only one mapping available in the data"?
That sounds not so nice :P.
My description concerning the mapping was a little bit confusing: For my HW-# there are min. 25 different files in the DATA which can be flashed. My actual ZUSB is for the N57 and there is no file for the M57 for the GKE215. The reason is, that the e92 325d from 2009 was one of the last models with the M57TU2UL, the 330d had already the N57 (245 HP), so BMW didn't develop an extra mapping for the M57 with GKE215.
Generally I would try to flash the Alpina Soft for the N54 and test the result. But I don't know if that could harm the transmission, because it's made for an entire different torque and power curve. On the other hand I have to start somewhere and like so see if it's possible to combine the Alpina-Soft with the standard-N57-mapping. The plan: Take the Alpina file and overwrite the N54-tables with the N57-tables. If this works I have a file with the alpina-display (Gears in D and DS) and can start to optimize the mapping. Now my question: Is it possible to isolate only the shift-maps und leave the rest?

Mik325tds 06-22-2015 06:41 AM
Quote:
Originally Posted by 3lli0t (Post 18129958)
That sounds not so nice :P.
My description concerning the mapping was a little bit confusing: For my HW-# there are min. 25 different files in the DATA which can be flashed. My actual ZUSB is for the N57 and there is no file for the M57 for the GKE215. The reason is, that the e92 325d from 2009 was one of the last models with the M57TU2UL, the 330d had already the N57 (245 HP), so BMW didn't develop an extra mapping for the M57 with GKE215.
Generally I would try to flash the Alpina Soft for the N54 and test the result. But I don't know if that could harm the transmission, because it's made for an entire different torque and power curve. On the other hand I have to start somewhere and like so see if it's possible to combine the Alpina-Soft with the standard-N57-mapping. The plan: Take the Alpina file and overwrite the N54-tables with the N57-tables. If this works I have a file with the alpina-display (Gears in D and DS) and can start to optimize the mapping. Now my question: Is it possible to isolate only the shift-maps und leave the rest?
First you have to find out if the cal files have the same structure for your HW number and the alpina flash. I use TotalCommander to do a binary file compare for that. If the files are the same length and the sectioning is the same you should see only differences in the data itself but not in the addresses. Best case would be if the HW number is the same for the alpina flash and your HW, but since it didn't flash I assume that is not the case.
As far as identifying the shift maps goes, I guess we'll have to wait until DWR shares his magic on that.

3lli0t 06-22-2015 11:05 AM
Quote:
Originally Posted by Mik325tds (Post 18130265)
First you have to find out if the cal files have the same structure for your HW number and the alpina flash. I use TotalCommander to do a binary file compare for that. If the files are the same length and the sectioning is the same you should see only differences in the data itself but not in the addresses. Best case would be if the HW number is the same for the alpina flash and your HW, but since it didn't flash I assume that is not the case.
As far as identifying the shift maps goes, I guess we'll have to wait until DWR shares his magic on that.
I compared the N54-Alpina file and the N57 file. The adresses are the same. If I make the right settings in WinOLS it finds around 100 maps, but I have no idea if the software is right .

Mik325tds 06-23-2015 03:37 PM
Quote:
Originally Posted by 3lli0t (Post 18131486)
I compared the N54-Alpina file and the N57 file. The adresses are the same. If I make the right settings in WinOLS it finds around 100 maps, but I have no idea if the software is right .
Wich one is the alpina file?
WinOLS will not help you. As DWR found out, the structure of the maps do not follow the Bosch standard structure, so WinOLS will not correctly identify maps. He used an excel file to read in the cal file and convert it to decimal numbers and then some magic on how to identify the maps. Hopefully, he'll let us in on how to exactly transfer that to other cal files. Success in this case certainly doesn't come without sweat.

Mik325tds 06-24-2015 06:12 AM
Quote:
Originally Posted by DWR (Post 18125262)
I'm in the midst of upgrading my map finding tool and have it inoperable right now. But you and the forum will have it shortly after I do . In the meanwhile, this is what I can tell you. After the first block of zeros, use the data value "534C" as the starting point, row1 and column1. The infield data for the shift maps is at row 7839, column 6, starting with value "0122". The maps do not follow Bosch format (that's why I could not find them at first), but rather run infield data consecutively, 10 columns, row 1 to 13, 10 maps, in that sequence.
I'm not quite sure I'm following you. In the file A7610591.0da row 7839 looks like this:
:10E4D00000010303000000140028026C030C03B6C3
Can't find 0122 anywhere close to that. The next 0122 is in row 8008 address :10EF6000. What am I missing?

[DWR]

DWR 06-28-2015 06:46 PM
Nice work MIK352tds! Given synchronicity issues I often see in datalogging, that looks like a good fit.

:cool!: We are still making progress!

DWR 06-28-2015 08:51 PM
Quote:
Originally Posted by Mik325tds (Post 18167505)
I'm starting to think that Stat_SA is a Status in a State machine that handles up and downshifts. SA starts changing values before a change in gears happens and ends at the end of the gear change.
You are right Mik. If you log the text value of SA, it tells you the state (although I found one that is clearly misnamed). It is both shift transitions and steady state gear operation. My graph of SA value vs gear tells the same story. In some cases, these state changes happen fast enough to be missed in datalogging. That also means the OSS, mph and rpms at which these things happen can get out of sync. Its just a resolution thing. The way that is overcome is by the same means you just used - closest fit. More data doesn't hurt either

Mik325tds 06-29-2015 06:14 PM
1 Attachment(s)
Uh. Another heart rate elevation tonight. May have even skipped a few beats...
Tried flashing a modified cal file with updated checksum by NCSdummy:

Mik325tds 06-29-2015 06:18 PM
1 Attachment(s)
Boy was I glad to see this when I tried going back to the original cal:

DWR 06-29-2015 07:52 PM
Quote:
Originally Posted by Mik325tds (Post 18173730)
Boy was I happy to see this when I tried going back to the original cal:
:bow: Oh, most brave one, I'm at the same time envious of your tremendous cohones and ever glad we have split the chores of this endeavor in a most appropriate manner.

So, I guess we still need to figure out the Cyclic Redundancy Check?

In the meanwhile, I think I'll repeat the datalog experiment you did, with the stock cal file in my vehicle, and see if the map locations coincide with your results.

Good job, Mik. :thumbsup:

Mik325tds 06-30-2015 07:33 AM
Quote:
Originally Posted by DWR (Post 18174152)
So, I guess we still need to figure out the Cyclic Redundancy Check?
It seems to be much worse than that. Reading up on NCSdummy, revtor writes that some of the flashfiles are digitally signed with an RSA signature which NCSdummy cannot fix.:mad0259:
Anyone with expertise on cryptology here?

Mik325tds 06-30-2015 07:58 AM
1 Attachment(s)
Found something about a weakness in the RSA signatures:
Looks like with that we'd be able to extract the public key using two signed cal files and then would be able to sign the moded cal file ourselves.

DWR 06-30-2015 11:08 AM
Quote:
Originally Posted by Mik325tds (Post 18176285)
Found something about a weakness in the RSA signatures:
Looks like with that we'd be able to extract the public key using two signed cal files and then would be able to sign the moded cal file ourselves.
Looked over the attachment, got to love mathematics if you want to understand cryptography. Hopefully, the open source program will work. Is that your thought also?

Mik325tds 06-30-2015 01:37 PM
Quote:
Originally Posted by DWR (Post 18177220)
Looked over the attachment, got to love mathematics if you want to understand cryptography. Hopefully, the open source program will work. Is that your thought also?
Which open source program?
From what I've been reading today, we'd have come to a full stop here. BMW uses a RSA asymmetric signature which means that with the public key you can authenticate (verify the correct signature) in the file but you need the secret key in order to sign the file.

DWR 06-30-2015 03:26 PM
Quote:
Originally Posted by Mik325tds (Post 18178156)
Which open source program?
From what I've been reading today, we'd have come to a full stop here. BMW uses a RSA asymmetric signature which means that with the public key you can authenticate (verify the correct signature) in the file but you need the secret key in order to sign the file.
I was referring to Yafu, but apparently that just finds public keys.

So, does that put a question mark on JA Tuning's flash box? Or are they in the know?

DWR 06-30-2015 04:54 PM
So Mik, do you think it is worthwhile to look at the other available cal files and characterize their appropriateness?

iaknown 06-30-2015 04:56 PM
Quote:
Originally Posted by DWR (Post 18178892)
I was referring to Yafu, but apparently that just finds public keys.

So, does that put a question mark on JA Tuning's flash box? Or are they in the know?
You mean JFA or JR? Both sell a "flash box" and neither are actually the manufacturer of it. I can dig up the company if you need it.

Mik325tds 06-30-2015 04:58 PM
Quote:
Originally Posted by DWR (Post 18178892)
I was referring to Yafu, but apparently that just finds public keys.

So, does that put a question mark on JA Tuning's flash box? Or are they in the know?
I doubt that they have the secret key. I think they just replace the bootloader and then never check for signature again. In order to authenticate yourself for flashing the bootloader you just need to use the same seed/key authentication that WinKFP does.
But for us it seems to be end of the story.:cry:
Thank you for all the hard work. It's been a pleasure working with you and we have learned a lot.
Also thanks to the other contributers.

iaknown 06-30-2015 05:35 PM
Quote:
Originally Posted by Mik325tds (Post 18179504)
I doubt that they have the secret key. I think they just replace the bootloader and then never check for signature again. In order to authenticate yourself for flashing the bootloader you just need to use the same seed/key authentication that WinKFP does.
But for us it seems to be end of the story.:cry:
Thank you for all the hard work. It's been a pleasure working with you and we have learned a lot.
Also thanks to the other contributers.
I don't understand most of the technical mumbo jumbo in this thread, but if you had the ability to write your own "flashbox" (providing its not a crock of BS) could you do the same thing they are? Perhaps the original manufacturer of the flashbox offers a way to custom program?

Hoooper 06-30-2015 05:56 PM
I really don't know anything about the RSA signatures, but why does it change if you just change text in the file? I also don't get why an open file would have a digital signature at all.

DWR 07-01-2015 12:49 AM
Quote:
Originally Posted by iaknown (Post 18179490)
You mean JFA or JR? Both sell a "flash box" and neither are actually the manufacturer of it. I can dig up the company if you need it.
Oh, that might be good. Yes, please.

DWR 07-01-2015 12:56 AM
Quote:
Originally Posted by Mik325tds (Post 18179504)
I doubt that they have the secret key. I think they just replace the bootloader and then never check for signature again. In order to authenticate yourself for flashing the bootloader you just need to use the same seed/key authentication that WinKFP does.
But for us it seems to be end of the story.:cry:
Thank you for all the hard work. It's been a pleasure working with you and we have learned a lot.
Also thanks to the other contributers.
Why can't we do what they are doing? Why can't we just use the same seed/key authentication that WinKFP does?

Mik325tds 07-01-2015 05:44 AM
Quote:
Originally Posted by Hoooper (Post 18179824)
I really don't know anything about the RSA signatures, but why does it change if you just change text in the file? I also don't get why an open file would have a digital signature at all.
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.

Mik325tds 07-01-2015 05:52 AM
Quote:
Originally Posted by DWR (Post 18181648)
Why can't we do what they are doing? Why can't we just use the same seed/key authentication that WinKFP does?
We could. The seed/key authentication is a different hurdle than the signature of the file though. The seed/key authentication only "unlocks" the ECU to start the flashing process. Once the new program or cal file is transferred, the bootloader then checks the signatures before it actually runs the new program.

The bootloader is a section in the ECU that usually doesn't get reflashed, but it is possible to be reflashed through a special configuration in WinKFP. The thing is: You need a new bootlaoder that doesn't check for the signature of the new program/cal file afterwards. Where are we going to get that from?

DWR 07-02-2015 10:42 PM
NEWS FLASH ... working in the background. This effort isn't dead, yet.

Mik325tds 07-03-2015 08:42 AM
Quote:
Originally Posted by iaknown (Post 18179710)
I don't understand most of the technical mumbo jumbo in this thread, but if you had the ability to write your own "flashbox" (providing its not a crock of BS) could you do the same thing they are? Perhaps the original manufacturer of the flashbox offers a way to custom program?
That could be an option. Maybe the original manufacturer of the flash box already knows how to replace the bootloader so it doesn't check for signatures anymore.

Mik325tds 07-04-2015 04:45 PM
Alpina B3 cal

In a desperate attempt to try something we haven't confirmed yet, I substituted the Cal A7610591.0da with the Alpina file A7615836.0da from the GKE215 folder. The HW numbers are just one number apart 7591971A.0pa vs 7591972A.0pa and differ marginally.
It flashed ok and didn't complain about checksums or signatures...
... but it didn't shift out of Park either. And it had this awful message about transmission failure on the CIC.

At least we have confirmation now. Alpina B3 does not work for the 335d.

[DWR]

Chief Orman 07-05-2015 06:53 AM
Quote:
Originally Posted by Mik325tds
Quote:
Originally Posted by 3lli0t (Post 18111608)
Hi.

thank you very much for this thread and your work! I'm also very interessted in an transmission remap for the N57/M57. Concerning the checksum: Afaik NCS-Dummy can update the checksum on modified NFS(WinKfp)-Files!
3lli0t - you're awesome!
It works!
I changed this line from
:1001300000000000000000000000000000000000BF
to
:10013000000000000000000FF000000000000000BF
Old checksum was
$CHECKSUMME 571E U

Used NCS dummy to read the file. It said that the checksum doesn't match and if I'd like to update it. YESSSS!!!
:10013000000000000000000FF000000000000000C0
$CHECKSUMME B1C8 X
How much more convenient can it be?

We are now ready to flash updated cal files to our EGS! :happyanim::happyanim:
Well done!

DWR 07-05-2015 12:04 PM
Quote:
Originally Posted by Mik325tds (Post 18199953)
In a desperate attempt to try something we haven't confirmed yet, I substituted the Cal A7610591.0da with the Alpina file A7615836.0da from the GKE215 folder. The HW numbers are just one number apart 7591971A.0pa vs 7591972A.0pa and differ marginally.
It flashed ok and didn't complain about checksums or signatures...
... but it didn't shift out of Park either. And it had this awful message about transmission failure on the CIC.

At least we have confirmation now. Alpina B3 does not work for the 335d.
OK, so not the results we had hoped, but I still this is awesome work you are doing! :thumbsup:

_TB_ 08-14-2015 06:51 AM
What about the Alpina D3 file on a 325d? It uses the same gearbox as the 320d/alpina D3.

Does anybody have the Alpina D3 file?

3lliot?

briansjacobs 08-14-2015 07:46 AM
I did not make it past the first two post of this thread, I will stick to selling houses, you guys find things for me to throw money at.

DWR 08-14-2015 01:26 PM
Quote:
Originally Posted by briansjacobs (Post 18416771)
I did not make it past the first two post of this thread, I will stick to selling houses, you guys find things for me to throw money at.
Ha, PM me. I'll give you an account you can direct deposit to! :lol:

DWR 08-14-2015 01:30 PM
Seriously, just an update. Mik325tds and I are on a break due to other priorities. In addition, we decided to wait when a forum member with the reflash started to get concerned with shifting in his trans.

_TB_ 08-14-2015 01:37 PM
Quote:
Originally Posted by DWR (Post 18418843)
Seriously, just an update. Mik325tds and I are on a break due to other priorities. In addition, we decided to wait when a forum member with the reflash started to get concerned with shifting in his trans.
Do you have the Alpina D3 binary?

among other things I'm working as a remapper - I'm pretty used to find maps in binary files. Both in WinOLS and my own developed programs.

I'm not afraid of challenges.

DWR 08-15-2015 12:01 PM
Quote:
Originally Posted by _TB_ (Post 18418898)
Do you have the Alpina D3 binary?

among other things I'm working as a remapper - I'm pretty used to find maps in binary files. Both in WinOLS and my own developed programs.

I'm not afraid of challenges.
That really isn't the issue. The issue is getting the remap into the TCU. We originally thought there would be minimal protections - well, that turned out to be incorrect. Mik325tds and a few others have been able to flash existing BWM maps from other vehicles into the 335d, but nothing modified. So our challenge at this time is getting past the security gates. At least one other interested party is chipping away at this. If you would like to participate in that part of the effort, please PM Mik325tds, as he knows the specifics better than I.

Thanks for the offer of help.

deepocean 08-15-2015 04:40 PM
ask

guys can just anyone explain to me straight forward what you r talking about is it something tune for transmission?

DWR 08-15-2015 05:54 PM
Quote:
Originally Posted by deepocean (Post 18424127)
guys can just anyone explain to me straight forward what you r talking about is it something tune for transmission?
DIY transmission tuning.

Chief Orman 08-16-2015 05:53 PM
Quote:
Originally Posted by deepocean (Post 18424127)
guys can just anyone explain to me straight forward what you r talking about is it something tune for transmission?

Quote:


Originally Posted by Chief Orman View Post

At the risk of asking a stupid question, where is all this leading? I assume that by dissecting the software files the intent is to create our own transmission software flash. Correct? To the technologically sophisticated folks who have dedicated countless hours to the noble endeavor how far away are we from the end goal (assuming I have summed it up correctly)?

There are no stupid questions. You got it almost right Chief. The SW for this transmission comes in two parts. One is the software which includes the allgorithms on which valves have to close/open in order to achieve gears. That we are not intending to change. The second part is the so called calibration. That's a different file and can be flashed with the same base SW. The cal file contains a whole bunch of maps which for instance tell the SW when to shift from 2>3 based on throttle input and output shaft speed. That is something we are trying to change and are very close to trying out the first changes.

We are also trying to change the lock up behavior of the clutch especially in first and second gear in order to get rid of the slushy behavior. That is a little further out since we haven't found the maps yet and don't quite understand yet how they work.

deepocean 08-17-2015 11:27 AM
mr orman

highly appreciated ur reply and explination..

Chief Orman 08-17-2015 03:26 PM
Quote:
Originally Posted by deepocean (Post 18430221)
highly appreciated ur reply and explination..
The useful part of the quote above is from MIK325tds

rjahl 08-31-2015 04:44 PM
Quote:
Originally Posted by DWR (Post 18423001)
That really isn't the issue. The issue is getting the remap into the TCU. We originally thought there would be minimal protections - well, that turned out to be incorrect. Mik325tds and a few others have been able to flash existing BWM maps from other vehicles into the 335d, but nothing modified. So our challenge at this time is getting past the security gates. At least one other interested party is chipping away at this. If you would like to participate in that part of the effort, please PM Mik325tds, as he knows the specifics better than I.

Thanks for the offer of help.

Great work going on here, I've been reading this and it reminds me of when I tried to flash Z4 3.0SI software into my 3.0I. I got passed all of the ODA checksums using Revtors program and corrected the file checksum using other software. Never worked.

I managed to flash the 3.0SI code using a BDM and I'm very happy with the car but I'm starting to look at the transmission as a week link, that's what led me to this forum. It seems like the 6HP19 had two torque converters A121 and B121 and I can't find any documentation about them. I would love to flash the 3.0SI software into my transmission but I worried about the torque converter locking up before it's stall speed and burning up.

Did you know the CNV Code in the ODA file happens to be the Software checksum? Look at the end and you will see a line like

$CARB_MODE_9_CVN 0000B7C4 C

The B7C4 will be the checksum. Hint hint.

This still does not get you past the File signature. I think the public key is in the SGIDD.AS2 or SGIDC.AS2 files in the Gdaten folder.

DWR 08-31-2015 05:22 PM
Thanks for the hint.

Hoooper 08-31-2015 05:44 PM
Quote:
Originally Posted by rjahl (Post 18508180)
I worried about the torque converter locking up before it's stall speed and burning up.
Not sure why that would be a problem. Stall speed is a power dependent variable, most transmissions will lock up the torque converter before hitting stall speed. For instance, the stall speed of the converter in the 6hp26 in the 335d is about 2000 RPM (closer to 2500 RPM in mine with minor mods, probably close to 3000 in the heavier modded cars), the torque converter will lock up while accelerating as low as about 1000 RPM with stock map. The only thing that should contribute to burning up the converter clutch is overpowering it or trying to apply it slowly.

Mik325tds 08-31-2015 05:55 PM
Quote:
Originally Posted by rjahl (Post 18508180)
Great work going on here, I've been reading this and it reminds me of when I tried to flash Z4 3.0SI software into my 3.0I. I got passed all of the ODA checksums using Revtors program and corrected the file checksum using other software. Never worked.

I managed to flash the 3.0SI code using a BDM and I'm very happy with the car but I'm starting to look at the transmission as a week link, that's what led me to this forum. It seems like the 6HP19 had two torque converters A121 and B121 and I can't find any documentation about them. I would love to flash the 3.0SI software into my transmission but I worried about the torque converter locking up before it's stall speed and burning up.

Did you know the CNV Code in the ODA file happens to be the Software checksum? Look at the end and you will see a line like

$CARB_MODE_9_CVN 0000B7C4 C

The B7C4 will be the checksum. Hint hint.

This still does not get you past the File signature. I think the public key is in the SGIDD.AS2 or SGIDC.AS2 files in the Gdaten folder.
Thanks for the insight. I'm not quite getting your hint though. The line
;$CARB_MODE_9_CVN 00000DDC W
is commented out in our .oda file and I believe the checksum is in the line
$CHECKSUMME 571E U
At least that's the line that NCSdummy corrected after modification.

What is a BDM though? And how does it get around the digital signature?
Edit: Ah, yes. Bench programmer. Read out bootloader, deactivate signature check and reprogram. The only thing is, I don't feel like draining the oil again and opening the mechatronic unit to get to the micro.

rjahl 08-31-2015 06:16 PM
Quote:
Originally Posted by Mik325tds (Post 18508524)
Thanks for the insight. I'm not quite getting your hint though. The line
;$CARB_MODE_9_CVN 00000DDC W
is commented out in our .oda file and I believe the checksum is in the line
$CHECKSUMME 571E U
At least that's the line that NCSdummy corrected after modification.

What is a BDM though? And how does it get around the digital signature?
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

rjahl 08-31-2015 06:29 PM
Quote:
Originally Posted by Hoooper (Post 18508482)
Not sure why that would be a problem. Stall speed is a power dependent variable, most transmissions will lock up the torque converter before hitting stall speed. For instance, the stall speed of the converter in the 6hp26 in the 335d is about 2000 RPM (closer to 2500 RPM in mine with minor mods, probably close to 3000 in the heavier modded cars), the torque converter will lock up while accelerating as low as about 1000 RPM with stock map. The only thing that should contribute to burning up the converter clutch is overpowering it or trying to apply it slowly.
"overpower" is my worry, my car started life as a Z4 3.0I essentially a 325 setup and I've installed a three stage manifold and the Z4.3.0SI tune. This upgrades the original 215HP into 258HP and I'm sure I can dig out another 10HP or so. No custom exhaust or intakes.

Through data logging, I've noticed horribly slow shifts with long Can bus torque reduction requests and my low RPM torque figures seem off, possibly from more reduction request, I'm not sure. I'd like to try the 3.0SI transmission file but need to learn more about the repercussions.

Mik325tds 08-31-2015 07:00 PM
Quote:
Originally Posted by rjahl (Post 18508638)
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
Thanks for the link. Interesting read.
Anyway, we'll need the TCU out of the tranny for that.
I wasn't aware of the RAM checksum. Which tool can calculate that one?

[Mep_q8]

Look into Openflash for the 335i and Porsches. I've tuned several vehicles this way and it's a COMPLETE tuning system, with ALL parameters. No need for the $12000 Dimsport was going to charge me for their Tuning tools which only cost $3000. The $9000 was the "keys" and "software" that translates the hex into a legible format.

[mpeacock]

Look into Openflash for the 335i and Porsches. I've tuned several vehicles this way and it's a COMPLETE tuning system, with ALL parameters. No need for the $12000 Dimsport was going to charge me for their Tuning tools which only cost $3000. The $9000 was the "keys" and "software" that translates the hex into a legible format.

How did you confirm it had "all" parameters vs Dimsport or OEM engineering software? Interesting

[Mep_q8]

How did you confirm it had "all" parameters vs Dimsport or OEM engineering software? Interesting

It doesn't have OEM engineering software nor does it have ALL the parameters Dimsport can search for. Dimsport reads the hex out of ECUs, so you can completely break down the parameters if you have a lot of spare time, and pay near enough $15-16k to actually get all the software/hardware from them which is just way too much. (No wonder European tuning companies charge $1500 for a tune!)

Download tunerpro and take a look at these files. The openflash tool is Powergate which is an Alientech tool. You can either sell the Openflash tool to customers, or send them out a Burger Tuning opensource flash wire, but still use the XDF files found.

They have near enough have every parameter you need to tune for go fast mods.

Download the following from this site and try out the Tuner Pro software:

http://procedetuning.com/BMW/n54/Ope...s-3/index.html

[Hoooper]

As far as I know openflash does not have the capability to bypass or fix the RSA encryption that is blocking transmission flashes on that transmission, nor does it support tuning the encrypted computer of the 335d.

When tuning the 335i were you able to tune the transmission or just the engine?

[Mep_q8]

As far as I know openflash does not have the capability to bypass or fix the RSA encryption that is blocking transmission flashes on that transmission, nor does it support tuning the encrypted computer of the 335d.

When tuning the 335i were you able to tune the transmission or just the engine?

engine only