Pages: [1] 2
Author Topic: Simos12 info  (Read 12638 times)
Wommesz
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 12


« on: December 13, 2020, 12:52:38 AM »

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

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.

Logged
gremlin
Hero Member
*****

Karma: +179/-7
Offline Offline

Posts: 568


« Reply #1 on: December 13, 2020, 04:07:15 AM »

so I assume the AES keys are different for Simos12.
Or maybe it uses a different decompression altogether.

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.
« Last Edit: December 13, 2020, 04:11:36 AM by gremlin » Logged
Wommesz
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 12


« Reply #2 on: December 14, 2020, 09:43:03 AM »

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?

Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #3 on: December 14, 2020, 10:42:55 AM »

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.
« Last Edit: December 14, 2020, 01:19:16 PM by d3irb » Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #4 on: December 14, 2020, 10:44:09 AM »

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

Karma: +2/-0
Offline Offline

Posts: 12


« Reply #5 on: December 15, 2020, 01:37:54 PM »

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.

Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #6 on: December 15, 2020, 04:46:07 PM »

"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.
Logged
Wommesz
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 12


« Reply #7 on: December 16, 2020, 01:02:01 PM »

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.
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #8 on: December 16, 2020, 03:23:21 PM »

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.
« Last Edit: December 16, 2020, 03:28:40 PM by d3irb » Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #9 on: December 16, 2020, 04:22:02 PM »

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...
« Last Edit: December 17, 2020, 12:11:38 PM by d3irb » Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5790


« Reply #10 on: December 17, 2020, 02:27:47 AM »

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...
Logged

PM's will not be answered, so don't even try.
Log your car properly.
Wommesz
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 12


« Reply #11 on: December 17, 2020, 04:34:45 AM »

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!
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #12 on: December 17, 2020, 12:34:33 PM »

| DecryptFirmware    | 8002acec | 8002f79c |

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.
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #13 on: December 17, 2020, 12:37:42 PM »

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

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 Tongue
Logged
IamwhoIam
Hero Member
*****

Karma: +43/-99
Online Online

Posts: 1030


« Reply #14 on: December 18, 2020, 02:45:17 AM »

A TC1797 has PMEM0 and PMEM1 too Smiley it's just NOT a TC1791
Logged

I have no logs because I have a boost gauge (makes things easier)
Pages: [1] 2
  Print  
 
Jump to:  

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