MEDC17 Checksum Tool & CVN раtсh

MasterB8r said:

Hello all, I found this open-source tool, I tested it against other checksum tools and it works fine...

Click to expand...

Thanks for the share, mate.

However, I just tried the link and it's returning a 404 Not Found. It looks like the repository has been deleted or made private by the author.

Did you happen to fork it or download the source code? If so, could you please attach it here or upload it to a host? It's rare to see open-source solutions for MEDC17 that actually work well, especially if it handles the RSA signatures and not just the standard block checksums.

Would be interesting to analyze the algo.

I have cloned and zipped the repo for you.

MasterB8r said:

I have cloned and zipped the repo for you.

Click to expand...

Downloaded and took a look at the source. Thanks for saving this, it's actually quite a sophisticated little tool for a Python script.

I've analyzed the main.py and here is a technical breakdown of what it's actually doing versus what commercial tools (WinOLS/Kess) do:

The Good Stuff

1. RSA Signature Forging (Bleichenbacher Attack)
Most "free" checksum tools only calculate the CRC32/ADD32 blocks. This tool actually attempts to handle the RSA signature found in the TPROT blocks (0x40, 0x60, etc).
It uses the forge_bleichenbacher_signature function.
This exploits the fact that many older Infineon Tricore bootloaders verify the RSA signature using e=3 without properly checking the padding structure (PKCS#1 v1.5). It calculates a cube root of the hash to spoof a valid signature.
Note: This will work on many EDC17/MED17 ECUs, but newer ones with fixed bootloaders or different exponents will likely reject this.

2. CVN Patching via GF(2) Math
The CVN (Calibration Verification Number) logic is solid. Instead of brute-forcing, it uses Gaussian elimination in a Galois Field GF(2) to mathematically calculate the exact 4 bytes needed to force the CRC32 to match the original CVN.
See solve_crc32_patch_matrix and crc32_forge_patch. This is the "correct" way to do CVN fixes programmatically.

The Risks / Missing Parts

1. "Sync Blocks" are missing
The author admits this in the TODO:

Sync blocks - WinOLS references these, what are they??

Click to expand...

In Bosch structures, "Sync Blocks" are often cross-checks between the ASW (Application Software) and the Cal (Data) segments. If you modify the map area, the main checksum is updated, but often there is a secondary check in the code area that validates the data area. If this tool misses those, you might get a brick or a "P0601 Internal Memory Checksum Error" even if the main blocks look green.

2. Variant Datasets
VAG MED17.1/17.5 often contain multiple datasets (e.g., for different power classes or gearboxes) in one flash. WinOLS automatically detects which one is active or corrects all of them. This tool seems to struggle with the "Variant Dataset" (Block 0x80) structure. If it corrupts the header of the variant block, the ECU might die.

3. Monitoring / Algo Checksums
This tool handles the standard Bosch block checksums (start/end/result). It does not seem to handle the internal monitoring checksums (Torque monitoring, etc.) that are embedded inside the maps. You still need to disable those or correct them manually if your tune deviates too much.

Verdict

It is a great tool for learning how checksums work and might work fine for simple Stage 1 files on older VAG MED17.1 (as you tested).

However, be very careful using this on:

• Newer BMW/Mercedes EDC17 (more complex RSA).
• Files where you have patched the code (ASW), not just maps.
• ECUs with OTP sectors active.

If you use this, I highly recommend flashing via a tool that can do a full backup (Bench/Boot) first. Don't try this via OBD until you are sure the algo is 100% correct for your specific SW version.