Pages: 1 [2]
Author Topic: Simos 18 MK7 GTI Tuning  (Read 26680 times)
Praga
Full Member
***

Karma: +4/-3
Offline Offline

Posts: 62


« Reply #15 on: July 17, 2018, 10:52:56 PM »

PRJ is correct. They are the inverse maps for the torque control. They become limits as well and as its a main torque based ecu for driver request they are pretty important..

Thank you guys. Anyone swapped Boost Control for Race Start map on a GTi with one from a GTI R ?
Logged
NBR
Full Member
***

Karma: +20/-7
Offline Offline

Posts: 79


« Reply #16 on: July 18, 2018, 03:42:24 AM »

I think it's a good idea to start discussing this ECU. From what I understand, the "Maximum Torque at Clutch" maps are the input to the "Mass air flow setpoint" table (Someone correct me if I'm wrong). And then the "Pressure up throttle setpoint" is a sort of target boost pressure map which you can use to limit your max requested boost.

As for changing the boost pressure factor for race start on the GTi, I don't think it has an effect like the Golf R. There must be some config to get the launch control to build boost like the R?

Also, who here has gone through the FR and made any sense of it? The Bosch ones make sense to me, this Simos one I'm struggling to follow and it's in English  Huh

Here is a link to the FR that I have for anyone interested
https://mega.nz/#!12ACHK5a!hDqeuduZUD2a2VfDle9jzqP9Lb_b3tq6tNPXsPo1tLI
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #17 on: February 16, 2019, 12:54:32 PM »

I know this is a bit of a bump but want to revive this subject with some new information and I figured the existing thread was a good place.

If you want reads for this file you can decrypt from the flashdata like so:

1) Use available FRF reader tool to extract the FRF container (there's one that just calls the routines in the ODIS DLLs, it is usually found in a package called "VAG SGO FRF TOOLS", or if you have your own, I was too lazy to write one).

2) Now you have the XML formatted ODX file which contains the flash payload. I hope you can read well enough to understand the XML file.

3) The flash is structured as 5 blocks. The last block contains the calibration maps and begins with the identifier for the calibration. I have not fully reversed the firmware beyond the flash routines yet so I don't know too much about it beyond using the standard issue leaked DAMOS/OLS files to tune. Eventually I would like to write a map identifier so people do not need to rely on the DAMOS/OLS floating around. Hopefully this can help someone else get started though.

4) The flash payloads are encrypted. They are encrypted using AES128 with a fixed key and IV. I found the key and IV in an already decrypted flash payload and it seems to work for any SIMOS18 I have found so far. Decrypt that.

5) The flash payloads are compressed prior to encryption. They are compressed using a semi-standard LZ77-based algorithm called LZSS. I believe the dictionary size is 1024 and the window size is 64 but these are only necessary to know to write a compressor, not a decompressor. I used a standard decompressor I found for Nintendo files on GitHub here: https://github.com/magical/nlzss and modified it a bit to match the algorithm used in the files.

Please find attached a piece of very hacky Python3 code which will take an ODX file and produce the 5 blocks and a BIN. The block sizes are variable and I am not sure how most commercial software handles this as I do not have access to enough commercial virtual reads / ORIs to find out, so the BINfiles are not guaranteed to match whatever format your software uses (I think some software may pad them? Not sure...)

That's about it for now! I am working on figuring out the SecurityAccess seed/key algorithm and making my compressor output match the compressed files and then I may try for a flasher. After that I will need to figure out the protections in the firmware itself as there are some checksums and I think some sort of cryptographic signature also.
Logged
nihalot
Full Member
***

Karma: +40/-3
Offline Offline

Posts: 116


« Reply #18 on: March 10, 2019, 07:54:09 AM »


4) The flash payloads are encrypted. They are encrypted using AES128 with a fixed key and IV. I found the key and IV in an already decrypted flash payload and it seems to work for any SIMOS18 I have found so far. Decrypt that.

Great post, thanks for sharing!
BTW, how did you determine the Key/IV? I'm presently disassembling a Simos18.1, I've found the keys you've used for decrypting, in my bin, but can't find any code Xrefs to them in IDA. I'm interested in reversing the bootloader too.
Would appreciate any input

