NefMoto

I figured been working on alot these bad boys lately . Trying to gather as much input as I could to have a starting point for someone.

Attached is a Virtual read via CMD OBD.

Check out this map:

okay I saw tons of maps like these in the ford sti, which is also med17. What does this stand for?

I didn't see this attachment.

== much fun lol

somethings up with nef prolly has to do with the file being 8mb

Those virtual reads contain personal info from your lappy

Tuning these are easy compared to Bosh lol plenty of FR's flying around too :) and English.

frf are also available from flashdata cd, if anyone knows to extract. im not that smart. i was only able to extract uncompressed/unencrypted aisin files. :-\

FRF encyption is not Bosch either for these obviously.

I was difficult to decrypt mine for the B8 S4.  Algo's in bosch are changing too lol

Then you need to decypt the container within, they make it difficult lol

Just zip/rar it

Here's something  horded, just data area

Hello Guys

Anyone still interested in pursuing this topic ?

what do you need to know?

What does the Mass air flow setpoint for torque intervention, valve lift and CAMs - selective for high port flaps position map control ?

And the Reference indicated engine torque ,valve lift, and CAM´s - selective for high port flaps position ?

Seems like they related ?

Like KFMIRL & KMIOP ?

The latter analogy is quite good.

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 ?

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  ???

Here is a link to the FR that I have for anyone interested
https://mega.nz/#!12ACHK5a!hDqeuduZUD2a2VfDle9jzqP9Lb_b3tq6tNPXsPo1tLI (https://mega.nz/#!12ACHK5a!hDqeuduZUD2a2VfDle9jzqP9Lb_b3tq6tNPXsPo1tLI)

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.

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

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

anyone can help me?

Any news about this?

I am wondering how did you find the key for SIMOS 18 ODX ?

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!

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.

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. :(