OpenVMS file shredder

[Brian Knapp]

We recently discontinued use of our AlphaServer 4100 and have toiled with the idea of selling it. I was wondering if anyone knows of a method to thoroughly scour the hard drives. Thank you for any ideas.

Brian

[John Gillings · Accepted solution]

Brian,

It depends on how concerned you are about the data. There are labs that (for a BIG price) can recover data from disk platters anything up to 16 write cycles deep. So, for absolute security you need to follow the US DoD procedure which is, roughly:

1) Perform numerous runs of writing 0s to all accessible blocks on the disk

2) Perform numerous runs of writing a security erase pattern to all accesible blocks on the disk

3) Degauss drive in a huge magnetic field

4) Feed drive through shredder

5) Take shards from shredder and incinerate

6) Take resulting ashes and dispose in a secure landfill

(If you think I'm kidding, look it up! Remember security doesn't have to make any sense, it just has to be secure!)

Now, for more sane people, this is both unnecessary and expensive. You can erase a drive with:

$ INIT/ERASE disk

This will fill the drive with zeros.

For a slightly more rigourous "scrub" you can write an erase pattern to the drive with:

$ MOUNT/FOREIGN ddcu:
$ ANALYZE/MEDIA -
/EXERCISE=(-
NOKEEP,-
PATTERN=(32bitvalue,32bitvalue,â ¦)) -
ddcu:

According to $ERAPAT, one of the DoD security erase patterns is %XDB6DB6DB, so:

$ MOUNT/FOREIGN ddcu:
$ ANALYZE/MEDIA -
/EXERCISE=(-
NOKEEP,-
PATTERN=(%x0,%XDB6DB6DB)) ddcu:
$ ANALYZE/MEDIA -
/EXERCISE=(-
NOKEEP,-
PATTERN=(%XDB6DB6DB,%x0)) ddcu:

Two passes with different patterns each time.

For a system disk, you should be able to do this from the $$$ prompt having booted from CD.

Bear in mind that this may not scrub bad blocks that have been replaced, so again, it all depends on how secure you want it to

[Brian Knapp]

Great response John! I really appreciate your help.

[Anton van Ruitenbeek]

Brian,

A CPU boand cheaper methode than John's is to copy the VMB.EXE or the APB.EXE continuesly over the disk after have initialising this on.

$ INIT /ERASE CLEAR
$ MOUNT CLEAR
$ COPY SYS$SYSTEM:APB.EXE :[000000]CLEAR.TST
$ LOOP:
$ ON ERROR THEN GOTO LOOP_END
$ APPEND SYS$SYSTEM:APB.EXE :[000000]CLEAR.TST
$ GOTO LOOP
$ LOOP_END:
$ DISMOUNT
$ INIT /ERASE CLEAR

The reason why we use VMB.EXE or APB.EXE is this file is not a program but is actualy a processor dump.

If needed, repeat procedure.

AvR

[Uwe Zessin]

"processor dump"?

And I thought all the time that VMB, APB and IPB.EXE were the primary bootstrap code.

[Jan van den Ende]

Uwe, yes,

As far as I know, they are the first programs that run, in PHYSICAL addressing mode, before virtual addressing is even set up. There task _IS_ setting up Virtual Memory, and then transfering control to the next image, which _DOES_ run in Virtual Memory.

-- It was a loooooooong time since I had any class that touched this. If I mixed things up, I am sure John will step in with the correction.

hth

Proost.

Have one on me.

Jan

[Alon Jacob]

Brian.

From my expiriance there are 2 basic steps you can take :
1. run and INIT/ERASE command on each volume. That will assure your data could not be restored in any "standart" way.
2. From my army expirience, there are several companies who can restore data even after a few low-level formats and writing over a new data.
The only way to overcome this is to have the magnetic plates inside the drives melted in fire (which we did in the army).
Since I can't think you want to get that far, just do an init/erase and that should do.

Alon.