Thanks
Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
eazydaz
Full Member
***

Karma: +1/-1
Offline Offline

Posts: 184


« Reply #19 on: June 29, 2019, 08:07:38 AM »

pls someone can tell me how can I make "farts" while shifting more louder?

and which map is for exhaust flaps (for race mode)? it is this map "Map for exhaust flap setpoint in case of activation via DRIV_MOD" ?

I need make it a little bit louder, car is golf mk7.5 R
Logged
eazydaz
Full Member
***

Karma: +1/-1
Offline Offline

Posts: 184


« Reply #20 on: July 08, 2019, 09:59:03 AM »

anyone can help me?
Logged
R32VAG
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 20


« Reply #21 on: September 30, 2019, 11:34:05 AM »

Any news about this?
Logged
starshy
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 4


« Reply #22 on: November 19, 2019, 10:01:42 AM »

I am wondering how did you find the key for SIMOS 18 ODX ?
Logged
dstar
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 7


« Reply #23 on: June 10, 2020, 05:55:38 AM »

Hello.

Can we revive this very interesting topic?

Does anyone knows if the Simos-18 approach described by d3irb can work for other Bosch AA-encrypted ECU models like edc17c74?

I didn't found  similar thread here for edc17c74? Please advice me where to search for the AES keys? I tried many times but failed to find such keys in c74 OTP sections area.

Thanks!
Logged
nihalot
Full Member
***

Karma: +40/-3
Offline Offline

Posts: 116


« Reply #24 on: August 19, 2020, 04:27:16 PM »

I know this is a bit of a bump but want to revive this subject with some new information and I figured the existing thread was a good place.

If you want reads for this file you can decrypt from the flashdata like so:

1) Use available FRF reader tool to extract the FRF container (there's one that just calls the routines in the ODIS DLLs, it is usually found in a package called "VAG SGO FRF TOOLS", or if you have your own, I was too lazy to write one).

2) Now you have the XML formatted ODX file which contains the flash payload. I hope you can read well enough to understand the XML file.

3) The flash is structured as 5 blocks. The last block contains the calibration maps and begins with the identifier for the calibration. I have not fully reversed the firmware beyond the flash routines yet so I don't know too much about it beyond using the standard issue leaked DAMOS/OLS files to tune. Eventually I would like to write a map identifier so people do not need to rely on the DAMOS/OLS floating around. Hopefully this can help someone else get started though.

4) The flash payloads are encrypted. They are encrypted using AES128 with a fixed key and IV. I found the key and IV in an already decrypted flash payload and it seems to work for any SIMOS18 I have found so far. Decrypt that.

5) The flash payloads are compressed prior to encryption. They are compressed using a semi-standard LZ77-based algorithm called LZSS. I believe the dictionary size is 1024 and the window size is 64 but these are only necessary to know to write a compressor, not a decompressor. I used a standard decompressor I found for Nintendo files on GitHub here: https://github.com/magical/nlzss and modified it a bit to match the algorithm used in the files.

Please find attached a piece of very hacky Python3 code which will take an ODX file and produce the 5 blocks and a BIN. The block sizes are variable and I am not sure how most commercial software handles this as I do not have access to enough commercial virtual reads / ORIs to find out, so the BINfiles are not guaranteed to match whatever format your software uses (I think some software may pad them? Not sure...)

That's about it for now! I am working on figuring out the SecurityAccess seed/key algorithm and making my compressor output match the compressed files and then I may try for a flasher. After that I will need to figure out the protections in the firmware itself as there are some checksums and I think some sort of cryptographic signature also.

5. I can confirm dictionary size 1024 and window size 64, wrote a compressor

Seedkey is SA2, same as all VAG ECUs. There are a few documents here explaining it.
Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #25 on: December 14, 2020, 01:26:21 PM »

Great post, thanks for sharing!
BTW, how did you determine the Key/IV? I'm presently disassembling a Simos18.1, I've found the keys you've used for decrypting, in my bin, but can't find any code Xrefs to them in IDA. I'm interested in reversing the bootloader too.
Would appreciate any input

Thanks

