[Dshield] Dead hard drive disposal

Tomas L. Byrnes tomb at byrneit.net
Thu May 24 21:02:12 GMT 2007


There's lots of good info on this here:

http://cmrr.ucsd.edu/Hughes/subpgset.htm

As Valdis has pointed out, "zero fill" or other active writing methods
are quite different than passive "put it next to a speaker" ones.

And thermite works well, but I think you might have a problem with the
fire and police departments if you used it in a civilian setting. 

 

> -----Original Message-----
> From: list-bounces at lists.dshield.org 
> [mailto:list-bounces at lists.dshield.org] On Behalf Of 
> Valdis.Kletnieks at vt.edu
> Sent: Thursday, May 24, 2007 1:47 PM
> To: General DShield Discussion List
> Subject: Re: [Dshield] Dead hard drive disposal
> 
> On Thu, 24 May 2007 11:16:36 MDT, Open Phugu said:
> 
> > A one-pass overwrite with zeroes can easily be recovered. You just 
> > connect a digital storage oscilloscope to the head preamp, 
> read the whole disk, and average the output.
> > You then subtract the average from the output, and get the original 
> > data,
> 
> Please demonstrate an actual case of this being *done* on a 
> modern disk drive as opposed to just hand-waving about how to 
> do it.  It's *not* as easy as it looks. Hint - an all-zeros 
> run of data is *not* stored as zeros, but something else, 
> specifically so clock drift issues don't become a problem.
> Even the Gutmann paper understands this - the *reason* for 
> all the funky data passes is so that you get level 
> transitions where you wouldn't otherwise get one, and get 
> actual all-zero and all-one patterns written even though 
> all-zeros/ones bit patterns don't write that.  And that's 
> just MFM and RLL, it gets even stranger with PRLM and later...
> 
> The hard drive in my laptop: 156301488 512-byte hardware 
> sectors (80026 MB)
> 
> http://www.seagate.com/staticfiles/support/disc/manuals/notebo
> ok/momentus/7200.1/SATA/100320528a.pdf
> 
> Recording method                      16/17 EPRML
> Recording density BPI (bits/inch max) 700,000
> Track density TPI (tracks/inch max)   114,000
> Areal density (Mbits/inch2 max)       81
> 
> That's getting pretty damned dense. Contrast this to a 
> popular disk drive from the same vendor in Gutmann's era, the 
> Barracuda:
> 
> 1993 Seagate Technology ST12550 "Barracuda" 2,139 Megabytes, 
> ten 3.5" disks.
> http://www.seagate.com/support/disc/manuals/scsi/7780c.pdf
> 
> Tracks per inch 3,047
> Bits per inch   52,187
> 
> Lots more room for each bit there.
> 
> A nice discussion of the technical details:
> 
> http://www.storagereview.com/guide2000/ref/hdd/geom/dataRequir
> ements.html
> 
> Note that MFM and RLL (which were the prevalent methods when 
> Gutmann originally wrote his paper) are significantly 
> different than EPRML, the most common method used today.  To 
> get the data densities, they've *already* dropped the signal 
> strength down to the point where you need to do some fancy 
> signal processing to read the data back even if it *isn't* 
> overwritten...
> 
> > Not. The drive might have detected several bad sectors and might 
> > refuse to write to them.
> > Data might still be recoverable.
> 
> Hmm.. Let's actually think for a moment.
> 
> Now let's say that the drive is getting old and near failure 
> - you may have as many as several hundred reallocated sectors 
> (if you have more than several hundred, that drive is needing 
> to be replaced *already*).  So you're looking at *literally* 
> one-in-a-million blocks are bad.  And a normal "read" 
> operation is going to go to the reallocated block, not the 
> bad one, as will 
> 
> So to read the *bad* block, you're doing that same "read the 
> residual field"
> trick that nobody is actually *demonstrating* the ability to 
> do on a *good* disk - except you're trying to do it on a 
> block known to be so *bad* that the drive electronics gave up 
> on it, even after ECC and retries. So you've got bad 
> unpredictable oxide, and the drive's made anywhere from 3-4 to a dozen
> attempts to over-write it, with *unknown* data rather than zeroes.   
> 
> (For bonus points - did the gear you're using to do this have 
> the right circuitry to raise the probe vertically if it 
> encounters a disk flaw, or do you damage the probe when you 
> hit a bump? :)
> 
> And even if you get a readable block, you have to figure out 
> what it means, totally devoid of any filesystem info.
> 
> Forensics challenge time - what data did you just get here:
> 
> % cat rand.c
> #include <stdlib.h>
> 
> main() {
>         srand(time(0));
>         printf("Your random number is %d\n",rand() % 
> 156301488); } % cc -o rand rand.c % ./rand Your random number 
> is 31879307 % su # dd if=/dev/sda bs=512 count=1 
> skip=31879307 | hexdump -C
> 1+0 records in
> 1+0 records out
> 512 bytes (512 B) copied, 4.2114e-05 s, 12.2 MB/s 00000000  
> 15 43 83 c0 6e 54 d1 94  99 92 15 96 2f 46 30 08  
> |.C..nT....../F0.| 00000010  ac 19 77 b0 2e b3 6a 05  4f e4 
> d1 1a 50 36 22 c7  |..w...j.O...P6".| 00000020  c4 27 92 19 
> 12 3e ac 4f  62 6a 01 0b 20 81 5e d2  |.'...>.Obj.. .^.| 
> 00000030  ad b5 87 e9 a9 8c 9f a4  b3 51 e7 93 da 68 2b 3b  
> |.........Q...h+;| 00000040  54 86 cf 2a d5 4b 07 01  9b 92 
> b7 ad 30 82 6b f7  |T..*.K......0.k.| 00000050  ab a0 a6 64 
> d8 a8 d8 14  44 2d 3e 13 92 c8 73 e4  |...d....D->...s.| 
> 00000060  0a 41 90 e1 ca b7 3c 37  57 fd 13 95 4f 67 67 53  
> |.A....<7W...OggS| 00000070  00 01 00 5e 3b 00 00 00  00 00 
> ce 0b 6e 1f 3e 01  |...^;.......n.>.| 00000080  00 00 36 93 
> b5 0b 24 3e  ff 3e ff 45 3c 45 4b 49  |..6...$>.>.E<EKI| 
> 00000090  3d 3d 4d 4b 4e ff 4f ff  3e ff 39 ff 37 ff 33 ff  
> |==MKN.O.>.9.7.3.| 000000a0  31 ff 49 3a 37 3a 39 38  4f 4a 
> ff 90 6c 8f 83 b6  |1.I:7:98OJ..l...| 000000b0  5f be 05 0c 
> cc d5 f8 f7  9f 1e e6 31 8b d4 ca db  |_..........1....| 
> 000000c0  a2 c4 18 de c5 fe 88 af  f1 e9 80 b7 a1 3b b0 58  
> |.............;.X| 000000d0  90 d8 2e 01 53 08 e6 48  40 ff 
> b1 14 de f0 98 0f  |....S..H at .......| 000000e0  8a 07 0d 90 
> 00 0f 30 08  00 9e 2b 1e 5d 2e 72 29  |......0...+.].r)| 
> 000000f0  ba a7 81 72 f0 dd f5 6e  35 46 2d e1 92 50 1d 79  
> |...r...n5F-..P.y| 00000100  6f 32 72 f2 2c 32 f7 5e  fa d0 
> 26 62 7d 07 00 d8  |o2r.,2.^..&b}...| 00000110  f7 31 da 68 
> 7c c0 49 69  55 35 12 c2 00 80 ec dd  |.1.h|.IiU5......| 
> 00000120  3f ec 2c 69 3a ea 73 9b  bf 3c 66 a3 3e c7 7c 4e  
> |?.,i:.s..<f.>.|N| 00000130  27 cd 83 6a 7c 8f 53 01  a0 20 
> 7c 92 c1 20 cb b9  |'..j|.S.. |.. ..| 00000140  36 eb 11 67 
> f5 a8 25 4e  0c b4 66 65 44 0a c3 e6  |6..g..%N..feD...| 
> 00000150  93 fd 64 1b b9 92 31 4e  82 80 3d 05 6c 7d a8 b2  
> |..d...1N..=.l}..| 00000160  92 c2 55 b0 7f fc ae 88  67 aa 
> b4 ec bd f4 9b 92  |..U.....g.......| 00000170  b2 61 b4 cc 
> 79 3e b7 73  b2 e4 d2 4c ba fa 1a c0  |.a..y>.s...L....| 
> 00000180  a5 95 e9 cc 5d 13 74 6a  56 4b bc d3 6a 51 02 72  
> |....].tjVK..jQ.r| 00000190  2d a8 c2 e3 c1 f4 42 47  d6 74 
> f6 aa da 50 8c b4  |-.....BG.t...P..| 000001a0  ed ce ab 28 
> 74 7b 43 2e  ad 27 5d d0 09 08 d8 21  |...(t{C..']....!| 
> 000001b0  e4 00 2b 08 85 9d dd 91  6d 57 50 f1 ed 94 b2 52  
> |..+.....mWP....R| 000001c0  17 79 0c f7 28 49 b1 11  36 28 
> fa 43 c3 ae bd 3a  |.y..(I..6(.C...:| 000001d0  f6 e2 9d 76 
> 35 2d ed d5  da a6 6f 19 33 eb ba 0d  |...v5-....o.3...| 
> 000001e0  e6 82 ea a2 6d 79 26 c4  3f 35 4a be 5f 6c 04 be  
> |....my&.?5J._l..| 000001f0  21 0f b8 b6 2d 75 e0 f1  28 f8 
> 7c 7b e2 92 61 10  |!...-u..(.|{..a.|
> 
> (Yes, I know what it is, but only because I had access to the 
> entire filesystem structure at the time. :)
> 
> Go ahead - use the program to get yourself 10 or 20 random 
> block numbers, dump them out, and ask yourself "what is it" 
> and "how sensitive is the data I just got", and decide for 
> yourself.  For what it's worth, recent copies I've seen of 
> DOD5220.m and the NIST guide already mentioned don't seem to 
> think that "bad data blocks" is a data-leakage issue.  You 
> only need to overwrite the *accessible* blocks for Secret and 
> below, and Top Secret and up you're basically looking at 
> thermite and similar.
> 
> 



More information about the list mailing list