NefMoto

My nephew brought home a problematic MK4 GTI. While waiting for parts, I'm pondering if a previous owner tinkered with its binaries. I'm no stranger to configuring a calculator, but I've barely started getting into the weeds on this particular system.

Applying labels to a hex dump to find imbedded checksum and CRC values is in my wheelhouse. So it occurs to me that I should be able to pull those values and compare to known stock values to determine the OEM state of the ECU. The problem I'm running into is no one seems to have bothered tabulating stock checksums. Which would make sense. Documentation is a by product of work and the work seems more interested in how can we push it to breaking than knowing how it was originally.

So here's my questions.
Is my logic sane for determining if this unknown ECU has a stock tune?
Are stock binaries uniform for each example of a specific ECU part number?
Is there a checksum lookup table that I've just failed at finding?

no
yes
no

read your binary, find a stock binary, md5sum them yourself or just do a straight binary compare of the two files (using "diff" if you aren't on a toy OS).

Thank you for the answers, and I apologize for imposing on you further with some follow-up.

I'm not going to get into why my logic isn't sane, I can figure that out for myself. What I would like to follow up on is the inability to locate a database of ECU revisions.
Finding a stock image for the ECU on this GTI and comparing my own checksums will tell me what I want to know for this project. My 2001 TT is another project. Picking out a compatible wideband ECU is the next step in that project. Knowing the differences between revisions is crucial to picking the right ECU. Cut twice and measure once in wood shop was only good to keep me off the honor roll...

To do that research, the avenue that seems clearest to me would be parsing the posts here: http://nefariousmotorsports.com/forum/index.php?board=17.0 (http://nefariousmotorsports.com/forum/index.php?board=17.0)

I understand bandwidth is not free. Before targeting thread content, I would want to have generated a specific list of content to target. To generate that target list, a curation of thread topics would be the bare minimum. That should be possible with a minimal amount of text traffic thanks to your outlined and enforced naming conventions.

Do you object? I would of course share any information I generated from my parse on topic titles before asking about an en masse curation of information on actual binaries and thread content.

As much as I'd love to get into a friendly drunken discussion about the pros and cons of an object stream based OS with a semi-curated lib base vs a file stream based OS with fractured lib base and abstracted object shells... Let's just say Get-FileHash and Compare-Object works fine on the Wintendo kiddie box.

I would love a real db of stock images and md5sums.

Would be more than happy to contribute the binaries I have, and I don't have a problem with you scraping the site.

Ideally, you'd make a website, and publish the source to it (and/or docker images etc) so somebody could relaunch the site easily :)

Entertaining the full DevOps path sounds like the type of creep that would cause my adhd to orphan a project on the launch pad.

For now, I think a rough index of what and where ECU data exists, serialized as JSON is enough to get me moving. Deciding how to store the index and ECU bins, building a custom front end, and hosting solutions can come later.