Self-Destructing Drive Experiment

I thought a fun project would be to experiment with drive shredding techniques I can launch remotely. I want to set up a panic button of sorts I can activate from any location connected to the internet that will not only wipe the data of a drive, but overwrite it with nonsense so it can't be recovered. I was wondering what /sec/'s opinion is on the most efficient way to pull this off. My initial idea was a rudimentary batch command like dd if=/dev/urandom of=/dev/sda bs=1000k, which I tested out on an old craptop, but the problem I ran into was that the command could only write over so much data before overwriting crucial parts of the code, crashing the computer. It did a pretty fine job of turning the boot sector into alphabet soup, but it's possible that entire chunks of the drive were spared when the OS finally crashed. It also took like an hour for a pretty small drive. I'm thinking the best way to circumvent this is to use a liveUSB bootable service like DBAN, but I'm not sure what the best implementation for that would be, assuming I wanted to have it ready to be activated remotely at a moment's notice. Should I just run a script that sets the bios to boot from a USB and then reboot? Is it a better option to install it to grub so I don't have to clog up a USB port all the time, or is that going to run into the same issue as before with it overwriting itself? Are there any other recommended alternatives that take these things into account, or provide an option for some kind of wipe confirmation after it's done? Honestly I see a lot of sites online recommending DBAN but I don't see a whole lot of testimonies that speak to its effectiveness one way or another. Has anyone designed a similar process in the past? What tools did you use to get the job done? How pleased were you with the results? inb4 "physically destroy the drive, it's the only way to be sure". This is just a fun little thing I wanted to see if I could do, I'm not intending to base my opsec on this killswitch.

Simply encrypt the data in a LUKS container, then use the command to wipe the keyslot when it's time. man cryptsetup

Oh and don't forget to unmount and close the container first so the master key is wiped from RAM.

iirc Peter Sunde has a system like this. His computer is encrypted and rigged to shut down with an password protect command on his phone. He asked the police for a phone call and used the phone to remotely shut down the computer. Once turned off, the key is no longer in ram and the drive is unrecoverable. There is also USBKill, which was developed after the arrest of Ross Ulbricht. You whitelist known and trusted USB devices, so if an unknown USB device is detected, a killswitch command is executed.

>>4349 >>4346 Arduino, GSM board, HDDs, Electromagnet. This is the best way and is probably a lot easier to set up.

>>4347 This is the best solution afaik. It's common practice for paranoid server owners to set up a system where a call or sms can kill everything by shredding the luks header of your drives, then shutting down the system by both turning it off and cutting off the power supply

>>4349 no server content was erased. the drives were simply shut down, and encrypted with LUKS beforehand. what Sunde did was simply a remote >shutdown -h now source: I've been told by a reliable source. also: jag är från Stockholm.

>>4347 >Simply encrypt the data in a LUKS container, then use the command to wipe the keyslot >>4752 >This is the best solution afaik. "best" where "best" is defined as "simplest to implement". I'd recommend a few variants to >>4353 >Arduino, GSM board, HDDs, Electromagnet. which also physically destroy the drive. Place the drive in a fire-proof container or above an acid bath. Use the Arduino & GSMboard to operate an actuator to burn the drive. After a pre-determined time a remote cam takes a photo and returns a picture message. The electromagnet suggestion may need a Faraday cage (an old microwave will do) to limit interaction with other devices. Also you would need to consider removing the shielding on the drive for it to be more effective, but doing so may cause interference during operation. If you use an RPi instead of Arduino you could set the server drive as a networked drive of the RPi, then completely shred it without crashing the computer.

>>4775 >"best" where "best" is defined as "simplest to implement" And also as in "I'm sure this isn't a Heath Robinson level machine and will actually work should it be needed" :) Anyways, I don't think you can easily obtain a store an acid that's agressive enough to destroy a harddrive in a matter of minutes and even if you could, I wouldn't let it near my sensitive data in case something tips over it or worse

>>4779 Not many fall into the category of those who need to blow up a building containing their Faraday cage because someone made a phone call, so a simple LUKS rewrite should be sufficient for most.

One benefit of using the LUKS method is that you can reuse the drive after a wipe. If you don't want to use the cryptsetup command because it requires you to type "YES" at a prompt, you can write urandom up to the point in drive where the LUKS header is stored with something as simple as cat /dev/urandom > /dev/sdX.

