
What is the best way to wash a disk? I tried this but it is taking forever. dd if=/dev/zero of=/dev/sdg1 Thanks

On Mon, Sep 2, 2013 at 3:02 PM, David Zuccaro <david.zuccaro@optusnet.com.au
wrote:
What is the best way to wash a disk?
http://www.dban.org/ cheers, / Brett

On 2013-09-02 15:04, Brett Pemberton wrote:
On Mon, Sep 2, 2013 at 3:02 PM, David Zuccaro <david.zuccaro@optusnet.com.au> wrote:
What is the best way to wash a disk?
cheers,
/ Brett
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
[1]
Yep dban is what I used to wipe all the branch servers and workstations from NAB a few years back, never had any issues with it

Christopher M. Bailey wrote:
On 2013-09-02 15:04, Brett Pemberton wrote:
On Mon, Sep 2, 2013 at 3:02 PM, David Zuccaro <david.zuccaro@optusnet.com.au> wrote:
What is the best way to wash a disk? http://www.dban.org/ [2]
cheers,
/ Brett
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
[1] Yep dban is what I used to wipe all the branch servers and workstations from NAB a few years back, never had any issues with it Whilst it does state: "...DBAN prevents all known techniques of hard disk forensic analysis. It does not provide users with a proof of erasure, such as an audit-ready erasure report."
From memory the consensus at ComputerBank many years ago was that if one's life was on the line and NSA wanted the info; dismantle the drive and dissolve the drive platters carefully in in a large quantity of molten aluminium.. Apparently the problem is that the magnetic domains which represent bits are analogue. So whilst the heads on the original drive can detect no magnetic domain; someone with a souped up head might be able to. Initially the method we used wrote zero's to all sectors but eventually to speed things up I think we ether used a generic LLformat utility and /or proprietary utilities from the respective drive manufacturers; probably via a self booting DOS floppy. apologies to luv-main; Rohan McLeod

Warm soapy water and a clean sponge.... But seriously, destroy the disk if you want it to actually be completely safe from being recovered. Many datacenters and large firms use physical disk shredders. For home use a sledgehammer, magnet, and depositing the pieces into random city rubbish bins is something I have adopted in the past. Apparently an angle grinder was sufficient to satisfy the GCHQ when they had The Guardian destroy hard drives recently, and thining about it, and angle grinder is a great idea - and fun too. In regards to dd, I would run a few of passes, and make one of them if=/dev/random. As stated earlier, altering the bs should help with the speed, but if you though zeroing was slow - wait til you see experience the random write ;) I place a fairly low trust in scrub and shred. I know shred suffers some issues on journaled and raid configurations, and scrub may have the same problems. I guess it depends on your threat model, so rewinding a bit - who are you wanting to prevent accessing your data? This greatly informs the conversation. The methods offered above, and in many of the replies thus far, assume a very sophisticated adversary. Daniel On Mon, Sep 2, 2013 at 5:12 PM, Rohan McLeod <rhn@jeack.com.au> wrote:
Christopher M. Bailey wrote:
On 2013-09-02 15:04, Brett Pemberton wrote:
On Mon, Sep 2, 2013 at 3:02 PM, David Zuccaro <david.zuccaro@optusnet.com.au> wrote:
What is the best way to wash a disk? http://www.dban.org/ [2]
cheers,
/ Brett
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
[1] Yep dban is what I used to wipe all the branch servers and workstations from NAB a few years back, never had any issues with it Whilst it does state: "...DBAN prevents all known techniques of hard disk forensic analysis. It does not provide users with a proof of erasure, such as an audit-ready erasure report."
From memory the consensus at ComputerBank many years ago was that if one's life was on the line and NSA wanted the info; dismantle the drive and dissolve the drive platters carefully in in a large quantity of molten aluminium.. Apparently the problem is that the magnetic domains which represent bits are analogue. So whilst the heads on the original drive can detect no magnetic domain; someone with a souped up head might be able to. Initially the method we used wrote zero's to all sectors but eventually to speed things up I think we ether used a generic LLformat utility and /or proprietary utilities from the respective drive manufacturers; probably via a self booting DOS floppy.
apologies to luv-main; Rohan McLeod
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main

On 09/02/2013 05:45 PM, Daniel Cross wrote:
Warm soapy water and a clean sponge....
Wont work! detergents leave residue which can collect bits and bytes in random order and make the shiny disk surface greasy so the heads stick. I have found a log splitter to be pretty effective if used sharp end down and swung particularly hard to impact a drive which is positioned neatly on an anvil or piece of railway line! Roger

