Wiping Disks: more than /dev/zero ...

[Robert Gamble]

I searched the forums and found out how to use /dev/zero to write one layer of zeros.
Ideally, management wants three layers of garbage on the drive. I would like to write a layer of zero, than a layer of ones, then another layer of zeros.

What would I do to get something like a '/dev/one' ?

Thanks in advance!

[John Carr_2]

Hi

has management considered formatting the drives using command mediainit. This can also be run from the support CD I believe.

cheers
John.

[Vincent Fleming]

It never ceases to amaze me how "management" comes up with ideas like this to keep us busy!

I would suggest writing a simple C program to do this for you.

Attached is an example. If you don't know C, have someone check it for you - I haven't any way to test it. It compiles on my UNIX box here, though.

Good luck!

[Tim D Fulford]

That would be management, why do a job once when you can insist on doing it 3 times... Its broken & unrecoverable, lets break twice more to be sure...

Tim

[Robert Gamble]

I was hoping for something that could be executed via script, not a compiled executable. Thank you though.

I have used mediainit in the past, and afterwards, the drives it was used on are flaky. The mean-time-to-failure afterwards is usually less than 1000 hours in my experience. Since all my systems are covered by a contract, and I used a HP provided command, they were replaced by HP. I would prefer not to have to deal with the associated downtime this time around. (I realize there could be other factors that caused those disks to fail, but I don't want to go through that again.)

[Craig Rants]

Does your management have some adversion to using mediainit? That was good enough for the DOD when I worked for them. (I am taking a wild guess that your management is some government entity)

C

[John Carr_2]

Hi

you might wish to read this thread which covered this type of issue once before.

cheers
John.

[John Carr_2]

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x03a6e7e60861d511abcd0090277a778c,00.html

opps forgot to paste the thread

John.

[Martin Johnson]

If you are going to hammer a disk by writing zeros and ones all over the entire disk you are going to increase the risk of a disk failure. This is true if you use a C program, a script, media init or anything else.

I was wondering... Since your management is so keen on protecting the company's data, are your computers locked up in a vault? At highly secure government sites, the computers are locked in a vault along with the users. Do you find this uncomfortable?

Marty

[Robert Gamble]

My client is not the Govt, but they do have extremely sensitive data that could be exploited competing companies.

I realize I could use mediainit, but like I mentioned before, I do not wish to use it.

Thanks for the replies so far, but I am really looking for something similar to /dev/zero, but for 'ones'.

[A. Clay Stephenson]

Hi Robert, you already have a /dev/one; you just dont know that you have one.

cat /dev/zero | tr '\0' '\377' | dd bs=64k of=/dev/rdsk/cXtYdZ

[Stefan Farrelly]

I dont see how you can create a /dev/one device file. However, you can simulate it.

eg. if you do;

dd if=/dev/zero of=/tmp/0 count=1

Then look at /dev/zero it looks like this;
512 bytes /tmp/0
if you cat it it looks like this;
cat /tmp/0|vis
\000\000\000\000....... (full of null zeroes)
You can count up the characters like this;
cat /tmp/0|wc -c
and the result is 512 bytes again.

So, now we can create a /tmp/1 file like this;
let x=0;while [ $x -lt 512 ]
do
let x=$x+1
echo "\001\c" >>/tmp/1
done

If you check the resulting file is looks like this;
512 bytes /tmp/1
You can verify its contents again by doing;
cat /tmp/1|wc -c
and the result is 512 bytes again and you can view it with;
cat /tmp/1|vis
and it looks like this;
\001\001\001..... (full of ones)

So /tmp/0 and /tmp/1 are the same (except one has zero nulls and the other one nulls).

Now, how to use dd from this instead of a /dev/one file. You need to use the oseek option which means skip a record on the output device (a disk or a flat file) for each iteration, depending on how big your disk is. eg. if diskinfo says your disk is 4000000 kbytes then divide 4000000000/512 to get the number of iterations to run (4000000 * 1000 / 512 bytes);

let x=0;while [ $x -lt 7812500 ]
do
let x=$x+1
dd if=/dev/one of=/dev/rdsk/cxxxxx oseek=$x
done

Ive tested it on an old disk here, worked fine. This would take a long while to run but you could write just a random pattern of ones if you wanted (just as good) by increasing x by say 10 instead of 1 (or even increase it by a random number!).

[Stefan Farrelly]

Clay - if you cat /dev/zero and pipe output into vis you will see that its not all \000 so I dont think your tr command will work.

[Stefan Farrelly · Accepted solution]

I think you have the answer though Clay - this works a treat;

cat /dev/zero | tr '\000' '\001' | dd of=/dev/rdsk/cxxxxx bs=64k

This will keep running until end of device (end of the disk) and you will get an I/O error, but it works fine. Tested it on output to some files, output same as my previous long winded answer but much simpler!

And you can substitute \001 for whatever you want.

[Robert Gamble]

Thanks Clay and Stefan !!


Now here is my plan for each disk (non-vg00) to wipe:

1)# mknod /dev/zero c 3 0x000003
2)# chmod 444 /dev/zero
3)# dd if=/dev/zero of=/dev/rdsk/cXtYdZ bs=64k
4)# cat /dev/zero | tr '\000' '\001' | dd of=/dev/rdsk/cxxxxx bs=64k
5)# dd if=/dev/zero of=/dev/rdsk/cXtYdZ bs=64k