Why wait for a command? If they jam the network at your place it will never go through. Instead built in a failsafe that shuts your server down when it can't connect to some IP/do a handshake with some ssh server/whatever OR you send the shutdown command (or rather, fail to send a keepalive command within some timeframe). Also keep in mind that overwriting data counts as destruction of evidence in most countries which is something you don't want to be charged with. (Automatically) shutting down an encrypted harddrive and "forgetting" the password on the other hand is perfectly legal in most developed countries. This has also the added benefit that you're able to recover from an accidental shutdown (for example because your internet went down).

>>4346 https://www.youtube.com/watch?v=Tr7qnX3S2KA Deviant Ollam did this at Defcon years ago. If you want the drive to be toast, you need to physically destroy it. >>4353 No, it still leaves tons of forensic data on there. Unless your magnet is ungodly strong. >>4775 Acid doesn't work, and drives aren't easily flammable. If you watch the above video, the most effective method of total destruction was a blowtorch applied directly to a spinning platter over the entire circumfrence of the platter for several seconds at a time. >>4806 Forgetting works, until they realize that's what you are doing and design a sting to get the password. I'd say the best thing to actually do is schedule regular deletes of all data. "hey sorry, I delete everything every 12 hours. Always have, always will. It's automated." That might still count as "destruction of evidence" but it erases any form of intent for a particular crime. Then again, it's absolutely abnormal behavior, which might cause the law to "find a way" to charge you. >Also keep in mind that overwriting data counts as destruction of evidence in most countries which is something you don't want to be charged with. (Automatically) shutting down an encrypted harddrive and "forgetting" the password on the other hand is perfectly legal in most developed countries. This has also the added benefit that you're able to recover from an accidental shutdown (for example because your internet went down).

>>4808 >destruction of evidence IANAL, but it has to actually become evidence before it can actually count as "destruction of evidence." If you destroy it before they classify your hard drive as evidence it is fine.

>>4808 >drives aren't easily flammable true, but thermite does wonders ;)

>>4808 >until they realize that's what you are doing and design a sting to get the password. True, but at that point they already visited you once, so you can take additional precautions. Plus, pretty much the only way to get a password out of a running machine is a cold boot. To do that they occasionally wire your setup up to a portable power source and do it in their lab, where there's no network, Your monitor kicks in and shuts off the machine. >I'd say the best thing to actually do is schedule regular deletes of all data. Depending on what data you have that might not be viable >>4809 >IANAL, but it has to actually become evidence before it can actually count as "destruction of evidence." If you destroy it before they classify your hard drive as evidence it is fine. It's not, at least not over here in Germany. Basically if they can show that you deleted data because you were aware of, or expecting a raid in which the drive could have been evidence, it is to be assumed that the evidence was on there from a legal perspective. In most cases destroying data because of a raid is a very bad idea.

>>4810 People have tried thermite too, and it's not worth the trouble. People get obsessed with Thermite, I don't know why. At that point you may as well blow the thing up with C4. You will be attracting the interest of the higher authorities once you start melting soykaf with explosives. >>4811 >True, but at that point they already visited you once, so you can take additional precautions. Plus, pretty much the only way to get a password out of a running machine is a cold boot. To do that they occasionally wire your setup up to a portable power source and do it in their lab, where there's no network, Your monitor kicks in and shuts off the machine. "They" can do cold boots in-situo. "They" are familiar with the technique you just described. >Depending on what data you have that might not be viable Then I'd focus my efforts on making my data impossible to locate. It all depends on what you are encrypting. > In most cases destroying data because of a raid is a very bad idea. Getting raided in the first place is usually game over. It's better to have a good reason to have the illegal thing you have. The authorities are not morons. Say they decide you have missile launch codes, or cheese pizza or something. Say you manage to destroy all the data via magic. They are going to assume you will do it again, and just wait for you access the data again later and nab you when you aren't being paranoid. With the added benefit of knowledge of your methods. In fact they might do a fake raid first just to see how you protect yourself. Better to just keep anything incriminating in ram, and leave the hard storage to less accessible sources.

>>4812 >At that point you may as well blow the thing up with Yup. See >>4780 >Not many fall into the category of those who need to blow up a building containing their Faraday cage

>>4349 Working off this: 1) Make a modified liveboot that wipes any attached drives on boot 2) When you go out, set your primary boot device in BIOS as the liveboot 3) Have your computer running with a program active to remotely restart it when a phone call is made to the unique number, as described in >>4349

