Crypt / Decrypt

Decrypt and encrypt slave ECU files online

Slave tools hand you an encrypted read that no editor will open. We decrypt it into an editable binary, and once you have made your changes we seal it back into the original container so your tool will flash it. Both directions are self-serve and take about a minute.

  • Decrypt a protected read into an editable binary
  • Re-encrypt your modified file back into its container
  • KESS3, Autotuner and MMS Flex
  • Both directions, processed automatically
Upload the file, pick your tool, download the result.

How it works

  1. Upload the file For a decrypt, that is the protected read straight off the tool. For an encrypt, upload the original read together with your modified binary.
  2. Pick your tool Alientech KESS3, Autotuner or MMS Flex. The container format follows from the tool, so there is nothing else to configure.
  3. Download the result A decrypt returns a plain binary you can open in any editor. An encrypt returns a flash-ready file in the tool's own container.

Supported tools

Each tool protects its slave reads differently and hands back a different container. These pages cover what that means in practice — what a master licence changes, why an editor will not open the file, and what you get back.

MMS Flex is supported by the service in both directions; it has no page of its own yet.

Prefer to link your device? Linked, we work in the native container and the decrypt step disappears from your workflow — and it is the route to take when a job needs more than the file on its own.

Why a slave file has to be decrypted at all

Tool manufacturers protect the reads their slave devices produce. The data is real, but it is wrapped in an encrypted container tied to the tool, so opening it in WinOLS or any other editor gives you nothing usable. That protection is what separates a master licence from a slave one.

Decrypting unwraps that container into an ordinary binary — the same bytes the ECU actually runs — which you can then edit like any master read. Encrypting is the return trip: your modified binary goes back into the original container, correctly formatted and accepted by the tool that produced it.

Supported tools

These three are handled end to end, in both directions. Each has its own container format and its own quirks, which is why the flow asks you which tool the file came from rather than trying to guess.

  • Alientech KESS3 — encode and decode of protected slave reads
  • Autotuner — slave file decrypt and re-encrypt
  • MMS Flex — .mmf container decrypt and re-encrypt

What you get back

A decrypt returns a readable binary with the checksum layout intact, so an editor can map it correctly. A re-encrypt returns a file in the same container the tool expects, which means it writes back without complaint.

If you would rather not decrypt at all, the alternative is linking your device to us. Once linked we can work on the file in its native container, and the decrypt step disappears from your workflow entirely.

Frequently asked questions

Alientech KESS3, Autotuner and MMS Flex, in both directions — decrypt and re-encrypt.

About a minute in normal conditions. The job is processed automatically as soon as the upload finishes.

Not to have a file unlocked — that is what this service does, per file. Linking is the other route, and the one to take if you would rather skip decryption altogether and work in the native container, or if a job turns out to need more than the file on its own.

Yes — that is exactly what the encrypt direction is for. Upload the original read alongside your edited binary and we return it sealed in the original container.

Decryption does not change the calibration, so checksums are left as they are in the source file. If you want the checksum corrected after editing, run the file through the tuning service.
Ready when you are. Upload the file, pick your tool, download the result.
StageGen
© 2026 StageGen · by CoderIO