Data Recovery and File Carving: Deleted, Hidden, Encrypted

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:

• NTFS holds every file's metadata in a Master File Table ($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.
• ext4 marks the inode as free and updates the block group descriptor, but the inode itself is usually preserved until reuse. The journal (typically /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.
• APFS is the hardest of the three for traditional undelete because copy-on-write plus aggressive TRIM means the original blocks are usually freed and discarded quickly. APFS snapshots are the recovery path that actually works; cross-link macOS Forensic Artifacts: plist, Keychain, Time Machine and Browser Traces.
• FAT32 / exFAT still appear on Indian-investigation USB sticks and SD cards. Deletion replaces the first byte of the filename with 0xE5. The directory entry, FAT chain and clusters often remain. Recovery is straightforward with TestDisk's "undelete" view or PhotoRec.

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:

The carving tools:

• PhotoRec (CGSecurity) is the most widely used. Free, cross-platform, ships with TestDisk. Supports several hundred signatures. Strength: forgiving and recovers from severely damaged media. Weakness: filenames are lost, replaced with sequential numbering.
• Foremost (US Air Force OSI) reads a config file (foremost.conf) that defines header/footer pairs. Compact, scriptable, predictable. The default config covers common types; custom signatures are one line each.
• Scalpel is a Foremost fork that's faster on large images by skipping irrelevant block ranges. Same config style.
• Bulk Extractor carves not files but content fragments: email addresses, URLs, credit-card numbers, phone numbers, BTC addresses, search-engine queries. Different problem class; very useful for cross-referencing.
• X-Ways Forensics and ReclaiMe are commercial. X-Ways has the best filesystem-aware carving (it understands NTFS fragmentation and reassembles non-contiguous files where PhotoRec gives up).

Hard-drive recovery techniques do not transfer to SSDs, and the mechanism that breaks them is TRIM. 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:

• An SSD seized hot, with the system running, may already have lost most recently-deleted content. The first responder's job is to image fast and minimise live OS activity. Pulling the plug stops TRIM operations in flight but the damage is largely already done.
• Built-in encryption on SSDs (SED, OPAL) means the controller may secure-erase by key destruction. A factory reset on an SED takes milliseconds and produces unrecoverable media.
• eMMC (used in Android phones, IoT devices, low-cost laptops) supports TRIM via the discard operation. Same problem class, slightly slower garbage collection.
• Chip-off recovery from the raw NAND can sometimes find data in wear-leveling reserve pages that the FTL has remapped but not yet erased. This is a specialist procedure done by CFSL chip-off labs (Hyderabad, Chandigarh and a handful of state labs); equipment cost runs into crores and per-case turnaround is weeks.

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.

1. Acknowledge media
   Identify SSD vs HDD vs eMMC vs UFS at intake. The recovery plan depends on it. SMART data and the controller's model number are part of the chain-of-custody record.
2. Image at the lowest defensible level
   For SSDs, image the logical drive through a write blocker. Chip-off only if the case justifies the cost and the case-officer authorises it; document the decision.
3. Set recovery expectations early
   If the device is a TRIM-enabled SSD and the alleged deletion was more than a few hours before seizure, communicate the low recovery probability to the IO before they build the case around it.
4. Try snapshots, cloud and backups first
   APFS snapshots, Windows Volume Shadow Copies, Time Machine, OneDrive/Google Drive history, Android cloud backup. Often higher yield than carving the device.
5. Carve and parse with realistic SLA
   Run PhotoRec/X-Ways carving against the image with the right signatures. Treat anything recovered as bonus, not base case.

A drive that "looks blank" to Windows or macOS often is not. Three scenarios show up regularly in Indian investigations:

• Quick format. Most consumer OSes default to a quick format, which writes a new filesystem header (NTFS boot sector, FAT BPB, ext superblock) and a new empty file table. The data clusters remain untouched. Recovery is high probability with PhotoRec or filesystem-specific tools.
• Full format. Windows 10 and later perform a full format by default if the option is selected, writing zeroes (or random data on encrypted volumes) over every sector. After a full format, signature carving has nothing to find. The drive is, for practical purposes, blank.
• Damaged or deleted partition table. The first 512 bytes (MBR) or the first 17 KiB (GPT) of a drive can be corrupted, overwritten or deliberately deleted, while leaving the partitions themselves intact further down the disk. The drive shows as unallocated in Disk Management, but the data is whole.

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:

1. Image the raw drive
   dd or ddrescue the physical device to an .img or .E01 file, behind a hardware write blocker. Hash the source and image.
2. Run TestDisk on the image
   Use the file-backed image so the original device is never modified. Choose the partition table type (Intel for MBR, EFI GPT for modern systems), let TestDisk Analyse, then Quick Search.
3. Validate the proposed partition table
   TestDisk highlights probable partitions. Spot-check by walking the directory listing inside TestDisk before committing the write. Do not commit to the source image; write to a working copy.
4. Mount read-only and proceed
   Attach the recovered partition with -o ro,noload,noatime and continue analysis with Autopsy, X-Ways, FTK or your tool of choice.

In a 2023 Hyderabad financial-fraud matter, a suspect used a low-level utility to wipe only the MBR while leaving the data partition intact; TestDisk reconstructed the partition table and the prosecution recovered three months of accounting records.

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."

The legitimate paths in order of preference:

• Ask the user. Under BNSS Section 94 production notice or with consent at seizure, the user is legally compellable to produce passwords for devices in their custody. Many Indian magistrates now accept "I have forgotten the password" as a fact question subject to cross-examination. CrPC-era cases like Selvi v. State of Karnataka shaped the limits; the BSA 2023 evidentiary frame is the active reference for new matters.
• Recovery keys from the user's account. BitLocker keys are routinely escrowed to Microsoft accounts (consumer) or Azure AD / Intune (enterprise). FileVault keys go to iCloud or to Jamf/Kandji. LUKS keys may sit in a sysadmin's password manager. A correctly-drafted production notice to the right entity, often faster than the user themselves, recovers the key.
• RAM extraction. A device seized in an unlocked state with the encrypted volume mounted holds the master key in RAM. The first responder's job is to capture RAM before shutdown. Tools: MAGNET RAM Capture (Windows), AVML or LiME (Linux), Recon ITR (macOS). The captured image is then scanned by Volatility plugins (bitlocker, luks, truecryptmaster) or by tools like passware/ElcomSoft for the master key.
• Hibernation file (Windows). 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.
• Cold-boot attack. RAM contents persist for seconds to minutes after power loss, longer when chilled. Pouring liquid nitrogen on DRAM modules then rebooting into a small key-extraction OS recovers keys that have not yet faded. The technique is real and was demonstrated against laptops at the 2008 USENIX Security Symposium (Halderman et al.); subsequent cold-boot work on Android phones appeared in separate academic venues, not at USENIX. Indian state FSLs have the capability in concept; the practical execution requires the device to be intercepted in a powered state by a team prepared for cold-boot work.

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 last category covers data that was never deleted but was placed where a routine examination would not reach.

The locations Indian I4C and CERT-In analysts check by default:

• Slack space. The unused portion of the last cluster of every file. NTFS file using 12 KB of a 16 KB cluster leaves 4 KB of slack. Tools: bulk_extractor, X-Ways. Useful for finding fragments of deleted-then-overwritten files, occasionally hand-placed payloads.
• Alternate Data Streams (ADS) on NTFS. Covered in detail in Windows Artifacts: ShellBags, ADS, LNK, Hibernation and Slack. notes.txt:hidden.exe is the canonical pattern.
• Bytes between MBR and the first partition. Sectors 1 through 62 (the first 31.5 KB) are typically unused and can host bootkits, hidden payloads or just text files. dd at the right offsets reveals them.
• EFI System Partition. Hidden from Windows Explorer by default. Tools like BadRabbit and BlackLotus place persistence here. mount with mount -t vfat /dev/sdaX /mnt and check.
• Host Protected Area (HPA) and Device Configuration Overlay (DCO). Reserved regions at the end of an ATA drive that subtract capacity reported by the firmware. hdparm --dco-identify and hdparm -N detect them; some forensic acquisition appliances temporarily disable the HPA to image the full physical capacity.
• Encrypted ZIP / RAR / 7z containers. Password-protected archives are common in Indian financial-fraud and CSAM matters. Hashcat modes -m 13600 (WinZip), -m 12500 (RAR3), -m 13000 (RAR5), -m 11600 (7-Zip).

Steganography is a separate problem class. The technique embeds payload data into a carrier file (image, audio, video) in a way that is statistically subtle. The most common scheme is LSB substitution: replace the least-significant bit of each pixel's red/green/blue channel with one bit of payload. A 1920 by 1080 JPEG decoded to a bitmap has roughly 6 million pixels and 18 million channels, enough for a 2 MB payload while staying invisible to the eye.

The detection workflow:

1. Identify carrier files
   Bulk extract all images, audio and video from the image. Hash and dedupe against known clean-set databases (NSRL).
2. Run statistical detectors
   StegExpose against bitmaps; stegoVeritas for a battery of checks; chi-square against the LSB plane of each colour channel. Anomalously uniform LSB distribution is the signature.
3. Try known-tool extraction
   StegHide, OutGuess, F5 and OpenStego have distinctive signatures. Run each tool's extract mode against suspect carriers. A successful extract with the suspect's password produces the payload directly.
4. Brute force passwords on flagged carriers
   stegcracker, stegseek and hashcat can brute-force common stegano tool passwords with reasonable dictionaries.
5. Correlate to user activity
   If a carrier image flags, check timestamps, source application, browser download history and any local copies of stego tools. The case lives or dies on attribution, not on the bare detection.

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.