It's not an actual backdoor. An attacker found a way to exploit Windows after booting it up in this recovery mode. The security of files on the device depends on it being impossible for Windows to be pwned by an attacker on any surface exposed before the user is unlocked.

This is why operating systems like GrapheneOS disable the USB port on the initial boot to limit the attack surface that an attacker has.

▲

tsimionescu 11 minutes ago | parent [-]

Having a specific file name trigger the decryption to happen automatically, while also removing said files after this is achieved, is an extremely unlikely bug. I think for most people evaluating this, the onus is now on anyone thinking this is not a backdoor to prove how a mistake in the code can trigger this very specific scenario.

This is like finding out that an OS accepts an SSH private key circulating online that the sysadmin for those OS boxes never authorized, and saying "wait, we don't know that this is a backdoor into that system, the attackers just found a bug".

	▲	charcircuit 2 minutes ago \| parent [-]
		>Having a specific file name trigger the decryption That is not what happens. There is nothing wrong with decrypting the drive. If you just powered on the computer normally, it will "trigger the decryption." There just isn't way to read a file from the lock screen. This exploit is getting you to a state where the drive is unlocked but the user has access to a command prompt. A command prompt, unlike a basic login screen gives the user the ability to actually see the contents of arbitrary files. >specific file name It's a specific file name because Windows stores transaction logs under that name. >also removing said files after this is achieved It doesn't seem farfetched for a transaction log to be deleted after it is successfully replayed.