www.sysinternals.com/ntw2k/source/sdelete.shtml
Mark Russinovich Last Updated: October 15, 2003 v12 Introduction One feature of Windows NT/2000's (Win2K) C2-compliance is that it impleme nts object reuse protection. This means that when an application allocat es file space or virtual memory it is unable to view data that was previ ously stored in the resources Windows NT/2K allocates for it. Windows NT zero-fills memory and zeroes the sectors on disk where a file is placed before it presents either type of resource to an application. However, object reuse does not dictate that the space that a file occupies before it is deleted be zeroed. This is because Windows NT/2K is designed with the assumption that the operating system controls access to system reso urces. However, when the operating system is not active it is possible t o use raw disk editors and recovery tools to view and recover data that the operating system has deallocated. Even when you encrypt files with W in2K's Encrypting File System (EFS), a file's original unencrypted file data is left on the disk after a new encrypted version of the file is cr eated. The only way to ensure that deleted files, as well as files that you encr ypt with EFS, are safe from recovery is to use a secure delete applicati on. Secure delete applications overwrite a deleted file's on-disk data u sing techiques that are shown to make disk data unrecoverable, even usin g recovery technology that can read patterns in magnetic media that reve al weakly deleted files. You can use SDelete both to securely delete existing files, as well as to securely erase any file data that exists in the unallocated portions of a disk (including files that you have already deleted or encrypted). SDelete is presented with full sourc e code so that you can verify yourself that it works as advertized. Note that SDelete securely deletes file data, but not file names located in free disk space. SDelete Usage SDelete is a command line utility that takes a number of options. In any given use, it allows you to delete one or more files and/or directories, or to cleanse the free space on a logical disk. SDelete accepts wild ca rd characters as part of the directory or file specifier.
What is more tricky is securely deleting Win dows NT/2K compressed, encrypted and sparse files, and securely cleansin g disk free spaces. Compressed, encrypted and sparse are managed by NTFS in 16-cluster blocks . If a program writes to an existing portion of such a file NTFS allocat es new space on the disk to store the new data and after the new data ha s been written, deallocates the clusters previously occupied by the file . NTFS takes this conservative approach for reasons related to data inte grity, and in the case of compressed and sparse files, in case a new all ocation is larger than what exists (the new compressed data is bigger th an the old compressed data). Thus, overwriting such a file will not succ eed in deleting the file's contents from the disk.
Using the defragmentation API SDelete can determine precisely which clusters on a disk are occupied by data belonging to compressed, sparse and encrypted files. Once SDelete knows which clusters contain the file 's data, it can open the disk for raw access and overwrite those cluster s Cleaning free space presents another challenge. Since FAT and NTFS provid e no means for an application to directly address free space, SDelete ha s one of two options. The first is that it can, like it does for compres sed, sparse and encrypted files, open the disk for raw access and overwr ite the free space. This approach suffers from a big problem: even if SD elete were coded to be fully capable of calculating the free space porti ons of NTFS and FAT drives (something that's not trivial), it would run the risk of collision with active file operations taking place on the sy stem. For example, say SDelete determines that a cluster is free, and ju st at that moment the file system driver (FAT, NTFS) decides to allocate the cluster for a file that another application is modifying. The file system driver writes the new data to the cluster, and then SDelete comes along and overwrites the freshly written data: the file's new data is g one. The problem is even worse if the cluster is allocated for file syst em metadata since SDelete will corrupt the file system's on-disk structu res. The second approach, and the one SDelete takes, is to indirectly overwrit e free space. SDelete does this using non-cached file I/O so that the contents of the NT file system cache will not be thrown out and replaced with useless data assoc iated with SDelete's space-hogging file. Because non-cached file I/O mus t be sector (512-byte) aligned, there might be some left over space that isn't allocated for the SDelete file even when SDelete cannot further g row the file. To grab any remaining space SDelete next allocates the lar gest cached file it can. For both of these files SDelete performs a secu re overwrite, ensuring that all the disk space that was previously free becomes securely cleansed. On NTFS drives SDelete's job isn't necessarily through after it allocates and overwrites the two files. SDelete must also fill any existing free portions of the NTFS MFT (Master File Table) with files that fit within an MFT record. An MFT record is typically 1KB in size, and every file or directory on a disk requires at least one MFT record. Small files are s tored entirely within their MFT record, while files that don't fit withi n a record are allocated clusters outside the MFT All SDelete has to do to take care of the free MFT space is allocate the largest file it can - when the file occupies all the available space in an MFT Record NTFS w ill prevent the file from getting larger, since there are no free cluste rs left on the disk (they are being held by the two files SDelete previo usly allocated). When SDelete can no l onger even create a new file, it knows that all the previously free reco rds in the MFT have been completely filled with securely overwritten fil es. To overwrite file names of a file that you delete, SDelete renames the fi le 26 times, each time replacing each character of the file's name with a successive alphabetic character. The reason that SDelete does not securely delete file names when cleaning disk free space is that deleting them would require direct manipulation of directory structures. Directory structures can have free space conta ining deleted file names, but the free directory space is not available for allocation to other files. Hence, SDelete has no way of allocating t his free space so that it can securely overwrite it.
|
http://csua.com/feed/