DEEN Download

The emergency brake

Ransomware runs inside the guest with every privilege there is. It can see the antivirus in there, switch it off, and does. What it cannot see is the layer on which its hard disk is in truth a file on somebody else's machine — and on that layer it is unmissable.

The emergency brake in Phillux with watched guests and incidents

Why this cannot be evaded

Encrypted data looks like noise — close to eight bits of entropy per byte, where ordinary data is nowhere near. The ransomware reads your file and writes it back to the same place as noise, thousands of times over, faster than a person ever writes.

That is not a heuristic a new variant gets around. It follows from the job: it cannot avoid the signature without ceasing to be ransomware.

Not a threshold — a turn

A fixed threshold would be useless. Measured on a plain Debian guest, 19 % of the blocks that hold data are already at 7.8 bits or above, because compressed files, packages and images look like noise too.

So what is watched is not the height but the turn: a probe that held ordinary data at the last calm reading and now holds noise. Each disk is compared against its own picture of itself, and the number that comes out says something a person can act on — this much of what used to be ordinary data is now noise.

Freezing, not killing

The reaction is to suspend, and that is the whole design. Freezing takes milliseconds and stops everything where it stands — and it is completely reversible: resume, and the guest has not noticed anything.

Because it is reversible, it is allowed to be aggressive. A measure that destroys something has to be sure before it acts; one that can be undone with a click can act on a suspicion. From the first turn to a halted guest was six seconds in the measurement.

Killing, by contrast, throws away exactly what is most valuable at that moment: the memory of the machine that was in the middle of encrypting.

Containers: the same question, one layer up

A container has no disk image, and the block layer underneath it belongs to the host with every other guest's data mixed in. So the watch asks the same question of the files instead: it remembers a few hundred of them and reads them again every round.

Two things are better here. It can name the files — under a disk image there are only blocks, and no block says which document it belongs to. And freezing a container is a write to a cgroup file: no time at all, no cooperation from inside.

One thing is worse, and it is written down: only the beginning of each file is read, so something that encrypts only the tail of every file moves nothing here.

The key in the frozen memory

A suspended guest stands still in the middle of the act. Its memory is complete, the host can write it out at leisure, and the thing doing the encrypting still has its key in hand.

AES does not encrypt with the key directly — it expands it once into a schedule that every block then uses, and that schedule is recognisable without knowing the key, because each word is derived from earlier ones by a fixed rule. A wrong guess survives the first check with a probability of about one in four billion.

What this claims and what it does not: a schedule found here proves that something in that guest was doing AES. It does not say which key encrypted which file, and it does not by itself decrypt anything. Searching the memory image is a permission of its own, because that image holds everything that was in the guest at the moment it was halted.

It buys the hour, not the year The brake stops the spread; it does not undo what was already written. What undoes that is a backup that has been proven to restore — see backups.

Try it on your own hardware

A month, complete, with no registration and no data asked for. The installer writes a whole server — a spare machine or a VM is the place for it.