Announcement

Collapse
No announcement yet.

Writing Directory Entries

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Writing Directory Entries

    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.


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

  • #2
    I think that this task could be solved by following way.
    1) To use "temporary" names of files.
    Code:
          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).]

    Comment


    • #3
      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.

      Comment


      • #4
        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]
        hellobasic

        Comment


        • #5
          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).]

          Comment


          • #6
            Code:
            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]

            Comment


            • #7
              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.

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

              Comment


              • #8
                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.

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

                Comment


                • #9

                  Code:
                  [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).]

                  Comment


                  • #10
                    [duplicate deleted]


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

                    Comment


                    • #11
                      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).]

                      Comment


                      • #12
                        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).

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

                        Comment


                        • #13
                          Code:
                          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).]

                          Comment


                          • #14
                            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).]

                            Comment


                            • #15
                              Code:
                               
                              > 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]

                              Comment


                              • #16
                                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).]

                                Comment


                                • #17
                                  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

                                  ------------------
                                  Thanks,

                                  John Kovacich
                                  Ivory Tower Software

                                  Comment

                                  Working...
                                  X