On 02.09.13 18:01, Roger wrote:
On 09/02/2013 05:45 PM, Daniel Cross wrote:
Warm soapy water and a clean sponge....
Wont work! detergents leave residue which can collect bits and bytes in random order and make the shiny disk surface greasy so the heads stick. I have found a log splitter to be pretty effective if used sharp end down and swung particularly hard to impact a drive which is positioned neatly on an anvil or piece of railway line!
Ah, the splitting hammer¹, not the 20 tonne hydraulic log splitter in the woodshed ... I thought it was taking destruction to new heights. ;-) Having a wood heater, I'd likely extract the (typically aluminium) platters, and drop them into the fire. On a winters night, with the air register open, it'll melt aluminium quite readily. (Then all the bits go up the chimney, I guess.) Or, a pair of tinsnips would allow the thin platters to easily be snipped into strips, and then little squares, which could be sprinkled into bins along the street on bin night. If the spooks put that back together, they'd be really disappointed with what's on my drives. Erik ¹ My splitting hammer (cum block splitter) gets to split 8 - 10 m^3 of firewood each year. It wouldn't leave a disk drive in a good state. -- I sense much distrust in you. Distrust leads to cynicism, cynicism leads to bitterness, bitterness leads to the Awareness of True Reality which is referred to by those-who-lack-enlightenment as "paranoia" I approve. - fortune

On 09/02/2013 10:42 PM, Erik Christiansen wrote:
On 02.09.13 18:01, Roger wrote:
On 09/02/2013 05:45 PM, Daniel Cross wrote:
Warm soapy water and a clean sponge....
Wont work! detergents leave residue which can collect bits and bytes in random order and make the shiny disk surface greasy so the heads stick. I have found a log splitter to be pretty effective if used sharp end down and swung particularly hard to impact a drive which is positioned neatly on an anvil or piece of railway line! Ah, the splitting hammer¹, not the 20 tonne hydraulic log splitter in the woodshed ... I thought it was taking destruction to new heights. ;-)
Having a wood heater, I'd likely extract the (typically aluminium) platters, and drop them into the fire. On a winters night, with the air register open, it'll melt aluminium quite readily. (Then all the bits go up the chimney, I guess.)
Or, a pair of tinsnips would allow the thin platters to easily be snipped into strips, and then little squares, which could be sprinkled into bins along the street on bin night. If the spooks put that back together, they'd be really disappointed with what's on my drives.
Erik
¹ My splitting hammer (cum block splitter) gets to split 8 - 10 m^3 of firewood each year. It wouldn't leave a disk drive in a good state.
Mine too! I did try it on hard drives, the bits are more easily washable! Aluminium cans thrown in the fire are supposed to help clean the chimney so I'm guessing the heat of the fire will also clean the hard drive. But! Linux has so far survived anything thrown at it. The installation may just hang around in the firebox....waiting....! If you see a flames screen saver in the firebox door, rejoice Linux survived.... Roger

On Mon, 2013-09-02 at 17:45 +1000, Daniel Cross wrote:
I guess it depends on your threat model, so rewinding a bit - who are you wanting to prevent accessing your data? This greatly informs the conversation. The methods offered above, and in many of the replies thus far, assume a very sophisticated adversary.
Daniel
Let us assume that the adversary is not a three-letter-government-agency; not that I consent to three-letter-government-agencies accessing any of my information.

Well, in that case probably Dban will be sufficient for your needs. If still going with dd I agree with the bs=1M switch. Incidentally, a discussion with a friend this evening lead us to the decision that a good way (although involved) to erase a drive would be: 1) Open disk enclusure. 2) Use bench grinder to create aluminium powder from the top of the disk enclosure 3) find something rusty, (or another source of iron oxide) and create powder. 4) mix 50:50 by volume. 5) if available add some magnesium (left over guy fawks sparklers?) 6) pour powder over HDD spindles. 7) Light and step well back while the platters melt. I might try this in coming months and report my results ;) Daniel On Mon, Sep 2, 2013 at 6:30 PM, David Zuccaro <david.zuccaro@optusnet.com.au
wrote:
On Mon, 2013-09-02 at 17:45 +1000, Daniel Cross wrote:
I guess it depends on your threat model, so rewinding a bit - who are you wanting to prevent accessing your data? This greatly informs the conversation. The methods offered above, and in many of the replies thus far, assume a very sophisticated adversary.
Daniel
Let us assume that the adversary is not a three-letter-government-agency; not that I consent to three-letter-government-agencies accessing any of my information.

