Slave vs Master ECU Files Explained: What Each Format Means and Why It Matters for Tuning

The first time a workshop owner sees a .slave.zip file on their screen, the natural reaction is “what do I do with this?”. The vendor tool that produced it knows. The vendor’s API knows. Most of the chiptuning portals built around those vendors also know. The workshop owner — especially one running a self-hosted portal — is left wondering whether to unzip it, whether the contents are the same as a plain .bin, and what the price difference between “slave” and “master” actually buys.

This post is the plain-English explainer. By the end you’ll know exactly what a slave file is, how it differs from a master file, why every vendor (AutoTuner, KESS3 / Alientech, Flex / Magicmotorsport, bFlash, CMD Flash, MPPS) wraps the same underlying BIN differently, and how a modern self-hosted portal handles all of them without you needing a separate desktop app for each.

What a “BIN” actually is

Before we get to slave/master, the foundation: a BIN file is a raw binary dump of the calibration region of an ECU. It’s what an ECU stores in flash memory — fuel maps, ignition maps, boost targets, torque limits, DTC tables, immobiliser data, the works. A typical Bosch EDC17 calibration is 4 MB; a modern MD1CS petrol ECU is 8 MB.

A tuner opens a BIN in WinOLS / ECM Titanium / DimSport’s editors, modifies map cells, recalculates checksums, and saves the new file. The new file is, structurally, still a BIN — same length, same offsets, different bytes inside the maps.

Writing that modified BIN back to the ECU is what people mean when they say “flashing”. The bench tool, the OBD tool, or the BDM rig is the wire between the BIN on the laptop and the ECU on the bench.

What a “master file” is

A master file is a plain BIN. No vendor wrapper, no encryption, no envelope. You can:

• Open it directly in WinOLS / ECM Titanium / a hex editor
• See every byte
• Modify any cell
• Write it back through any flashing tool that supports the ECU

Master files are what professional tuners work with. They’re also what every workshop’s archive ends up containing: a folder of original_filename.bin and tuned_filename.bin per job, ready to re-use when the same SW/HW combination comes through again.

The catch: most modern bench tools and OBD tools do NOT give you a master file directly. They give you a slave file.

What a “slave file” is

A slave file is a vendor-encrypted wrapper around the same underlying BIN. The vendor’s tool reads the ECU, wraps the bytes in a proprietary envelope (typically .slave.zip, .bfp, .ktag, or a custom extension), and ships that to you. Inside the envelope:

• The actual BIN, encrypted with a vendor key
• Metadata (vendor request ID, slave device ID, sometimes SW/HW numbers in cleartext)
• A cryptographic signature that prevents you from tampering with the envelope

To turn a slave file into a master file, you call the vendor’s API: “here’s my slave file, here’s my API account, give me the BIN inside”. The vendor’s server checks your account balance, decrypts the file, returns the plain BIN. Each decrypt typically costs €5-€20 depending on vendor.

Slave files exist for business reasons, not technical ones:

1. The vendor monetises every decrypt — €10 per file × tens of thousands of customers = serious revenue
2. The vendor can revoke a customer who breaches their terms (sells the tool, runs counterfeit hardware) by refusing future decrypts
3. The slave file format provides a clean handoff between low-cost field-tool customers (who just want the encrypted file) and tuner-customers (who pay for decrypts)

You can run an entire chiptuning workshop on slave files alone IF you have an active API balance with the relevant vendor.

The five vendor formats you’ll actually see

A workshop accepting files from end-customers typically encounters these envelope formats:

1. AutoTuner — .slave.zip

A standard ZIP archive containing the encrypted BIN plus a slave.xml declaring vendor request ID, slave device ID, and (usually) the SW/HW numbers in cleartext. Decryption goes through AutoTuner’s vendor API at €5-15 per call. AutoTuner is dominant in Eastern Europe and gaining ground in the UK / Western Europe.

2. KESS3 / Alientech — .ktag / .kess family

