Evidence Eliminator Tested

[Ian Batten]

On 13 Sep 09, at 2222, signup at bealoid.co.uk wrote:

> Quoting John <j.s.tyne at btinternet.com>:
>
>> Without knowing the settings I can't offer any detail, but the MG  
>> Rover report states in the conclusion of the dedicated chapter XXIV  
>> entitled Evidence Eliminator,  "that data could not be recovered  
>> and so it was impossible to assess the importance of the material  
>> deleted."
>>
>> I have sent this information because in the legal groups there has  
>> been much speculation and uncertainty about the forensic recovery  
>> of data after deletion using EE. I see now that forensic imaging is  
>> not all it is cracked up to be.
>
> You need to use threat models to decide if software like heidi's  
> eraser / dban / etc are effective.
>
> A single overwrite of the whole disc is probably enough to render  
> any data on it unrecoverable.  Be aware of sectors marked as bad  
> (which may contain data and not be overwritten), of Host Protected  
> Partitions, etc.
>
> More overwrites, using pseudo-random data, isn't going to hurt  
> anything.



For some value of pseudo-random.

I can be confident that an endless sequence of zeros, or some other  
fixed pattern, is information free.  If I read the disk back on  
another machine to confirm that it contains the pattern I wrote then  
modulo subversion of the disk drive firmware (not a trivial risk, of  
course) I'm good to go.

[[ An obvious strategy would be for the disk to have more capacity  
than is advertised, and use the spare space to squirrel away  
`interesting' blocks that can be retrieved using a special driver: if  
I'm worried about that, physical destruction is the only route. ]]

If I deployed some strategy that the disk drive firmware could not  
predict to pass back fake results, though, such as writing successive  
blocks of the output from some shift register or repeated results of  
X(n)=(X(n-1)^a)%m for prime a and m forming a generator, then I'm also  
good to go.

What would be very, very bad would be to use:

dd if=/dev/urandom of=/dev/rdsk/c0t0d0s2 bs=1024k

(or /dev/random)

because I have absolutely no way to confirm that the data I'm writing  
is not derived from what I'm overwriting, nor that the disk has really  
taken the blocks and is going to write them to the surface.

ian