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#L188The CRC _is_ also checked again, so we need to back-repair the CRC in the patch data.
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:
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.