Alientech’s KESS3 and K-TAG tools produce encrypted reads with their own envelope. Older KESS V2 5.017 (China clone) reads are usually plain BINs already. KESS3 V2 (genuine, post-2021) is slave-wrapped. Alientech’s reseller network is enormous worldwide.

3. Magicmotorsport — .bfp (Flex / FlexBox)

Magicmotorsport’s Flex tool wraps reads in .bfp (BinFlexProject). The envelope includes the BIN plus extensive metadata about the read session (voltage, timing, retry count). Flex is the dominant bench tool in the Italian and Spanish markets.

4. bFlash — .bflash / .bf2

bFlash (formerly Bitbox) wraps in a custom envelope similar to slave.zip in structure. Decryption is API-based. Strong in Germany and Benelux.

5. CMD Flash / Trasdata / MPPS

A long tail of older tools. Most of these produce plain BINs by default — they predate the slave-file business model. If a customer hands you a CMD Flash dump, it’s already a master file in 80% of cases.

How slave vs master changes your workflow

Three workflow differences matter for a workshop:

Difference 1 — Pricing per job. If a customer’s file requires a vendor decrypt, your cost per job includes that decrypt fee. A €10 AutoTuner decrypt + your usual tuning labour + checksum + reflash = your job cost. If the same customer brings a plain BIN (master file), you skip the decrypt fee.

Difference 2 — Library reuse. Master files in your library are re-usable indefinitely. Slave files are NOT — each customer’s slave file is locked to their vendor account. You can decrypt a slave file once, store the resulting master, and re-use the master forever; but you cannot share that decrypted master back to other workshops without breaching the vendor’s terms.

Difference 3 — The “compatible file” problem. When a new customer’s slave file matches the SW/HW of a master file already in your library, you can serve the tuned BIN from your library without re-decrypting their slave. The customer doesn’t need their slave decrypted at all — you have the master, you tune from there, you re-encrypt the result back to their slave format using the same vendor API.

The third point is what makes library matching economically valuable. A workshop with a mature library can serve 30-55% of incoming slave files from their master library, paying zero vendor decrypt fees on those.

Re-encrypting: the round-trip

Decryption isn’t the only vendor API call you make. After tuning, you also need to re-encrypt the modified BIN back into a slave format the customer’s vendor tool can write to the ECU. Workflow:

1. Customer uploads customer.slave.zip (encrypted by their AutoTuner)
2. Your portal calls AutoTuner API → receives plain BIN (cost: ~€10)
3. Your tuner modifies the BIN in WinOLS / built-in map editor
4. Your portal calls AutoTuner API again → wraps the modified BIN into a new .slave.zip the customer can write back (cost: ~€10)
5. Customer downloads the modified slave, writes to ECU via their AutoTuner

So a typical AutoTuner job costs you ~€20 in vendor API fees, plus your tuner’s time, plus your overhead. Pricing your service at £60-£120 covers it comfortably.

A library-match job — same SW/HW already in your master library — costs ~€10 (one re-encrypt, no decrypt needed). Pricing the same £60-£120 makes the library-match job almost pure margin.

What about plain BINs from customers?

Some customers will hand you a plain BIN — typically because they used a tool that reads in master mode (older KESS V2 5.017, CMD Flash, bench reads via OpenPort 2.0). In that case there’s no vendor envelope at all. You tune the BIN, return a tuned BIN, and the customer writes it back through their tool.

A modern portal should accept all of:
– Plain .bin, .ori, .bak files
– AutoTuner .slave.zip
– KESS3 .kess / .ktag
– Flex .bfp
– bFlash .bflash
– ZIP archives containing any of the above

The portal’s file identification routine detects the format from magic bytes + filename and routes to the right decryption path automatically. The customer doesn’t pick a format from a dropdown; they drop the file in and the system figures out the rest.

The “wrong format” failure mode

