[Mik325tds]

Originally Posted by HeatherM35d

I could hook you up.

Please do! The thing is, I can't promise that I won't brick it...
PM send.

[Mik325tds]

Originally Posted by 808AWD325xi

The Motorola Freescale MPC500 family has BDM/JTAG headers. You should be able to get a full dump on the bench.

The difficult thing is to get to it. If I remember right, Robert had to basically destroy the rest of the TCU in order to get to the Microcontroller pins. And it's on a ceramic substrate with all kinds of gel around it.
I was hoping to get a full dump through K-Line and then start writing single addresses with Ediabas and see if it still works afterwards.

[Mik325tds]

Originally Posted by ChrizLoud

What we want here is a modification to the program that would always prevent automatic up-shifts in manual M-mode. Just like an SMG, or a F-series car with sport-automatic in sport mode.

This can certainly be done by adjusting the shift points for DS mode to be above the rev limiter. But that would be a custom tune just for the drifters. Not all of us would want that all the time.
The options are limitless - once we get past the road block of getting a custom tune loaded to the TCU.

[808AWD325xi]

Originally Posted by Mik325tds

The difficult thing is to get to it. If I remember right, Robert had to basically destroy the rest of the TCU in order to get to the Microcontroller pins. And it's on a ceramic substrate with all kinds of gel around it.
I was hoping to get a full dump through K-Line and then start writing single addresses with Ediabas and see if it still works afterwards.

I wondered about the ceramic substrate being an inhibitor...

If the TCU has to be set to programming mode to write to a specific address, it will require authentication. I've tried to set it to that mode and was denied access.

[Mik325tds]

Originally Posted by 808AWD325xi

I wondered about the ceramic substrate being an inhibitor...

If the TCU has to be set to programming mode to write to a specific address, it will require authentication. I've tried to set it to that mode and was denied access.

Yes, I saw that a few posts back. There's a sequence to the authentication: Request seed, then do the key calculation and request authorization. I'll have to do some digging for the specifics of that sequence.
Did you do it through CAN or K-Line?

[ChrizLoud]

Originally Posted by Mik325tds

This can certainly be done by adjusting the shift points for DS mode to be above the rev limiter. But that would be a custom tune just for the drifters. Not all of us would want that all the time.
The options are limitless - once we get past the road block of getting a custom tune loaded to the TCU.

DS should be untouched and still have automatic shifts.

It's just in M-Mode (manual model) that we want to prevent the automatic up-shifts when redlining. (just like the BMW F-cars behaves as stock or the E-Series SMG-boxes)
I think most guys want it that way (even BMW them self) (manual should be "manual")

Or do you mean it's not possible to just alter the shift points in M-mode leaving DS-mode untouched?



ESS offers a transmission flash to the old good MS43 that gives us just want we want but nothing for our transmission.

"""Optimized steptronic transmission software, recommended for both for NA and Supercharged applications. Increases shift firmness under heavy acceleration and increases the transmissions capability to hold power during shifts. The software also converts the operation to work similar to SMG's, meaning it will not upshift in manual mode until you shift. Also increases the shift RPM point under automatic mode to 6600.
""" http://esstuning.com/ms43-steptronic...sion-software/

[Mik325tds]

Originally Posted by ChrizLoud

DS should be untouched and still have automatic shifts.

It's just in M-Mode (manual model) that we want to prevent the automatic up-shifts when redlining. (just like the BMW F-cars behaves as stock or the E-Series SMG-boxes)
I think most guys want it that way (even BMW them self) (manual should be "manual")

Or do you mean it's not possible to just alter the shift points in M-mode leaving DS-mode untouched?

Sorry, I wasn't clear enough. Yes, there is a different shift map for M-mode than for DS mode. We just have to find it.
...and solve the other challenge of downloading modified cals first.

[808AWD325xi]

Originally Posted by Mik325tds

Yes, I saw that a few posts back. There's a sequence to the authentication: Request seed, then do the key calculation and request authorization. I'll have to do some digging for the specifics of that sequence.
Did you do it through CAN or K-Line?

CAN.

[Mik325tds]

Originally Posted by 808AWD325xi

Thanks!

I used an early build SGBD to run the authentisierung_zufallszahl_lesen job, it returns the authentication random number and authentication type.

