NefMoto

Is there anything known on decryption of Simos12 ecus?
I'm trying to decrypt an .frf for the VAG 8K0906264B ecu. The extracted .ODX looks fine.

I've followed the steps for Simos18:
http://nefariousmotorsports.com/forum/index.php?topic=10364.msg122889#msg122889 (http://nefariousmotorsports.com/forum/index.php?topic=10364.msg122889#msg122889)

The LZSS decompression stumbles on the data, so I assume the AES keys are different for Simos12.
Or maybe it uses a different decompression altogether.

Any hints or points are appreciated.

All Simos versions dervatives (12.x/14.x/16.x/18.x etc) use different AES key/iv pairs.
Even subversions (for example 12.1, 12.2, 12.9) use various encrypt keys.      
Compress/decompres algo is the same in all cases.

Decrypt example for your frf in attach.

Oh, sweet!

Do you happen to more information on this ECU that you're willing to share?
Is there anything known about where what mappings are located?
I suppose there's a checksum somewhere, is there anything known about that?

Looks a lot like Simos18.

There is a CRC checksum block at 0x300 in CBOOT/ASW1/CAL (block0/block1/block4) and 0x0 in ASW2/ASW3 (block2/block3).

The checksum looks like: 4 bytes of checksum data, 1 byte telling how many regions were summed, and then n 4-byte region_start:region_end specifiers for the region that is checksummed.

Checksum tool here: https://github.com/bri3d/VW_Flash/blob/master/checksumsimos18.py

Please note that these CRC regions for CBOOT are hardcoded in SBOOT - that is, even if you get clever and alter the region specifiers in the checksum header, the same areas in CBOOT are still checksummed. There is no reason to do this anyway as the correct checksum is trivial to calculate (see tool above).

Then there is an RSA signed SHA256 hash at the end of each block. This is not altered but is instead bypassed in all tools I am aware of by turning RSA off. This is done by patching a development mode ECU check. Unlike ME7 or older ECUs with RSA, the public keys are in OTP and can't be overwritten, so it's easier to turn it off than to try to do it "right" like ME7Sum does for ME7.

Maybe my Simos18 documentation can help you: https://github.com/bri3d/VW_Flash/blob/master/docs.md .

I am working on a write-up targeted at this forum and audience to be released soon, along with some more detail about SBOOT and how to find the AES keys.

I will quickly drop some hints here, sorry if they are scattered as I am in a bit of a rush:

SBOOT 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 TransferData 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).

I am assuming Simos12 is the same based on what I have seen in your files so far, maybe I am wrong, but I hope this helps.

Oh, and as for calibration maps, they are all in "block_4" in the dump you were provided. This is the "Calibration" block.

Oh, that's an amazing amount of work, thanks!

Both in the 8R2907115C (Simos 18) and 8K0906264B (Simos 12.1) I can only find external function calls to
d000a0a4 .. d001b034 and d001ed80, with base address of the 1st out of 5 data chunks set to 0x8001C000.
I'm new to Ghidra, so I might just be pushing wrong buttons. I'll post an update here if I'm getting further.

"External function calls" in Ghidra will only mark things that are outside of the memory map. The stock Tricore memory map in Ghidra, however, will include all of PMEM, thus, the function calls you are seeking are internal. What you want to do in Ghidra is probably use Navigate -> Go To, go to the address to be inspected, and then see if any XRefs to it are defined. In the case of finding out how the AES keys work, I believe that you additionally need to load CBOOT into RAM to make everything resolve correctly. To do this you need to copy 162FF bytes from 80022000 -> D0008000 to reflect the way CBOOT is loaded into RAM during the UDS Programming session. You can accomplish this using the Memory Map tool in Ghidra. Furthermore, Ghidra doesn't know how to follow the CAN table in order to mark functions as code, so you need to use the Aggressive Instruction Finder or locate the CAN table and define each reference from it as code.

I know that's a lot - there's a lot to learn here, hopefully this can set you down the path.

Ah, after setting up the memory maps as you described (including one for the SBOOT area),
I indeed found the expected key/iv as input arguments for the AES call on the Simos18 dump I have (FL_8R2907115C).

On the Simos18 file, the first 4 bytes of CBOOT (80 01 CA E8) are a jump to a function.
On the FL_8K0906264B, the first 4 bytes (80 03 0d 60) seems to jump to an empty area.
Should I consider that the memory map for the Simos12 file is different?

The CBOOT code copied to the d0008000 region has references to d0004000, that also doesn't seem quite right.

I'll fiddle with things, see if I can make sense of it.

By looking at the offsets in the checksum block, we can indeed find that the load areas for Simos12 are a bit different. It looks as though Simos12 only utilizes the first flash area on the processor, so CAL is just after CBOOT rather than in the second Program Flash area before ASW3 as it is on S18:

CBOOT: 0x80020000
ASW1: 0x800C0000
ASW2: 0x80180000
ASW3: 0x80240000
CAL: 0xA0040000

Presumably the CBOOT->RAM area will be mapped differently too, you'll have to find the function that copies it to determine where it lives.

Spent a few minutes with your file. The CAN handlers in S12 aren't xreferenced to RAM the way they are in S18 but rather into PMEM, it looks like CBOOT works a little differently in S12.

Furthermore the AES is done right there in CBOOT, not in an library in OTP.

Anyway I think I have found the AES keys at 80030027, the 0x34 RequestDownload handler can be found in the CAN table at 8002f9dc, and the handler itself is at 8002acec.

