[Unklejoe]

Originally Posted by Terraphantm

You've got the general idea.

The thing about RSA is that the public key and private key are related numbers, but it's very difficult to derive the private key from the public key.

Essentially you start with two large prime numbers (p and q), along with an exponent (e) which is relatively prime to those numbers (BMW generally uses 3 or 7).

The public modulus (n) is p and q multiplied together. Both n and e are usually stored in plaintext in the binary. Private key is kept secret. Without getting into all of the math, if you know p, q, and e - you can generate the private key. But it is very difficult to get p and q from n. So as long as those factors are kept secret, the code is secured.

Computers have gotten fast enough to factor "short" (512-bit) keys in a reasonable time frame. It's not really brute force - there is a definite algorithm to the process rather than trial division (which would take eons even with today's computers). To do the actual factoring, I used the general number field sieve - which you can read about here: http://gilchrist.ca/jeff/factoring/n...ers_guide.html

The guys who actually made those algorithms and programs are legit geniuses. I understand enough to kind of get how it works, but I'm no mathematician.


As far as which regions the MD5s are calculated from and such -- you can tell by disassembling the code. It's all declared in a very specific format.

Thanks! That was a great explanation.

When you say the keys are usually stored in plain text, do you mean like actual ASCII characters? That seems like a rather unusual approach for storing a number within something like a bootrom, but I bet it helps to make it a little easier to identify when looking at a dump of the binary. ASCII strings seem to stand out, especially when your viewer has the ASCII view on the right side (like WinHEX or something).

Originally Posted by Terraphantm

I haven't been able to actually, but the keys were stored in plain text, and the parameter signature was easy enough to figure out IIRC.

I don't think it's encrypted, but rather it's compressed.

Yeah, I remember reading that the CPU has the ability to execute compressed instructions directly, and portions of the bootrom were compressed. I think the dictionary is available in the processor reference manual. I think that's how they were able to start disassembling the bootrom.

As for this new tool, I'm curious about how it works. I was under the impression that they didn't actually crack the RSA key, but rather, the "bootrom programming mode" authentication key (I'm assuming that's the level 3 security access key). This then allowed them to write to the bootrom. At that point, it seems like you can then either replace the BMW public key with your own so you can sign your own images, or modified the code to bypass the check completely.

[Terraphantm]

Originally Posted by Unklejoe

Thanks! That was a great explanation.

When you say the keys are usually stored in plain text, do you mean like actual ASCII characters? That seems like a rather unusual approach for storing a number within something like a bootrom, but I bet it helps to make it a little easier to identify when looking at a dump of the binary. ASCII strings seem to stand out, especially when your viewer has the ASCII view on the right side (like WinHEX or something).

Ah I should have used better terminology. I just meant it's stored as a number - it's not encrypted or obfuscated in any manner

Originally Posted by Unklejoe

As for this new tool, I'm curious about how it works. I was under the impression that they didn't actually crack the RSA key, but rather, the "bootrom programming mode" authentication key (I'm assuming that's the level 3 security access key). This then allowed them to write to the bootrom. At that point, it seems like you can then either replace the BMW public key with your own so you can sign your own images, or modified the code to bypass the check completely.

Yeah I'm not sure what they did for the new tool coming out. The newer GKE modules have 1024-bit keys, so they definitely didn't crack the key itself unless they have an inside source.

They probably found a way to bypass the RSA check. Generally that involved changing the pointers for the RSA check so that you can flash and execute your own code while the module thinks it's authorized. Alternatively they may have figured out how to wipe the boot sector with one of the security access levels (I don't think Level 3 would do it, but levels 4 and 5 might -- I haven't worked on any of those yet)


For the older modules, the key I published should at least allow someone to flash those GKEs.

[Mik325tds]

Originally Posted by Terraphantm

You've got the general idea.

The thing about RSA is that the public key and private key are related numbers, but it's very difficult to derive the private key from the public key.

Essentially you start with two large prime numbers (p and q), along with an exponent (e) which is relatively prime to those numbers (BMW generally uses 3 or 7).

The public modulus (n) is p and q multiplied together. Both n and e are usually stored in plaintext in the binary. Private key is kept secret. Without getting into all of the math, if you know p, q, and e - you can generate the private key. But it is very difficult to get p and q from n. So as long as those factors are kept secret, the code is secured.

Computers have gotten fast enough to factor "short" (512-bit) keys in a reasonable time frame. It's not really brute force - there is a definite algorithm to the process rather than trial division (which would take eons even with today's computers). To do the actual factoring, I used the general number field sieve - which you can read about here: http://gilchrist.ca/jeff/factoring/n...ers_guide.html

The guys who actually made those algorithms and programs are legit geniuses. I understand enough to kind of get how it works, but I'm no mathematician.


As far as which regions the MD5s are calculated from and such -- you can tell by disassembling the code. It's all declared in a very specific format.

