topic Re: OpenVMS file shredder in Operating System - OpenVMS

OpenVMS file shredder

Brian Knapp — Thu, 20 Jan 2005 15:49:43 GMT

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

Re: OpenVMS file shredder

John Gillings — Thu, 20 Jan 2005 16:48:52 GMT

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

Re: OpenVMS file shredder

Brian Knapp — Thu, 20 Jan 2005 16:55:46 GMT

Great response John! I really appreciate your help.

Re: OpenVMS file shredder

Anton van Ruitenbeek — Fri, 28 Jan 2005 07:26:21 GMT

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

Re: OpenVMS file shredder

Uwe Zessin — Fri, 28 Jan 2005 07:39:32 GMT

"processor dump"?

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

Re: OpenVMS file shredder

Jan van den Ende — Fri, 28 Jan 2005 10:18:03 GMT

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

Re: OpenVMS file shredder

Alon Jacob — Sun, 30 Jan 2005 07:17:13 GMT

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.