Satz : 1
  JOB_STATUS                      = OKAY
  ZUFALLSZAHL                     = 8 Bytes
    0000 : DC CB 00 00 5F DA FC FD                            ÜË.._Úüý  
  AUTHENTISIERUNG                 = Symetrisch
  _TEL_AUFTRAG                    = 10 Bytes
    0000 : 87 18 F1 31 07 03 00 00   00 00                    ?.ñ1....  ..
  _TEL_ANTWORT                    = 14 Bytes
    0000 : 8A F1 18 71 07 DC CB 00   00 5F DA FC FD E4        ?ñ.q.ÜË.  ._Úüýä

I reran the job today using the SGBD from the SP Daten and it returns an Asymmetric authentication type. Which means that the TCU more closely aligns with the Full EVITA HSM variant.

I don't think the authentication used for programming on the E90 is based on the EVITA project. The used Seed-Key (also challenge-response) method is based on SAE J2186 or ISO15031-7.
The EVITA project started in 2009 and ended in 2011 (see attached presentation). The E90 (PL2) was developed between 2003-2006.
The HSM (Hardware security module) and SHE (Secure hardware extension) is a piece of HW that can do encryption routines much faster then per SW, so it could potentially be used to authenticate messages on the CAN bus. SHE-compliant processors are just hitting the market.

However, I think you're on the right path. In order to use the Ediabas jobs "speicher_lesen" und "speicher_schreiben" we most likely need to authenticate ourselves for Flash programming which is Level 03.
There are a total of 3 levels (3,5,7) which each have their own authentication key.
The first step is to request the "challenge" or "seed" which is a random number generated by the TCU. The Service ID is $31 $07 and the level is 03. You can see that in the TEL line of the Ediabas screen shots. That is actually the raw data on the CAN bus if you log it.
The TCU answers with the random number or "seed". The "response" or "key" is then calculated by the tool using the "seed" the level and the crypto key for flash programming access.
The next step is to send the calculated key to the TCU. That is done via SID $31 $08 xx xx xx xx xx xx xx xx, where xx is the calculated key.
The ECU calculated the same key using the same function and if they match, you have flash programming access for the rest of the diagnostic session.

What I don't know is how to calculate the key and the crypto key for flash programming access.

[HeatherM35d]

Originally Posted by Mik325tds

Please do! The thing is, I can't promise that I won't brick it...
PM send.

Working on making time to pull the TCU out

[ChrizLoud]

Wow! Your knowledge is impressive and the time you guys put in this project is much appreciated. Keep up the good work.

[808AWD325xi]

Originally Posted by Mik325tds

I don't think the authentication used for programming on the E90 is based on the EVITA project. The used Seed-Key (also challenge-response) method is based on SAE J2186 or ISO15031-7.
The EVITA project started in 2009 and ended in 2011 (see attached presentation). The E90 (PL2) was developed between 2003-2006.

I should have been clearer, my apologies for any confusion. I wasn't trying to state that the TCU security architecture was based on the EVITA project, but merely that I had verified functional attributes that aligned with the EVITA HSM specifications. There have been a myriad of projects over the years aimed at defining open software and hardware architectures.

Originally Posted by Mik325tds

The HSM (Hardware security module) and SHE (Secure hardware extension) is a piece of HW that can do encryption routines much faster then per SW, so it could potentially be used to authenticate messages on the CAN bus. SHE-compliant processors are just hitting the market.

Actually, SHE-compliant processors have been shipping for years. Key features of the SHE specification include

• A secure storage for crypto keys
• Crypto algorithm acceleration (AES-128)
• Secure Boot mechanism to verify custom firmware after reset
• Offers 19 security specific functions
• Up to 10 general and 5 special purpose crypto keys

The Freescale Qorivva MPC564x was the first to ship with a Cryptographic Services Engine (CSE) module that fully implements the official HIS SHE-specification.

Originally Posted by Mik325tds

However, I think you're on the right path. In order to use the Ediabas jobs "speicher_lesen" und "speicher_schreiben" we most likely need to authenticate ourselves for Flash programming which is Level 03.
There are a total of 3 levels (3,5,7) which each have their own authentication key.
The first step is to request the "challenge" or "seed" which is a random number generated by the TCU. The Service ID is $31 $07 and the level is 03. You can see that in the TEL line of the Ediabas screen shots. That is actually the raw data on the CAN bus if you log it.
The TCU answers with the random number or "seed". The "response" or "key" is then calculated by the tool using the "seed" the level and the crypto key for flash programming access.
The next step is to send the calculated key to the TCU. That is done via SID $31 $08 xx xx xx xx xx xx xx xx, where xx is the calculated key.
The ECU calculated the same key using the same function and if they match, you have flash programming access for the rest of the diagnostic session.

What I don't know is how to calculate the key and the crypto key for flash programming access.