IV: 30 6e 37 42 6b 6b 53 6f 31 6d 4a 69 74 36 6d 34
Key: 31 4d 75 36 41 6e 30 47 39 6a 41 32 52 35 6f 45

I don't have an encrypted ODX for this ECU handy to verify, so if you could check by modifying my script that would be amazing. I may have inadvertently switched the key and IV also...

You guys are missing the blatantly obvious fact that Simos12 uses a different processor, also with a lightly older instruction set without the 1.6 extensions and there is no 4mb gap either...

You just beat me to it, you have the right addresses.
What I have so far:

| Description | Simos 12 | Simos 18 |
|---------|----------|----------|
| CBOOT   | 80020000 | 8001c000 |
| DecryptFirmware    | 8002acec | 8002f79c |
| CallAesSetKey | 8002c654 | 80030cb2|
| AES Key | 80030037 | d00080c0 |
| AES IV  | 80030027 | d00080b0 |

With this, I can decrypt FL_8K0906264B__0003.frf successfully.
Thanks a lot for all the help!

It's worth renaming this to what it is - UDS_34_RequestDownload. You can find it cross-referenced directly in S12 or in the loaded RAM overlay in S18 from the CAN handler table. If you define out the rest of the table (the structure is painfully obvious), CBOOT will start to look a lot easier to disassemble and follow!

Reading the MultiCAN documentation, specifically the CAN Message structure for Tricore, will let you quickly define most of the referenced functions for getting various properties out of the CAN messages, and then it becomes pretty simple to see what's going on.

These tables are also, of course, very easy to patch to add in or alter your own UDS functions for fun and profit.

I addressed the so-called "4MB gap" (aka the reserved area between PMEM0 and PMEM1) already: "It looks as though Simos12 only utilizes the first flash area on the processor"

Thanks for the pointer though, the processor not having a PMEM1 to start with does help to explain why it is not used :P

A TC1797 has PMEM0 and PMEM1 too :) it's just NOT a TC1791

Okay, okay, I read the docs, which is more than I ever intended to do with Simos12... I see now, the two PMEMs in TC1797 are contiguous instead of separated, now next time I get challenged to a round of Tricore Trivia I won't lose.

LOL :)

There's definitely a lot to learn for me on these ecu's, thank for the help d3irb.

Being a bit curious: There should also be cars out there with Simos10, FL_03F906070GN_4046 for example.
Do you happen to have an unencrypted version of that one as well?

Getting the key/iv for that one seems like a good practice for me.

It's Simos10.24
FRF isn't AES crypted and use another methode.
Here is decrypted CAL block example.

Ah, interesting.

The decrypted data is all zeros at the end. The encrypted data repeats every 256 bytes at the end.
Maybe encryption is a 256-byte xor key?

Some file sizes:
encrypted/compressed: 90761
unencrypted: 245760
LZSS compression: 86208
Zip : ~56kb
RLE: 186840

The LZSS (https://github.com/bri3d/VW_Flash/tree/master/lzss (https://github.com/bri3d/VW_Flash/tree/master/lzss)) pattern of 0-data repeats every 17 bytes, so that doesn't fit the repetition pattern of the encrypted data very well.
So compression seems to be something in spirit of LZSS, but with slightly worse compression ratio.

I was trying to guess the first part of the key by guessing the first part of the compressed data. Then applying
that to the 0-encrypted data to get to a repetitive pattern, but that went nowhere.

I'll keep you guys posted. Not that I think that I'm telling you something new, but then at least you know that you gave someone a good puzzle to solve.

Boom :)

Usually when you see 256-byte repeating XOR like this, the XOR key is some permutation of a byte counter. I believe this could be the case for this file too, although I don't have any originals handy to try on. Try something simple like (psuedo code of course):

There are fully unpacked S12 dumps available. Why not dump the routine?
Ghidra will probably make short work of it.

Great thread, don't want to hijack it too much but I'm also playing with another older Simos ecu, Simos 8.4/8.5 in my case. Because of this thread and http://nefariousmotorsports.com/forum/index.php?topic=10364.0, I was able to identify start addresses and checksum locations in cboot, asw and cal (only one asw section there) as well as identify references to maps in cal. I'm trying to dig into this further and reverse the part of the cboot which gets copied into RAM, however I'm having trouble with this. FR says this cboot part is getting copied to 0xd4000000 and presumably it should be 0xbfff bytes:
However, I can't find anything which copies 0xbfff bytes to 0xd4000000.
Wonder if it's more obvious to somebody else.
CBOOT starts at 80020000, asw is at 80080000 and cal is at a0040000
P.S. odx payload is not compressed and can be "decrypted" as shown in one of the posts above, i.e., it's xor'ed.

HI all , this is my first post, i followed this thread and Bri3d project for a while now, I've been working on the Simos12 patch for the last 6 month , but unfortunately I can now tell for certain that is not possible flashing it using the exploid used in simos 18 ecu (write without erase). With VW_Flash for simos 12 from now you can flash only signed ori files but ... IF you have the possibility to Full bench write your ecu once you can flash my patched CBOOT and then you can use VW_flash like for simos 18 because the car will validate all blocks.

Hi there! Is there any updates on this? I've seen your github, I'm in the same situation, I could help.

Take a commercial tool and sniff. All of them can portflash S12.

I have kess v2 but I’m a supporter of open source so I’d like to help with anything:)