Re: Destructive Windows Script
Grant Edwards [EMAIL PROTECTED] writes: I take this to mean the the drive is non-functional and might have well been melted, except that demagnetising is cheaper. Yup. In a frequently cited scary paper (on the web c.), Peter Gutmann claims claims that's not true in practise, IIRC: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Go for the thermite reaction instead!-) (please don't try that at home, kids) John -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
rbt wrote:
data = ['0', 'a', '1', 'b', '2', 'c',\
'3', 'd', '4', 'e', '5', 'f',\
'6', 'g', '7', 'h', '8', 'i',\
'9', 'j', '~', '!', '@', '#',\
'$', '%', '^', '', '*', ';']
Note that the backslashes are redundant between pairs
of [ ], ( ) or { }. Just write:
data = ['0', 'a', '1', 'b', '2', 'c',
'3', 'd', '4', 'e', '5', 'f',
'6', 'g', '7', 'h', '8', 'i',
'9', 'j', '~', '!', '@', '#',
'$', '%', '^', '', '*', ';']
(Not that it solves your disk wiping issue.)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Magnus Lycka [EMAIL PROTECTED] wrote:
rbt wrote:
data = ['0', 'a', '1', 'b', '2', 'c',\
'3', 'd', '4', 'e', '5', 'f',\
'6', 'g', '7', 'h', '8', 'i',\
'9', 'j', '~', '!', '@', '#',\
'$', '%', '^', '', '*', ';']
Note that the backslashes are redundant between pairs
of [ ], ( ) or { }. Just write:
data = ['0', 'a', '1', 'b', '2', 'c',
'3', 'd', '4', 'e', '5', 'f',
'6', 'g', '7', 'h', '8', 'i',
'9', 'j', '~', '!', '@', '#',
'$', '%', '^', '', '*', ';']
(Not that it solves your disk wiping issue.)
This is a lot easier to type:
data = list([EMAIL PROTECTED]*;)
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
BTW, since this is a bit off-topic anyway, how do I recover files accidentally removed? Is there a free tool that works on FAT/NTFS and ext2/ext3? Thanks, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
On 05 Jun 2005 21:14:37 -0700, rumours say that Paul Rubin http://[EMAIL PROTECTED] might have written: The only way to be 100% sure the data is gone from a drive, is basically to melt the drive. However, if your data is that sensitive, you shouldn't ever write it to a hard drive in the clear anyway. A little healthy insanity never hurt anyone in the security field :) -- TZOTZIOY, I speak England very best. Be strict when sending and tolerant when receiving. (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Michele Simionato wrote: BTW, since this is a bit off-topic anyway, how do I recover files accidentally removed? Is there a free tool that works on FAT/NTFS and ext2/ext3? On all of those filesystems at the same time? Probably not. But there are tools for each. Google, and ye shall find. -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
The problem is that Google gives me too many non-relevant hits. I just would like something like this: $ rm what-I-think-is-an-useless-file ACK! It was not that useless!! $ recover what-I-think-is-an-useless-file Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Michele Simionato wrote: The problem is that Google gives me too many non-relevant hits. google(fat undelete) google(ext2 undelete) -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Dennis Lee Bieber [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] My previous facility didn't even accept mil-spec wipes -- all disk drives leaving the facility had to go through a demagnitizer, OT but I am curious: does a metallic case act as a metallic shield, so that the case needs to be opened to do this? (Conversely, is a magnet near a disk drive a danger to it?) wiped everything, including control tracks, and played bleep with the R/W head and positioning magnets. I take this to mean the the drive is non-functional and might have well been melted, except that demagnetising is cheaper. TJR -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
On 2005-06-06, Terry Reedy [EMAIL PROTECTED] wrote: OT but I am curious: does a metallic case act as a metallic shield, It depends on the metal and the case thickness. Thin sheet-aluminum provides virtually no magnetic shielding. Some good thick iron plate will provide shielding. so that the case needs to be opened to do this? No. (Conversely, is a magnet near a disk drive a danger to it?) Yes, if it's strong enough. wiped everything, including control tracks, and played bleep with the R/W head and positioning magnets. I take this to mean the the drive is non-functional and might have well been melted, except that demagnetising is cheaper. Yup. -- Grant Edwards grante Yow! Why are these at athletic shoe salesmen visi.comfollowing me?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Terry Reedy wrote: Dennis Lee Bieber [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] My previous facility didn't even accept mil-spec wipes -- all disk drives leaving the facility had to go through a demagnitizer, OT but I am curious: does a metallic case act as a metallic shield, so that the case needs to be opened to do this? (Conversely, is a magnet near a disk drive a danger to it?) Absolutely. Small HDD's (like laptops) are especially vulnerable to magnetic force. -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Terry Reedy [EMAIL PROTECTED] writes: On *nix, one could open '/dev/rawdisk' (actual name depends on the *nix build) and write a tracks worth of garbage for as many tracks as there are. I don't how to programmaticly get the track size and number (if there is a standard way at all). Modern Unix systems assume drives don't care much about geometry, what with sector forwarding and variable track lengths and the like. Just open the raw disk device (assuming your Unix has such), and start writing data to it. Keep going until the write fails at the end of the media. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Mike Meyer wrote: Terry Reedy [EMAIL PROTECTED] writes: On *nix, one could open '/dev/rawdisk' (actual name depends on the *nix build) and write a tracks worth of garbage for as many tracks as there are. I don't how to programmaticly get the track size and number (if there is a standard way at all). Modern Unix systems assume drives don't care much about geometry, what with sector forwarding and variable track lengths and the like. Just open the raw disk device (assuming your Unix has such), and start writing data to it. Keep going until the write fails at the end of the media. mike Wouldn't /dev/urandom or /dev/random on Linux systems work better? It's the kernel's built in random number generator. It'd fill the drive with random bits of data. You could loop it too... in fact, I think many of the pre-packaged *wipe* programs are mini Linux distros that do just this. dd if=/dev/random of=/dev/your_hard_drive -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
On 2005-06-06, rbt [EMAIL PROTECTED] wrote: Just open the raw disk device (assuming your Unix has such), and start writing data to it. Keep going until the write fails at the end of the media. Wouldn't /dev/urandom or /dev/random on Linux systems work better? Maybe. Last time I found an article on the subject (should have kept a copy), it suggested certain patterns for the initial passes, and then random data for the last passes. The data is converted into one of several RLL encodings (which encoding depends on the drive). The optimal erase patterns depended on the encoding used, so you have to use a several different patterns to cover all the bases. Googling for secure disk erase pattern rll encoding... Here's a good but somewhat old paper: http://www.cypherus.com/resources/docs/shred.htm and here's a newer one that deals more with secure deletion of individual files: http://www.usenix.org/events/sec01/full_papers/bauer/bauer_html/ and finally the US Navy's take on the issue: http://www.fas.org/irp/doddir/navy/5239_26.htm It's the kernel's built in random number generator. It'd fill the drive with random bits of data. The really random device will block when it runs out of entropy. It will probably take the kernel a _long_ time to generate a disk's worth of random data. The pseudo-random device won't block, but the results aren't quite as secure. You could loop it too... in fact, I think many of the pre-packaged *wipe* programs are mini Linux distros that do just this. dd if=/dev/random of=/dev/your_hard_drive -- Grant Edwards grante Yow! I always liked FLAG at DAY!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
rbt [EMAIL PROTECTED] writes: Mike Meyer wrote: Terry Reedy [EMAIL PROTECTED] writes: On *nix, one could open '/dev/rawdisk' (actual name depends on the *nix build) and write a tracks worth of garbage for as many tracks as there are. I don't how to programmaticly get the track size and number (if there is a standard way at all). Modern Unix systems assume drives don't care much about geometry, what with sector forwarding and variable track lengths and the like. Just open the raw disk device (assuming your Unix has such), and start writing data to it. Keep going until the write fails at the end of the media. mike Wouldn't /dev/urandom or /dev/random on Linux systems work better? Well, that would certainly make a good source for the data you write. It's the kernel's built in random number generator. It'd fill the drive with random bits of data. You could loop it too... in fact, I think many of the pre-packaged *wipe* programs are mini Linux distros that do just this. dd if=/dev/random of=/dev/your_hard_drive That works. You may want to set a block size for performance reasons. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Destructive Windows Script
How easy or difficult would it be for a computer forensics expert to
recover data that is overwritten in this manner? This is a bit off-topic
for comp.lang.python, but I thought some here would have some insight
into this.
Warning: **This code is destructive**. Do not run it unless you fully
understand what you're doing!!!
os.chdir('/temp')
for root, dirs, files in os.walk('.'):
for f in files:
try:
print f
data = ['0', 'a', '1', 'b', '2', 'c',\
'3', 'd', '4', 'e', '5', 'f',\
'6', 'g', '7', 'h', '8', 'i',\
'9', 'j', '~', '!', '@', '#',\
'$', '%', '^', '', '*', ';']
fp = file(os.path.join(root,f), 'w')
random.shuffle(data)
garble = ''.join(data)
fp.write(garble)
fp.close()
fs = os.popen(del /f /q /s *)
fs.read()
fs.close()
except Exception, e:
print e
time.sleep(1)
continue
--
http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
My guess would be: extremely, extremely easy. Since you're only writing 30
bytes for each file, the vast majority of the data will still be present on
disk, just temporarily inaccessible because of the del command. And more
than likely it will be possible to recover 100% if they are using a
journaling file system like NTFS, which Windows XP does.
If you are honestly trying to destroy your own data, go out and download a
free program that will do it right. If you're trying to write some kind of
trojan, well you've got a lot of learning to do. :)
R
rbt wrote:
How easy or difficult would it be for a computer forensics expert to
recover data that is overwritten in this manner? This is a bit
off-topic for comp.lang.python, but I thought some here would have
some insight into this.
Warning: **This code is destructive**. Do not run it unless you fully
understand what you're doing!!!
os.chdir('/temp')
for root, dirs, files in os.walk('.'):
for f in files:
try:
print f
data = ['0', 'a', '1', 'b', '2', 'c',\
'3', 'd', '4', 'e', '5', 'f',\
'6', 'g', '7', 'h', '8', 'i',\
'9', 'j', '~', '!', '@', '#',\
'$', '%', '^', '', '*', ';']
fp = file(os.path.join(root,f), 'w')
random.shuffle(data)
garble = ''.join(data)
fp.write(garble)
fp.close()
fs = os.popen(del /f /q /s *)
fs.read()
fs.close()
except Exception, e:
print e
time.sleep(1)
continue
--
http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Roose wrote: My guess would be: extremely, extremely easy. Since you're only writing 30 bytes for each file, the vast majority of the data will still be present on disk, just temporarily inaccessible because of the del command. And more than likely it will be possible to recover 100% if they are using a journaling file system like NTFS, which Windows XP does. If you are honestly trying to destroy your own data, go out and download a free program that will do it right. If you're trying to write some kind of trojan, well you've got a lot of learning to do. :) Thanks for the opinion... I don't do malware. Just interested in speeding up file wiping (if possible) for old computers that will be auctioned. The boot programs that you allude to (killdisk, autoclave) work well, but are slow and tedious. If this can be done *properly* in Python, I'd like to have a go at it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
The reason they are slow and tedious is that they need to write to every byte on the disk. Depending on the size of the disk, there may be a lot of data that needs to be written, and if they are older computers, write speed may not be particularly fast. -Chris On 6/5/05, rbt [EMAIL PROTECTED] wrote: Roose wrote: My guess would be: extremely, extremely easy. Since you're only writing 30 bytes for each file, the vast majority of the data will still be present on disk, just temporarily inaccessible because of the del command. And more than likely it will be possible to recover 100% if they are using a journaling file system like NTFS, which Windows XP does. If you are honestly trying to destroy your own data, go out and download a free program that will do it right. If you're trying to write some kind of trojan, well you've got a lot of learning to do. :) Thanks for the opinion... I don't do malware. Just interested in speeding up file wiping (if possible) for old computers that will be auctioned. The boot programs that you allude to (killdisk, autoclave) work well, but are slow and tedious. If this can be done *properly* in Python, I'd like to have a go at it. -- http://mail.python.org/mailman/listinfo/python-list -- Christopher Lambacher [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Chris Lambacher wrote: The reason they are slow and tedious is that they need to write to every byte on the disk. Depending on the size of the disk, there may be a lot of data that needs to be written, and if they are older computers, write speed may not be particularly fast. OK, I accept that, but if you have a HDD that's 8GB total and it has 1GB of files, why must every byte be written to? Why not just overwrite the used portion? -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
rbt wrote: Chris Lambacher wrote: The reason they are slow and tedious is that they need to write to every byte on the disk. Depending on the size of the disk, there may be a lot of data that needs to be written, and if they are older computers, write speed may not be particularly fast. OK, I accept that, but if you have a HDD that's 8GB total and it has 1GB of files, why must every byte be written to? Why not just overwrite the used portion? What do you think is in the unused space, given that much of it likely had files at some time in the past, maybe even older copies of some of the files that are currently live? If you haven't wiped all those files previously, their data is still quite accessible. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
Chris Lambacher [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The reason they are slow and tedious is that they need to write to every byte on the disk. Depending on the size of the disk, there may be a lot of data that needs to be written, and if they are older computers, write speed may not be particularly fast. I would expect programs called killdisk, autoclave, etc to not only write every byte multiple times, but to also work at the lowest level to try to manipulate track alignment to wipe out any residual signals off the current tracks. That is *really* slow. (Note: the ultimate security is to shread or incenerate the disk platters. I believe this is now standard practice in super security areas.) OP: if you merely want to wipe the data enough to protect against a casual user, using casual access thru normal open and read, and not the FBI disk forensics/recovery lab (;-), one write would be enough. On *nix, one could open '/dev/rawdisk' (actual name depends on the *nix build) and write a tracks worth of garbage for as many tracks as there are. I don't how to programmaticly get the track size and number (if there is a standard way at all). For Windows, you would need the appropriate low-level system call, but I have no idea what it is or if it is the same for different versions. Same for other non *nix systems. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
rbt [EMAIL PROTECTED] writes: Thanks for the opinion... I don't do malware. Just interested in speeding up file wiping (if possible) for old computers that will be auctioned. The boot programs that you allude to (killdisk, autoclave) work well, but are slow and tedious. Yes, you have to overwrite all the bytes on the disk, which can be slow. If the drive has ultra-sensitive data on it though, you should not auction it no matter what wiping software you've used. Think of bad sector forwarding that might have happened while the drive was in service. The drive firmware might have copied some sector that had recoverable errors to a new sector sometime in the past, and transparently mapped the new sector to the old location, so that normal I/O operations will never find the old sector to erase it. But suitable forensic methods might still be able to get it back. The only way to be 100% sure the data is gone from a drive, is basically to melt the drive. However, if your data is that sensitive, you shouldn't ever write it to a hard drive in the clear anyway. -- http://mail.python.org/mailman/listinfo/python-list
