NefMoto

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.

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

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!

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.


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:


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.

Madness! Thanks for your answer.


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


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?




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?

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:


Yes, at this point the software is stock.

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:

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.

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.



Ohhh, would be great - do you message me?

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


Hopefully I get to this tomorrow or so my time.

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?


Thanks!

Another question, after flashing your File + Patch, VCP still says "5G0906259 0010" as ECU Number, is that normal?

Hey!

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

Thanks!

Hey!

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

Thanks!

BTW. thats my Output:
(https://i.ibb.co/HnCVBNK/flash.png)

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.

Hi

now i get: (https://i.ibb.co/JBVwq6V/flash1.png)

I tired to delete all old files and use the complete new pull. But same result as in my last image


(https://i.ibb.co/JBVwq6V/flash1.png)

Not quite the same error this time... please pull again. I tried to use a feature which only works in some Python versions. Should be good to go now.

Hi,

thanks for your help. Now the Output is that:
(https://i.ibb.co/mFfJcSJ/flash4.png)



VCP still says the old ECU number.

This looks like better output, although I would prefer logs (there should be a flash.log and a few other generated logfiles for this purpose).

Please DM me and we can try to figure out what's going on for you. Does VCP show you the Hardware Number (H13 / X13) ?

Hi!

Sent. X13 as ECU Variant is shown. H13 I can't see but i attached the Image from VCP in the DM.

You could however repeat this process every time you write a modfied/tuned file, right? Flash all 5 blocks of patched 8V software and then just flash all of the blocks for the original frf on the car with a modified CAL sector/block (remap)? Or am i missing something and it would trigger an IMMO brick?

If X13 is shown the in-memory patch is working and the car is now in a fake Sample Mode CBOOT. So, you should be able to flash a patched set of blocks now. There is an issue I just thought of though with not having a patched CBOOT to flash (don't worry, you can always go back to stock!). Read along:


This would work, except for something I just thought of which prevents it. Without flashing a patched CBOOT first, this actually won't work, unfortunately. Here's why:

Your car is now loading an ASW which loads up a fake Sample Mode CBOOT in RAM. This fake Sample Mode CBOOT will accept _any_ block, and will mark it as Valid in the ECU memory. But, the next block that's flashed actually has to be a CBOOT with the Sample Mode patch applied, in order to flash a custom CAL. Here's why:

When the ECU writes CBOOT, it actually does it by downloading the data into the CAL block and then copying it into the CBOOT area if it passes all checks. Next, it instantly and immediately reboots into the new CBOOT.

This means that the ASW-based CBOOT patcher will be instantly removed across this reboot - and the now-running CBOOT will not accept patched blocks, unless it is in Sample Mode.

And, when I wasn't thinking right before, I had thought "well, just write CAL first, it will be marked as valid and the rebooted CBOOT won't care" - but this isn't true, because flashing a new CBOOT erases CAL, inherently, because the CAL area is where the temporary CBOOT is written.

So in short - vt1111, you need a patched-into-Sample Mode CBOOT to flash over the top. Right now, your ECU was patched successfully, and it is in fake Sample Mode each time it boots up (that's the X13 identifier you see). Right now, it will write unsigned blocks. But, unfortunately, the unsigned blocks you write need to be a full-time patched CBOOT, for the reasons listed above.

So it is currently not possible to flash any software but only if it is 8V.... where you have a patch, right?

8V is nothing to do with it - CBOOT and ASW versions are independent of brand and product and are shared across all product lines, which is convenient as for USDM MQB cars there is actually a shared CBOOT and ASW (I0 CBOOT and S50 ASW) which has a calibration for almost all models: GTI/A3 2.0 5G 259L__0002, R/S3 8V 259K__0003, Golf/Sportwagen/A3 1.8 8V 264K__0003, and TT-S 8S 259C__0004 all have an I0 S50 calibration for USDM.

Anyway, I added an automated patcher. It is incredibly naive and just patches a hex string, which I am not particularly proud of as it is generally a horrible practice (vs. writing a disassembler and doing it right). However, amazingly, I automated the FRF/ODX extraction process and tested my patcher on every single CBOOT sample I have for all Simos MQB ECUs, and the naive hex patching actually seems to be OK on all known CBOOTs.

So the new process is:

* Flash 8V0906259H__0001 with patch.bin, as you have done. Double check this by looking - Hardware Number should now read X13 (as yours did).

* `python3 VW_Flash.py --action flash_frf --frf yourcar.frf --patch-cboot` . This will apply the FRF to your car but with a patched CBOOT, which will allow unsigned code and CAL blocks for your boxcode going forward.

* Extract the FRF/ODX for your boxcode. FD_4 will be the CAL. To flash a new CAL in the future, you can do `python3 VW_Flash.py --action flash_cal --infile FD_4 --block CAL` to flash a new CAL with whatever changes you want. flash_cal has also been updated to correct both the CRC32 and ECM3->ECM2 summation checksums.

* You can also flash new ASW patches using `python3 VW_Flash.py --action flash_bin --infile FD_1 --block ASW1` for example. Be aware that doing this without having very well-tested patches or ready access to bench/boot tooling (Raspberry Pi with 5V level shifters and CAN hat to use my open-source stuff, or commercial tools), is rather hazardous and can easily result in a brick.

I tested this whole process on my bench ECU using the latest VW_Flash `master` branch and `FL_5G0906259___0009.frf`, I didn't have ___0010 handy. Everything worked great.

The most dangerous part of this process is that you _must_ make sure that the FRF you flash is for the correct vehicle. If the IMO_idxTun0X_C_VW table does not contain a match for the adapted PClass in the ImoDat, the ECU will happily flash the file, boot up, and not find a PClass. Then you will get stuck in "IMMO brick" which requires bench tools to restore.

Here is some code to get the file number and version from any S18.1 ECU:
You can adapt this code, and then when flashing make sure that the file number in the ECU (queried with 22 F1 87) matches what you are trying to flash. If they do not match, throw an error and do not continue.
Allow overriding this by specifying a special command line switch.

This way it is possible to flash a newer or older version, but not a different file number. This guarantees that you never run into immobilizer problems.

https://github.com/bri3d/VW_Flash/blob/master/VW_Flash.py#L384 - thanks, but it's been in there for many months now - when using flash_cal to update a calibration, there's no chance for an easy mistake.

Users really only need to watch out when they're flashing initially - and this is in no small part my own fault because I encourage USDM users to cross-flash to specific versions in https://github.com/bri3d/VW_Flash#getting-started to avoid the endless hunt for definition files. Unfortunately, this means any warning added to the "full flash" handler would probably be zombie-accepted anyway.

I think I'll manually generate a table of calibration names with known matching idxTun tables in a bit, and match using a CSV. For now, people should just pay attention to what they're flashing when they're not using flash_cal :)

Very nice! Thanks for your adaption. I will try in next days and will get back to you.

Hello

3. Flash FL_5G0906259___0010 Block 1-4

How can i do that?

After flashing the frf for the car, I didn`t see the X13 and my cal block is overwritten.

Thank you.

Best regards
keine Ahnung