crchack VS TC1791_CAN_BSL

After the Seed/Key process was figured out, the CRC exploit was very obvious as the bounds checking is blatantly broken. https://github.com/resilar/crchack came in handy to take the CRC + unknown data and back-generate the correct data used to produce the CRC.

In addition to the RSA signature, all Simos18 code blocks are also checked against a simple CRC checksum. And, in this case, SBOOT tries to validate the CRC checksum before it validates the RSA signature. It turns out the CRC validation is performed using an address header, and the address header has weak bounds checking. So, we can ask the ECU to checksum the boot passwords, and send us the checksum back. Since CRC is not a cryptographic hash (it is reversible), we can use the CRC values to back-calculate the boot passwords. Unfortunately, we can't do this cleanly, because the high side of the address range IS correctly bounds-checked. So instead, we have to start the CRC checksum process, then rapidly reboot into the Tricore Bootstrap Loader and dump the contents of RAM, to see the intermediate/temporary CRC values that have been calculated for only the boot passwords. https://github.com/bri3d/TC1791_CAN_BSL/blob/main/bootloader.py#L113