I just finished reading a novel in which the home computer of a suspect needed to be accessed by a law enforcement agency. An officer duly searches, and finds, a list of login candidates and their passwords. Confiscated, the laptop is now in the scientific lab. Some officer is about to enter the [Windows 7] login passphrase for the normal user but is stopped by one of the Crime Lab Experts. The Expert says “Don’t do that, it might be a special trigger passphrase which will start a whole disk erase operation.”
I like to think of myself as halfway computer savvy, but I cannot think of way to make [Windows 7] start wiping my entire disk if I enter some passphrase for my usual user account. There’s only one passphrase per account, so I can’t provide a secondary “destroy all data” passphrase for my normal account.
I can see it happening if a different user account is selected and login gained. But not for my normal account.
I’m sure there are magic programs, hacks and esoteric ways to do what I’m describing. But for the 90% of us lay folks using home computers, is “will self destruct in five seconds” a real capability?
Maybe not for a real “usual account”, but how do you know which accounts on the list are the real ones? Make an account called “User” or “Guest” or something that you never use, write it and its password down on a piece of paper, and then put a startup script in it that deletes everything if that account ever logs in.
But it’s still not a practical protection against the police, because if they’re at all competent the first thing they do will be to clone the hard drives.
It could have been done with a custom GINA DLL in versions of Windows prior to Vista. The GINA mechanism allowed the login prompt displayed after CTRL-ALT-Del to be replaced with a custom DLL that could display a new dialog and handle authentication to things like Novell servers.
On current versions of Windows, you would have to write a Credential Provider, or wrap code (or hook) around an existing credential provider. So possible, but very unlikely.
The story part is unclear - if they found a list of login candidates and passwords, how do they know for sure which one is the ‘usual’ user account and not a decoy deliberately set up for this scenario? Even without setting up an alternate login program, you could just use GuyAS as your regular account, and have ASGuy as the account with the drive erase program. So it’s certainly possible, but like other people have pointed out, this won’t do much good against a competent search, because the first thing they’ll do is clone the disk so there’s no chance of losing the data. They also might not bother with a login, since you can generally access data on the drive by placing it in another system.
Encrypting the drive would make it much harder to get into, as they’d have to defeat the encryption to do anything, and encryption programs can be equipped with a ‘brick this drive if password X is entered’ software (I’m not sure if any commercial programs actually have this).
Here’s some real world cases of police being stymied by encrypted drives (a few of the early ones are non-English):
That’s how it works in many (most?) flavors of Linux. Why wouldn’t you do that? Overwriting a large drive takes some time if it is something like a hard disk. Of course, if you have no time, they grab the system while it is powered on or clone it anyway, and there still may be viable backups somewhere.
And how does that work? Even if they were able to trash, let’s postulate, 1 gigabyte per second, it should still take a few minutes to get to all of your files.
Where do you have the idea it happens in seconds? As far as I can tell those are designed to lurk on your drive for days and encrypt not only your local data, but remote back ups and such as well before the hackers tell you it’s time to pay up.
Ransomware takes much longer than that to encrypt files, but it does it in the background so you don’t see the pop up that it’s done so until it’s finished and typically has already ‘phoned home’ to let the ransomer know. There’s no need for it to even try to operate in seconds, it’s pretty much either going to be caught by anti-malware instantly and stopped, or left to run for hours without an issue. There’s also some malware that works by popping up a window saying something like ‘you’ve been infected, download this/call this number to save yourself!’, but in that case the ‘you’ve been infected’ part is a lie and the actual attack is the thing it wants you to download or that the ‘support line’ you call will get you to install.
I subjected one of my lab computers to ransomware several years ago to see how the process… ummm… processed.
It takes a bit longer to encrypt files than it does to just copy them from one location to another. So small amounts of data are effectively instantaneous while larger files take a noticeable amount of time.
Do you have a link showing that? I just did a quick search to find a Linux drive encryption that would brick the drive if a particular password is entered, and it looks like cryptsetup definitely doesn’t have a built in way to do that. I’m not sure what the technical term for ‘delete all keys if this password is entered’ is, though, so it’s hard for me to search it out. I know that all three of the windows-based software packages I’ve used doesn’t have that option, at least in open documentation in the versions I encountered.
I should also mention, if someone is really worried about having their drive searched, they could rig up an electromagnet in a booby trap to try to wipe the drive if the PC case is opened incorrectly or moved without disabling the device. This runs the risk of the device not working, the device accidentally getting triggered, or the device injuring someone or starting a fire (which could be a worse crime than what the evidence shows), and it certainly makes the person setting it up look guilty. I haven’t seen anywhere that one of these has been used IRL, but I’ve read paranoid types talking about setting one up.
idk if this would work on Windows, but on a Linux system, here’s what I’d do:
Create a user account named “guest” and one called “myrealname”
I use the account “guest” for normal usage. The “myrealname” account is the poison pill with root permisions.
I set up a login script for the poison pill account. It can’t be thorough because it needs to be fast, but I think you could automatically delete the partition table and maybe corrupt some important stuff like the filesystem superblocks.
When they request the username/password, I happily give them myrealname/myrealpassword. Then the fun begins.
The data would likely be mostly recoverable with enough effort. But it would deter or delay intruders who aren’t very resourceful or determined (local LEO or CBP taking an unwarranted stroll through your hard drive).
For fictional interest purposes, it’s important to note that the sensitive data may not be on the laptop at all, so there would be no point in “wiping the hard drive.” The sensitive info might be in an external database or attached storage. In that situation, it would be easy for a login script to silently trigger destruction of externally stored data when a network connection is detected.
Analysts might detect your laptop sending the destroy command, but if they don’t control the external data source, they probably can’t stop it before it’s finished the external wipes.
Lots of plot holes to fill there, but there are paths to do what OP is asking.
You can do it with cryptsetup using the luksAddNuke command. I found some old tutorials explaining how it works under Kali Linux, Ubuntu Linux, etc., including how to patch cryptsetup in case that command is not supported out of the box (it’s been a few years since the patch came out, though, so maybe it’s more widespread)
If I were doing something bad enough that needing a self destructing drive was an actual concern, I’d grab one of these SSD modules and then rig it so that when someone opened the case to clone the drive it would trigger the switch to melt itself. I know that drives can be cloned by booting the system from an external device, but that’s what full drive encryption is for.
Thanks for the responses. It appears I am correct that multiple accounts (on my Windows 7 workstation) are needed to achieve the self-destruct goal.
I forgot disk cloning as a preservation mechanism. Once a clone is made the crime lab can just try a random account and hope they get in without the self-erase taking place.
I agree, encryption is the preferred way to go. If necessary, subtly modify the encryption algorithm so the encryption is nonstandard. However, obviously to decrypt the drive, you need an executable encryption /boot process that is not encrypted unless you get really technical. A forensics team could analyze that to figure out the method of encryption.
The first thing someone might do is unplug the drive and connect it as an external/extra drive to another system. If the drive is not encrypted, it could be readable. you would find the current most used userid by the last write dates of the user files for each user - in Windows, that’s C:\USERS
If I were to set up a “kill switch” userid as OP described - presuming someone could figure out the password - I would set so that you login normally, but if you don’t run that obscure icon on the desktop within 60 seconds, the wipe begins. But if the drive is unencrypted, the first thing law enforcement does is make a copy. Maybe an added security would be to wipe the customized encryption program -better than nothing, but not foolproof. (another thing is the deadman switch - if I don’t run the program when prompted every, say, 20 minutes then the wipe kicks in, in case I’m interupted by a raid…
Wipes and virus encryptions are not instantaneous. I found one enterprise, many years ago, where the shared drive had been encrypted up to the folders beginning with “C” - at which point the AV must have realized there was a virus active and killed it or denied access from that workstation.
Even more ludicrous is the claim by encryption viruses - “we have downloaded your personal data!!” Considering until recently most smaller enterprises had limited bandwidth and these virus programs are not terribly sophisticated - how does it find and download the critical data among hundreds of gigabytes of spreadsheets, email folders, etc.? Odds are all they did was encrypt thanks to someone clicking on the wrong email attachment. The ones downloading critical data are those who manage to get remote control access and use human intervention to peruse the files.
I don’t know that Security by Obscurity is a reliable technique, or technically necessary assuming that the entire drive is encrypted via a secure algorithm with the keyfiles necessary to boot kept physically separate, on a USB drive for example. If the latter were not recoverable, the forensics team should not be able to get more than random garbage, under reasonable assumptions.
The wiping doesn’t have to erase the entire drive, just the key used to encrypt the drive. The way it usually works is that a password is used to lock a large encryption key. The key is then used to encrypt the drive. Once that key is gone, the drive cannot be decrypted, even if you have the password. Instead of having to overwrite TBs of data, you only have to overwrite 4KB, which is going to be almost instant on even the slowest spinning hard disk.
As mentioned, the obvious counter to a self destruct password that wipes the key, is to copy the (encrypted) key before trying passwords.
Other techniques include things such as the encryption key not being stored on the same media as the encrypted data. If the attacker gets the encrypted drive, but not the USB drive with the key, then the encrypted drive is worthless to them.
Some drives implement hardware encryption, and the encryption key is stored in a place that can’t be copied. This tends to have huge problems, and is not nearly as safe as software encryption, though. The hardware encryption is often full of bugs; is closed source, so may have back doors; and the non-copyable key location may just be a place on the drive hidden from the OS, but accessible when accessing the drive directly.
Subtly modifying encryption algorithms (unless you are an actual encryption specialist) is usually a really good way to make your encryption easier to break.
The road to broken encryption hell is paved with the good intentions of non-specialist programmers who just thought - I can change this and make it better/easier/faster
