(untitled)

Why do people drill their hard drives when shred exists? Can't you make a shell script that shred s illegal stuff from your computer and run it before the police bust down your door?

>>16444 Simple -drilling is potentially faster than running a command -it destroys the data irreparably, with no hope for recovery, even a slim one. Shred SHOULD provide the same irrecoverable deletion, but it can potentially fail, a 10mil drill to the disc cannot. -it looks cooler. But I get your point, chummski.

Shred is designed for HDDs not SSD, and nobody even knows what SSD firmware is doing when you tell it to delete stuff. The whole mystery firmware thing probably applies to HDDs too at a lesser level. Also shred takes a long time. If it's literally a police bust down your door timeframe, you are just going to have to rely on FDE or preferably an amnesiac system.

>Why do people drill their hard drives Because it looks more spectacular on TV.

They don't. HDDs get degaused and/or shredded. SSDs get shredded. Sufficient fire also works in a pinch.

if you have FDE all you have to do is overwrite the LUKS partition header and power off, the data will be gone forever.

>>16444 >Can't you make a shell script that shred's illegal stuff from your computer and run it before the police bust down your door? Overwriting a harddrive takes hours. And even if all the bad things are in a single file, parts of the data will get cached in other parts of the harddrive like swap and thumbnails and things. >Why do people drill their hard drives when shred exists? Because even if you overwrite the whole drive you are not guaranteed to get everything. When sectors fail the harddrive firmware will transparently remap them so shred can't reach them and the original data is still intact for investigators to find.

>>16465 Adding to this, if you're doing forensics on a disk that recently had the shred command run on then stuff still exists: https://www.sans.org/blog/digital-forensics-a-quick-note-about-shred/ "...indirect blocks are file metadata that ends up being placed in the midst of the block runs that make up the file. shred is apparently unable to clobber this information...If you look at the shred source code, it simply opens the file like any normal user process, jumps to the beginning of the file, and proceeds to overwrite the file from beginning to end. As a normal user process, it has access to the data blocks that make up the file content, but not the indirect block metadata. The file system drivers in the OS 'hide' the indirect blocks from the shred program. A program that wanted to clobber the indirect block data would have to have superuser privileges so that it could open the raw disk device and attack the necessary blocks directly. Normal user space programs like shred aren't going to have this level of access." "The other implication, of course, is that if you're 'wiping' data off a drive using shred, you should just be aware that there actually will be residue left on the drive. If you really want to wipe a drive, you're better off using dd as root to write zeros over the entire drive via the raw disk device."

>>16465 >he thinks shred actually overwrirtes the entire disk anon lol

>>16467 Doesn't shred -uvzn3 /dev/sda?

>>16473 probably a waste of time compared to dd if=/dev/urandom of=/dev/sda

>>16467 >>16474 Yes you're so smart for finding the dumbest interpretation from an ambiguous sentence and then projecting it back onto the author. Thankyou for your valuable contribution to the thread.

>>16444 Because it takes about an hour to overwrite the data on a 500-1TB drive. Drilling isn't very effective on a hard drive if someone is willing to spend time and enough money. A HDD degausser + drilling should work.

>>16444 I'm not really knowledgeable in this area, but I've heard people say overwriting, deleting, or corrupting the LUKS headers is sufficient. What do you all think of this?

>>16567 The main zeitgeist premise today is that any modern hard drive or ssd is a black box with unknown inner workings. You write data, it writes data, you read data, it gives you data, you send "delete data" command, it replies "sure pal, data deleted, trust me", you overwrite it with zeroes or random, it pushes the cycles to clean banks and reassigns file system position in the controller. Thus having any kind of cryptographic keys or even passphrase-protected headers residing on same drive where encrypted data itself is located, "erasing" their supposed location is not enough. Keeping the header on separate drive (a small flash memory chip, SD card) is a cheap solution to this. Crushing an 8MB fingernail-sized chip back into sand is as trusty as you could come near "erasing" old encrypted data without mechanically damaging the source drive. I'm not sure why even threads like this keep appearing, are they posted by bots? Nobody under actual threat of police raid keeps data on unencrypted drives, or has time to do software overwrite when they bust your door at 5AM and put you face into floor.

>>16570 > has time to do software overwrite when they bust your door at 5AM and put you face into floor. That reminds me, why do people install such soykafty flimsy doors?

>>16570 Very good points. Yeah, I agree there's really not much that can be done in the span of time it takes for a van of feds or cops to pull up, get out, and kick down your door. Shit, I probably wouldn't even be able to rip out a drive and physically damage it enough in that timespan. Anyone who acts like they can is either really overestimating themselves or they have a mile long driveway. Plus, let's be real, if the cops are coming to no knock you, you're probably already fuarrrked.

>>16444 shred cannot overwrite dead sectors a drill can

