Add Secure Delete to Context Menu in Windows 10  

I'm just now noticing this useful SDelete.exe utility from that trusted Windows SysInternals source.

And while I do like the convenience of these context menu options, I don't trust myself or my shaky hands even with that big red [X] icon having deleted too many things when wanting to just rename. Anyway I don't 'Secure Delete' that much stuff anyway so for me I found putting the process in a safer spot a better option. I thought others might appreciate this bat file as an alternative.


So I pieced together this simple quick and dirty *.bat file from several sources so that I can drag and drop to a shortcut created for it in the same directory that I've un-zipped the SDelete.zip files. This shortcut once it's created in the same folder as the sdelete.exe file can then be copied anywhere that's more convenient.


Note: The 'cmd /c exit -1073741510 2>nul' is just a easy way to pause the delete with a 'Y/N to Terminate' prompt.

Code:

@ECHO OFF

echo About to SDelete this file\folder:
echo.
echo %1
echo. 
cmd /c exit -1073741510 2>nul

sdelete64.exe  %* -s -p 3

Hary said:

Can you describe the process of adding. Thank you.

Hello Hary,

If you mean for the Recycle Bin context menu, then the tutorial below will hopefully help.

Add Secure Delete to Recycle Bin Context Menu in Windows 10

Hary said:

That's exactly what interests me.
From day one on the 7, 10, 11 forums, I am always impressed by your speed and correctness. Thank you for always being around and always wanting to help people like me.

You're always most welcome.

Because of the nature of NAND flash memory, SSDs cannot directly overwrite data. Repeatedly overwriting a file before deleting it will not securely erase it on an SSD—the data would just be written elsewhere on the NAND. NAND flash is divided into blocks, each consisting of a set of pages. Each page may be written to individually, but pages cannot be rewritten until erased, and erasing can only be done in whole blocks. This means that whenever data is rewritten, the SSD must mark the data in the affected pages invalid and rewrite it elsewhere, possibly in a different block. At a more appropriate time, ideally when the drive is idle and all pages in a block are marked invalid, the SSD can erase blocks that are no longer in use. This cleanup process is called garbage collection.

In order for the SSD to know which blocks can be erased, the operating system must tell it which blocks no longer contain valid data. This is done using the ATA TRIM command. The SSD is then free to garbage-collect those unused blocks. However, there can be absolutely no guarantee that it will garbage-collect ALL of them, and, even if you are lucky enough that it DOES erase them all, then there can still be absolutely no guarantee about WHEN. So, possibly, it could take forever until ALL those unused blocks will have been permanently irreversibly erased. It could be months, it could be years. There's just no way you can tell.

SSDs try to spread writes evenly over the NAND to avoid premature failure, a process which relies on the free space available to the drive. Each NAND block can only sustain a finite number of write/erase cycles. As a result of this, SSDs must spread writes out over the entire drive to avoid placing undue wear on any single block in order to avoid premature failure of the drive, through a process called wear leveling. Efficient wear leveling can only be achieved if there is a certain amount of space (over-provisioning) that is reserved to allow for efficient garbage collection as required even if the drive is nearly full.

Under extreme conditions where the SSD is being asked to write data faster than it can erase old blocks (common in write-heavy datacenter workloads), it may be forced to rewrite the data in one block into another block, then erase the old block immediately to make way for new data, before it has had a chance to perform garbage collection. Forced rewriting of a block is less than ideal because it degrades performance and contributes to write amplification, where more data is written to the underlying NAND than the actual amount the drive is instructed to write. Added over-provisioning helps mitigate write amplification by providing more spare space to rewrite data and erase old blocks.

The only way to truly erase data on an SSD is to use the ATA Secure Erase command. Secure Erase instructs the drive to wipe all stored data, including data which may remain in the over-provisioned NAND regions. That is, at least as far as the mapping table is concerned. It should, however, also be noted that some SSDs were found in the past that did not have this command implemented correctly. See:
https://cseweb.ucsd.edu//~swanson/pa...11SecErase.pdf

In drives with self-encrypting capability, called Self-Encrypting Drives (SEDs) Secure Erase can simply be implemented by wiping the encryption key. Since the data on the NAND of an encrypted drive is unreadable without the key, there is no need to erase all blocks as would be necessary on an unencrypted drive. However, multiple SSDs were found in the past that... well, you got the picture. It is the reason why BitLocker no longer uses the internal encryption mechanism of SED devices by default (but it used to do that by default until Microsoft decided the time had come to change that). So these days your best bet is to go buy an SSD that can support Sanitize, which, put simply, is a modernized successor to Secure Erase. Unlike Secure Erase, Sanitize does not only erase the mapping table. Instead, Sanitize erases every block in the whole drive so it is slower compared to Secure Erase.

In short, traditional-old secure deletion, or data shredding software techniques do not work on SSDs. To anyone with basic knowledge about how SSDs work on the inside, this is really just a trivial fact, essentially. Which isn't to say that it will be easy to recover data (even partially) after said data has been deleted with a technique such as the one described in this tutorial. It isn't, as it requires expensive forensic lab professional equipment combined with top level expertise to stand a reasonable chance of being successful at it to some non negligible extent. Even so, it's possible and that's why any secure deletion technique that isn't specifically designed for SSDs should be recommended to use on SSDs, and touted "secure" on SSDs, to no one excepting only your worst enemies maybe. On the flip side, the excess wear and tear that results from keep writing to the SSD with SDelete actually might kill the drive prematurely if you keep repeating it often enough with large data, thus achieving the goal of securely killing all data stored on the device, successfully, still nevertheless. lol

sterno900 said:

Is it possible to place it in-between the Delete and Rename ?

Hello, and welcome.

I'm afraid there's only 3 positions available:

Top = Very top of context menu.

Middle = Places it right below "Print".

Bottom = Current position.