Hi, copying this from another thread - I plan to supply more information on this as part of a big write-up on Simos I have been working on.

SBOOT starts at 80000000 of course, but comes in two halves, the actual SBOOT and what I'll call the "OTP part". The "OTP part" of SBOOT starts at 80014000 and seems to be written in the end-of-line manufacturing of the ECU. It is flagged with OTP by Tricore, so it cannot be written ever again.

The OTP part of SBOOT starts with an export table at 80014000. References to anything in 80014000-80014090 from other parts of software are calling into the cryptography library in SBOOT. The export at 80014088 in Simos18 is essentially "AES_SetKeyMaterial" and thus by finding XRef to this export from CBOOT (the XRef will be in the UDS 0x34 RequestDownload handler itself in all cases I have seen), you can find the location of the TransferData AES keys in a flash dump.

The OTP part next has some blank space followed by the Tricore device identifier right at 80014200 (to marry the OTP with this specific ECU), followed by the Tricore flash memory unlocking passwords or "boot passwords" (specific to the device) at 8001420C.

After the passwords, there's a cryptography library containing CRC, AES, SHA256, and PKCS #1 RSA used to sign the SHA256, as well as the public key material used to verify the RSA signatures. The library starts off with obvious constants tables for CRC, AES, SHA256, and a PKCS#1-SHA256-RSA header which is injected into the RSA signature to pass into a standard PKCS verification library (I guess they thought storing the PKCS header in the flash would be too obvious).

As for the XRefs and why you were maybe not able to find them - when CBOOT is running, it's loaded into RAM so that it can write to PFLASH (Tricore flash controller can't read when it's in command/write mode). To correctly disassemble CBOOT in Simos you need to copy 0x162FF bytes from 80022000 to RAM at D0008000, and dissassemble in RAM. All of the absolute addressing tables like the CANbus message handlers are pointed into RAM, so if you just disassemble PFLASH you won't get the right Xrefs.
« Last Edit: December 18, 2020, 12:54:55 PM by d3irb » Logged
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #26 on: February 06, 2021, 04:48:56 AM »

Hi, copying this from another thread - I plan to supply more information on this as part of a big write-up on Simos I have been working on.

SBOOT starts at 80000000 of course, but comes in two halves, the actual SBOOT and what I'll call the "OTP part". The "OTP part" of SBOOT starts at 80014000 and seems to be written in the end-of-line manufacturing of the ECU. It is flagged with OTP by Tricore, so it cannot be written ever again.

The OTP part of SBOOT starts with an export table at 80014000. References to anything in 80014000-80014090 from other parts of software are calling into the cryptography library in SBOOT. The export at 80014088 in Simos18 is essentially "AES_SetKeyMaterial" and thus by finding XRef to this export from CBOOT (the XRef will be in the UDS 0x34 RequestDownload handler itself in all cases I have seen), you can find the location of the TransferData AES keys in a flash dump.

The OTP part next has some blank space followed by the Tricore device identifier right at 80014200 (to marry the OTP with this specific ECU), followed by the Tricore flash memory unlocking passwords or "boot passwords" (specific to the device) at 8001420C.

After the passwords, there's a cryptography library containing CRC, AES, SHA256, and PKCS #1 RSA used to sign the SHA256, as well as the public key material used to verify the RSA signatures. The library starts off with obvious constants tables for CRC, AES, SHA256, and a PKCS#1-SHA256-RSA header which is injected into the RSA signature to pass into a standard PKCS verification library (I guess they thought storing the PKCS header in the flash would be too obvious).

As for the XRefs and why you were maybe not able to find them - when CBOOT is running, it's loaded into RAM so that it can write to PFLASH (Tricore flash controller can't read when it's in command/write mode). To correctly disassemble CBOOT in Simos you need to copy 0x162FF bytes from 80022000 to RAM at D0008000, and dissassemble in RAM. All of the absolute addressing tables like the CANbus message handlers are pointed into RAM, so if you just disassemble PFLASH you won't get the right Xrefs.


Interesting, You are really dominant in Tricore.
I wish there was someone to help me. Sad
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.042 seconds with 17 queries. (Pretty URLs adds 0s, 0q)