I should actually add a disclaimer to the above. Don't actually do this unless you are sure and safe in what you are doing! :P On Mon, Sep 2, 2013 at 9:23 PM, Daniel Cross <daniel@ritualmedia.co.nz>wrote:
Well, in that case probably Dban will be sufficient for your needs. If still going with dd I agree with the bs=1M switch.
Incidentally, a discussion with a friend this evening lead us to the decision that a good way (although involved) to erase a drive would be:
1) Open disk enclusure. 2) Use bench grinder to create aluminium powder from the top of the disk enclosure 3) find something rusty, (or another source of iron oxide) and create powder. 4) mix 50:50 by volume. 5) if available add some magnesium (left over guy fawks sparklers?) 6) pour powder over HDD spindles. 7) Light and step well back while the platters melt.
I might try this in coming months and report my results ;)
Daniel
On Mon, Sep 2, 2013 at 6:30 PM, David Zuccaro < david.zuccaro@optusnet.com.au> wrote:
On Mon, 2013-09-02 at 17:45 +1000, Daniel Cross wrote:
I guess it depends on your threat model, so rewinding a bit - who are you wanting to prevent accessing your data? This greatly informs the conversation. The methods offered above, and in many of the replies thus far, assume a very sophisticated adversary.
Daniel
Let us assume that the adversary is not a three-letter-government-agency; not that I consent to three-letter-government-agencies accessing any of my information.

