Identify Any ECU File in Seconds: Drag-Drop SW, HW, VIN, and ECU Family Extraction

Before you tune a file, you need to know what it is. The customer says “Audi A4 2.0 TDI, 2018, EDC17”. They are correct about the brand and the year. They are wrong about the ECU — it’s an EDC17C46 with a software revision they don’t know the number of, and the file they sent you is from a KESS3 OBD read which means the checksum sub-region is missing. Tune the file blind and you’ll get a phone call about a limp-mode dashboard light within 48 hours.

This is the identification problem, and traditionally workshops solve it by opening the file in a hex editor or in WinOLS, scrolling to the offset where the software number lives for that ECU family, and reading it manually. Faster workshops automate this with a desktop tool. Even faster workshops drag the file onto their portal dashboard and let the portal do it in three seconds.

This post explains exactly what you should be able to extract from any ECU file before you touch it, where in the file each piece of data lives, and how to wire that into a workflow that catches the “wrong file uploaded” problem before it costs you a remap.

What you should extract from every ECU file — and where it lives

A modern ECU dump — Bosch, Continental, Delphi, Marelli, Siemens — contains several pieces of identification metadata at fixed offsets. The exact offsets vary per ECU family, but the data is always there:

A KESS3 OBD read covers the calibration region (CAL) and includes most of these fields. A bench read or BDM dump includes the full image plus boot, full ASW, and PSW (parameter software) — much more data, but the identification fields are still at the same offsets.

Vendor slave files (AutoTuner .slave.zip, bFlash .bfp, KESS .kess, Alientech .ktag) wrap the BIN in a vendor envelope. Inside the ZIP is typically an info.xml or a slave.xml declaring the SW/HW/VIN explicitly — no offset scanning needed. The envelope is the source of truth; the BIN inside is just bytes.

A robust identification routine handles all three cases:

1. Slave-format files (AutoTuner / bFlash / Alientech / KESS) → parse the XML envelope first
2. Plain BIN files → scan known offsets per ECU family
3. Encrypted / scrambled files → mark as “encrypted, decrypt required” and stop

The “wrong file” failure modes you avoid by identifying upfront

Three real-world failures from chiptuning forums in the last six months, all preventable by a 3-second identification step:

Failure 1 — Customer sends OBD read, claims it’s a bench read. Tuner pushes a full file back via bench, ECU bricks because the BSL/boot region wasn’t actually there to begin with. £600 ECU replacement.

Failure 2 — Customer sends encrypted slave file, tuner mistakes it for a plain BIN. Hex editor shows random bytes; tuner assumes the customer messed up; the customer assumes the tuner is incompetent. The actual problem: it’s a vendor-encrypted slave that needs decrypting through the vendor API before anything else.

Failure 3 — Customer sends a file from a different car. SW number on the file does not match the SW number from the original read on the customer’s actual car (which the tuner doesn’t have). Tuner tunes it, writes it to the car, immobiliser kicks in, customer’s car won’t start.

All three are caught by reading SW + HW + VIN before reading the rest of the file.

The drag-drop workflow

The fastest identification workflow is also the simplest:

1. Engineer opens their portal dashboard.
2. Drags the file onto a drop zone widget.
3. Within a few seconds, the widget displays:
   – File type (plain BIN, AutoTuner slave, bFlash, KESS, etc.)
   – SHA-256 hash (for cross-referencing against your historical library)
   – SW number, HW number, SW version, VIN
   – Detected ECU family (Bosch EDC17C46, Bosch MED17.5, etc.)
   – Decryption requirement (yes / no / unknown)
4. Engineer either continues to the full file-request submission, or — if the customer’s claims don’t match the file’s actual fields — flags the discrepancy and asks the customer for the correct read.

The whole loop is under 10 seconds. The alternative (open in WinOLS, scroll to offset, copy, paste) is 3-5 minutes per file. Multiply by 20 files a day and the difference is an hour and a half.

Realtime progress matters more than you’d think

A drag-drop widget that says “Processing…” for 6 seconds and then dumps all results at once feels broken. A widget that shows progress through the four stages — Upload → Detect → Decrypt → Ready — with a live progress bar feels fast even at 8 seconds. The same waiting time, perceived very differently.

The same principle applies to the actual identification logic: surface partial results as they’re discovered. The SHA-256 is computable in under a second; show it. The vendor envelope is parsed in a couple of seconds; show those fields next. The full BIN scan finishes last; the customer (or the engineer) has already seen enough to decide whether to continue.

Cross-referencing against your historical library

Identification gets dramatically more valuable when you can cross-reference the file against everything you’ve previously tuned.

If a workshop has 18 months of file history, the SHA-256 of an incoming file might match an exact file they’ve previously delivered — in which case the tuned version is in their library already and the new customer can be served from cache in zero seconds. The SW + HW pair might match (same factory ECU, different vehicle) — in which case a previously-tuned file is a strong starting point and the tuner only needs to verify the modifications match.

This is the workflow people call “Tier 2 cache” or “library match”, and it’s what turns a workshop’s accumulated file history from a backup folder into a real-time delivery engine.

The hard requirements for this to work:

