Securely deleting files

[white scorpion]

Hi all,

I've written a small function which should securly delete the input file.
I want to implement this in TableCrypt to delete the original file if a user wants to do so.

Now i know the content of the file isn't going to be retrievable by software solutions, but how about hardware solutions?
Would it be better to overwrite the file multiple times with the same data, or multiple times with different data?

I don't have the technical skills and stuff to test this, so anyone who does is highly encouraged to tell his view on this.

here's the code which deletes file 'test.txt' 10 times:

Code Select Expand


.686                     
.model flat, stdcall     
option casemap :none   

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc


includelib \masm32\lib\masm32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib

RemoveFile              PROTO :DWORD, :DWORD
GenerateRandomByte      PROTO

.data
FileName    db 'test.txt',0
AppName     db 'Sdel v1.0 - White Scorpion',0
Format      db '%s %d %s',0
Firstline   db 'File overwritten ',0
Secondline  db ' times successfully',13,10,'and deleted afterwards.',0
base        dw 256
.data?
mybuf       db 128 dup (?)
myseed      dd ?

.code
start:

invoke RemoveFile,addr FileName,10
invoke ExitProcess,0

RemoveFile proc file_to_delete:DWORD,number_of_times:DWORD
    LOCAL hFile:DWORD
    LOCAL inputfilesize:DWORD
    LOCAL hMap:DWORD
    LOCAL myoffset:DWORD

    cmp number_of_times,0
    jnz @F 
    xor eax,eax
    dec eax
    ret
@@:
    invoke CreateFile,file_to_delete,GENERIC_WRITE + GENERIC_READ, 0, NULL, OPEN_EXISTING,\
    FILE_ATTRIBUTE_NORMAL, NULL
    mov hFile,eax
    invoke GetFileSize,eax,NULL
    mov inputfilesize,eax
    invoke CreateFileMapping,hFile,NULL,PAGE_READWRITE,0,0,NULL
    .if eax==NULL
@@:
        invoke CloseHandle,hFile
        xor eax,eax
        dec eax
        ret
    .endif   
    mov hMap,eax
    invoke MapViewOfFile,hMap,FILE_MAP_WRITE,0,0,0
    .if eax==NULL
        invoke CloseHandle,hMap
        jmp @B
    .endif
    mov myoffset,eax
;----First Round Start ----   

    xor ebx,ebx
    mov ecx,inputfilesize
@@:
    mov byte ptr [eax],bl
    inc eax
    dec ecx
    jnz @B   
    invoke FlushViewOfFile,myoffset,inputfilesize
;----First Round End ------

    .if number_of_times>1
;---- Second Round Start ----   
        mov eax,myoffset
        xor ebx,ebx
        dec ebx
        mov ecx,inputfilesize
@@:
        mov byte ptr [eax],bl
        inc eax
        dec ecx
        jnz @B 
        invoke FlushViewOfFile,myoffset,inputfilesize
;---- Second Round End ------
    .endif

;----Rest of Rounds Start -----
    .if number_of_times>2
        invoke GetTickCount
        mov myseed,eax
        mov edx,number_of_times
        sub edx,2
times_loop:
        mov ecx,inputfilesize
        push myoffset
        pop esi
        push edx
@@:
        push ecx
        push esi
        invoke GenerateRandomByte
        pop esi
        pop ecx
        mov byte ptr [esi],al
        inc esi
        dec ecx
        jnz @B
        invoke FlushViewOfFile,myoffset,inputfilesize
        pop edx
        dec edx
        jnz times_loop     
;----Rest of Rounds End ------- 
    .endif
 
    invoke FlushViewOfFile,myoffset,inputfilesize
    invoke UnmapViewOfFile,myoffset
    invoke CloseHandle,hMap
    invoke CloseHandle,hFile
    invoke DeleteFile,file_to_delete
    push offset Secondline
    push number_of_times
    push offset Firstline
    push offset Format
    push offset mybuf
    call wsprintf
    invoke MessageBoxA,NULL,addr mybuf,addr AppName,MB_OK
    xor eax,eax
    ret
RemoveFile endp


GenerateRandomByte proc
        mov eax,myseed
        mov ebx,127923
        mul ebx
        xor eax,479573
        xor eax,edx
        mov myseed,eax
        xor edx,edx
        div base
        mov eax,edx
        ret
GenerateRandomByte endp

end start

[TNick]

I don't knew if you read this section in WorkShop (WriteFile <-> HadrDrive <-> Data Recovery ); there were some interesting replies on this matter

[Ratch]

White Scorpion,

     That is a heavy subject you are playing with.  I once saw a TV interview with a computer whiz about securely erasing files.  He said that they can recover more than 80% of the data after the hard disk has been reformatted.  He also said that a lot of programs aver that they complete erase data, but very few really do it correctly.  My file manager is ZTREE, which features a disk "wash" with a selection of 3 methods.  They are writing with nulls, random, or the "Department of Defense sanitization method".  If you GOOGLE for "erase files", you can find a lot of programs and info about this subject.  Anyway, it is unlikely that an uninitiated hacker will come up with a secure erase algo.  From what I seen about this subject, it is going to take study, research, and knowledge that one person is unlikely to be able find out about just by theorizing on their own.  I tried washing a 3" floppy with ZTREE, and it took longer than formatting it would have.  Ratch

[Mark Jones]

If you REALLY want the data destroyed, nothing beats a sledge hammer or chunk of thermite... :U

[asmfan]

I think that the layer of API abstraction cannot give the full access over what happens on h/w (HDD in particular). The idea of writing random bits is good. You can also compare to a different standarts of secure deletion of data, there are a lot of them... From writing 0's and/or 1's for several times to mixing them all in a different sequence... These standards are fully documented and considered more or less secure and used on huge productions

[Darrel]

Here's a program I wrote a while back that overwrites a file with 0's then 1's a specified number of times. Simply place it or a shortcut in your SendTo folder then you can right click on any folder or file and send it to DigitalShredder. Source is included.

Regards,

Darrel

Edit: See my next post for corrected file.

[white scorpion]

From what I seen about this subject, it is going to take study, research, and knowledge that one person is unlikely to be able find out about just by theorizing on their own.

There's no need to re-invent the wheel.
These studies have already been performed.
i've did quite some research about it a few years ago since i wanted to know more about it and perform data recoveries.

Like i said, no software solution will retrieve these files. But that's not a problem to fix, most programs are capable of doing so. If you keep the file on the original location and overwrite that location (which you can do using the windows API's) then there is nothing to worry about.
However, by changing the location of the head against the platters you can read the outside of a sector and read data that has not been overwritten yet (by time).

I don't knew if you read this section in WorkShop (WriteFile <-> HadrDrive <-> Data Recovery ); there were some interesting replies on this matter

I did read it, but decided to start my own thread since i don't want to waste the threadstarters thread.

In theory, if you would write the same random bytes of data multiple times the magnetic field of the bits should get stronger and so making it harder to retrieve the original bits. However, in the time i've spend learning on the subject i still don't have a good number of times needed to securely erase a file.
Formatting a harddisk doesn't help because often you aren't overwriting all bytes, and even if you do (full format), the same problem with the head vs platter occurs.
If a harddisk has just been formatted, it's quite easy (for someone with the technical knowledge and equipment) to retrieve the data.

According to our government standards you should overwrite a file at least 3-4 times. However, if these 3 to 4 times would be random data at all times, then in my opinion it wouldn't be as strong as 3 - 4 times with the same random data every time.
This is the main subject on my question, i would like to hear your opinions about the subject.

here is a nice article on the subject. In the time i was studying the subject i've also spoken to some of the guys of this company.
However, since this is information they don't really want to share, it's something i decided to ask here, since here most people are willing to share information.

If you REALLY want the data destroyed, nothing beats a sledge hammer or chunk of thermite..

Could you give me the sourcecode for this approach?  :bg

[Mark Jones]

If you REALLY want the data destroyed, nothing beats a sledge hammer or chunk of thermite..

Could you give me the sourcecode for this approach?  :bg

Well, if you happen to have the CPU heatsinked to the HDD and execute this code, it should work about the same as thermite:

Code Select Expand


loopit:
    RDTSC
    jmp loopit


[white scorpion]

Well, if you happen to have the CPU heatsinked to the HDD

I doubt that will be the case.. why this instruction?
Doesn't any endless instruction heat up the cpu?

[Mark Jones]

Oh come on, it's a joke! :U

[white scorpion]

I know,
but i've never seen above instruction before, so it's something not used that often.
That's why i wondered why you choose exactly that instruction, even for a joke.

Btw, there were times when people actually believed that with an endless loop your whole computer would explode.
Although the cpu can be heated up, an intel cpu will stop working around 75 degrees celsius.
I believe amd is around 85-90 degrees.
I still don't get why it would explode ;)

[Mark_Larson]

White Scorpion,

     That is a heavy subject you are playing with.  I once saw a TV interview with a computer whiz about securely erasing files.  He said that they can recover more than 80% of the data after the hard disk has been reformatted.

That's because when you reformat a HD it doesn't erase any of the data.  It simply does a read-verify of all the sectors.   That's a common misconception that people have that formatting their drive erases their data.  That's why you hear people trying to do "low level formats" to get around issues like this.  Scorpions solution looks workable, I'll have to peruse it more carefully when I get the chance.

  He also said that a lot of programs aver that they complete erase data, but very few really do it correctly.  My file manager is ZTREE, which features a disk "wash" with a selection of 3 methods.  They are writing with nulls, random, or the "Department of Defense sanitization method".  If you GOOGLE for "erase files", you can find a lot of programs and info about this subject.  Anyway, it is unlikely that an uninitiated hacker will come up with a secure erase algo.  From what I seen about this subject, it is going to take study, research, and knowledge that one person is unlikely to be able find out about just by theorizing on their own.  I tried washing a 3" floppy with ZTREE, and it took longer than formatting it would have.  Ratch

  There are probably other solutions that are workable.  I'll have to see if I can dig up my copy of Norton Diskeditor to see if how well Scorp's code works.  Anyone else have a copy of Norton Diskeditor that can try in case I can't find my copy?

It basically let's you look at the disk at the low level.  you see the Root directory, fat tables, partition tables, sectors, etc.  You can modify it all directly.  I would keep backups of my first sector.  If I virus overwrote it, I could use Norton Diskeditor to write a new copy.  It supported saving different sectors to a file.

[white scorpion]

although no norton disk editor, but this cd (free of course), has some utilities which allow you to edit and view sectors of the harddisk:
http://www.ultimatebootcd.com/

I've used the cd quite often to solve partition problems, doing memtests and a whole lot more..

[skywalker]

If you REALLY want the data destroyed, nothing beats a sledge hammer or chunk of thermite... :U

That would waste the disk, a strong magnet works much better.

[Mark Jones]

...and have you tried this?

How strong is "strong?"

AFAICR, the magentic field strength at the track-level is very high because of the way the head channels the magnetic lines of force into the platter. I doubt even rubbing a neodymium straight on the disk surface itself would do much good, although I could be mistaken.