On 02.09.13 21:25, Daniel Cross wrote:
I should actually add a disclaimer to the above.
Don't actually do this unless you are sure and safe in what you are doing! :P
Ahem, yes. The pyrotechnics of thermite were used in WW2 in small stick-like incendiary bombs, one of which incinerated a stook of half a dozen rain-sodden sheaves in a field on our family farm in Denmark, leaving only a few blackened straw ends in a rough circle. (Very tame compared to the morning of the invasion, I must admit, but still not an indoor activity.) The reaction reduces the ferric oxide to _molten_ iron (i.e. > 1500°C), and is used in the in-situ welding of railway lines. (Just not on total fire ban days.) This one is second-hand: I have a clipping from a woodworking magazine; the author had very finely divided aluminium powder on one of those narrow file-like belt sanders, then attacked some rusty iron. The sparks were enough to ignite the finely divided freshly produce Al powder and rust mix, creating an incandescent fireball enveloping his forearms, causing flash burns to his face, and leaving the skin on hands and lower forearms hanging loosely, in a well cooked state. It is a reaction to be treated with some caution.
Incidentally, a discussion with a friend this evening lead us to the decision that a good way (although involved) to erase a drive would be:
<pedantry> OK, it's in front of my nose now. Forgive me please. I can't resist, especially since it was used on the "disincorporation" thread as well. What ever happened to "led" as the past tense of "lead"? Almost wherever one turns, leading turns to a heavy metal once it's past tense. Are LEDs to blame? </pedantry>
I might try this in coming months and report my results ;)
Before summer, please, away from flammables, with a good visor, leather welding gloves, and cold water for plunging scalded body parts into, just in case. Have fun! =8-) Erik (Who once fed pure oxygen through a steel pipe into his operating crucible furnace, causing the steel pipe to burn back reasonably rapidly toward him, leaving a trail of molten steel. (Don't tell Daniel.)) -- "Research is what I'm doing when I don't know what I'm doing." -Wernher Von Braun

On 09/02/2013 10:20 PM, Erik Christiansen wrote:
On 02.09.13 21:25, Daniel Cross wrote:
I should actually add a disclaimer to the above.
Don't actually do this unless you are sure and safe in what you are doing! :P Ahem, yes. The pyrotechnics of thermite were used in WW2 in small stick-like incendiary bombs, one of which incinerated a stook of half a dozen rain-sodden sheaves in a field on our family farm in Denmark, leaving only a few blackened straw ends in a rough circle. (Very tame compared to the morning of the invasion, I must admit, but still not an indoor activity.)
The reaction reduces the ferric oxide to _molten_ iron (i.e. > 1500°C), and is used in the in-situ welding of railway lines. (Just not on total fire ban days.)
This one is second-hand: I have a clipping from a woodworking magazine; the author had very finely divided aluminium powder on one of those narrow file-like belt sanders, then attacked some rusty iron. The sparks were enough to ignite the finely divided freshly produce Al powder and rust mix, creating an incandescent fireball enveloping his forearms, causing flash burns to his face, and leaving the skin on hands and lower forearms hanging loosely, in a well cooked state.
It is a reaction to be treated with some caution.
Incidentally, a discussion with a friend this evening lead us to the decision that a good way (although involved) to erase a drive would be: <pedantry> OK, it's in front of my nose now. Forgive me please. I can't resist, especially since it was used on the "disincorporation" thread as well. What ever happened to "led" as the past tense of "lead"? Almost wherever one turns, leading turns to a heavy metal once it's past tense. Are LEDs to blame? </pedantry>
I might try this in coming months and report my results ;) Before summer, please, away from flammables, with a good visor, leather welding gloves, and cold water for plunging scalded body parts into, just in case. Have fun! =8-)
Erik (Who once fed pure oxygen through a steel pipe into his operating crucible furnace, causing the steel pipe to burn back reasonably rapidly toward him, leaving a trail of molten steel. (Don't tell Daniel.))
I LUV the Linux sense of humour, Thanks very much to all who contribute. OT though it is, it's a condition that welds our community. Cheers Roger

Erik (Who once fed pure oxygen through a steel pipe into his operating crucible furnace, causing the steel pipe to burn back reasonably rapidly toward him, leaving a trail of molten steel. (Don't tell Daniel.))
Urban myth has it that a development with the steel pipe packed with steel rods; and a suitably large supply of oxygen, was used by bank robbers to cut not just through the side of the safe, but the stone /brick walls which enclosed it ! ...not sure what length of pipe was used. regards Rohan McLeod

On Tue, 3 Sep 2013, Rohan McLeod <rhn@jeack.com.au> wrote:
Erik (Who once fed pure oxygen through a steel pipe into his operating
crucible furnace,
causing the steel pipe to burn back reasonably rapidly toward him,
leaving a trail of molten steel. (Don't tell Daniel.))
Urban myth has it that a development with the steel pipe packed with steel rods; and a suitably large supply of oxygen, was used by bank robbers to cut not just through the side of the safe, but the stone /brick walls which enclosed it ! ...not sure what length of pipe was used.
http://en.wikipedia.org/wiki/Thermal_lance The Wikipedia page explains how this works. http://en.wikipedia.org/wiki/Curie_point But to destroy data you only need to heat it above it's Curie point, such high temperatures aren't required. Any sort of camp fire or gas stove should do the job. http://en.wikipedia.org/wiki/Thermite http://en.wikipedia.org/wiki/Thermate As for Thermite, the only special thing about it is that it can be used for welding. It's designed to produce a clean stream of molten metal with slag that floats on top. The Wikipedia page links to the Thermate page which notes it's military application in cutting tank armor etc. Thermate is basically gunpowder with a reactive metal to replace charcoal. The Wikipedia page about Thermite also suggests that thermate is better for document destruction. Seriously though if the people who want to steal your data won't be stopped by writing /dev/zero over the disk then this is the wrong place to ask for advice. As an aside, cat should write to a disk device node in a minimum size of one page for the CPU in question so it's performance should be almost the same as using dd with the bs=1m option. I say should because I submitted a patch to make it do so about 10 years ago, I recall that the patch was accepted and I hope it hasn't been backed out. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

As an aside, cat should write to a disk device node in a minimum size of one page for the CPU in question so it's performance should be almost the same as using dd with the bs=1m option. I say should because I submitted a patch to make it do so about 10 years ago, I recall that the patch was accepted and I hope it hasn't been backed out.
Presumably when not using the oflag=direct option, the writes are merged anyway. James

http://en.wikipedia.org/wiki/Curie_point
But to destroy data you only need to heat it above it's Curie point, such high temperatures aren't required. Any sort of camp fire or gas stove should do the job.
Is the curie point of the magnetic medium higher or lower than the melting point of the aluminium the platters are made of? The curie point of iron is very high but presumably the harddisk medium is an alloy which might change things. On the flip side of this question, how many times have you encountered people who think a fire proof safe rating applies to harddisks stored inside? James

Russell Coker <russell@coker.com.au> writes:
Seriously though if the people who want to steal your data won't be stopped by writing /dev/zero over the disk then this is the wrong place to ask for advice.
I was going to find a reference to this, similar to NSA's "how to redact properly", but the closest I could find before getting bored was http://dsd.gov.au/publications/

On Mon, 2013-09-02 at 17:45 +1000, Daniel Cross wrote:
I guess it depends on your threat model, so rewinding a bit - who are you wanting to prevent accessing your data? This greatly informs the conversation. The methods offered above, and in many of the replies thus far, assume a very sophisticated adversary.
Daniel hi
when the Space Shuttle blew up 60km above Texas, over 98% of the data was recovered from the disks found in the debris. Steve

On Mon, Sep 02, 2013 at 10:06:00PM +1000, Steve Roylance wrote:
when the Space Shuttle blew up 60km above Texas, over 98% of the data was recovered from the disks found in the debris.
so that would be a bad method of erasing data then? no problem, it sounds way too expensive anyway. craig -- craig sanders <cas@taz.net.au>

On 3 September 2013 01:35, Craig Sanders <cas@taz.net.au> wrote:
On Mon, Sep 02, 2013 at 10:06:00PM +1000, Steve Roylance wrote:
when the Space Shuttle blew up 60km above Texas, over 98% of the data was recovered from the disks found in the debris.
so that would be a bad method of erasing data then?
no problem, it sounds way too expensive anyway.
Although if we deployed Daniel's thermite method into space, I'm sure we'd have paying customers lining up for that! ~ J

On 02-Sep-13 10:06 PM, Steve Roylance wrote:
when the Space Shuttle blew up 60km above Texas, over 98% of the data was recovered from the disks found in the debris.
Context from http://www.informationweek.com/storage/disaster-recovery/hard-drive-data-fro...: "... the drive had melted before landing with other debris in Texas, but the drive was only half full and since the astronauts had used DOS the data was not scattered. The portion of the drive containing the data was not damaged and Edwards recovered almost all of the data". Not really at the "almost impossible" end of the data-recovery spectrum. -- Email to luv-sub@tripleg.net.au will bounce. Email to george at the same domain will accept.

Brett Pemberton writes:
Active ingredient now apt-gettable as "nwipe" in jessie and sid. (DBAN CD may still be preferable, depending on your trust model.)

What is the best way to wash a disk?
I tried this but it is taking forever.
dd if=/dev/zero of=/dev/sdg1
Someone else suggested a tool to do it, but just fyi dd's default block size is pretty small (is it 1 byte?) which will be terrible for performance. Add bs=1M or something to improve the speed. James

On Mon, 2 Sep 2013, 15:10, James Harper wrote: } > } > What is the best way to wash a disk? } > } > I tried this but it is taking forever. } > } > dd if=/dev/zero of=/dev/sdg1 } > } } Someone else suggested a tool to do it, but just fyi dd's default block } size is pretty small (is it 1 byte?) which will be terrible for } performance. Add bs=1M or something to improve the speed. According to Wikipedia..:) Default block size is 512 bytes. [ https://en.wikipedia.org/wiki/Dd_%28Unix%29#Block_size ] -- Block size A block is a unit measuring the number of bytes that are read, written, or converted at one time. Command line options can specify a different block size for input/reading (ibs) compared to output/writing (obs), though the block size (bs) option will override both ibs and obs. The default value for both input and output block sizes is 512 bytes (the block size of Unix block devices) -- For the 'disk wipe' example (below) a 4k block size is used to illustrate a faster operation than the default of 512b. (I am wondering at this point if there are any downsides to using a much higher block size like 1M or 2M..). [ https://en.wikipedia.org/wiki/Dd_%28Unix%29#Disk_wipe ] -- Disk wipe For security reasons, it is necessary to have a disk wipe of the discarded device. To check to see if a drive has data on it, send the output to standard out. dd if=/dev/sda To wipe a disk by writing zeros: dd if=/dev/zero of=/dev/sda bs=4k conv=notrunc The bs=4k option makes dd read and write 4 kilobytes at a time. This makes the whole process a lot faster on any relatively modern system. Note that filling the drive with random data will always take a lot longer than zeroing the drive, because the random data must be rendered by the CPU first. On most relatively modern drives, zeroing the drive will render any data it contains permanently irrecoverable.[5] Zeroing the drive will render any data it contains irrecoverable by software. Note that it still may be recoverable by special laboratory techniques; read about data remanence. -- Incidentally, if you want to check the progress of 'dd', you can send its process ID number the USR1 signal, ie. kill -USR1 <PID> T.