Because of the I/O error associated with the commands, this process would be manual and not scripted.

Thanks again !!

[James R. Ferguson]

Hi Robert:

If you are running 11.11 you should already have /dev/zero. If not, do this to create it:

# mknod /dev/zero c 3 0x000003 #...on 10.20
# mknod /dev/zero c 3 0x000004 #...on 11.x

# chown bin:bin /dev/zero
# chmod 666 /dev/zero

Regards!

...JRF...

[Robert Gamble]

JRF: sadly, my customer doesn't consider 11i 'stable enough' yet, so I am still on 11.0.

Why the 'chmod 666', shouldn't 444 suffice ?

[James R. Ferguson]

Hi Robert:

No reason other than I made it look like /dev/null, but in the case of /dev/zero readonly permissions are perfectly fine!

/No Points Please/

Regards!

...JRF...

[A. Clay Stephenson]

Not to be nit-picky but a tr '\000' to '\001' is only flipping 1 bit whereas a tr '\000' '\377' flips every bit. There appears to be a bug in tr in that it behaves differently if reading input from a pipe.

cat /dev/zero | tr '\0' '\377' is broken
but
tr '\0' '\377' < /dev/zero works perfectly (and is more efficient to boot). I should have tested my 'off the cuff' idea but it was so neat I just had to post it as soon as I saw the thread.


Anyway, this command should work AND flip all your bits to '1'.

tr '\0' '\377' < /dev/zero | dd bs=64k of=/dev/rdsk/cXtYdZ
-------------------------------------------
Now as to whether any of this process to 'wipe' disk makes sense ....


Regards, Clay

[James R. Ferguson]

Hi (again) Robert:

BTW, I stumbled on this. With regard to leaving write permissions on or off, try this with your /dev/zero file:

# chmod 666 /dev/zero
# cat /etc/hosts > /dev/zero

Regards!

...JRF...

[Vincent Fleming]

Related to this thread... someone posted about a product that does just this in the following thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x81b73a7b3682d611abdb0090277a778c,00.html

[A. Clay Stephenson]

As a clarification, I just got the official word from HP that /dev/zero is only officially supported on 11.11.
If you create a /dev/zero c 3 3 on 10.20,11.0, or 11.11 they all display the garbaged output stream. I have absolutely no idea why
cat /dev/zero | tr produces a little garbage and yet tr < /dev/zero works perfectly.

On 11.x, Major device 3 Minor device 4 works perfectly.

The funny thing is that a minor device 3 3 can (rather than the proper 3 4) be created on 11x
and the device behaves like the 10.20 3 3 device. Sadly, if you attempt a mknod /dev/zero c 3 4 on 10.20 the device is non-functional so the best you can do on 10.20 is to create a 3 3 device but accept that it's not perfect.

[A. Clay Stephenson]

Hi again:

I reduced the problem to it's simplest form:
For any /dev/zero with device numbers 3,3

cat /dev/zero | dd bs=1k count=2 | od -c
produces garbage but
dd bs=1k count=2 if=/dev/zero | od -c
is perfect. I still have no idea why.

The good news is that that for 11x mknod /dev/zero c 3 4
produces perfect results everytime.

Note: mknod /dev/zero c 3 4 on 10.20 produces a non-functional /dev/zero.


Regards, Clay

[Wodisch]

Hello Robert,

in case your idea of writing zeros then one then zeros to a disk is to make the contents of that disk absolutely unrecoverable, your wrong!
Physical Desaster Recover companies will still be able to read the data as it was previusly written to the disk...
The simple reason is that the write-head of the disk does not (never) exactly overwrite the old track but moves over the center of that track but not exactly the center of the track.
If I remember right, then you need about 17 (seventeen!) overwrites of the same track to be *certain* you cannot recover any data!
And even then I would recommend to alternatively write 0x55 and 0xAA patterns...

Just my $0.02,
Wodisch

[Robert Gamble]

Woodisch,

I never stated it had to be totally unrecoverable, just that my client's management wanted the disk to be overwritten 3 times. They understand that *anything* can be recovered, they just want to make sure that who ever is going to try that has to jump through some hoops.

I've read theory white papers about methods that can read disks well after the 17 overwriting as well. The more $$$ you have to dispose, the more options you have to recover it. Unless of course you melt it ;)

I would like to say thanks again for all the responses, and see you on the boards!