Sysinternals - SDelete - Wipe free space RRS feed

  • Question

  • Hi 

    I'm trying to wipe free space from my USB using sdelete64 -p 1 -c  DriveLetter and sdelete64 -p 1 -z DriveLetter, but as far as I can tell the difference is that the last one zeros the unallocated space and the first one fills it with random data. But I'm checking with an Hex Editor the drive and there are residual files in the USB, how can I configure the command so it makes a deeper work? 

    PD: increasing the number of -p doesn't seem to have an impact (from 1 to 3)

    Friday, October 18, 2019 10:23 PM

All replies

  • This is an excerpt from the Sysinternal's book on how Sdelete works.

    How SDelete works
    Securely deleting a file that has no special attributes is relatively straightforward: the
    secure-delete program simply overwrites the file with the secure-delete pattern. What is
    trickier is to securely delete compressed, encrypted, or sparse files, and securely
    cleansing disk free spaces.
    Compressed, encrypted, and sparse files are managed by NTFS in 16-cluster blocks.
    If a program writes to an existing portion of such a file, NTFS allocates new space on
    the disk to store the new data, and after the new data has been written NTFS deallocates
    the clusters previously occupied by the file. NTFS takes this conservative approach for
    reasons related to data integrity, and (for compressed and sparse files) in case a new
    allocation is larger than what exists (for example, the new compressed data is larger
    than the old compressed data). Thus, overwriting such a file will not succeed in
    deleting the file’s contents from the disk.
    To handle these types of files SDelete relies on the defragmentation API. Using the
    defragmentation API, SDelete can determine precisely which clusters on a disk are
    occupied by data belonging to compressed, sparse, and encrypted files. When SDelete
    knows which clusters contain the file’s data, it can open the disk for raw access and
    overwrite those clusters.
    Cleaning free space presents another challenge. Because FAT and NTFS provide no
    means for an application to directly address free space, SDelete has one of two options.
    The first is that—like it does for compressed, sparse, and encrypted files—it can open
    the disk for raw access and overwrite the free space. This approach suffers from a big
    problem: even if SDelete were coded to be fully capable of calculating the free-space
    portions 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 system. For example, say
    SDelete determines that a cluster is free, and just 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 gone. The
    problem is even worse if the cluster is allocated for file-system metadata because
    SDelete will corrupt the file system’s on-disk structures.
    The second approach, and the one SDelete takes, is to indirectly overwrite free
    space. First, SDelete allocates the largest file it can. SDelete does this using noncached
    file I/O so that the contents of the NT file-system cache will not be thrown out and
    replaced with useless data associated with SDelete’s space-hogging file. Because
    noncached file I/O must be sector (512-byte) aligned, there might be some leftover
    space that isn’t allocated for the SDelete file even when SDelete cannot further grow
    the file. To grab any remaining space, SDelete next allocates the largest cached file it
    can. For both of these files, SDelete performs a secure 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 1 KB in size, and every file or directory on a disk requires at least one MFT
    record. Small files are stored entirely within their MFT record, while files that don’t fit
    within 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 will prevent the file from getting larger,
    because there are no free clusters left on the disk. (They are being held by the two files
    SDelete previously allocated.) SDelete then repeats the process. When SDelete can no
    longer even create a new file, it knows that all the previously free records in the MFT
    have been completely filled with securely overwritten files.
    To overwrite the file name of a file 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 renaming of sample.txt would be to AAAAAA.AAA.
    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 containing deleted file names, but the free
    directory space is not available for allocation to other files. Hence, SDelete has no way
    of allocating this free space so that it can securely overwrite it.

    As you can see there are still cases where "something" may remain on the disk even after some passage from SDELETE. I would say your approach is definitely correct. Sdelete rename files 26 time, so I simply would run it at least 10 times:

    sdelete64 -p 10 -c  DriveLetter


    Monday, October 21, 2019 8:36 AM