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

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.

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

Any news about this?

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!

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.