I'm looking for a technical second opinion about roughly 100 GB of architecture and project files that disappeared from F:Work on a Samsung 1 TB SSD. Windows is installed on C:, while the affected files were on a separate F: partition. Another Kingston SSD is also installed, and the Samsung drive has reportedly passed health checks.
Before the loss, the folders inside Work were visible, but an AutoCAD file would not save or export correctly into one of them. I eventually saved the file elsewhere, shut the laptop down normally, and went to sleep. When I reopened it later, most folders and files under Work were gone. The folder dropped from about 100 GB to roughly 500 MB, while other data on the same partition appeared unaffected. There was no ransom note, unusual extension, Windows warning, Recycle Bin copy, search result, or Previous Version.
A professional recovery company found NTFS metadata, folder names, file sizes, and deletion traces, but reported that the LBAs containing the file contents return zeros. They also attempted firmware-level recovery and said the SSD appears healthy but the data is effectively unrecoverable.
I had recently installed Fortnite, downloaded an AutoCAD file from an employee, and downloaded some images, but I have no direct evidence of malware. The SSD has been preserved and I have not written to it, formatted it, run CHKDSK, or reinstalled anything.
How conclusive are zero-filled LBAs after TRIM? Could NAND-level, chip-off, or controller-level recovery still work, especially on a modern Samsung SSD with wear leveling and possible internal encryption? Does the earlier failure to save suggest NTFS or directory corruption rather than deliberate wiping? Could corruption affect one directory while leaving the rest of the partition normal? Does this pattern provide meaningful evidence of malware, or is the cause impossible to determine now? Is another specialist lab worth considering, or do failed firmware recovery and zero-filled reads effectively end the recovery prospects?
2 Answers
The surviving NTFS names and file sizes only show that filesystem metadata was not immediately overwritten; they do not prove that the file contents remain. If the relevant LBAs consistently return zeros after the SSD has processed TRIM, normal recovery software has nothing useful to read.
On SSDs, TRIM marks deleted ranges for the controller, and garbage collection may later erase or recycle the corresponding NAND pages. Wear leveling also means raw NAND cannot be interpreted like a hard drive. Controller mapping, scrambling, and possible encryption can make chip-off recovery useless even when the chips themselves can still be read. If the lab genuinely verified zero-filled reads and already attempted controller or firmware-level recovery, the odds of a second lab obtaining the files are unfortunately very low.
TRIM does not normally choose random files by itself. Something first has to mark those files or clusters as deleted or deallocated; TRIM and later garbage collection can then make that deletion permanent. The failed AutoCAD save is an important clue, but it does not identify the cause. Filesystem or directory corruption, a controller or storage problem, buggy software, or an accidental deletion are all possible.
A single damaged directory with the rest of the partition working normally can happen with NTFS corruption, so this pattern does not establish malware. It also does not rule malware out, but there is not enough evidence here to call it a targeted wipe. A deliberate wiper would be only one hypothesis among several, and the original event may be impossible to reconstruct after TRIM and metadata changes.
Keep the SSD disconnected while recovery decisions are being made. If the data is important enough to justify another attempt, use a lab experienced specifically with SSD controller and NAND recovery and give them the prior findings. Otherwise, replace the drive, preserve any unaffected data through a read-only or carefully verified backup, scan the system from trusted offline media, and check other sources for project copies. Do not run CHKDSK or continue normal use of the affected volume before that decision.
Would you recommend investigating the cause anyway, or should I replace the SSD, scan the computer, and restore whatever remains from backups?