This is awesome! Thanks for the insights Terraphantm!

[TorqueAddict]

I have access to pretty decent computing resources (80 physical cores + RAM in several Terabytes). Let me know if i can be of any help.

[rjahl]

Originally Posted by Terraphantm

Ah I should have used better terminology. I just meant it's stored as a number - it's not encrypted or obfuscated in any manner

Yeah I'm not sure what they did for the new tool coming out. The newer GKE modules have 1024-bit keys, so they definitely didn't crack the key itself unless they have an inside source.

They probably found a way to bypass the RSA check. Generally that involved changing the pointers for the RSA check so that you can flash and execute your own code while the module thinks it's authorized. Alternatively they may have figured out how to wipe the boot sector with one of the security access levels (I don't think Level 3 would do it, but levels 4 and 5 might -- I haven't worked on any of those yet)


For the older modules, the key I published should at least allow someone to flash those GKEs.

Terraphantm,

I'd like to repeat, great write up.

With this information can you resolve and calculate the calibration file, RSA signature for the GKE211? In other words would it be possible to write a script to create a valid RSA signature on a modified calibration file?

It's not like I'm having great success with official files but it would be nice to know how far this can go.

[Terraphantm]

Originally Posted by rjahl

Terraphantm,

I'd like to repeat, great write up.

With this information can you resolve and calculate the calibration file, RSA signature for the GKE211? In other words would it be possible to write a script to create a valid RSA signature on a modified calibration file?

It's not like I'm having great success with official files but it would be nice to know how far this can go.

Yes, it's definitely possible to make a script or program that does so. Python would probably be easiest to use since it handles large numbers natively.

Basically what you'd have to do is find the RSA pointers, calculate the MD5 for that chunk of data, byte swap and reverse the md5, sign that with the private key, and insert the newly generated signature into the calibration.

The other thing that one can do is change the RSA pointers to cover a short range of bytes that never change, calculate a signature for that range, and then just insert that signature into any file you make without having to resign the file every time.

[mob17]

Ignore sorry

[mob17]

Anyone remember that guy who spent 500 GBP on a tranny tune?

[mestonian]

Ive got a uk car, 2006 e91 330d. My hardware number is (i think) 7587969, is this on the supported list? Ive looked at the compatibility chart and it says vu92 type code which mine is. I really hope it is!!

[RBT-Tuning]

Originally Posted by mestonian

Ive got a uk car, 2006 e91 330d. My hardware number is (i think) 7587969, is this on the supported list? Ive looked at the compatibility chart and it says vu92 type code which mine is. I really hope it is!!

Look at the bottom of the list. If you are in the 2006/2007 bucket it might not be supported, despite listed. You're hardware number points to the old TCU, so no luck at the moment, sorry.

[drhousedk]

Originally Posted by mestonian

Ive got a uk car, 2006 e91 330d. My hardware number is (i think) 7587969, is this on the supported list? Ive looked at the compatibility chart and it says vu92 type code which mine is. I really hope it is!!

Most probably not. My car is a 01/2007 production 330dA e91, hw bmw nr 7563325, which is not supported. Word is that if your mechatronic unit is a 13 bolt one, you could plug-n-play replace your TCU with a supported one. Unfortunately, mine is a 10 bolt - as luck would have it, I have a photo from when I replaced fluid and oil pan on my transmission:



Most easily identified by the solenoids. 10 bolt mecha doesn't have any bright orange solenoids:



We'll just have to wait.

[_TB_]

Just a quick update from me - the app is absolutely awesome. It is far more robust than I would have imagined a beta version would be. I have tried two of the OTS maps (Stage1+2), and I have tried to flash a "custom" tune. (Custom is just flashing the backup the app makes as the first thing, in order to test the custom flash capabilities). There is extensive sanity check to the custom file before flashing it to the TCU. Overall I'm quite impressed.

[Unklejoe]

I have a few questions regarding how this tool will work once it's released.

For the OTS maps, are there separate versions of each OTS map based on every possible stock software revision, or are the OTS maps based on a common revision which would get flashed to every car regardless of its original stock software revision?

If there are separate OTS map versions, does this tool automatically read the UIF to determine the current software version, then use that to choose the appropriate version of the desired OTS map? I ask because my UIF doesn't necessarily reflect what's actually on the TCU.

My last question is regarding the custom flashing capabilities.

My N55 car currently has the Alpina B3 flash. Will this tool be able to read that image out and reflash a modified version if it (assuming I made the modifications myself, of course)? Or are there limitations on which factory software revisions can be customized/cksum corrected/etc?

[_TB_]

Originally Posted by Unklejoe

My N55 car currently has the Alpina B3 flash. Will this tool be able to read that image out and reflash a modified version if it (assuming I made the modifications myself, of course)? Or are there limitations on which factory software revisions can be customized/cksum corrected/etc?

