 |
|
 |
Why do you assume 512-byte sectors? I know, it's not common, but 512 is not a constant.
|
|
|
|
 |
|
 |
You are absolutely right, I guess I didn't do my homework.
Does anyone know how to get the sector-size if the drive in question?
|
|
|
|
 |
|
|
 |
|
 |
Hello,
Be aware of a fact that enabling system restore on drive, sometimes may save data you want to be completely destroyed.
|
|
|
|
 |
|
 |
Hi Johan,
I read your article and noticed your successful experiments, but nevertheless I have two
issues with it:
1.
if you write to a file stream, rewind, write again, rewind, etc, what assures you
that each of these passes gets actually written to disk? it could as well be memory bytes
that get written all the time, and only when the stream gets closed it is committed
to the file system's cache and after that also to the disk. So it might well be that only
the final pass's data makes it to the disk, if so what is the sense of the many passes?
2.
if you write to an existing file, what guarantee do you have that the same physical sectors
will be reused? The data gets cached, then flushed to disk; the file system will discover
it can write entire sectors or clusters, but could choose to change the actual sectors/
clusters being used (e.g. in an attempt to reduce disk fragmentation on the go).
I guess it will not, most of the time, but is there any documented guarantee? And does
it apply to all kinds of file systems? (local FAT, FAT32, NTFS,...) and remote file
systems (Windows or other).
If I were to go and erase a file thoroughly I would rely on P/Invoke and the lowest-level
system calls I can find to circumvent all possible buffers, caches and delayed execution.
modified on Monday, January 07, 2008 9:03:33 PM
|
|
|
|
 |
|
 |
I would hope that flushing the stream would handle the first part.
Opening the file for read and write should handle the second.
For the third part; that's why when I wrote something similar last summer I used C rather than C#.
|
|
|
|
 |
|
 |
PIEBALDconsult wrote: I would hope that flushing the stream would handle the first part.
It would be a step in the right direction, but still not sufficient; disk drives themselves
have built-in caches, and at best guarantee they get flushed to the medium within some
short time, say 30 seconds. I am not aware they offer a way to force it any sooner.
Flushing a file stream at best will send data to the disk's built-in cache.
So the advice would be to have a delay of say 1 minute in between write passes.
PIEBALDconsult wrote: Opening the file for read and write should handle the second.
I doubt that too: a single process reading or reading+writing to a stream should
make no difference, the data gets cached in the PC memory anyway; maybe setting
Shared.ReadWrite is an improvement, but in both cases, as long as the OS is aware the
sector is cached somewhere in memory, it could write it out to another physical location
on disk.
[ADDED]What I am saying basically is: I expect the file system cache to be a logical
cache, holding sectors that belong in files, as opposed to a physical cache, which
would hold sectors by their sector number.[/ADDED]
For a disk wiping utility, I would prefer to see documented facts and some strong
logic reasoning.
PS: I am not applying for a DOD job, just trying to imagine what happens behind the scenes...
|
|
|
|
 |
|
 |
<small>1.
if you write to a file stream, rewind, write again, rewind, etc, what assures you
that each of these passes gets actually written to disk? it could as well be memory bytes
that get written all the time, and only when the stream gets closed it is committed
to the file system's cache and after that also to the disk. So it might well be that only
the final pass's data makes it to the disk, if so what is the sense of the many passes?</small>
It's true and not, I ran a test like this, first pass 0, second pass 1, third pass 3 and so on, having a break-point after each pass.
When checking the disc in hex-view using Disk Investigator after each pass, all but the last sector is written to.
The conclusion I came to is that it doesn't release the dummybuffer to disc until I call Filestream.Write a second time or Filestream.Close, but it does write to the disc in each pass.
<small>2.
if you write to an existing file, what guarantee do you have that the same physical sectors
will be reused? The data gets cached, then flushed to disk; the file system will discover
it can write entire sectors or clusters, but could choose to change the actual sectors/
clusters being used (e.g. in an attempt to reduce disk fragmentation on the go).
I guess it will not, most of the time, but is there any documented guarantee? And does
it apply to all kinds of file systems? (local FAT, FAT32, NTFS,...) and remote file
systems (Windows or other).</small>
When I use Disc Investigator, I can step each cluster and sector on the disc so I can see it's the right parts on the disc that gets overwritten on FAT, FAT32 and NTFS.
However, this is tested on a clean disc so the fragmentation could be a problem in some cases.
|
|
|
|
 |
|
 |
Johan Martensson wrote: I ran a test like this...
Sure, but didn't your test infuence the system's behavior? you added a process accessing the
same file, and you probably increased the delay in between the write passes a lot.
|
|
|
|
 |
|
 |
That's certainly true but the fact remains that no file could be recovered using any of the software recovery tools I tried, not in file- or raw-mode.
Then again I would have to agree with you, to be absolutely certain, using P/Invoke and the lowest-level system calls would be the way to go.
|
|
|
|
 |
|
|
 |
|
 |
Ohhh, that's bad, thanks for the heads up.
I have submitted an update...
|
|
|
|
 |
|
 |
This is very nice. I have seen other examples of something like this, but none that change the file size to 0.
Btw, the DoD overwrites the file three times; first with 0's, then 1's, then 0's again.
|
|
|
|
 |
|
 |
There are actually a couple of implementations of DoD with various number of passes and I was thinking about implementing them and a couple of other standard algorithms in this class so there will be an ability to choose.
Stay tuned for updates...
|
|
|
|
 |
|
 |
I'm just wondering if erasing the file with a new file of the same size with all 0 byte value would do the job instead of using a complicated random byte generator?
|
|
|
|
 |
|
 |
That would work in most cases.
But if you want to be really paranoid, think about it, if you go with all zeros it would leave a nice clean hole on your drive where the file use to be but if you fill that with random data you hide the fact that a file has been wiped.
There are several standard wiping algorithms to chose from, here are some
http://www.whitecanyon.com/esupport/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=164&nav=0[^]
The important thing is, the more times you write over the file, the more it's destroyed
|
|
|
|
 |
|
 |
> The important thing is, the more times you write over the file, the more it's destroyed
Can some exists algorithm/programm restore information after at least 1 write over the file with random bytes???
modified on Wednesday, January 09, 2008 1:43:41 AM
|
|
|
|
 |
|
 |
I found a couple of interesting blog-spots where they quote Ontrack's Remote Data Recovery Manager Sean Berry and Csuba from KUERT Group's Data Recovery
http://blogs.computerworld.com/node/5687[^]
http://blogs.computerworld.com/node/5756[^]
After reading this, I'm beginning to think that overwriting the data once should be enough with modern-day harddrives.
So as to your question, for now I would have to say, no there isn't.
|
|
|
|
 |
|
|
 |