MEDC17 Checksum Tool & CVN раtсh

  • Thread starter Thread starter MasterB8r
  • Start date Start date
  • Tagged users Tagged users None
Hello all, I found this open-source tool, I tested it against other checksum tools and it works fine...

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.

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.
Python:
def forge_bleichenbacher_signature(ripemd_hash: bytes) -> bytes:
    # ...
    # RSA with e=3, NO modulus (just cubes the signature)
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??
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.
 

That link is also returning a 404 Not Found. Seems like the page is either down or the URL has changed.

Is this a web-based checksum validator? A few questions:

  • What ECU families does it support? Just MEDC17 or also EDC17, MG1, MD1, etc.?
  • Does it handle CVN correction as well, or only block checksums?
  • Is it doing the calculation server-side (i.e., you upload your bin to their server)?

If it's a cloud-based tool where you upload your binary, I'd be very cautious about that. You're essentially giving away your modified file (and potentially your customer's original) to an unknown server. There's no way to know if they're storing, logging, or reselling those bins.

The whole point of the open-source Python tool above is that everything runs locally on your machine — no files leave your PC.

If you can get the link working again, share a screenshot of the interface and what options it offers. Would be interesting to compare the results against the GitHub tool for the same bin. That's the best way to validate — take a known-good corrected file from WinOLS, strip the checksums from the original mоd, run it through both tools, and compare byte-for-byte:

Bash:
# Quick compare after both tools correct the same input
python main.py modified.bin --correct --output corrected_python.bin
# Then download the result from the web tool as corrected_web.bin

# Binary diff
fc /b corrected_python.bin corrected_web.bin
# or on Linux:
diff <(xxd corrected_python.bin) <(xxd corrected_web.bin)

If the outputs match, both tools are doing the job correctly. If they differ, check which offsets differ — that will tell you immediately if one tool is missing a block or calculating a different initial value.
 
Back