This I can answer

The first thing you do in the app - before you're allowed to flash anything - is to make a full 1MB backup of your current TCU. This can be an Alpina, ori BMW or whatever.

This file you can edit - as long as you do not touch some areas of the file. (as far as i know you're not allowed to touch the program part of it, only calibrations part). That means you can alter your Alpina file - and then flash your modified alpina as a custom tune. This is what I have done right now for my 325d.

..But please be aware - the alpina file does have the same maps as a std. BMW file - but it uses them in a different manner. It is not a big issue, just takes quite some longer time to find out how it uses the maps. Also IMHO the Alpina file is pretty "advanced" already, it is hard to find huge gains in it.

[_TB_]

A question for you guys that have been tinkering with the files and/or datalogging.

The shiftmaps have Throttle% as input - and then columns for up changes and down changes. The output is output shaft speed. So far so good.

I have made some alterations to an alpina file - in order to lower the shiftpoints to better suit a diesel. This goes perfectly well - apart from 100% throttle. I did some TestO logging today, and i can the that OSS is well above the shiftpoints set in my file for the current gear (in all shiftmaps!) - but it does not change gears - just bounces of the limiter. Does anybody have any idea why it does not adhere to the shiftmaps @ 100% throttle? Everything below(~90%) is perfectly fine. 5th from 58km/h 4th from 39km/h and so on.

[Unklejoe]

Originally Posted by _TB_

This I can answer

The first thing you do in the app - before you're allowed to flash anything - is to make a full 1MB backup of your current TCU. This can be an Alpina, ori BMW or whatever.

This file you can edit - as long as you do not touch some areas of the file. (as far as i know you're not allowed to touch the program part of it, only calibrations part). That means you can alter your Alpina file - and then flash your modified alpina as a custom tune. This is what I have done right now for my 325d.

..But please be aware - the alpina file does have the same maps as a std. BMW file - but it uses them in a different manner. It is not a big issue, just takes quite some longer time to find out how it uses the maps. Also IMHO the Alpina file is pretty "advanced" already, it is hard to find huge gains in it.

Nice. That's what I wanted to hear. Literally all I want is the regular Alpina B3 calibration but with higher shift points in "D". It normally shifts at around 1800 RPM, and that's too low for the gasoline engines.

Are you developing/using an XDF file for the Alpina B3 firmware? Do you plan to continue using the Alpina B3 as your "base"? Or do you plan to switch to a regular BMW firmware due to the difficulty in figuring out how the Alpina B3 firmware uses its maps?

[_TB_]

Originally Posted by Unklejoe

Nice. That's what I wanted to hear. Literally all I want is the regular Alpina B3 calibration but with higher shift points in "D". It normally shifts at around 1800 RPM, and that's too low for the gasoline engines.

Are you developing/using an XDF file for the Alpina B3 firmware?

I'm not the mastermind behind the XDF - I'm merely trying to get an understanding of how it all works together.

What you would like to achieve should be quite easy to accomplish.

[Unklejoe]

Also, is there an easy way to run Android on a Linux/Windows PC so that I don't have to buy a phone just for this?

I know there are a few Android emulators out there (and the Android-x86 project), but I'm curious if this will work under that environment.

[_TB_]

Originally Posted by Unklejoe

Also, is there an easy way to run Android on a Linux/Windows PC so that I don't have to buy a phone just for this?

I know there are a few Android emulators out there (and the Android-x86 project), but I'm curious if this will work under that environment.

I'm running Android x86 (The CM13 variant) - and the latest version of the tool seems to support it fully.

[Unklejoe]

Originally Posted by _TB_

I'm running Android x86 (The CM13 variant) - and the latest version of the tool seems to support it fully.

Thanks!

[RBT-Tuning]

Originally Posted by Unklejoe

I have a few questions regarding how this tool will work once it's released.

For the OTS maps, are there separate versions of each OTS map based on every possible stock software revision, or are the OTS maps based on a common revision which would get flashed to every car regardless of its original stock software revision?

If there are separate OTS map versions, does this tool automatically read the UIF to determine the current software version, then use that to choose the appropriate version of the desired OTS map? I ask because my UIF doesn't necessarily reflect what's actually on the TCU.

My last question is regarding the custom flashing capabilities.

My N55 car currently has the Alpina B3 flash. Will this tool be able to read that image out and reflash a modified version if it (assuming I made the modifications myself, of course)? Or are there limitations on which factory software revisions can be customized/cksum corrected/etc?

The base file get's chosen based on your Vehicle VIN and yes, it is not a "one fits all" approach. Different cars, get different base files. It's a lot of work, but the only way to avoid problems. Anyone remember the problems some N55 have with the Alpina flash?

[_TB_]

If I would like to log shift times with TestO - what do I need to log then?