>>16571 The front door is rarely the problem. The point of failure is typically shallow screws securing the strike plate. You can add longer screws and it will survive a few good kicks but the door jamb will eventually fail. To do much better, you need to install some kind of brace. >>16570 >>16572 There was a good Defcon talk years ago about destroying hard drives. The TL;DW is thermite isn't practical, nail guns work well, high explosives are effective if you have them and can use them, and you can blow SSDs apart by pushing current through them. If you're expecting the cops, you can plan for them. If you automate everything then you might even beat the destruction of evidence charge.

>>16576 Yeah, by Dr. Zoz IIRC. I met him at defcon 24, really cool dude.

What about a some kind of DIY degausser enclosure within your case

>>16584 All you would need inside the case is a coil of wire next to the drive. I have no idea how you would spec this though and how to make sure that it's making the platters unreadable and not just unreadable by you.

>>16571 Americans, they know nothing better. In all seriousness in raid videos filmed in Brazil or Russia where armored doors are far more common, and walls are not made of cardboard either, it takes a team with heavy duty metal saws, clamps and torches 15 minutes to cut the toughest door.

>>16587 That's an interior door in a house that's been converted to apartments. Depending on where that is and how old it is, a door constructed like that may be a code violation.

>>16464 >he doesn't about data forensics ngmi

>>16610 do you even know how data forensics works? You can't even recover the data for a LUKS partition normally, why do you think you'd be able to magically extract information from a blob of random data overwritten with random data?

>>16592 >blah blah amerishartlegaleseterm#17827 regulayshun violayshun Sure, pal. I've seen enough 80's horror and action movies to confidently state that any building in your country can be entered by cutting a hole with a handsaw or punching with a fist.

>>16466 >A program that wanted to clobber the indirect block data would have to have superuser privileges so that it could open the raw disk device and attack the necessary blocks directly. Normal user space programs like shred aren't going to have this level of access So it would have to run in kernelspace on Windows? How would you even do that? What if I somehow run bash off a usb (not boot from it though, that takes too long)

>>16570 >Keeping the header on separate drive (a small flash memory chip, SD card) is a cheap solution to this. Crushing an 8MB fingernail-sized chip back into sand is as trusty as you could come near "erasing" old encrypted data without mechanically damaging the source drive. How do you do this?

>>16576 This is a real door: https://www.youtube.com/watch?v=ET9SNXpeORY

>>16587 got a story for the vid?

>>17378 From what I remember some psycho kicked in this dudes door with a machete and the guy killed him with his pistol.

>>17209 Straight from the cryptsetup(8) manpage. To specify a detached header, the --header parameter can be used in all LUKS commands and always takes precedence over the positional <device> parameter. ... --header <device or file storing the LUKS header> Use a detached (separated) metadata device or file where the LUKS header is stored. This option allows one to store cipher‐ text and LUKS header on different devices. This option is only relevant for LUKS devices and can be used with the luksFormat, open, luksSuspend, luksResume, status and resize commands. For luksFormat with a file name as the argument to --header, the file will be automatically created if it does not exist. See the cryptsetup FAQ for header size calculation. For other commands that change the LUKS header (e.g. luksAdd‐ Key), specify the device or file with the LUKS header directly as the LUKS device. If used with luksFormat, the --align-payload option is taken as absolute sector alignment on ciphertext device and can be zero. WARNING: There is no check whether the ciphertext device speci‐ fied actually belongs to the header given. In fact, you can specify an arbitrary device as the ciphertext device for open with the --header option. Use with care.

I prefer wipe(1), which is in apt

>>16444 You can't write over dead sectors. But you can drill through.

firmware/hardware attacks. If the firmware or hardware themselves are compromised, how is shred supposed to help?

>>16587 IM GLENN QUAGMIRE

Are you ever truly 100% confident that you've really wiped something? Are you really truly confident that your networked machine isn't compromised? Unless you're working on something totally airgapped you really never know. Besides the software/hardware might not be working correctly or like you think it does maybe it has some quirk ie trying to shred a single file on a journaling file system. Smash that soykaf and scatter the pieces. If I absolutely positively had to give one of my old drives away I'd dd if=garbage and encrypt the whole thing with luks a bunch of times, obsessively, maybe dban it. Even then i'd be a very unhappy camper about someone else having their grubby dickbeater hands all over my hardware.

If you have a SSD you can just flush it down the toilet

>>16444 SMR drives might just ignore those write commands, SSHD or other hybrid nonstandard firmware might just ignore those. Even bad sectors remain untouched.

Can magnets Do the same as drilling for HDDs?

>>16444 Bad sectors cannot be written to. Shred just tells the hard drive to write data over the sectors it can. Its possible that large chucks of data are still on the dead sectors of the drive. A drill on the other hand physically mangles the data on the drive making it impossible to recover even to some insane data scientist luck would become the key factor in the possibility of data recovery. Always ALWAYS destroy drives. Drives are cheap but data is expensive.