• Every uploaded file must persist with its SW, HW, VIN, and SHA-256 indexed and searchable.
• The library must be queryable by SHA (exact match), by SW + HW (calibration twin), and by ECU family + customer vehicle (loose match for tier-3 search).
• Match confidence must be surfaced honestly — a SHA match is a confidence-100% result; a SW+HW match without SHA is confidence-80%; a family + vehicle match is confidence-50%, and the engineer should be told which.

Workshops that don’t track this end up tuning the same SW+HW pair a dozen times for a dozen customers, each time re-doing the work. Workshops that do, deliver the dozenth one in 5 minutes.

When identification matters most — encrypted slave files

A vendor slave file from AutoTuner, KESS3 (in encrypted mode), or bFlash arrives at your portal as random bytes. Without decrypting through the vendor API, you cannot read any of the offsets. The identification routine must:

1. Recognise the file is a vendor envelope (file extension, magic bytes, or XML signature)
2. Extract whatever the envelope declares (some envelopes carry SW/HW in cleartext even when the BIN is encrypted)
3. Mark the file as “decryption required” and stop

Only after a successful decrypt — through the vendor API, billed per call — does the workflow continue to full identification. Decrypts cost money per SHA, so cache them aggressively: one vendor decrypt per unique SHA across your entire customer base, indexed against your library, free for every subsequent customer who submits the same file.

If a workshop processes 20 files a day and 8 of them are duplicates of files already in their library, that’s 8 vendor decrypt calls saved per day — at typical vendor pricing, £20-40/day in API costs avoided.

Filename intelligence — the cheap shortcut

When a file is named Audi_Q3_2011_8U_2-0_TSI_180_hp_Continental_Simos18-2_OBD_VR.slave.zip, the filename already declares the vehicle, ECU family, reading method, and even the reading tool. A smart upload form parses the filename and pre-fills the file-request fields before you’ve even opened the BIN.

This sounds like a small detail but compounds. Engineers who drop a filename-rich slave file into the form get half the wizard pre-filled. Engineers who type the values manually misspell Simos18.10 as simos 18,10 and break the search index later.

Filename intelligence is independent of the actual file contents — it works on encrypted slaves, on incomplete reads, on anything with a structured name.

What this looks like in TunerSuite

TunerSuite v2.8.159+ ships a Quick File Tool widget on the master dashboard. Drag a .bin, .slave, .ori, or vendor-envelope file onto it. The widget:

• Computes the SHA-256 in under a second
• Reads vendor envelope (if present) within 2-3 seconds
• Decrypts through the configured vendor connector (AutoTuner, bFlash, Alientech) if needed
• Extracts SW number, HW number, SW upgrade, ECU family, VIN
• Cross-references against your library and shows compatible historical files (full SHA match, SW+HW twin, or family match)
• Renders the result on a 4-stage progress indicator with realtime updates

The same identification fires automatically on every file submitted through the customer-facing wizard. Engineers don’t need to drag-drop again — the data is already extracted when they open the request.

Filename intelligence runs at the same time: if the dropped file is named Audi_A4_2018_8K_EDC17C46_OBD_VR.slave.zip, the vehicle search field is pre-filled when the engineer continues to the file-request form.

This is bundled with the TunerSuite licence — £699 setup + £49.99/month — no separate “BIN analyzer” add-on, no per-file fee for identification. The AI ECU Analyzer feature page lays out the full identification pipeline.

FAQ

Will this work on files I haven’t tuned myself, e.g. customer-supplied originals?
Yes. Identification reads what’s in the file, regardless of provenance. The library cross-reference only finds matches against files you have previously processed — but identification on a brand-new file works on the first upload.

What if the SW number is at a non-standard offset for an obscure ECU?
A robust identifier ships with offset tables for the common ECU families (EDC15, EDC16, EDC17, MED9, MED17, MD1, Simos18, MG1, MD1CS, MG1CS) and falls back to pattern-scanning (looking for ASCII strings matching the SW number format) for less common ones. Coverage isn’t 100%, but it’s >95% on the families that make up the bulk of European chiptuning work.

Does the tool work on petrol ECUs too?
Yes. The offset tables include the Bosch MED and MG families (petrol DI) and the gasoline Simos family. Pops & Bangs, launch control, and Stage 1/2 work on petrol files identifies identically to diesel.

What’s the difference between identification and decryption?
Identification reads metadata fields (SW, HW, VIN) without modifying the file. Decryption converts a vendor-encrypted slave into a plain BIN you can edit. Decryption costs money per call (vendor API); identification is free. The Quick File Tool does identification first; it only decrypts if you ask it to.

Can I run identification headless from a CLI?
Yes. The same identification logic runs from php artisan tunersuite:identify path/to/file.bin for batch processing. Useful when migrating a library of historical files from a previous portal — you can re-index a directory of 1,000 files in one command.

Next step

If you’re running TunerSuite, the Quick File Tool is on your master dashboard as of v2.8.159 — drop a file, see what happens.

If you’re shopping and the portal you’re evaluating asks you to type the SW number manually, you’re going to spend more time identifying files than tuning them. TunerSuite £699 one-time covers identification, decryption (with your vendor API key), library matching, and the full file-request workflow.

For a deeper read on the ECU families this tool recognises, see the EDC15/16/17 vs MED17 guide. For more on which reading method to use when, the OBD vs Bench vs Boot guide is the right starting point.