To the best of my knowledge, E90 modules implement (4) levels of authentication (with the exception of the DME/DDE and CCC/CIC.) None, Simple, Symmetric, and Asymmetric:

		<RESULT>
			<RESULTNAME>AUTHENTISIERUNG</RESULTNAME>
			<RESULTTYPE>string</RESULTTYPE>
			<RESULTCOMMENT>Authentisierungsart</RESULTCOMMENT>
			<RESULTCOMMENT>&apos;Keine&apos;        Keine Authentisierung</RESULTCOMMENT>
			<RESULTCOMMENT>&apos;Simple&apos;       Einfache Authentisierung</RESULTCOMMENT>
			<RESULTCOMMENT>&apos;Symetrisch&apos;   Symetrische Authentisierung</RESULTCOMMENT>
			<RESULTCOMMENT>&apos;Asymetrisch&apos;  Asymetrische Authentisierung</RESULTCOMMENT>
		</RESULT>

I verified that the gs19.11 TCU responds to level 3 and level 4 authentication requests.

I discovered yesterday that in the default and development diagnostic modes, the TCU does not appear to return valid data to the speicher_lesen job. Depending upon the segment being read, it always returned zeroes or a repeating pattern.

My guess is that we need to authenticate and be in programming mode for the speicher jobs to function properly.

[dave205t]

Hi Guys,

