Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Secure delete ie shred a file

by fluffyvoidwarrior (Monk)
on Jan 26, 2006 at 07:20 UTC ( [id://525657]=perlquestion: print w/replies, xml ) Need Help??

fluffyvoidwarrior has asked for the wisdom of the Perl Monks concerning the following question:

Hello All, Can anyone advise me on a perl solutiion for shredding files beyond recovery on win32. Can't find anything on CPAN and a perl answer would be nice. Thanks again

Replies are listed 'Best First'.
Re: Secure delete ie shred a file
by GrandFather (Saint) on Jan 26, 2006 at 07:47 UTC

    This is a tough problem, even if you have low level access to the disk. Perl does not. You could write code to delete the file then fill the entire hard disk by creating junk files, but that doesn't sound very efficient! You could perform a defrag following deleting a file and that may confuse the trail somewhat, or it may not.

    How secure do you really need to be? There are techniques that may be used to recover data from disks that have been over written (they may require special hardware and likely effectively destroy the hard disk though) so anything trivial you do is unlikely to be enough to prevent highly motivated people from recovering data from your disk.

    A good whack with a hammer is likely to be effective however.


    DWIM is Perl's answer to Gödel
      I would like to put deleted files beyond the reach of commercially available "undelete" programs at least. I don't think I have the expertise to confidently start poking with disks at a low level and so was hoping for a module. Maybe I can find a command line tool somewhere . . .

        Norton used to make a utility for doing what you want for FAT drives.


        DWIM is Perl's answer to Gödel
        Here's some untested code for you. The intention is to first figure out how much crap we need to overwrite the file with, then open the file in read/write mode - this avoids clobbering the file and creating a new one which would happen if we just opened the file for writing, and also means that we can get at the beginning of the file unlike if we opened it for appending. Then it just overwrites the file with 'X's. Finally, it closes the file and unlinks it.

        This will certainly protect you from "undelete" on DOS (all it will undelete is a file of 'X's) and DOS-a-likes such as Win95, and probably on WinNT and its successors if using the FAT filesystem. My understanding of ext2 leads me to believe that it should also protect you on most Linux systems. But I can't be sure that it will work anywhere else, including on Linux systems using stuff like Reiserfs, and as other people have pointed out, it certainly won't protect you against The Man. And even that paper is now out of date.

        my $bytes = -s $filename open(FILE, '+<', $filename); seek(FILE, 0, 0); print FILE "X" x $bytes; close(FILE); unlink $filename;
        "commercially available 'undelete'" sounds like you don't mean to consider even marginally clever adversaries. In this case, truncating the file may all you need, with copying something innocent (a random configuration or help file from a windows system directory) or such as a safer second choice. 'undelete' normally only covers *deletion*, right?
Re: Secure delete ie shred a file
by cyclist38 (Hermit) on Jan 26, 2006 at 08:44 UTC
    i've done this before by first encrypting the file with a temporary key, write it back to disk, then delete the file. the file is still recoverable by commercial utilities, but not the information.

      I'm not sure this is actually as secure as you think it is. You have no guarantee that your filesystem will use the same blocks for your new (encrypted) data as for the old, and even less guarantee that the device driver/device will map those blocks to the same physical sectors. Flash devices, for example, will try hard to use new, unallocated space, because the flash media has a very limited number of write cycles within its lifespan. So the information in the original file may no longer be accessible to the filesystem but it can still be read directly from the disk.

      At the very least, you need to make sure that your encrypted/zeroed file is the same size as or larger than your original, otherwise some of your original data can remain in the slack space between file and block size.

      Secure file deletion depends on several variables, including the file system and the physical device used. The only general way to do this semi-securely is GrandFather's suggestion of deleting the file and filling the then empty space on the partition with data multiple times (making sure you flush your page cache between passes). Even then there can be problems, like for example NTFS's alternate streams.

      Personally I'd probably go a different way and rather transparently encrypt the file while using it. If all you're guarding against is later recoverability you just need to make sure the encryption key cannot be recovered, and even if you fail that it is very probable that simple corruption of your encrypted file (e.g. by managing to wipe it partially) will render the file completely unrecoverable.


      There are ten types of people: those that understand binary and those that don't.
        So won't a sequence like this actually write to the same disk sectors (ntfs hard drive)
        step1 - set file pointer position,
        step2 - sysread lump of data,
        step3 - encrypt lump of data,
        step4 - reset pointer to original posn,
        step5 - syswrite lump of data in same file posn,

        or is it just a case of probably , sometimes.
      i've done this before by first encrypting the file with a temporary key
      Why encrypting the file?!
      Overwriting the file with random bytes is security-wise the same (or it's even better, since there is no chance that someone could decrypt the file content).
      And using random bytes is much, much faster and memory efficient than an encryption.

      Update

      And overwriting the file with a fixed pattern would be even better! ;-)

      Ciao,
      Emanuele.

        nice point actually - never thought about using random bytes. ++
      I think that will do the job nicely. p.s. Wish I'd thought of that
Re: Secure delete ie shred a file
by Old_Gray_Bear (Bishop) on Jan 26, 2006 at 18:47 UTC
    If some one has enough resources and motivation, they can recover your 'wiped' magnetic media.

    An acquaintance of mine who (probably) works for a Large Intelligence Agency in Virginia said that they never bother trying to 'erase beyond the ability of anyone to recover' their obsolete/failed hard drives. When a hard drive is slated for decommisioning, it goes into an electro-furnace and gets toasty at 3000F for an hour or so. The resultant liquid metal is cast into five pound ingots and put into the basment storage vault. A few years ago, they ran out of space in the vault and, after a *lot* of research and high level discussion, they decided that anything more that ten years old could be removed from dead storage and sold on the open market as 'scrap metal, mixed alloy'. Even then, they restricted the amount sold to any one dealer to 50 pounds.

    ----
    I Go Back to Sleep, Now.

    OGB

      That's nothing and just shows you how lax and decadent our western security services have become.

      A couple of years ago I met the head of KGB Data Security Division in a bar, and after a few rounds of slivovitz he revealed to me that the main purpose of the Soviet nucular and space programs was secure data destruction! You see, when the Russians want to destroy a data medium (be that a magnetic tape, harddisk, paper file or a dissenter's brain) they transport said medium to Siberia where it is manually disassembled by convict slave workers. These convicts are so good that they can pick the 1s and 0s off a harddisk platter using household tweezers! The ground-down bits are then transported to the nearest testing site for nucular weapons and blasted with a hydrogen bomb of no less than 40 megaton yield. They wait for a few minutes to let the remains cool off, then scrape the slag off the walls and seal it in titanium-alloy containers. These containers are placed into a Soyuz and shot straight into the sun!

      Now, you may think you can just fly up to the sun and retrieve that data, but they've got laser-equipped guardian satellites around it which will shoot down any approaching spacecraft. They even have a contingency plan should the satellites be compromised, it involves manipulating several neighbouring stars to fall into the sun, thus creating a black hole. You see, at the time these plans were drawn up it was believed that no information could ever escape a black hole. As you can imagine, they're in a bit of a panic now that this theory has been disproved.

      The Chinese, OTOH, just feed their hard-disk platters to goats, since it is a well-known fact that the digestive juices of goats will corrode everything. Interestingly, research has shown that the average IQ of the Mongolian Mountain Goat is rising at an alarming rate, and prices for goat droppings on the world market have exploded, though it is unclear who buys all this goat shit.


      I say we nuke the site from orbit, it's the only way to be sure - Ripley
        Would something like the following be at all secure? I imagine it might keep amateurs out, but not real spies. sub srm { my $filename = shift; my $filesize = -s "$filename"; open FH, ">$filename"; binmode FH; for (my $c = 0; $c < $filesize; $c++) { print FH '9'; # it's more interesting than 0 } print "Erased $filesize bytes!\n"; close FH; unlink $filename; }
      ya i saw something simular using thermite as a way to keep the feds from recovering incrimating evidence from a HD. it was all packaged neatly in a spare bay above the labtops HD.. one flick of the switch and the entire labtop became a smolding pile. what u cant reconize you cant read from.


      just another perl hacker
Re: Secure delete ie shred a file
by glasswalk3r (Friar) on Jan 26, 2006 at 12:53 UTC

    You could try to flush all the file content and then unlink it. Anyway the information is destroyed.

    The Camel Book describes what you need to do to avoid race conditions using sysopen. Using file locking also should help to make it more secure too (but I'm not sure if flock() will work fine in Win32, I never used it there).

    Alceu Rodrigues de Freitas Junior
    ---------------------------------
    "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://525657]
Approved by Corion
Front-paged by Anneq
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2024-03-19 02:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found