On 2013-09-03 12:35, Tony Crisp wrote:
On Mon, 2 Sep 2013, 15:10, James Harper wrote:
} > } > What is the best way to wash a disk? } > } > I tried this but it is taking forever. } > } > dd if=/dev/zero of=/dev/sdg1 } > } } Someone else suggested a tool to do it, but just fyi dd's default block } size is pretty small (is it 1 byte?) which will be terrible for } performance. Add bs=1M or something to improve the speed.
According to Wikipedia..:)
Or you could just check the info page: mattcen@toto:tmp$ info dd 2>/dev/null | grep -A 13 ^\`ibs `ibs=BYTES' Set the input block size to BYTES. This makes `dd' read BYTES per block. The default is 512 bytes. `obs=BYTES' Set the output block size to BYTES. This makes `dd' write BYTES per block. The default is 512 bytes. `bs=BYTES' Set both input and output block sizes to BYTES. This makes `dd' read and write BYTES per block, overriding any `ibs' and `obs' settings. In addition, if no data-transforming `conv' option is specified, input is copied to the output as soon as it's read, even if it is smaller than the block size. -- Regards, Matthew Cengia

On Tue, Sep 03, 2013 at 12:35:08PM +1000, Tony Crisp wrote:
To check to see if a drive has data on it, send the output to standard out.
dd if=/dev/sda
this is pretty nearly completely useless, dumping of raw binary data to the tty is a) unlikely to be readable by any human and b) likely to screw up the tty settings - many control characters move the cursor around, change colors and other attributes, put ttys into weird graphics-character modes, and even mess up keyboard input/display. at least use a hexdumper program to get hex+ascii output, like 'hd' aka 'hexdump'. not only will it be actually readable, it will protect the tty from raw control and escape codes (actually, even piping dd output into less will help with the latter). for example: hd /dev/sda | less hd is in the bsdmainutils main utils package in debian. example output (30 lines is just enough to show readable ascii text from grub): # hd /dev/sda | head -30 00000000 eb 63 90 00 00 00 00 00 00 00 00 00 00 00 00 00 |.c..............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 02 |................| 00000040 ff 00 00 20 01 00 00 00 00 02 fa 90 90 f6 c2 80 |... ............| 00000050 75 02 b2 80 ea 59 7c 00 00 31 00 80 01 00 00 00 |u....Y|..1......| 00000060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...........t...p| 00000070 74 02 b2 80 ea 79 7c 00 00 31 c0 8e d8 8e d0 bc |t....y|..1......| 00000080 00 20 fb a0 64 7c 3c ff 74 02 88 c2 52 be 80 7d |. ..d|<.t...R..}| 00000090 e8 17 01 be 05 7c b4 41 bb aa 55 cd 13 5a 52 72 |.....|.A..U..ZRr| 000000a0 3d 81 fb 55 aa 75 37 83 e1 01 74 32 31 c0 89 44 |=..U.u7...t21..D| 000000b0 04 40 88 44 ff 89 44 02 c7 04 10 00 66 8b 1e 5c |.@.D..D.....f..\| 000000c0 7c 66 89 5c 08 66 8b 1e 60 7c 66 89 5c 0c c7 44 ||f.\.f..`|f.\..D| 000000d0 06 00 70 b4 42 cd 13 72 05 bb 00 70 eb 76 b4 08 |..p.B..r...p.v..| 000000e0 cd 13 73 0d f6 c2 80 0f 84 d8 00 be 8b 7d e9 82 |..s..........}..| 000000f0 00 66 0f b6 c6 88 64 ff 40 66 89 44 04 0f b6 d1 |.f....d.@f.D....| 00000100 c1 e2 02 88 e8 88 f4 40 89 44 08 0f b6 c2 c0 e8 |.......@.D......| 00000110 02 66 89 04 66 a1 60 7c 66 09 c0 75 4e 66 a1 5c |.f..f.`|f..uNf.\| 00000120 7c 66 31 d2 66 f7 34 88 d1 31 d2 66 f7 74 04 3b ||f1.f.4..1.f.t.;| 00000130 44 08 7d 37 fe c1 88 c5 30 c0 c1 e8 02 08 c1 88 |D.}7....0.......| 00000140 d0 5a 88 c6 bb 00 70 8e c3 31 db b8 01 02 cd 13 |.Z....p..1......| 00000150 72 1e 8c c3 60 1e b9 00 01 8e db 31 f6 bf 00 80 |r...`......1....| 00000160 8e c6 fc f3 a5 1f 61 ff 26 5a 7c be 86 7d eb 03 |......a.&Z|..}..| 00000170 be 95 7d e8 34 00 be 9a 7d e8 2e 00 cd 18 eb fe |..}.4...}.......| 00000180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard | 00000190 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 |Disk.Read. Error| 000001a0 0d 0a 00 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 |...........<.u..| 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff |................| 000001c0 ff ff ee ff ff ff 01 00 00 00 af 6d 70 74 00 00 |...........mpt..| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| BTW, note how it consolidated consecutive lines of all zeroes (00000010 to 00000020) - in this case, only two consecutive lines but it does the same thing no matter how many there are. so if the disk is completely zeroed, you'll only see two or three lines of output total. craig ps: oh no! now i've posted the partition table of one of my drives for the entire world to see, and archived by google and their colleagues[1] at the NSA forever. [1] they're both in the business of spying on you, for pretty much the same reasons. the political and the commercial worlds aren't as different as they should be. -- craig sanders <cas@taz.net.au>