>>4815 The standard practice these days is to collect the drives before interviewing the suspect. The drive will be examined on a separate computer, offline.

>>4845 You'll obviously encrypt them anyways to prevent exactly that

So much crypto-nerd fantasies up here and if they want to get you they can just plant evidence, works best. But let me try to take this whole topic serious for a moment, let's at least assume we are the good guys, maybe some whistleblower. GSM will never be an option. Some police units do have stingrays and mobile signal jammers to make it impossible to warn your buddies. The room with the server itself must be booby trapped, a dead man switch cutting the power hard if opened by a person unaware how to deactivate it. Low-tech saves the day again. Now how do we stop them using cold sprays to extract the leftover keys from RAM? Got a solution for that as well: 1) buy one of the things in my picture (electrical fuse with timer) 2) door to server room opens triggers the timer 3) the 110-240V current activates a relay for 10 seconds that interrupts power to the server 4) server is down, only cold boot is a threat now 5) server boots after 10 seconds again, during boot we run some code to cycle the RAM with 0s and 1s 6) RAM is clean If you have a room with a steel door they would have to cut through a wall to defeat this logic. Only works for people with basements, not your average burger home where you can punch a hole into the gypsum walls with your fist.

>>4349 Found this https://www.reddit.com/r/privacy/comments/2lr5jr/what_app_did_pirate_bay_founder_use_to_shut_his/ https://github.com/ashwinvasudevan/TBTWC-Mozilla https://www.quora.com/What%E2%80%99s-the-best-way-to-setup-a-mobile-app-to-send-a-signal-to-my-computers-Shut-down-immediately-to-encrypt-my-Mac-like-Pirate-Bay-Peter-Sunde-did https://guardianproject.github.io/haven/

>>4992 I vomited a little reading the replies to OP in that reddit link. But still informative. Sure an oldschool tone dial PIN is an extra layer of not frying yourself by accident, but again. GSM is unreliable and might be jammed on purpose by SWAT.

>When Police and SWAT Teams arrive at a crime scene, they deploy Tactical Jammers in order to control communications of criminals and terrorists. http://www.secintel.com/ecom-catshow/tactical_jammers.html now your whole gsm breakout board is useless

>>4347 rephrased: Simply encrypt the data in a LUKS container, then use the command "luksKillSlot <device> <key slot number>" to wipe the keyslot when it's time. This http://linuxbsdos.com/2010/10/06/how-to-manage-disk-encryption-passphrases-and-key-slots/ explains it better.

>>4782 >you can write urandom up to the point in drive where the LUKS header is stored How do you find that "point" [does it have something to do with sectors?] in a drive? Or am I missing something obvious here?

>>4996 Read the fukken manual head -c 1052672 /dev/zero > /dev/sde1; sync

>>4997 Ensure you clear the key in ram as well. Why not just use /dev/urandom though? A small detail to be sure.

>>5002 Because unless you use an ancient 100MB IDE drive the tracks on modern SATA disks with several TB are so tiny that one wipe is enough, even if just zeroes. https://www.vidarholen.net/~vidar/overwriting_hard_drive_data.pdf

>>5003 For disk drives, fair enough, my main concern was flash storage, since it doesn't rely on polarity, NAND/NOR drive controllers also write to random sectors. Idk, with the gained write speeds you would be able to iteratively wipe and re-wipe the LUKS headers. One underrated advantage of SSD's is that... you can just set them on fire without worrying about the Curie point.

>>5012 Also, here is a nice paper about Flash memory forensics. http://www.dtic.mil/dtic/tr/fulltext/u2/a509258.pdf

>>5013 Countering that, TRIM and grbage collection make it useless at least on modern SSDs: http://articles.forensicfocus.com/2014/09/23/recovering-evidence-from-ssd-drives-in-2014-understanding-trim-garbage-collection-and-exclusions/ >>5012 Just use a fast Mersenne-Twister to fill any flash drive, the only thing that legitimately worried me about flash is that at least SSDs could utilize compression algorithms. So your 500GB file of zeroes could be 4k on the drive and you might not realize it at first. Hence incompressible (pseudo-)random data is sufficient. >you can just set them on fire without worrying about the Curie point. why be destructive? they write fast enough to be cleaned in minutes