Recovering data from an HDD with DMDE — and why an SSD is a different machine

Data recovery does not start with a tool. It starts with a decision: nothing else gets written to that disk.

DMDE (DM Disk Editor) is a solid tool for HDDs when a filesystem has come apart, a partition has vanished, or folders came back empty after a “repair”. It is not a head-swap lab, and it does not undo TRIM on an SSD.

This note is about what DMDE actually sees on a platter, what it cannot see in NAND, and where software recovery stops.

Did you know? A deleted NTFS file is usually not wiped. The directory record and allocation bits go away. The clusters stay until something overwrites them — or until you run chkdsk /f “to fix it”.

What an HDD is before you open DMDE

A spinning disk is mechanics plus a firmware translator.

The OS sees LBA addresses: sequential sectors, usually 512 or 4096 bytes. Inside: platters, an actuator, heads, and a service area that is not in normal LBA. Firmware modules, the translator and defect lists live there.

If the translator is alive, DMDE reads whatever the controller exposes as LBAs. If the PCB, heads or service area are dead, the OS often shows 0 bytes capacity. A directory scan will not help. That is a donor-board / head job, not another GUI.

HDDs have one property that still saves logical recovery: a filesystem delete does not clear the magnetic trace. Until a sector is overwritten, it can show up in a disk image.

DMDE on an HDD is worth trying when:

• files were deleted, or a partition was quick-formatted
• the boot sector / VBR is damaged
• the partition table is gone
• NTFS $MFT is damaged but copies and clusters remain
• some bad sectors exist but most of the surface still reads

It is not enough when:

• the drive is clicking
• the device shows 0 MB / 0 sectors
• Pending / Reallocated counts climb on every read
• someone “repaired” a RAID in Windows and overwrote metadata

Always work on a copy. Source in read-only. Image with ddrescue or another imager that logs errors instead of dying on the first bad sector. Then open the image in DMDE, not the production volume.

Did you know? Booting Windows on a damaged NTFS volume can rewrite $MFT and the journal. “Check disk” is not diagnostics. It is a write.

An SSD is not a fast HDD

An SSD has no platters. It has NAND, a controller and an FTL (flash translation layer).

NAND is programmed in pages and erased in blocks. A page cannot be overwritten in place. The controller writes a new version elsewhere and updates a map: LBA → physical page. The old page becomes garbage until garbage collection erases the whole block.

On top of that:

• wear leveling — data moves physically even if the LBA stays put
• over-provisioning — spare blocks outside the advertised capacity
• TRIM / UNMAP — the OS tells the controller those LBAs are free; the controller may invalidate them immediately and erase later
• often hardware encryption (SED / TCG Opal, or BitLocker with keys in the controller)

For recovery: sector 1000 is not “a place on the chip”. It is a row in the FTL map. If TRIM, the map or GC dropped that mapping, the LBA reads as zeros or an error. There is no magnetic ghost.

Did you know? After TRIM, many SSDs return zeros for a free LBA immediately. That is not unallocated space you can signature-scan. That is the controller refusing to hand out the old page.

What matters in a lab:

• HDD — magnetic film; LBA via firmware translator; deleted clusters usually remain until overwrite; a bad sector can often be skipped. Encryption usually sits in the OS (BitLocker on the volume).
• SSD — NAND cells; LBA via FTL; TRIM and GC can erase data in minutes; dying blocks get retired and the whole map may die with them. Encryption is often in the controller, so a raw dump without the key is noise.

The same story — “I formatted the partition, I want the files” — can be routine in DMDE on an HDD, and already over on an SSD if the OS issued TRIM and the controller honoured it.

On modern Windows, TRIM on SSDs is on by default. The longer the machine stays powered after a delete, the worse software recovery gets.

What DMDE is, and is not

DMDE is a disk editor and a logical recoverer: partitions, filesystems, signatures.

It can:

• open a physical disk or an image
• search for volumes when the table is wrong
• scan NTFS / FAT / exFAT / ext / HFS+ and rebuild a tree from metadata
• show raw sectors so you can see whether a boot sector is garbage or a superblock is still there
• assemble a software RAID when you know order and stripe

It cannot:

• repair heads or a spindle
• read NAND while bypassing a dead SSD controller
• “undo TRIM”
• decrypt a SED without the key
• promise a complete file set

The free edition limits how much you can restore. Larger directory trees need a licence. That is a constraint, not a review.

HDD procedure (short enough to replay)

1. Writes to the source destroy part of the evidence. Unmount. Do not install DMDE on that disk.
2. Identify. Model, interface, SMART (Reallocated, Pending, CRC). Note time, host, how it was attached.
3. Image. Read-only source (USB bridge with a write blocker, hdparm -r1, or a read-only port). Imager with an error log. Second disk for the image — never the same HDD.
4. DMDE on the image. Look at partitions first. If NTFS and $MFT are visible, a full scan may be unnecessary. If there is no partition: volume search, then scan.
5. Reconstruct. Inspect the tree, signatures, sizes. Copy selected files to a third disk. Do not “fix” the source by writing a boot sector until you have an image.
6. Verify. Hash what you can. List what is missing. Keep the hypothesis (“deletion”) apart from the fact (“no clusters in the image”).

The wider intake → copy → analysis template is in the forensics worksheet. This post is the disk layer, not expert-witness work.

Did you know? DMDE sometimes shows a correct filename and zero content. That is not a recovery. That is metadata without clusters — on an HDD after overwrite, on an SSD after TRIM.

Do not:

• run chkdsk, TestDisk “write”, or Windows startup repair on the only copy
• defragment or “clean up” the disk
• copy a tree off a mounted, failing volume — you hammer bad sectors and grow Pending
• assemble a RAID “just to see” in Disk Management

If SMART Pending climbs during a scan, shorten the scan or go back to the ddrescue image and its error map. The tool is not allowed to finish off the surface.

SSDs: when DMDE still has a window

Narrow cases:

• a USB stick-class device with no TRIM (rare on internal NVMe)
• a delete followed by immediate power-off, before GC
• a filesystem smash without TRIM (odd RAIDs, some USB enclosures)
• a logical mess (partition table) with a live FTL — then DMDE behaves like it does on an HDD, because LBAs still point at old pages

No window when:

• Windows, macOS or Linux already issued TRIM on free blocks
• the controller does hardware crypto and you do not have the key
• the disk enumerates as 0 B or “not initialized” after an FTL crash
• someone ran secure erase / sanitize — on an SSD that really erases cells

Did you know? Secure Erase on an HDD often means overwriting LBAs. Sanitize on an SSD means erasing NAND cells. After sanitize there is no “maybe a JPEG header in unallocated”.

If the device is NVMe after a sudden controller death, the next step is a chip-off / controller shop — outside DMDE and outside this article.

What I write down after a scan

Before anyone hears “got it” or “gone”:

• model, serial, interface, image vs live
• filesystem type and whether metadata is visible ($MFT / superblock)
• how many files have content vs names only
• whether read errors existed and whether they grew
• hypothesis: logical delete / format / mechanics / TRIM
• what I did not check (e.g. no NAND off the board)

Without that, a DMDE report is a directory dump. A tree with no clusters is not recovered data.

Close

On an HDD, DMDE is a logical-layer tool on a copy. It works because deletes and formats usually leave the platter alone.

On an SSD the same Recycle Bin click goes through FTL and TRIM. The construction is different, so the ending is different: either the LBA still points at old pages, or the controller will not hand them over.

The difference is not “which program is better”. It is whether there is still anything under that LBA.