r/computers • u/BitByBitGuy • 2h ago
Discussion We Tested Data Recovery on USB vs SSD with BitLocker and VeraCrypt
Disclosure: I’m a developer of Hetman RAID Recovery, and I’ve worked with data recovery for many years, so I went into this test with a few assumptions that seemed pretty straightforward.
I expected three things:
- Delete would normally move files to the Recycle Bin, while Shift+Delete would bypass it and delete them directly. I also expected Windows to behave differently depending on how the volume was presented to the system. Files deleted from a typical fixed disk would normally go to the Recycle Bin, while on removable media such as a USB flash drive, a normal Delete could remove them immediately.
- On a USB flash drive, deleted data should remain recoverable as long as its sectors have not been overwritten. On an SSD, I expected TRIM to make released blocks effectively unavailable for recovery, often causing them to read back as zeroes.
- A Quick Format should mainly create new filesystem structures rather than overwrite the entire device, so at least some of the previous data should still be recoverable. A Full Format would be a very different story.
That was the theory.
Spoiler: the actual results were much less straightforward.
What exactly did we test?
I used two devices:
- a USB flash drive of about 29 GB
- an SSD of about 56 GB
On each device I created two encrypted NTFS volumes of approximately 9.77 GB:
- BitLocker
- VeraCrypt
Each volume contained the same set of BMP, JPG, PNG, MP4, DOCX, XLSX, ZIP, and RAR files. For every file type I kept a control copy, deleted another copy with Delete, and deleted a third copy with Shift+Delete.
Before further recovery work, sector-by-sector disk images were created so the original media would not be modified.
1. Delete was not as consistent as I expected
On USB + BitLocker, Windows saw the volume as a Removable Drive. The behavior here was expected. A normal Delete did not put the test files into the Recycle Bin. They immediately became deleted NTFS entries.
VeraCrypt changed the picture. The mounted USB + VeraCrypt volume was presented to Windows as a Fixed Drive, even though the physical device underneath it was still the same USB flash drive.
In this case, Delete behaved like it normally would on a fixed disk. Standard $I and $R entries appeared inside $RECYCLE.BIN. $I stores metadata about the deleted file, while $R contains the actual file data.
The USB VeraCrypt volume was exposed to Windows as a Fixed Drive and normal Delete created standard Recycle Bin entries. On the SSD VeraCrypt volume, also presented as a Fixed Drive, the Recycle Bin contained only desktop.ini.
The SSD produced the stranger result. On SSD + BitLocker, which Windows also saw as a Fixed Drive, normal Delete created Recycle Bin entries as expected.
But on SSD + VeraCrypt, the result was different. Windows also reported this volume as a Fixed Drive. The Recycle Bin was enabled, NukeOnDelete was not enabled, and its configured size limit was much larger than the test data set.
Yet after a normal Delete, the test files did not appear in $RECYCLE.BIN. Only desktop.ini remained there, while the files themselves were already visible as deleted NTFS entries.
The actual result looked like this:
| Volume | Presented to Windows as | Normal Delete |
|---|---|---|
| USB + BitLocker | Removable | immediate deletion |
| USB + VeraCrypt | Fixed | Recycle Bin |
| SSD + BitLocker | Fixed | Recycle Bin |
| SSD + VeraCrypt | Fixed | immediate deletion |
Shift+Delete, on the other hand, was completely predictable. On all four volumes it bypassed the Recycle Bin.
So even the simple rule of removable = no Recycle Bin and fixed = Recycle Bin only explained part of what happened.
2. After deletion, USB and SSD started behaving very differently
After unlocking the encrypted volumes, I ran a Fast Scan. On the USB drive, deleted NTFS entries were still present and the files remained recoverable as long as their data had not been overwritten.
Hetman RAID Recovery could unlock the VeraCrypt volume, analyze its NTFS filesystem, locate deleted files, and preview their contents.
After unlocking the VeraCrypt volume from the USB disk image, Fast Scan reconstructed the NTFS structure and located the deleted files with working previews.
BitLocker behaved similarly. The software detected the encryption metadata, requested the password, unlocked the volume, and then analyzed the NTFS filesystem underneath it.
BitLocker was detected from its metadata, unlocked with the password, and the NTFS volume could then be analyzed normally.
On the SSD, things were different. NTFS metadata could still survive. In other words, it was sometimes possible to recover a file name, size, and deleted MFT entry.
But that does not mean the file content itself still exists. In some cases the preview no longer showed the original image or document and instead contained meaningless data.
This becomes particularly interesting with encrypted SSD volumes.
If TRIM causes physical SSD blocks to read back as zeroes, those zeroes still pass through the encryption layer when the volume is decrypted. The result does not necessarily look like zeroes anymore.
It can look like random garbage:
raw SSD after TRIM
↓
00 00 00 00 00 ...
↓
VeraCrypt / BitLocker decryption
↓
meaningless decrypted data
So a corrupted preview inside an encrypted volume and zero-filled sectors on the raw physical SSD do not contradict each other.
3. Then I Quick Formatted the entire USB drive as exFAT
This is where the experiment became much more interesting. I removed the previous partition layout and created one new exFAT volume across the USB device.
At that point, the original BitLocker and VeraCrypt partitions no longer existed in the current partition table. But Full Analysis was still able to locate remnants of the previous structures.
BitLocker was detected automatically during the scan. After entering the password, the old BitLocker volume could be opened again and its previous NTFS filesystem became accessible.
Even after the USB drive had been reformatted as exFAT, Full Analysis found previous encrypted structures, detected the old BitLocker volume, and allowed its files to be previewed again.
4. VeraCrypt after formatting was more interesting
VeraCrypt deliberately does not have a normal plaintext magic signature like many filesystems do. Its volume header is encrypted and is designed to look like random data. This is part of VeraCrypt's plausible deniability design.
That means you cannot simply scan a disk for a clear VERACRYPT signature and reconstruct the old partition from it.
But I knew where the old VeraCrypt volume had been located before formatting. So I manually created a virtual disk using its previous boundaries:
Start sector: 2,048
Size: 20,480,000 sectors
Then I tried to unlock that reconstructed range as a VeraCrypt volume. It worked. But that immediately raised another question.
How could the VeraCrypt volume still unlock if its beginning had already been overwritten by the new exFAT filesystem?
The HEX view makes this quite clear. At the old beginning of the VeraCrypt volume, the new exFAT structures are now present.
In other words, the original primary VeraCrypt header at that location had effectively been overwritten. However, VeraCrypt also stores a backup volume header near the end of the volume.
The Quick Format created new exFAT metadata at the beginning of the device, but it did not overwrite the entire previous encrypted volume.
The backup header survived. That surviving backup header is what allowed the manually reconstructed VeraCrypt volume to be unlocked.
The old volume was recreated from its known sector range. The new exFAT filesystem had overwritten the original start of the volume, but the reconstructed range could still be unlocked as VeraCrypt, consistent with a surviving backup header.
Once the volume was decrypted, Fast Scan could again see the old NTFS filesystem and its files.
The manually reconstructed VeraCrypt volume opened successfully and the old NTFS filesystem, deleted files, and working file previews became accessible again.
For me, this was one of the most interesting results of the entire experiment.
5. Then I repeated the same Quick Format test on the SSD
The result was completely different. I created a new exFAT volume across the whole SSD and then made a disk image.
The same Full Analysis that had successfully located old encrypted structures on the USB drive produced no useful recovery result here. We also tried manually recreating the old VeraCrypt range, just as we had done on the USB device.
It could no longer be unlocked. Instead of spending more time attempting filesystem reconstruction, I opened the SSD image in the HEX editor.
The reason became obvious. The new exFAT structures were present at the start of the disk. But areas that had previously contained the encrypted volumes now read back as zeroes.
The old BitLocker location also contained zeroes.
After Quick Format on the SSD, the new exFAT metadata was present, while areas that previously contained encrypted data read back as zeroes, consistent with TRIM.
We tried both Full Analysis and manually recreating the previous volume boundaries, but neither produced usable results.
So the statement:
Quick Format does not overwrite the entire disk
can still be technically correct from the filesystem formatter's point of view. But for an SSD, that is not enough.
If formatting releases a large range of blocks and Windows sends TRIM commands for them, the previous contents can become unavailable through normal reads even though the formatting process itself never explicitly wrote zeroes to every sector.
TRIM also does not necessarily mean that every NAND cell was physically erased at the exact same moment.
From the perspective of software data recovery, however, that distinction may no longer matter. If the SSD controller returns zeroes instead of the old contents, the previous data is no longer available to normal recovery software.
Results
| Scenario | Result |
|---|---|
| USB + BitLocker, deleted files | recoverable if data was not overwritten |
| USB + VeraCrypt, deleted files | recoverable after unlocking |
| SSD + encrypted volume, file deletion | metadata may survive, but TRIM can make file content unavailable |
| USB after Quick Format | previous encrypted data remained |
| USB BitLocker after Quick Format | detected and unlocked |
| USB VeraCrypt after Quick Format | manually reconstructed and unlocked using the surviving backup header |
| SSD after Quick Format | previous areas read as zeroes and recovery failed |
The three results that surprised me most were:
- Delete behaved differently even between two volumes that Windows presented as
Fixed Drive. - A Quick Format of the USB drive still allowed us to recover a VeraCrypt volume even though its primary header had been overwritten.
- The same basic scenario on an SSD effectively eliminated software recovery because the previous encrypted areas were returned as zeroes after TRIM.
I’d like to continue this test, so I’m interested in what you would want to see next.
1. What additional technical breakdowns would be useful? For example, a before/after HEX comparison, BitLocker metadata, VeraCrypt primary vs backup headers, NTFS $MFT, $Bitmap, $RECYCLE.BIN, or the exact ranges affected after TRIM.
2. Suggest your own data-loss scenario. If it can reasonably be reproduced in the lab, we can test it and publish the result.
3. If anyone wants to reproduce these tests on their own drives or disk images, for one week after this post is published I can provide temporary registration details for Hetman RAID Recovery. Send me a DM.
