KESS3 files: decrypt, edit, re-encrypt
KESS3 is Alientech's programming tool for engine and transmission control units. What it hands you depends on your licence: a master reads files in the clear, a slave reads them encrypted. This page explains why that is, and what to do when the file you own will not open in your editor.
- Decode a protected slave read into an editable binary
- Re-encode your modified file back into its container
- OBD reads, decoded and re-encoded in both directions
- About a minute, from €9.95
What KESS3 is
KESS3 is a hardware programming tool from Alientech, used to read and write ECU and TCU software. It is the device end of the job: it talks to the control unit, pulls the software out and writes a modified version back. It does no calibration work itself — the editing happens elsewhere, in WinOLS or a comparable editor.
The part that trips people up is not the hardware, it is the licence. KESS3 is sold in master and slave configurations, and the two behave very differently with the files they produce. Buying the tool does not automatically mean you can open what it reads.
Master and slave: what actually differs
Alientech are direct about this. With a master configuration you read the files in the clear — you can work independently, modify the software yourself or send it to whichever file provider you choose, and you can build your own network of slave users beneath you.
With a slave configuration you read and write encrypted files, and only your master can decrypt them. The tool still works: it reads, it writes, and functions such as DTC handling, DataLogger and DynoDrive remain available. What you do not get is the ability to open the calibration and change it, because the file that lands on your disk is a sealed container rather than a binary.
This is a deliberate commercial arrangement, not a fault. A slave tool is cheaper and is bought with a designated master behind it. It becomes a problem the day you want to work with a provider other than that master, or edit something yourself.
Why your editor will not open the file
Open a slave read in WinOLS and you get nothing useful. The bytes on disk are not the bytes the ECU runs — they are an encrypted representation of them, wrapped in a container tied to the tool. Automatic map search finds nothing, because there are no maps to find in ciphertext.
Alientech's own vocabulary for the two directions is decode and encode rather than decrypt and encrypt; the terms are used interchangeably in the wider trade and mean the same thing here. Decoding unwraps the container into an ordinary binary — the same bytes the control unit actually executes — which behaves like any master read once it is out.
What StageGen returns
A decode returns a plain binary with the checksum layout intact, so an editor maps it correctly and a checksum plugin recognises it. Where a read spans several memory regions, the result is delivered as a zip containing each file rather than being flattened into one.
An encode is the return trip. Upload the original read together with your modified binary and we seal your changes back into the container the tool expects, so KESS3 writes it without complaint. Nothing about the calibration is altered in either direction — this service moves a file between two representations, it does not tune it.
- Decode → editable binary (.bin), or a .zip for a multi-region read
- Encode → flash-ready file in the KESS3 container
- Checksums are left exactly as they are in the source file
OBD reads — and what is not covered
The service handles KESS3 reads taken over OBD. Boot and bench reads are not supported yet: if you upload one the job is rejected rather than silently returning something that will not flash, which is the behaviour we would want in your position.
If your file came off the bench, the alternative today is linking your device to our master, which removes the decode step from the workflow entirely rather than working around it.
How it works
Three steps, the same as every job on the crypt/decrypt service. There is nothing to configure beyond telling us which tool the file came from — the container format follows from that.
- Upload the file — the protected read for a decode; the original read plus your modified binary for an encode
- Pick Alientech KESS3 as the tool
- Download the result — typically about a minute later
Price, and the alternative to paying per file
A crypt or decrypt job is €9.95 and covers a single file. For occasional work that is usually the whole answer, and there is nothing to set up first.
If you are decoding files every week, linking your device to our master is worth considering instead: once linked we work in the native container and the decode step disappears rather than being paid for each time. Linking is also the route when a job needs more than the file on its own. The form is below.
Linking your device
Unlocking a file and linking a device are two routes to the same place. Per job, you upload the file and we return it decrypted. Linked, we work in the native container and the decrypt step disappears from your workflow — which is also the route to take when a job needs more than the file itself.
Frequently asked questions
Related
- Autotuner slave files The same problem on a different tool — and the same way out of it.
- Crypt / Decrypt The service itself, covering KESS3, Autotuner and MMS Flex in both directions.
- WinOLS projects Where the file goes once it is editable — and how to skip the mapping work.
- Tuning files If you would rather not edit it yourself: upload the read, pick the options, download the result.