On Tue, 3 Sep 2013, 13:24, Craig Sanders wrote: } On Tue, Sep 03, 2013 at 12:35:08PM +1000, Tony Crisp wrote: } > To check to see if a drive has data on it, send the output to standard } > out. } > } > dd if=/dev/sda } } this is pretty nearly completely useless, dumping of raw binary data } to the tty is a) unlikely to be readable by any human and b) likely to } screw up the tty settings - many control characters move the cursor } around, change colors and other attributes, put ttys into weird } graphics-character modes, and even mess up keyboard input/display. } } at least use a hexdumper program to get hex+ascii output, like 'hd' aka } 'hexdump'. not only will it be actually readable, it will protect the } tty from raw control and escape codes (actually, even piping dd output } into less will help with the latter). } } for example: } } hd /dev/sda | less } } hd is in the bsdmainutils main utils package in debian. } } example output (30 lines is just enough to show readable ascii text from } grub): } } # hd /dev/sda | head -30 } 00000000 eb 63 90 00 00 00 00 00 00 00 00 00 00 00 00 00 |.c..............| } 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| } * } 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 02 |................| } 00000040 ff 00 00 20 01 00 00 00 00 02 fa 90 90 f6 c2 80 |... ............| } 00000050 75 02 b2 80 ea 59 7c 00 00 31 00 80 01 00 00 00 |u....Y|..1......| } 00000060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...........t...p| } 00000070 74 02 b2 80 ea 79 7c 00 00 31 c0 8e d8 8e d0 bc |t....y|..1......| } 00000080 00 20 fb a0 64 7c 3c ff 74 02 88 c2 52 be 80 7d |. ..d|<.t...R..}| } 00000090 e8 17 01 be 05 7c b4 41 bb aa 55 cd 13 5a 52 72 |.....|.A..U..ZRr| } 000000a0 3d 81 fb 55 aa 75 37 83 e1 01 74 32 31 c0 89 44 |=..U.u7...t21..D| } 000000b0 04 40 88 44 ff 89 44 02 c7 04 10 00 66 8b 1e 5c |.@.D..D.....f..\| } 000000c0 7c 66 89 5c 08 66 8b 1e 60 7c 66 89 5c 0c c7 44 ||f.\.f..`|f.\..D| } 000000d0 06 00 70 b4 42 cd 13 72 05 bb 00 70 eb 76 b4 08 |..p.B..r...p.v..| } 000000e0 cd 13 73 0d f6 c2 80 0f 84 d8 00 be 8b 7d e9 82 |..s..........}..| } 000000f0 00 66 0f b6 c6 88 64 ff 40 66 89 44 04 0f b6 d1 |.f....d.@f.D....| } 00000100 c1 e2 02 88 e8 88 f4 40 89 44 08 0f b6 c2 c0 e8 |.......@.D......| } 00000110 02 66 89 04 66 a1 60 7c 66 09 c0 75 4e 66 a1 5c |.f..f.`|f..uNf.\| } 00000120 7c 66 31 d2 66 f7 34 88 d1 31 d2 66 f7 74 04 3b ||f1.f.4..1.f.t.;| } 00000130 44 08 7d 37 fe c1 88 c5 30 c0 c1 e8 02 08 c1 88 |D.}7....0.......| } 00000140 d0 5a 88 c6 bb 00 70 8e c3 31 db b8 01 02 cd 13 |.Z....p..1......| } 00000150 72 1e 8c c3 60 1e b9 00 01 8e db 31 f6 bf 00 80 |r...`......1....| } 00000160 8e c6 fc f3 a5 1f 61 ff 26 5a 7c be 86 7d eb 03 |......a.&Z|..}..| } 00000170 be 95 7d e8 34 00 be 9a 7d e8 2e 00 cd 18 eb fe |..}.4...}.......| } 00000180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard | } 00000190 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 |Disk.Read. Error| } 000001a0 0d 0a 00 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 |...........<.u..| } 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff |................| } 000001c0 ff ff ee ff ff ff 01 00 00 00 af 6d 70 74 00 00 |...........mpt..| } 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| } } } BTW, note how it consolidated consecutive lines of all zeroes (00000010 } to 00000020) - in this case, only two consecutive lines but it does the } same thing no matter how many there are. so if the disk is completely } zeroed, you'll only see two or three lines of output total. } } } craig hmmm, I like it, works on partitions too =] # hexdump -C /dev/sda2 | head 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 01 00 00 00 6d 42 0f 00 00 00 00 00 06 7f 25 6d |....mB........%m| 00000410 64 c1 43 f9 92 06 58 bc ee 00 b6 1d 00 00 00 00 |dÁCù..X¼î.¶.....| 00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2| 00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00008000 40 7f d9 fc ba 7f 00 00 16 c3 ef f6 ba 7f 00 00 |@.Ùüº....Ãïöº...| T.

