Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
What 'deleted' means at the filesystem level, signature-based carving with PhotoRec and Foremost, SSD TRIM realities, BitLocker/FileVault/LUKS/VeraCrypt recovery paths, cold-boot key extraction, and the steganography detection workflow Indian CFSL teams actually run.
Half of digital forensics is recovery. The other half is interpretation, but you cannot interpret what you cannot recover. The phrase "deleted file" hides a stack of very different scenarios, and the examiner who treats them all as one problem will produce wrong conclusions in court. A file deleted from a Windows NTFS desktop is not the same problem as a file deleted from an Android phone's flash storage, which is not the same as a file overwritten by a paranoid suspect with shred -uvz. Each demands a different recovery technique, a different success probability, and a different way of writing it up under BSA 2023 Section 63.
This topic walks the recovery stack from easy to hard: filesystem-aware undelete on NTFS, ext4 and APFS; signature-based carving with PhotoRec, Foremost and Scalpel; the SSD/TRIM problem that makes consumer SSDs the worst recovery target in the lab; partition-table recovery with TestDisk; encrypted-volume recovery for BitLocker, FileVault, LUKS and VeraCrypt; cold-boot key extraction; hashcat brute force with the right mode numbers; and the steganography and hidden-partition tricks that come up in CERT-In and I4C casework. Image first, work on copies, log every step. That last rule is the only one that has no exception.
The file entry is freed. The content stays until someone writes over it. Sometimes.
When a user clicks Delete or runs rm, the operating system does not erase content. It updates a small piece of metadata that marks the file's directory entry as available for reuse. The data blocks holding the file's actual content remain on the storage device, untouched, until the filesystem allocator reuses those blocks for a new file. On a lightly used drive that can be weeks. On a heavily used drive it can be seconds.
The mechanism differs per filesystem:
$MFT) entry. Deletion flips the entry's in-use bit and marks the entry as available. The content extents are dereferenced but not overwritten. Recovery walks the MFT looking for entries with the bit clear that still have valid extent pointers. Tools: MFTECmd, analyzeMFT, X-Ways. The $LogFile and $UsnJrnl:$J journals can hold older MFT states and recover entries the live MFT has reused./dev/<device>1 block group 0's journal inode) holds older inode states. Tools: extundelete, ext4magic, debugfs. ext4's delayed-allocation behaviour means recently created files might not even be on disk yet when deleted.0xE5. The directory entry, FAT chain and clusters often remain. Recovery is straightforward with TestDisk's "undelete" view or PhotoRec.When the filesystem is gone, headers and footers are all you have.
Filesystem-aware undelete works only while metadata exists. After a full format, a corrupted partition table or a deliberate mkfs, the metadata is gone but the content blocks often remain. File carving is the recovery technique that ignores filesystem metadata entirely and scans raw disk blocks for known file headers and footers.
The classic header/footer pairs every examiner memorises:
| File type | Header (hex) | Footer (hex) | Notes |
|---|---|---|---|
| JPEG | FF D8 FF E0 / FF D8 FF E1 | FF D9 | JFIF (E0) or EXIF (E1); footer is the EOI marker |
| PNG | 89 50 4E 47 0D 0A 1A 0A | 49 45 4E 44 AE 42 60 82 | Header is the PNG signature; footer is the IEND chunk + CRC |
| 25 50 44 46 (%PDF) | 25 25 45 4F 46 (%%EOF) | Multiple %%EOF possible (linearized / incremental update) | |
| DOCX / XLSX / PPTX / ZIP | 50 4B 03 04 (PK..) | 50 4B 05 06 (PK..) | All ZIP-family; differentiation needs central-directory parse |
On a modern SSD with TRIM, your recovery window is measured in seconds.
The hardest part of teaching data recovery in 2026 is convincing students that everything they learned about HDD recovery is half-wrong on SSDs. The mechanism is TRIM.
When a file is deleted on an SSD-backed filesystem with TRIM support (Windows NTFS, macOS APFS, Linux ext4 with discard mount option or periodic fstrim), the OS issues the TRIM (ATA) or UNMAP (SCSI) command to tell the SSD which logical blocks are no longer in use. The SSD's garbage collector then erases the corresponding NAND pages physically. Within seconds to minutes, the actual content is gone from the flash cells. No carving, no journal walking, no MFT scanning will bring it back.
The practical implications for Indian casework:
discard operation. Same problem class, slightly slower garbage collection.For Windows BitLocker-encrypted SSDs the picture is even thinner: the underlying flash content is ciphertext, so even physical recovery of the bytes yields only ciphertext until the BitLocker key is provided.
The drive 'looks blank' until you fix the partition table.
A drive that "looks blank" to Windows or macOS often is not. Three scenarios show up regularly in Indian investigations:
For the third case, TestDisk (CGSecurity, same author as PhotoRec) is the canonical tool. TestDisk scans for filesystem signatures across the disk, reconstructs a probable partition table, and writes it back. After TestDisk's "Write" step, the drive mounts normally and recovery proceeds through standard tools. The workflow for a recovered MBR/GPT case:
Four mainstream encryption systems, four recovery paths, each with a hashcat fallback.
A correctly configured full-volume encryption system without the key is, to a first approximation, unbreakable. The forensic problem is therefore not "break the crypto" but "find the key, by any of the legitimate paths."
| System | Platform | Recovery paths | Hashcat mode |
|---|---|---|---|
| BitLocker | Windows 10/11 | TPM + PIN, user password, 48-digit recovery key, AD / Intune / MBAM escrow, RAM dump, hibernation file | -m 22100 |
| FileVault 2 | macOS APFS | User password, personal recovery key, institutional recovery key, iCloud-escrowed key, RAM dump (live system) | -m 16700 |
| LUKS / LUKS2 | Linux | Passphrase in any of 8 key slots, key file, TPM (LUKS2), RAM extraction of master key | -m 14600 (LUKS), -m 29541+ (LUKS2 by variant) |
| VeraCrypt | Cross-platform | Password, keyfile, PIM, RAM-resident master key while volume is mounted; hidden volume needs separate password |
A 200 MB MP4 video was deleted from an NTFS volume on a 7200-rpm HDD, four hours ago. The volume is 60% full. Which recovery approach is most likely to succeed?
Mounting an evidence image read-write, even briefly, can trigger journal replay, free-space reclamation and access-time updates that overwrite recoverable data. Always image first, hash, then mount the working copy with -o ro,noload,noatime (Linux) or attach as read-only through a hardware write blocker. CFSL Chandigarh's 2024 lab manual explicitly disqualifies any recovery output produced from an image that lacks a documented read-only mount sequence.
| MP4 / MOV | 00 00 00 ?? 66 74 79 70 (ftyp) | none | Length-prefixed boxes; no fixed footer, parse box tree |
| GIF | 47 49 46 38 37 61 / 47 49 46 38 39 61 | 00 3B | GIF87a or GIF89a |
| SQLite | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | none | Page-structured; no footer, recovery via page size header |
The carving tools:
foremost.conf) that defines header/footer pairs. Compact, scriptable, predictable. The default config covers common types; custom signatures are one line each.This is the workflow that recovered a deliberately wiped Toshiba laptop in a 2023 Hyderabad financial-fraud matter: the suspect had used a low-level partition wipe utility on the MBR but had not zeroed the data partition, and TestDisk reconstructed the table cleanly enough that the prosecution recovered three months of accounting records.
| -m 13711 to -m 13771 (per kdf and cipher) |
The legitimate paths in order of preference:
bitlocker, luks, truecryptmaster) or by tools like passware/ElcomSoft for the master key.C:\hiberfil.sys is a compressed RAM dump produced when a Windows machine hibernates. If the suspect closed the lid on an unlocked machine and the laptop hibernated, the BitLocker master key may still be in the hibernation file, recoverable with hibr2bin and Volatility.Brute force is the path of last resort. hashcat -m 22100 bitlocker.hash -a 0 wordlist.txt against a weak BitLocker password may work; against a 16-character random password it will not in the lifetime of the case. The realistic dictionary-attack work in Indian labs targets user-chosen passwords against rockyou.txt-style wordlists with rule-based mutation.
The forensic workflow underneath all of this is constant: image first, hash the source and the image, work on a verified copy, and log every step. The chain of custody from seizure through analysis to courtroom is covered in Chain of Custody and in Digital First Responder: Volatility, Seizure and Imaging, which together form the procedural backbone for everything in this topic.