Pages: [1] 2
Author Topic: FRF to Bin to FRF SIMOS18  (Read 9814 times)
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« on: July 09, 2021, 10:53:39 AM »

Hi,

as all know SIMOS18 Flash FRF is a encrypted Flash ODX with 5 Blocks in it. I want to modify the CAL Section but if I'm informed right the Block need to get a new RSA Signature and a CRC.

Is anyone there who can pack a FRF with modified CAL or either a ODX. Transforming from ODX to FRF can be done my me.
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #1 on: July 09, 2021, 12:55:24 PM »

This isn't possible, the RSA private key is unknown and there isn't a known/public exploit in the sigcheck.

You need to patch the CBOOT into Sample mode or patch out the RSA checks in CBOOT specifically, and flash a patcher / "unlock" exploit first.

The short summary of port flashing on newer Simos18 is this:

When each block is written, it is checked against the CRC in the block header (code here: https://github.com/bri3d/VW_Flash/blob/master/lib/checksum.py ) and an RSA signature at the end of the block.

The RSA signature checking is secure as far as is currently known, and issues from earlier Simos ECUs have been fixed. The crypto sigchecking code produces a SHA256 checksum over the block, with addresses mixed in during the SHA256 calculation to prevent block reuse attacks. Then, it embeds the SHA256 in an RSA2048-PKCS#1.5-SHA256 container and checks it against the signature at the end of the block by encrypting the signature using the public key and comparing the two. It correctly checks all of the PKCS padding and the ASN.1, plus uses e=65537 and there are no obvious bounds checking issues.

If the block is good, a "Valid" flag (H$B/B$H) is written immediately after the OBD-writeable area of the block. If this flag is present the block is considered "good" on boot and the RSA signature is not checked again - so it is easy to modify the block content with password/boot access.

As for port flashing: while the RSA check is secure as far as we know, there is an issue in CBOOT where a software block can be overwritten without being erased first. In this way, an ASW block can be marked as valid but with custom code patched into it.

The exploit is quite complex to execute on because the ECC system is still active in the Flash controller, and the block hasn't been erased. This means that we need to either only patch over 00 data (safe) or try to calculate an ECC collision (very unsafe as doing it wrong will cause major problems and will hard-brick most poorly made knockoff boot mode tools). Also, we need to both erase a block and then write a _different_ block, and we need to flash uncompressed (0A) data with a custom TransferData size. So, there's a deviation from the flash routine in the built-in ODX layers, meaning it would be hard to do via ODX/FRF - it's much easier to just make a custom flasher.

The way this is usually done is with an "initial flash" where a complete ASW is flashed and then one ASW block has custom code patched into it. This custom code usually then puts CBOOT into Sample Mode by patching the HWID check function, or patches out the RSA signature checking.

Next, a full flash is executed using the now-patched CBOOT which has RSA checking disabled, and from here on out the ECU is "unlocked" and will accept blocks with bad RSA signatures.

After this "unlock" process, you could FRF - but we needed a custom flasher anyway for the exploit, so what's the point?

https://github.com/bri3d/VW_Flash/blob/master/docs/docs.md
« Last Edit: July 09, 2021, 02:47:11 PM by d3irb » Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #2 on: July 12, 2021, 04:25:21 AM »

Hi! Wow it looks like you really know your way around the SIMOS18. I took a look at your project and am buff! Really cool!

What I have not understood yet, forgive me, you provide a patch, this must be packed in ASW3. But how can ASW3 now be flashed with modified data, the signature does not fit, right?

I have looked at your tool, is it possible to perform the complete flash process including patch with it? Except a Rasp and a CAN board it does not seem to need anything!

Thanks!
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #3 on: July 12, 2021, 08:00:10 AM »

Quote
What I have not understood yet, forgive me, you provide a patch, this must be packed in ASW3. But how can ASW3 now be flashed with modified data, the signature does not fit, right?

This is the exploit / mistake which I was explaining in Simos18 VW CBOOT - we can overwrite an ASW block after it has been flashed with correct data and verified.

First, we write any ASW block the "right" way, by erasing the block, using RequestDownload with 0xAA and sending a correct factory block, and then sending the Checksum routine request for that block. Once this is done, CBOOT writes a "Valid" identifier into Flash after the block, and the signature is never checked again unless that block is erased.

Next, the exploit: by using RequestDownload with 0x0A instead of 0xAA (encrypted rather than compressed+encrypted), the same block can be overwritten, but only with very careful patch data following very strict rules (because the Flash has not been erased since being written): only 0 bits can flip to 1, and if data that exists is patched this way, the bits that are flipped also need to satisfy ECC with the 0s flipped to 1.

Furthermore, the write pointer needs to be moved by writing zeroes 256 bytes at a time, and, the data we actually care to write needs to be written in a small enough chunk as to never intersect already-written data. We also need to try to send the same data repeatedly until we receive a positive response from the TransferData request, which can sometimes take a few tries. This is why it would be really hard to make an ODX layer that could flash properly - the required procedure is quite non-standard.

The reason we have to do this is because writing data over already-written space will cause a failure status in the Flash controller, and we need to work around CBOOT's error handling. So for data we don't care about, we choose 256 bytes - this is because this is the size of the Tricore flash controller's Assembly Page, and we can't allow CBOOT to try to split the data into multiple Assembly Pages or its own error handling will cause it to crash out.

Once the write cursor has been slid to an empty area by ignoring errors, we write the data we DO care about 8 bytes at a time - this is because 8 bytes is the size of an ECC block in the Tricore flash controller and if we write more than one ECC block at once, we risk writing data with an incorrect ECC.

https://github.com/bri3d/VW_Flash/blob/master/lib/simos_uds.py#L188

The CRC _is_ also checked again, so we need to back-repair the CRC in the patch data.

Quote
I have looked at your tool, is it possible to perform the complete flash process including patch with it? Except a Rasp and a CAN board it does not seem to need anything!

Yes, what's up on my GitHub will successfully port flash with a Pi and a Seeed Studios CAN hat. If you get this hardware combo and some 5V<->3.3V level shifters, you can also use my open source software as a bench/boot tool to extract passwords for ECUs you are okay with opening up.

If you don't care about bench/boot functionality, some of my collaborators also took the time to make it work with J2534 and on Windows, so you can use OpenPort as well.

The simple process would look like this:

Download 8V0906259H__0001.frf . Run it through `frf/decryptfrf.py` and `extractodxsimos18.py` . Now you have 5 decrypted blocks, FD_0 through FD_4. Place the patch.bin from the docs directory into the same folder. Next flash, by running:

Code:
python3 ../VW_Flash/VW_Flash.py --infile FD_0 --block CBOOT --infile FD_1 --block ASW1 --infile FD_2 --block ASW2 --action flash_bin --infile FD_3 --block ASW3 --infile patch.bin --block PATCH_ASW3 --infile FD_4 --block CAL

Now your Simos18 will be in a patched state where it won't run, but will just keep booting into a Sample Mode CBOOT. You can confirm this by checking the HW ID and SW IDs sent back over UDS - the HW ID will have changed to "X13" and the SW IDs to "X9999".

At this point the S18 is "unlocked" and you can flash blocks with bad signatures. But, if you want to be able to flash more than once, the next block you can flash with a bad signature needs to be a CBOOT that's patched into Sample Mode, and this is the part that's not automated yet. It's really trivial to do this patch a disassembler by looking for xrefs to b000218c (sample mode flag), or to d0000000 (HWID) and following backwards, but because USDM MQB cars can be cross-flashed onto a single software version, I haven't bothered to automate the process yet.

Unfortunately after spending around 3-4 weeks while between jobs working on S18 almost full-time, I took on a new job earlier in the year which is proving to be quite challenging, so I have not gotten the time to finish certain parts of the project like the automated patcher. Hopefully I will get to them later this summer.
Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #4 on: July 14, 2021, 12:37:37 AM »

Madness! Thanks for your answer.

Yes, what's up on my GitHub will successfully port flash with a Pi and a Seeed Studios CAN hat.

Perfectly I have a Pi with Seed Studio CAN Hat here.

Quote
But, if you want to be able to flash more than once, the next block you can flash with a bad signature needs to be a CBOOT that's patched into Sample Mode, and this is the part that's not automated yet.

On this point, I still have some difficulty understanding the whole thing. Does this apply only after a reset or directly after flashing the 5 blocks from "8V0906259H__0001.frf"? Because, as far as I understood your docs in Github, you recommend to flash first to the 8V0906259H__0001 incl. patch and then to any other one you want.

My target SW version is for example: FL_5G0906259___0010

So can I now first run the command you sent including patching and then write with the new blocks of FL_5G0906259___0010 with bad signature (actually only the CAL block with bad signature) afterwards?



Quote
It's really trivial to do this patch a disassembler by looking for xrefs to b000218c (sample mode flag), or to d0000000 (HWID) and following backwards, but because USDM MQB cars can be cross-flashed onto a single software version, I haven't bothered to automate the process yet.

I'm afraid I'm not that fit in the reverse engineering area yet.

And the last one:
If i use VCP or ODIS to flash a OEM FRF, the patch is gone = ECU is really back to stock, right?
« Last Edit: July 14, 2021, 06:28:43 AM by vt1111 » Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #5 on: July 14, 2021, 07:34:21 AM »

Quote
On this point, I still have some difficulty understanding the whole thing. Does this apply only after a reset or directly after flashing the 5 blocks from "8V0906259H__0001.frf"? Because, as far as I understood your docs in Github, you recommend to flash first to the 8V0906259H__0001 incl. patch and then to any other one you want.

The 8V0906259H__0001 with my patch will replace the startup of ASW with a jump into CBOOT running in Sample Mode. It is very important that you not try to flash 8V0906259H__0001 without the patch as it will probably PClass mismatch and cause an Immo brick.

Here are the states:

Stock ECU: Boots into ASW, runs car. Programming mode loads CBOOT, CBOOT enforces signature checking. Therefore -> can run car, and only reflash valid signatures.

Now we flash 8V0906259H__0001 *with* patch, bypassing signature check process. After the flash process, the ECU resets ->

ECU with patched 8V0906259H__0001: ASW startup replaced with jump into RAM-patched CBOOT. Cannot run car. RAM-patched CBOOT does not enforce signature checking -> all you can do from here do is reflash with any software, valid or invalid.

This is where the CBOOT patch comes in, what you really want to do next is:

Build patched software package targeting your ECU, with matching CBOOT, ASW, and CAL, and CBOOT patched to remain in Sample Mode. ->

ECU with patched CBOOT: ASW runs car. Programming mode loads CBOOT, CBOOT has been patched not to enforce signature checking. Therefore -> can run car, and can flash invalid software. Car is now "tunable."

And as for your last point:

Quote
If i use VCP or ODIS to flash a OEM FRF, the patch is gone = ECU is really back to stock, right?

Yes, at this point the software is stock.
Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #6 on: July 14, 2021, 08:04:49 AM »

Thank you for your answer.

This means that I can not, as of now (from your Github project) flash to my software version (FL_5G0906259___0010) and the vehicle starts, right? Since your patch currently exists only for 8V0906259H__0001?

Or can I run the patch first:
Code:
python3 ../VW_Flash/VW_Flash.py --infile FD_0 --block CBOOT --infile FD_1 --block ASW1 --infile FD_2 --block ASW2 --action flash_bin --infile FD_3 --block ASW3 --infile patch.bin --block PATCH_ASW3 --infile FD_4 --block CAL

And then flash OEM block 1-4 of FL_5G0906259___0010 and then block CAL modified?
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #7 on: July 14, 2021, 01:31:58 PM »

Thank you for your answer.

This means that I can not, as of now (from your Github project) flash to my software version (FL_5G0906259___0010) and the vehicle starts, right? Since your patch currently exists only for 8V0906259H__0001?

Or can I run the patch first:
Code:
python3 ../VW_Flash/VW_Flash.py --infile FD_0 --block CBOOT --infile FD_1 --block ASW1 --infile FD_2 --block ASW2 --action flash_bin --infile FD_3 --block ASW3 --infile patch.bin --block PATCH_ASW3 --infile FD_4 --block CAL

And then flash OEM block 1-4 of FL_5G0906259___0010 and then block CAL modified?

You could flash a modified CAL block once, by flashing the full 8V0906259H__0001 "loader", followed by modified FL_5G0906259___0010 CAL, and then the rest of the FL_5G0906259___0010 blocks over the patch. What would happen here is that the patched 8V0906259H__0001 running from memory would accept the new and CAL and write its signature flag, and then the unpatched SW written after would see the flag is already written and wouldn't check the CAL again until it was erased.

But, what you really want is a version of of FL_5G0906259___0010 with CBOOT patched into Sample mode. This is what you'd flash over the top of the patch to get a fully "tune-able" setup. I can probably help to make you one and send you a message about it.
Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #8 on: July 14, 2021, 03:17:10 PM »

Quote
You could flash a modified CAL block once, by flashing the full 8V0906259H__0001 "loader", followed by modified FL_5G0906259___0010 CAL, and then the rest of the FL_5G0906259___0010 blocks over the patch. What would happen here is that the patched 8V0906259H__0001 running from memory would accept the new and CAL and write its signature flag, and then the unpatched SW written after would see the flag is already written and wouldn't check the CAL again until it was erased.

Ah so the Steps are:
1. Flash 8V0906259H__0001 Block 1-5 + patch
2. Flash my own mod. CAL
3. Flash FL_5G0906259___0010 Block 1-4

Right? That works just once, since Step 3 "kills" the Patch.


Quote
But, what you really want is a version of of FL_5G0906259___0010 with CBOOT patched into Sample mode. This is what you'd flash over the top of the patch to get a fully "tune-able" setup. I can probably help to make you one and send you a message about it.

Ohhh, would be great - do you message me?
Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #9 on: July 14, 2021, 04:46:00 PM »

Ah so the Steps are:
1. Flash 8V0906259H__0001 Block 1-5 + patch
2. Flash my own mod. CAL
3. Flash FL_5G0906259___0010 Block 1-4

Right? That works just once, since Step 3 "kills" the Patch.

Exactly! Now you get it, I think! Sorry, it is quite complex really.

Quote
Ohhh, would be great - do you message me?

Hopefully I get to this tomorrow or so my time.
Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #10 on: July 15, 2021, 10:02:57 AM »

Quote
Exactly! Now you get it, I think! Sorry, it is quite complex really.

Perfect. And if I have similar Patch like you have for 8V.... just for mine version I dont need Step 3, since I can overrite CAL as often I want?

Quote
Hopefully I get to this tomorrow or so my time.

Thanks!

Another question, after flashing your File + Patch, VCP still says "5G0906259 0010" as ECU Number, is that normal?
« Last Edit: July 16, 2021, 05:05:07 AM by vt1111 » Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #11 on: July 20, 2021, 05:54:16 AM »

Hey!

do you have an update for me? Especially for my last question.

Thanks!
Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #12 on: July 20, 2021, 06:04:57 AM »

Hey!

do you have an update for me? Especially for my last question.

Thanks!

BTW. thats my Output:

Logged
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #13 on: July 20, 2021, 07:14:38 AM »

Hey!

do you have an update for me? Especially for my last question.

Thanks!

BTW. thats my Output:



Please pull the flasher and try again. I had introduced a bug in the course of adding Simos18.10 support which I didn't notice until now. Sorry - should work when you try again.
Logged
vt1111
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 27


« Reply #14 on: July 20, 2021, 07:34:20 AM »

Hi

now i get:
Logged
Pages: [1] 2
  Print  
 
Jump to:  

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