On 2013-09-03 14:44, Tony Crisp wrote: [...]
} for example: } } hd /dev/sda | less } } hd is in the bsdmainutils main utils package in debian. [...]
Perhaps more useful is limiting the output from hexdump: mattcen@toto:tmp$ sudo hexdump -Cn $((2**8)) /dev/sda 00000000 33 c0 fa 8e d8 8e d0 bc 00 7c 89 e6 06 57 8e c0 |3........|...W..| 00000010 fb fc bf 00 06 b9 00 01 f3 a5 ea 1f 06 00 00 52 |...............R| 00000020 52 b4 41 bb aa 55 31 c9 30 f6 f9 cd 13 72 13 81 |R.A..U1.0....r..| 00000030 fb 55 aa 75 0d d1 e9 73 09 66 c7 06 8d 06 b4 42 |.U.u...s.f.....B| 00000040 eb 15 5a b4 08 cd 13 83 e1 3f 51 0f b6 c6 40 f7 |..Z......?Q...@.| 00000050 e1 52 50 66 31 c0 66 99 e8 66 00 e8 21 01 4d 69 |.RPf1.f..f..!.Mi| 00000060 73 73 69 6e 67 20 6f 70 65 72 61 74 69 6e 67 20 |ssing operating | 00000070 73 79 73 74 65 6d 2e 0d 0a 66 60 66 31 d2 bb 00 |system...f`f1...| 00000080 7c 66 52 66 50 06 53 6a 01 6a 10 89 e6 66 f7 36 ||fRfP.Sj.j...f.6| 00000090 f4 7b c0 e4 06 88 e1 88 c5 92 f6 36 f8 7b 88 c6 |.{.........6.{..| 000000a0 08 e1 41 b8 01 02 8a 16 fa 7b cd 13 8d 64 10 66 |..A......{...d.f| 000000b0 61 c3 e8 c4 ff be be 7d bf be 07 b9 20 00 f3 a5 |a......}.... ...| 000000c0 c3 66 60 89 e5 bb be 07 b9 04 00 31 c0 53 51 f6 |.f`........1.SQ.| 000000d0 07 80 74 03 40 89 de 83 c3 10 e2 f3 48 74 5b 79 |..t.@.......Ht[y| 000000e0 39 59 5b 8a 47 04 3c 0f 74 06 24 7f 3c 05 75 22 |9Y[.G.<.t.$.<.u"| 000000f0 66 8b 47 08 66 8b 56 14 66 01 d0 66 21 d2 75 03 |f.G.f.V.f..f!.u.| 00000100 Don't forget, also: mattcen@toto:tmp$ sudo file -s /dev/sda /dev/sda: sticky x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 522240 sectors; partition 2: ID=0x83, starthead 162, startsector 524288, 487872512 sectors, code offset 0xc0 mattcen@toto:tmp$ sudo file -s /dev/sda1 /dev/sda1: sticky x86 boot sector, code offset 0x58 -- Regards, Matthew Cengia

Craig Sanders <cas@taz.net.au> writes:
On Tue, Sep 03, 2013 at 02:44:44PM +1000, Tony Crisp wrote:
hmmm, I like it, works on partitions too =]
it works on any file you have read access on.
and in unix, everything is a file.
Network interfaces aren't. CPUs aren't. I'd give a full list, but that would involve actually being a plan9 fanboy instead of just humming the tune.

On Mon, Sep 2, 2013 at 3:02 PM, David Zuccaro <david.zuccaro@optusnet.com.au> wrote:
What is the best way to wash a disk?
I tried this but it is taking forever.
dd if=/dev/zero of=/dev/sdg1
It depends who is trying to read your disk. If it's a three-letter-agency, just get a big magnet, and write it off as a loss. If not, dd using zero and a larger block size than default should do the trick. But I am sure the DoD mandates a certain number of passes of zeros/ones over the drive. I believe at a previous time it was 7 or 9 passes, using 'bcwipe.' The latter being commercial software. If you want to trash a single file, just use 'scrub' instead of 'rm' -Matt
participants (17)
-
Brett Pemberton
-
Christopher M. Bailey
-
Craig Sanders
-
Daniel Cross
-
David Zuccaro
-
Erik Christiansen
-
George Georgakis
-
James Harper
-
Joel W Shea
-
Matt Davis
-
Matthew Cengia
-
Roger
-
Rohan McLeod
-
Russell Coker
-
Steve Roylance
-
Tony Crisp
-
trentbuck@gmail.com