After being asked by 808AWD325xi on m5board, i offered to take a look at getting some insight on the checksum and rsa algorithm (already solved those before for some other ecu's) inside the stock TCU, do you have a full dump and processor used ? If someone has a before and after (tuned or modified) file with corrected checksums/rsa that will make it a bit easier.

I have also solved the seed/key for mss60/mss65 (and wrote a program to both and read and write those), solving this for TCU should be a similar task.

Best regards, Dave

[808AWD325xi]

Originally Posted by dave205t

Hi Guys,

After being asked by 808AWD325xi on m5board, i offered to take a look at getting some insight on the checksum and rsa algorithm (already solved those before for some other ecu's) inside the stock TCU, do you have a full dump and processor used ? If someone has a before and after (tuned or modified) file with corrected checksums/rsa that will make it a bit easier.

I have also solved the seed/key for mss60/mss65 (and wrote a program to both and read and write those), solving this for TCU should be a similar task.

Best regards, Dave

Thank you for coming over Dave !! Greatly appreciated !!

I'll take the first crack at summarizing where we are to date...

We believe that the processor is likely a Freescale MPC562, but to the best of my knowledge that hasn't been confirmed to date as nobody has gained physical access to a ZF gs19.11 TCU. The TCU is attached to the hydraulic control unit inside the automatic transmission, together they are referred to as the mechatronic. The mechatronic is constructed from substrate base on ceramic, further inhibiting JTAG/BDM access:
http://www.e90post.com/forums/showpo...&postcount=596

While the gs19.11 was being developed with ZF, BMW was also working with GM to develop the gs19.12. BMW specified the MPC562 or similar for the gs19.12:


Hopefully Mik325tds will have his hands on a TCU soon.

The MCP561/562/563/564 reference manual can be found here:
http://www.mouser.com/ds/2/161/MPC561RM-254522.pdf

The best dump we have is from rjahl, it was taken with BMW scanner. He has a 2007 E85 Z4 3.0I with a ZF 6HP19 transmission:
http://www.e90post.com/forums/showpo...&postcount=474

RayBan81 found the RSA signatures in the 0pa and 0da files:
http://www.e90post.com/forums/showpo...&postcount=544

On a related note, since you were able to crack the MSS60/MSS65, are you able to decipher these level 3 keys?

$K MSS60               JZ12AB0133c14b65e002d05b2db2f592e9ff372dd08e8147835f043c821d96b7e88bfec2289c4dd885033bc8b62f844c11d652b57b4d48dc4891a02816bd711f6b333b451f8f5c5f2a1ad07e6b29c9ee6212795b2b83d6e8aa899a4e41c986a1efd9da6b0efbbf0f39068c1124cff4a8aef5a95b7c812cee36b956960dd4f7a31df280da618fc82f34e14b1294
$K MSS65               JY12AB0069c8b6e63e9fb51da5158aa1d8dbfa7f5c08134ca1610d239ece79ee3e79ad1678667fc6d873b3675a22ac936125b69af1cb33598e02b0e92af91fd77697f0e8bfd5ae3ae8b98b8122446ed6330a455d62d91fb377a40c6f921862d4096ea0cf32e9a7137a9386bef32133abed4496f61e32699487e07192430695fc9866ff689d356338c2b13719d8

The reason that I ask, is because the TCU keys appear to be very similar:

$K GKE193              QM18AB0042e0996cfb58169373bb4b5ba8c5e1d604bdc15ed637066eff1d99411c09f15e6b420b7e0bc507065763ae2d7914103180968c768ce0ecadb896f0f46097d02870447db61199950dce5c314aec41e82130ffde43d68b03ad879d5727a0ec7443d37a3d18a6624e66ca3ab610cc3c56e06467e2a101e3e7557f06b25a5c2b3226952579d640d859e95a
$K GKE194              2P18AA018619533a9e40f48bb59f112684b33bf8b3916bcf053e7760c037102d8b568ca001e9ebf316bc9f71c28090722097a19b4a5eec3b51f8a42345661a458163aa5b2a8e206908bd2ea165d72202b833c05973d1b31a90f9fc94616b5126c817b496ef55b693e428e35e805a5a01df40dc28b950567a7487659d68ec7bec04f641ab52fdf4812433be30f7
$K GKE195              SL18AB0118A1AAD9A4D72F4811B9AAF2C4C7A4A61865AE857BCF204164C55FA9D8397071BB5008375325AB74B2BA4C06A945EE4D3D945C8A7E03FC172F10D75B5D3AEFCF084A7D453E5F4A1A308BD5765C4377F102AF8AEBEFFBAC609086C7378FB13317CB7995255C3A8D0A0A326322BADF89349A96C8D7AADD8CEE7C520098DA5AB1D80DEA396BDF11BE8AA3
$K GKE211              MH18AB0042e0996cfb58169373bb4b5ba8c5e1d604bdc15ed637066eff1d99411c09f15e6b420b7e0bc507065763ae2d7914103180968c768ce0ecadb896f0f46097d02870447db61199950dce5c314aec41e82130ffde43d68b03ad879d5727a0ec7443d37a3d18a6624e66ca3ab610cc3c56e06467e2a101e3e7557f06b25a5c2b3226952579d640d859e95a
$K GKE213              QN18AB0042e0996cfb58169373bb4b5ba8c5e1d604bdc15ed637066eff1d99411c09f15e6b420b7e0bc507065763ae2d7914103180968c768ce0ecadb896f0f46097d02870447db61199950dce5c314aec41e82130ffde43d68b03ad879d5727a0ec7443d37a3d18a6624e66ca3ab610cc3c56e06467e2a101e3e7557f06b25a5c2b3226952579d640d859e95a
$K GKE214              2S18AA018619533a9e40f48bb59f112684b33bf8b3916bcf053e7760c037102d8b568ca001e9ebf316bc9f71c28090722097a19b4a5eec3b51f8a42345661a458163aa5b2a8e206908bd2ea165d72202b833c05973d1b31a90f9fc94616b5126c817b496ef55b693e428e35e805a5a01df40dc28b950567a7487659d68ec7bec04f641ab52fdf4812433be30f7
$K GKE215              SM18AB0118A1AAD9A4D72F4811B9AAF2C4C7A4A61865AE857BCF204164C55FA9D8397071BB5008375325AB74B2BA4C06A945EE4D3D945C8A7E03FC172F10D75B5D3AEFCF084A7D453E5F4A1A308BD5765C4377F102AF8AEBEFFBAC609086C7378FB13317CB7995255C3A8D0A0A326322BADF89349A96C8D7AADD8CEE7C520098DA5AB1D80DEA396BDF11BE8AA3
$K GKE233              QO18AB051763d9d09983cd598d722ae0dbe99164c718263ee98c8865a54f33eecb7b8aa2e66b1d0ac42a909d9dd09d6a2e4a7d2452e71d2baa166685319b95aa973da2b8abcbbe46173cbbeb8d7d6efd7987f2ecac29078a0246964331993168721e4620df0c4b8c27c9d0b21d3b74da935ceea6b64cb04a20a8aa1440abfb3959a22400cf2a87690c4aa2f7be
$K GM1912              NC18AB0097c44a9b11cdd35805e85c7fc595654d863813ab3ebcb9d7a3207635dba1ba0e65acc8e1652225fc8ee8452fdb6f790a2df6ccffec2b4f98a5d270dac1d9ad476d86847086d2cc196d89fcc8e56c21854207e75e083b63aa0531c1a6aac879274e1281af23225260bdd3a1a3c6d51d3e6a265b61b29cca1ac8dd73e742c9514f06b2b1488fd2ce3690

My assumption is that they are encrypted with AES-128, but I'm not positive.

On behalf of everyone, thanks again for your willingness to assist !!

[DWR]

Originally Posted by dave205t

Hi Guys,

After being asked by 808AWD325xi on m5board, i offered to take a look at getting some insight on the checksum and rsa algorithm (already solved those before for some other ecu's) inside the stock TCU, do you have a full dump and processor used ? If someone has a before and after (tuned or modified) file with corrected checksums/rsa that will make it a bit easier.

I have also solved the seed/key for mss60/mss65 (and wrote a program to both and read and write those), solving this for TCU should be a similar task.

Best regards, Dave

Welcome aboard Dave. We could use someone with your skills!

[dave205t]

Originally Posted by 808AWD325xi

Thank you for coming over Dave !! Greatly appreciated !!

No problem, it never hurts to help

Originally Posted by 808AWD325xi

We believe that the processor is likely a Freescale MPC562

Okay mpc562, ppc similar to the mcp563 (from mss60/mss65 i worked on last).

Originally Posted by 808AWD325xi

The best dump we have is from rjahl, it was taken with BMW scanner. He has a 2007 E85 Z4 3.0I with a ZF 6HP19 transmission:
http://www.e90post.com/forums/showpo...&postcount=474

I'll take a look at the dump and investigate a bit. After a quick first look i think this dump is missing some code, could someone upload the 0da and 0pa matching this bin somewhere and post a link below so i can download everything from one place (which is known to belong together), thanks!

Originally Posted by 808AWD325xi

On a related note, since you were able to crack the MSS60/MSS65, are you able to decipher these level 3 keys?

Yes, i am able to decipher these keys.

Originally Posted by 808AWD325xi

My assumption is that they are encrypted with AES-128, but I'm not positive.

They are triple DES encrypted.

Best regards, Dave

[iaknown]

Originally Posted by dave205t

Hi Guys,

After being asked by 808AWD325xi on m5board, i offered to take a look at getting some insight on the checksum and rsa algorithm (already solved those before for some other ecu's) inside the stock TCU, do you have a full dump and processor used ? If someone has a before and after (tuned or modified) file with corrected checksums/rsa that will make it a bit easier.

I have also solved the seed/key for mss60/mss65 (and wrote a program to both and read and write those), solving this for TCU should be a similar task.

Best regards, Dave

Looking forward to not understanding more of what you guys are doing Dave

But seriously, thanks for coming over!

[rjahl]

Dave,

Great to have you looking into this.

Please let me know if I can help. Not sure how I can get you a copy of the matching ODA and OPA files. The forum does not allow uploads of this size. I can zip into multiple parts like a did before but I don't won't to duplicate efforts by others.

[Mik325tds]

Dave, great to have you on this thread. Much appreciated.
To my knowledge the RSA digitial signature of .oda files with asynchronous keys has not yet been cracked. You sure would be the master of the day if you can!
However, we might not need to if we find a smart way around it. If the TCU doesn't know that something has changed and isn't triggered to recalculate the hash we might be golden.
So I think what we are currently after is to get ourselves authorized for level $03 flash access and write some data to flash without using WinKfp. If you can help with that, it would be a big help!

[Works]

Originally Posted by rjahl

Not sure how I can get you a copy of the matching ODA and OPA files. The forum does not allow uploads of this size. I can zip into multiple parts like a did before but I don't won't to duplicate efforts by others.

Howabout you make a free dropbox account and upload them there and just share the link? How large files are we talking about here?

[RBT-Tuning]

Originally Posted by Mik325tds

Dave, great to have you on this thread. Much appreciated.
To my knowledge the RSA digitial signature of .oda files with asynchronous keys has not yet been cracked. You sure would be the master of the day if you can!
However, we might not need to if we find a smart way around it. If the TCU doesn't know that something has changed and isn't triggered to recalculate the hash we might be golden.
So I think what we are currently after is to get ourselves authorized for level $03 flash access and write some data to flash without using WinKfp. If you can help with that, it would be a big help!

Actually, based on what I've learned from looking at the *.ips files and the code of WinkFP I don't think that's a possible way. The ECU itself sets it's state to "Signature not checked" after ANY write to the flash. (not the EEPROM) You cannot skip or avoid this procedure from outside.

[RBT-Tuning]

@Dave: Thanks a lot for helping us out! Do you really need 2 bins (stock/tuned) or would some similar opa/oda files also help out? A7591972.opa and A7591971.opa differ only a few bytes. (GS19.11 program) The same is true for A7609647.0da and A7610591.0da. (data file 204hp diesel vs. 245hp diesel)

I attached all the files...rename to rar for extracting