>>18678 For the most part no - you need very powerful magnets to flip polarity but something to note is that when dealing with magnets that powerful the warping of the drive itself and heat would do the most damage.

just encrypt ur data and overwrite the LUKS partition header with dd if=/dev/urandom when the piggies come. Much faster than shred and basically same chance of recovery as drilling.

>>18681 wouldn't you just charged with obstruction of justice if you did that though? unless you can come up with some insane story about how you just accidentally wiped your partition header

>>18705 I imagine it's the same with a drill. I don't reckon "I slipped and fell and accidentally my hard drive sixteen times" is going to fly.

>>18705 >wouldn't you just charged with obstruction of justice if you did that though? This implies they know you did it. If you do it right they have no way of proving that it isnt just an effectively blank disk with no partitions or filesystems on it. This is the one advantage of pure software tools for this type of thing; it doesn't make it obvious that something was done. Smashing your hard drives with a sledgehammer might be a more effective way to delete the stuff on them, but it sure makes it look like you were trying to delete the stuff on them.

>>18680 Are there any alterbatives to drilling/microwaving then? Around here destruction of evidence can get you locked up even if there is no proof so something more subtle would be good to know

>>18753 And can the luks header and having it in a usb be done on an already luksed machine?

>>18680 FUUUCK YEAH! MAGNETS BITCH!

>>18755 Yes, The luksHeader is at offset zero of the luksDevice. You can make a backup with cryptsetup luksHeaderBackup --header-backup-file [SAVE_NAME] Zero the header on disk (not the whole disk!) Mount now with cryptsetup luksOpen --header [SAVEFILE] Per the cryptsetup manual, --header overides whatever is on disk.

>>18993 >Zero the header on disk If it's an SSD then the header could still be recovered by a forensic analyses because of wear leveling. This is also an issue if you check the password, someone can still use the old header + old password to unlock the disk.

Where does one begin if one wants to learn stuff like this?

>>19001 You mean digital security stuff? There are a lot of books on this board, lots of online sources, and then CTF teams and classes for you to look at once you have learned a bit. If you do not have much experience with computers, install some linux distro like arch on a virtual box and try to learn to write scripts in the terminal/ how computers work at a more basic level. Reading the board is decent in and of itself for getting started, helps you to get used to the terminology. Here is a book. May just be soykaf, but it is the only "hacker" book I have on hand.

>>19003 Seems the board refuses to take the PDF. Just look around the board, I got the book from here anyways.

what about the microwaves?

>>19007 i microwaved my macbook while losing my mind and it survived, typing on it right now. Was sandwiched between two thinkspads though and those died.

These guys are busy asking questions on how to destroy their harddrives, meanwhile I have panic attacks whenever I think about my HDs failing. It's silly, but whenever I imagine my death, the first thing I think about is how I'm going to archive the stuff on my drives. I have an easystore and WD external hdd, and a couple of samsung ssds. What can I do to prevent harddrive failure? I've thought about burning my pirated movies onto dvdrs (I know about muh disc rot, but I dont live in a weird climate and all my DVDs and tapes from decades ago are fine). All of my archived internet/music soykaf that's completely blanked off the internet, and the recorded gameplay from games that dont even have service anymore, that's the soykaf that'll be responsible for my suicide if it ever dies along with my harddrive.

>>19069 >What can I do to prevent harddrive failure? Don't drill holes in them. In all seriousness; leave them disconnected in a protected environment (shock proof, radiation proof etc) and make backups (at least 2) that you keep in another physical location (preferably different town further away in case of bomb strike).

>>19011 Ah yes, the MacMelt club. My favorite machinic cuisine.

>>17379 >guy killed him Incorrect >That scene unfolded on Feb. 22 last year in Pocatello, Idaho, according to the Idaho State Journal. The footage, which can be viewed below, was released in court during Thomas' sentencing hearing on Thursday. He pleaded guilty to attempted murder and aggravated assault as part of a plea agreement, and was sentenced to at least 10 years in prison.

>>19069 RAID (redundant array of inexpensive disks)

>>19069 Do what >>19081 says. The safest place I can think of right now that's extremely cheap would be a concrete cube lined with anti-ESD foam (looks black). Foam absorbs shock and prevents electricity from reaching the devices at the center (and electricity would have an extremely difficult time getting through concrete in the first place).

>>19108 the inexpensive part is the most important part of the acronym. >>19110 fml, imagine if those were poured concrete around some kind of vaccuum sealed hard drive. good house building material. j

>>16587 I LOLD at the quality of these doors. IKEA furniture is literally more durable than this soykaf. WTF t. Europoor here

>>17215 le Romanian quality guys must have been deeply disappointed no one were inside

>>19000 I recently changed my luks passphrase because I was using an insecure one before. You mean to tell me it was in vain?