A real-world failure that shows up on chiptuning forums monthly: customer reads their ECU with tool A (e.g. AutoTuner), uploads the .slave.zip to a workshop, the workshop tunes and returns a plain BIN (master file). Customer tries to write the plain BIN through their AutoTuner — the AutoTuner refuses, because it expects a .slave.zip to write back.

The customer thinks the tuned file is broken. It isn’t — it’s just in the wrong envelope. The workshop should have re-encrypted before delivery.

Modern portals catch this at upload: if the customer’s source file is a slave, the delivery must be a slave. The system tracks the format end-to-end and re-wraps automatically. Self-built portals that skip this step generate exactly this kind of confused dispute.

What this looks like in TunerSuite

A workshop running TunerSuite with the AutoTuner / KESS3 / Flex / bFlash connectors enabled accepts every file format above. The flow:

• Customer drops a .slave.zip (or .bfp, .ktag, plain BIN — whatever).
• The portal’s identification routine extracts SW/HW from the envelope.
• If a library match exists → serve the matching tuned BIN, re-encrypt to the customer’s vendor format, deliver in seconds.
• If no library match → call the vendor API to decrypt, route the plain BIN to the tuner, the tuner modifies, the system re-encrypts, the customer downloads in the original format.

The vendor API keys live encrypted in your portal’s settings — you bring your own AutoTuner account, your own Flex account, etc. The portal handles the round-trip; you pay the vendor only for the calls you actually make.

The connectors are bundled into the TunerSuite licence — £699 setup + £49.99/month — no separate “AutoTuner edition” pricing, no per-decrypt platform markup on top of what the vendor charges you. See the vendor tool comparison for the trade-offs between AutoTuner, Flex, Alientech KESS3, and bFlash.

FAQ

Can I decrypt a slave file without an active vendor API account?
No. The vendor’s encryption is the whole point — the decrypt requires the vendor’s server to do the work using their key. No account = no decrypt. If a customer hands you a slave file from a vendor you don’t have an account with, you have two options: open an account with that vendor (typical minimum €200-€500 starter balance) or refuse the job.

Can I share a decrypted master file with other workshops?
The vendor’s terms of service usually forbid this. In practice, master files of common SW/HW pairs circulate informally in chiptuning communities, but a workshop operating professionally should treat each decrypted master as belonging to the customer who paid for the decrypt. The library that grows on your portal is your asset — it works for your customers, not for third parties.

What’s the difference between a slave file and an OBD vs bench vs boot read?
Independent dimensions. The slave/master split is about envelope format. The OBD/bench/boot split is about how the file was extracted from the ECU. A bench read can be slave OR master depending on the tool; an OBD read can be slave OR master depending on the tool. The OBD vs bench vs boot guide covers the extraction side.

What if the customer doesn’t know which tool they used?
The portal can identify the format from the file’s magic bytes — PKx03x04 is a ZIP (likely AutoTuner slave), specific byte sequences identify Flex, KESS3, etc. Filename also helps (*.slave.zip, *.bfp). The customer doesn’t need to know; the system tells them what they uploaded.

Are slave files DRM?
Functionally yes — they’re vendor-locked digital artefacts that require ongoing payment to use. The chiptuning industry has accepted this as the price of access to modern vendor tools. The arms race between “open” tools (CMD Flash era) and “closed” tools (AutoTuner / Flex / KESS3) has gone firmly toward closed since 2018.

Next step

If you’re a workshop owner trying to decide which vendor tool ecosystem to commit to, the AutoTuner vs Flex vs Alientech vs bFlash comparison walks through pricing, coverage, and API behaviour for the four major options.

If you’re already established and just want a portal that handles all of them cleanly, the TunerSuite licence — £699 setup + £49.99/month bundles connectors for AutoTuner, KESS3 / Alientech, Flex, and bFlash. Bring your own vendor API keys; the portal handles the format conversion. See the AI ECU Analyzer feature for the file-identification side.