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 28 2019
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
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.
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 <rb*@athop1.ath.vt.edu> 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 la******@computer.org
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?
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?
Because sometime in the past, you may have had 8 GB of data on there.
There's no reliable way to know which bytes have been used and which
haven't.
This is a case where "doing it properly" means "slow."
--
Robert Kern rk***@ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
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
"Chris Lambacher" <la******@gmail.com> wrote in message
news:af************************@mail.gmail.com... 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
On Sun, 5 Jun 2005 21:12:57 -0400, Chris Lambacher <la******@gmail.com>
declaimed the following in comp.lang.python: 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.
And then, if you are looking for a mil-spec wipe, you are
looking at something like three complete passes using different
patterns. Last assignment I had that required wiping a file was able to
get away with the simple routine of:
get length of file
generate len random data
write data
read and compare
generate len random data
write data
read and compare
ones-complement data
write data
read and compare.
If any compare failed, the wipe, as a whole, was considered to
have failed.
Not too time-consuming on a 64 byte file... Tedious on
megabytes.
My previous facility didn't even accept mil-spec wipes -- all
disk drives leaving the facility had to go through a demagnitizer, which
wiped everything, including control tracks, and played <bleep> with the
R/W head and positioning magnets.
Partition Magic does have a non-DoD approved "Delete and Secure
Erase" for hard drives. Probably a single pass random write...
-- ================================================== ============ < wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < wu******@dm.net | Bestiaria Support Staff < ================================================== ============ < Home Page: <http://www.dm.net/~wulfraed/> < Overflow Page: <http://wlfraed.home.netcom.com/> <
rbt <rb*@athop1.ath.vt.edu> 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.
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
On 05 Jun 2005 21:14:37 -0700, rumours say that Paul Rubin
<http://ph****@NOSPAM.invalid> 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...
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 rk***@ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
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
Michele Simionato wrote: The problem is that Google gives me too many non-relevant hits.
google("fat undelete")
google("ext2 undelete")
--
Robert Kern rk***@ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
On 6 Jun 2005 07:04:26 -0700, "Michele Simionato"
<mi***************@gmail.com> declaimed the following in
comp.lang.python: 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
Highly unlikely... Most OSs implement a file "delete" by wiping
out the part of the directory structure that contained the file name...
Though I've never figured out how FAT handles directories...
If you haven't written to the drive since the delete, the
various tools will allow you to locate chains of data blocks that had
been associated with one or more files. You then determine which
chain(s) belong(s) to the file in question, and recreate a directory
entry for it.
On an old Amiga, this would be child's play -- The Amiga stored
file names in "file header blocks"; directory blocks only had pointers
to the header, accessed by a hash of name. The rest of the file system
was all multiple-head, linked-list, chains (root directory block points
to file-header/subdirectory blocks, file-header points to data blocks
and next "file header" for overflow data blocks, hash collisions handled
by chaining all colliding names into a list, etc...)
-- ================================================== ============ < wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < wu******@dm.net | Bestiaria Support Staff < ================================================== ============ < Home Page: <http://www.dm.net/~wulfraed/> < Overflow Page: <http://wlfraed.home.netcom.com/> <
"Dennis Lee Bieber" <wl*****@ix.netcom.com> wrote in message
news:io********************************@4ax.com... 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
On 2005-06-06, Terry Reedy <tj*****@udel.edu> 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.com following me??
Terry Reedy wrote: "Dennis Lee Bieber" <wl*****@ix.netcom.com> wrote in message news:io********************************@4ax.com...
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.
"Terry Reedy" <tj*****@udel.edu> 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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mike Meyer wrote: "Terry Reedy" <tj*****@udel.edu> 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
On 2005-06-06, rbt <rb*@athop1.ath.vt.edu> 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/f...er/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
rbt <rb*@athop1.ath.vt.edu> writes: Mike Meyer wrote: "Terry Reedy" <tj*****@udel.edu> 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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
On Mon, 6 Jun 2005 15:20:33 -0400, "Terry Reedy" <tj*****@udel.edu>
declaimed the following in comp.lang.python: 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?)
Most disk drive cases look to be a non-ferrous alloy, no block
to a drive... And yes, sticking a magnet on the side of the computer
near the a drive could be a threat <G> I take this to mean the the drive is non-functional and might have well been melted, except that demagnetising is cheaper.
Correct.
-- ================================================== ============ < wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < wu******@dm.net | Bestiaria Support Staff < ================================================== ============ < Home Page: <http://www.dm.net/~wulfraed/> < Overflow Page: <http://wlfraed.home.netcom.com/> <
On Mon, 06 Jun 2005 15:48:48 GMT, Dennis Lee Bieber
<wl*****@ix.netcom.com> declaimed the following in comp.lang.python: On an old Amiga, this would be child's play -- The Amiga stored file names in "file header blocks"; directory blocks only had pointers
I should clarify: deletion unlinked the file header from the
directory chain and marked the sectors as free in the disk bitmap, but
did not modify the file name stored in the file header. So a simple disk
sector browser could be used to locate file headers, then relink them to
a directory and mark the data sectors in use...
Originally, data sectors used some space to hold pointers back
to file headers, and to next data sector... Made it easy to recover
since almost any disk block could be used to locate the header, then
chain all the data back... Overhead was getting only 488 data bytes per
sector.
-- ================================================== ============ < wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < wu******@dm.net | Bestiaria Support Staff < ================================================== ============ < Home Page: <http://www.dm.net/~wulfraed/> < Overflow Page: <http://wlfraed.home.netcom.com/> <
I think it depends on your os variables
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.)
Magnus Lycka <ly***@carmen.se> 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("0a1b2c3d4e5f6g7h8i9j~!@#$%^&*;")
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Grant Edwards <gr****@visi.com> 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/~pgut00...ecure_del.html
Go for the thermite reaction instead!-) (please don't try that at home, kids)
John This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: dpackwood |
last post by:
Hello,
I have two different scripts that do pretty much the same thing. The main
perl script is on Windows. It runs and in the middle of it, it then calls
out another perl script that then...
|
by: Mad Programmer |
last post by:
I'm writing a destructive trojan with C++ and I need to know how I can
destroy the target's monitor and format the target's harddisk before the
target can stop the program.
What do I need to do?
|
by: lvpaul |
last post by:
Hallo !
I am using IIS-Windows-Authentication in my intranet
(web.config <authentication mode="Windows" /> <identity
impersonate="true" />
How can I get the users (client) IP-Address ?
I...
|
by: Chris Paul |
last post by:
I'm having trouble with PHP & PostgreSQL/OpenLDAP/Apache on Windows.
I've set this up countless times on BSD (piece of cake) but I'm trying
to do this on Windows now so that my developer can work...
|
by: reachsamdurai |
last post by:
Hello,
Can you please let me know the procedure to reach db2 command prompt
from a cygwin window (hence without using Start-> Run -> db2cmd
method). I'm planning to write shell scripts which...
|
by: candra |
last post by:
How Hackers Attack?
-Nukers
-File Wiping
-Email Bombz
-Destructive Tools
-Denial Of Service
|
by: AmberJain |
last post by:
Windows Autorun FAQs: Programs dealing with autoruns
Linked from the Original article- "Windows Autorun FAQs: Description".
Que: Can you list programs that help me to view/modify the autoruns...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |