Writing Directory Entries

[Dean Sadata]

I've written an encryption program that shreds the original unencrypted file according to Department of Defence standards. After overwriting the file, I also wipe the date and time stamps, and truncate the file to zero length. I would also like to rename the file before deleting it so that the original name is not visible when using programs like Directory Snoop or Norton Unerase. The problem is that every rename function I've ever seen (DOS, PB, VB, Win API, etc.) actually makes a new directory entry with the new name and shows the old name as being discarded. Of course, this defeats the whole purpose of renaming, since the old filename is still visible. Does anyone have a PB example that writes directly to the MFT? I'm assuming this is the only way to accomplish what I want. I'd be interested in hearing any other ideas anyone has for accomplishing the same thing.

Thanks.


------------------

[Semen Matusovski]

I think that this task could be solved by following way.
1) To use "temporary" names of files.

      Dim lpTempDir As Asciiz * %MAX_PATH, lpTempFileName As Asciiz * %MAX_PATH
      lpTempDir = Environ$("Tmp")
      If lpTempDir = "" Then lpTempDir = Environ$("Temp")
      If lpTempDir = "" Then MsgBox "Can''t find TMP/TEMP": Exit Function
      If (GetAttr(lpTempDir) And 16) <> 16 Then _
         MsgBox "TMP/TEMP directory doesn''t exist": Exit Function
      GetTempFileName lpTempDir, "~pb", 0&, lpTempFileName

2) After usage, to open this file as Binary and to write String$(Lof(f), 0).
It will be correction on place, means all previous information will be destroyed.
After this it's better to hide real length of file: open file as Output and to write any random information.
Then kill a file.
Norton unerase is able to restore this file. And what it will be visible ?


[This message has been edited by Semen Matusovski (edited August 03, 2000).]

[Dean Sadata]

Thanks for the suggestion, but I think you've misunderstood my problem.

Example: A user has a file called TOPSECRET.DOC that they encrypt using my program. After I encrypt the file to a new filename, I shred the original unencrypted file. I need to remove the directory entry for TOPSECRET.DOC, not some file my program creates. The problem is that renaming TOPSECRET.DOC to something else before deleting it does not remove the original name from the directory table; it just makes a new directory entry with the new name and the old name is still visible to various utility programs.

[Edwin Knoppert]

This is for the 'ordinary' hacker.
Very good tough.

Norton 'wipe' from norton 6 wrote the data a few times.
On hardware level 'intruders' 'could' read the actual magnetic pulses written.
I believe that retrieving data in the early days was possible until 8x rewritten.

Don't believe format, it's just a sector=valid check!

Do a format, reset computer < 100% and see your data.



------------------
[email protected]

[Semen Matusovski]

Dean --
I suggested not to use "normal" names similar TOPSECRET.DOC for unencrypted files, because to hide them is enough difficult.
You can look (and test) SDelete utility http://www.sysinternals.com/sdelete.htm
But even these clever guys didn't find 100% reliable solution.

PS. As I understand, typical solution of security questions is usage special drivers, which emulate "secret disks", "innvisible folders".
Like sample - "Secret Disk" http://www.alladin.ru (this is international company, which has departments in 20-30 countries, but I don't know another sites; anyway, it possible to ask them by E-Mail [email protected]).
To have access you should insert small electronic key into USB/LPT port and to enter password.
After this appears additional disk, which really is encrypted file (256-bit encryption).
Then you can work with it like with ordinary disk.



[This message has been edited by Semen Matusovski (edited August 04, 2000).]

[Greg Turgeon]

Dean--
   
Here's the best that you're likely to do.  Rename TOPSECRET.DOC at 
least twice.  Do so without performing any other file access in 
between the renamings.  Renaming the file will cause a new file entry 
to be created, and the old file entry will be deleted, with "deleted" 
meaning that the entry's first character is replaced with chr$(229). 
(I know. You know this already, and it's the source of the problem 
you're trying to address.)  However, when renaming the file a second 
time, the OS goes back and reuses the most recently deleted entry, 
overwriting the chr$(229)+"OPSECRET.DOC" entry with whatever file 
name you've supplied this second time.  This is true under Win9x, and 
it most likely is true under NT/2K as well. (I don't have the time to 
test it right now.) 
   
In effect:
   oldname$ = "TOPSECRET.DOC"
   newname$ = "XXXXXXXXX.XXX"
   name oldname$ as newname$
   
   oldname$ = newname$
   newname$ = "YYYYYYYYY.YYY"
   name oldname$ as newname$
   
At this point, if you examine the directory at the sector level, 
you'll see that the "TOPSECRET.DOC" entry no longer exists, and 
"YYYYYYYYY.YYY" has replaced it.

------------------
-- Greg
[email protected]

[Semen Matusovski]

Greg --
from a comment to SDelete utility.
To overwrite file names of a file that you delete, SDelete renames the file 26 times, each time replacing each character of the file's name with a successive alphabetic character. For instance, the first rename of "foo.txt" would be to "AAA.AAA".
But Note that SDelete securely deletes file data, but not file names located in free disk space.
In other words, SDelete tries, but can't garantee that renaming is reliable.

If to think about recovering (and Microsoft does it), more or less correct algorithm, in my understanding, looks so:
1) first of all, to use uninitialized entries.
2) if not available, to use entries for deleted files
3) if not available in clusters, which are already in use, to take new cluster.

------------------

[Dean Sadata]

Greg, thanks for your suggestion. However, renaming the file multiple times was something I already tried, unfortunately to no avail. I don't think your statement that the OS reuses the most recently deleted entry is accurate, because even the example you provided doesn't work. Your example creates directory entries for "TOPSECRET.DOC", "XXXXXXXXX.XXX" and "YYYYYYYY.YYY". The first two directory entries are still visible after processing is complete.

Even after multiple renames it always leaves at least some of the old file names. For example, I had a directory with 20 files which I shredded one at a time, renaming each as many as 50 to 100 times before deleting. There doesn't seem to be any definite rule that it follows so it's really difficult to nail down.

Semen, you suggested "not to use 'normal' names similar [to] TOPSECRET.DOC for unencrypted files." I have no control over what people name their files, and I can't suggest that they call "Budget - 1998.xls" something cryptic like "HgyYU3asf.xls". Furthermore, the names of most files that end up on a person's hard drive (from Internet, email, trialware, etc.) are completely beyond their control.

------------------

[Greg Turgeon]

[I've discovered, with much embarrassment, that I accidentally 
deleted a paragraph from this posting while cutting & pasting it from 
my text editor.  As a result, what I intended to say was badly 
distorted in my original posting.] 
   
Dean--
   
 

	

		

			

			
				...renaming the file multiple times was something I already 
tried, unfortunately to no avail. I don't think your statement that 
the OS reuses the most recently deleted entry is accurate, because 
even the example you provided doesn't work. Your example creates 
directory entries for "TOPSECRET.DOC", "XXXXXXXXX.XXX" and 
"YYYYYYYY.YYY". The first two directory entries are still visible 
after processing is complete.
			
		
	
I've now tried this on two PCs and under three operating systems. 
What I described worked exactly as I stated.  I also verified that 
the same method works with filenames on a floppy under NT4.  
   
Note also that my example does not create a directory entry for 
TOPSECRET.DOC.  It assumes that this file already exists. 
   
Having said all this, I also have not tested this approach across 
several file names in succession in a single directory.  It's not 
hard to imagine various factors (write-delays, for example) affecting 
when and how the disk is accessed by the OS.  Moreover, only fools  
rely on a tactic simply because "it seems to work OK."  Reusing the 
most recently deleted filename entry is consistent with other aspects 
of Microsoft file system operations, but Microsoft has never promised 
consistency about anything, even its fully documented features. 
   
   
Semen--
 

	

		

			

			
				If to think about recovering (and Microsoft does it), more or 
less correct algorithm, in my understanding, looks so:
   
1) first of all, to use uninitialized entries.
2) if not available, to use entries for deleted files
3) if not available in clusters, which are already in use, to take new 
cluster
			
		
	
All of this sounds fine, if you can find a way to access the 
directory reliably.  NT provides an interface for disk defraggers 
that might offer some help. 
   
An interesting little challenge.

[This message has been edited by Greg Turgeon (edited August 04, 2000).]

[Greg Turgeon]

[duplicate deleted]


[This message has been edited by Greg Turgeon (edited August 04, 2000).]

[Dean Sadata]

Since you had success with this, I attempted the same thing from the Windows 98 command prompt, and it worked as you reported. However, I just determined why: It's not because I did it from a command prompt, but rather, because there was only one file in the folder. As soon as there is more than one file in the folder this technique fails, whether using DOS, WinAPI, VB or PB.

For example, if I have a folder with two files in them, SERVICES.TXT and SUPPORT.TXT, and I rename SERVICES.TXT to XXXXXXXX.XXX, then rename XXXXXXXX.XXX to YYYYYYYY.YYY, and then delete YYYYYYYY.YYY, then the directory appears as follows:

?ERVICES.TXT
SUPPORT.TXT
?XXXXXXX.XXX
?YYYYYYY.YYY

If you repeat the same experiment with SERVICES.TXT in the folder all by itself, you'll get:

?XXXXXXX.XXX
?YYYYYYY.YYY

This explains why my past attempts to use file renaming to hide the original filename failed. Any other ideas? Some time ago I recall someone mentioning using DOS interrupt 13H to write directly to the allocation table, but I couldn't find anything to substantiate that claim.

Thanks for your suggestions.


------------------


[This message has been edited by Dean Sadata (edited August 04, 2000).]

[Semen Matusovski]

BTW, found http://www.tolvanen.com/eraser/source.html
(did not try)

Greg --
I don't doubt that method, which you suggested, works in certain situations.
(I have no Norton Utilities and even can't test).

But in general I beleive sysinternals...
These guys wrote well-known drivers, which allows to read (and write in commercial releases) NTFS disks under 9x and FAT32 under NT.
This means that they exactly know a structure of catalogs.

In their utility SDelete they do (even 26 times) exactly what you suggest.
If so, SDelete in any case should destroy catalog entries forever.
But authors don't promiss such effect.
For me this means that they know situations when renaming doesn't work.

It's clear that sooner or later OS will use unused entry.
Stupid idea (which I can't test): what happends, if to try to create a big list of dummy files, which names should be stored like minimum in one cluster.
(then to kill these dummy files, of course).

------------------

[Greg Turgeon]

Dean--
Have a look at what you've attempted.  You've replaced a short file 
name (SUPPORT.TXT) with a long file name (XXXXXXXXX.XXX).  Rename by 
using a file name with the same number of characters as the original, 
up to the 8.3 limit--unless the original is a long file name, 
in which case you probably should match the number of characters in 
the original. 
   
Please post the results here.
   
Moreover, if you plan to do something like this through code, then 
testing it at a command line seems unwise, doesn't it?  You end up 
adding a command interpreter's internal behavior to the mix. 
   
By the way, how are you checking the deleted directory entries?  Are 
you examining the disk itself with a disk editor, or are you relying 
on an undelete utility?
   
   
Semen--
   
Please see my corrected posting above.
 

	

		

			

			
				In their utility SDelete they do (even 26 times) exactly what 
you suggest. If so, SDelete in any case should destroy catalog 
entries forever. But authors don't promiss such effect. For me this 
means that they know situations when renaming doesn't work.
			
		
	
I too believe that the System Internals folks usually know what 
they're doing.  They certainly know more about internal OS design 
than I do.  However, in this case, think for a minute about their 
SDelete utility.  It attempts to obliterate file name entries by 
renaming 26 times.  The source code, which they make available, shows 
this occurring--26 passes through the loop.  And as Mark Russinovich 
states in the source code: 
   
// OverwriteFileName
//
// Securely deletes a file's original name by renaming it several
// times. This works by changing each non-'.' character in the file's
// name to successive alphabetic characters, thus overwriting the
// name 26 times.
   
They obviously should correct the inconsistency between this 
"Securely deletes" statement and their much more equivocal web site 
statements. 
      
In any case, from what is obvious just in the limited experimenting 
that I've now done, wouldn't it seem that 52 renamings would be 
required to achieve the desired 26 overwrites?
   
I stress again that I'm not endorsing apparent behavior as 
sufficient evidence of anything.  In this case, the next logical step 
would be to seek reliable information about how MS operating systems 
reuse file name entries.  Such information probably does 
exist--somewhere.

[This message has been edited by Greg Turgeon (edited August 04, 2000).]

[Dean Sadata]

Greg Turgeon wrote:

> Have a look at what you've attempted. You've
> replaced a short file name (SUPPORT.TXT) with
> a long file name (XXXXXXXXX.XXX).

Go back and count the Xs. Perhaps you're confused because the X is wider than most characters in the proportional spaced font that is being used (Verdana) so the filename appears longer. But it isn't; it's 8.3 just like the filename SERVICES.TXT. (Above you mentioned SUPPORT.TXT, but this isn't even the file that was being renamed.)

Either way, it won't make a difference.


> Moreover, if you plan to do something like this
> through code, then testing it at a command line
> seems unwise, doesn't it?

No, it doesn't. Everytime I test, I create a new directory and make fresh copies of the test files in it.


> By the way, how are you checking the deleted
> directory entries? Are you examining the disk
> itself with a disk editor, or are you relying
> on an undelete utility?

I use Directory Snoop by BriggSoft.


------------------




[This message has been edited by Dean Sadata (edited August 05, 2000).]

[Greg Turgeon]

 

	

		

			

			
				> Have a look at what you've attempted. You've
> replaced a short file name (SUPPORT.TXT) with
> a long file name (XXXXXXXXX.XXX).
   
Go back and count the Xs. Perhaps you're confused because the X is 
wider than most characters in the proportional spaced font that is 
being used (Verdana) so the filename appears longer. But it isn't; 
it's 8.3 just like the filename SERVICES.TXT. (Above you mentioned 
SUPPORT.TXT, but this isn't even the file that was being 
renamed.)
   
Either way, it won't make a difference.
			
		
	
You're right.  It was SERVICES.TXT that was being renamed.  Also a 
short filename, just like SUPPORT.TXT. 
      
I've investigated this one further.  Michael's Podanoffsky's book 
Dissecting DOS offers a good picture of the process by which 
DOS goes about searching for a free directory entry to use.  What he 
describes explains what I've seen happening, and probably what Dean 
has been seeing too. 
   
According to Podanoffsky, the process of locating the free entry is 
completely predictable.  It starts at the first directory entry and 
works forward, looking for a filename that begins with either a zero 
byte or E5h.  The zero byte indicates the beginning of free space in 
the directory (i.e., the end of the directory itself).  The E5h 
indicates a filename that has been deleted.  Naturally any deleted 
entries precede the inevitable zero byte entry. 
   
Because the search begins at the start of the directory, the 
following will be true: 
   
-- If the directory contains no deleted filenames, then the process 
which I've described (renaming a file twice to overwrite the original 
name) works as expected.  The total number of existing files in the 
directory is irrelevant.  Any number can exist.  What counts is the 
number of deleted files, which must be zero. 
   
-- If a directory already contains one or more deleted filename 
entries, then renaming twice will work only if the original filename 
appears in the directory before any of the existing deleted filename 
entries. 
   
Considering the work that would be entailed in manipulating a 
directory so as to control which deleted entry is overwritten, it's 
not surprising that reputable security utilities don't guarantee 
success.  The job could be done, of course.  But only if: 
   
-- The search process Podanoffsky describes is still executed the 
same way by MS operating systems in place today.  (It appears to be, 
at least on some of them, but only my anecdotal evidence supports 
this conclusion.) 
   
-- You're prepared to access the directory itself and rearrange its 
contents when necessary.  (Although not simple, this maneuver is 
certainly conceivable, at least under some operating systems.  But if 
you're prepared to go this far, you'll just access the directory and 
make it contain whatever you want.) 
      
-- You're protecting something valuable enough to be worth the all 
the trouble.
   
An interesting little challenge indeed.

------------------
-- Greg
[email protected]

[Michael Ritter]

Just noticed someone else suggested it. Sorry about that

I was glancing through this thread and was reminded
of a site with some code including some information
that you may find useful. Here is the link http://www.sysinternals.com/sdelete.htm hope it
helps.

Cheers,

Michael Ritter

------------------


[This message has been edited by Michael Ritter (edited August 08, 2000).]

[John Kovacich]

Dean, I realize this thread is a bit old, but you might try this:

Rename your file once.
Create x new files, perhaps 26 as used by sdelete. Better yet, if you
or anyone knows how to determine how many deleted files are in the derectory,
create that many files. Then rename your file a handful of times.
To be extra sure, repeat the whole process. Then delete all the temp
files.

As stated in this thread, succesive renames does not work if there
are more than one deleted files. So I am suggesting that you "fill"
the deleted entries, then delete all of them.

John Kovacich

------------------