Comment by tsimionescu
6 hours ago
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".
>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. If it was a random name it wouldn't be able to exercise this vulnerable code.
>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.