SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-disk-forensics

re-disk-forensics

General & other

View repository

Updated 10-15 21:34

About this skill

Disk forensics and file system analysis

When to use / when not to use

  • Use: when you have a disk image (dd / E01) or medium for forensics—deleted file recovery, timeline reconstruction, suspicious file/residual data location
  • Use: when incident response needs "what happened on the medium" (what was deleted, when it was written, what traces were left)
  • Use: partition table reconstruction and file rescue after partition loss/corruption (testdisk)
  • Don't use: memory forensics (that's [[re-mem-forensics]], another forensics branch parallel to disk forensics)
  • Don't use: ordinary file system mounting for use (that requires writable mounting; forensics is always read-only, see pitfall 1)
  • Don't use: encrypted volume without a key—find the key first (see pitfall 2)

Tool preparation

Forensics iron rule:read-only. All tools in this skill only read image files, do not mount writable, and do not write anything to the original medium (see pitfall 1). The results of image acquisition and suspicious object extraction are archived by sha256 + path (forensics requires traceability, see [[re-analyze/platform-tips]]).

sleuthkit — the mainstay of forensic analysis (fls/icat/tsk_recover/mmls/fsstat/blkls)

  • Debian/Ubuntu: apt install sleuthkit
  • Fedora: dnf install sleuthkit
  • Arch: pacman -S sleuthkit(extra repository)
  • macOS: brew install sleuthkit
  • Windows: prefer the Linux version inside WSL (see [[re-analyze/platform-tips]] WSL branch); for GUI use Autopsy (winget install SleuthKit.Autopsy, with built-in sleuthkit tools)
  • Verify: fls -h；mmls -h；tsk_recover -h；mactime -h

testdisk / photorec — partition repair and file carving (cgsecurity)

  • Debian/Ubuntu: apt install testdisk(photorec is in the same package; official documentation confirms there is no separate package)
  • Fedora: dnf install testdisk(photorec CLI comes with the package; the GUI version is a separate package qphotorec）
  • Arch: pacman -S testdisk(extra, photorec comes with the package)
  • openSUSE: zypper install testdisk photorec(on that distribution photorec is a separate package)
  • macOS: brew install testdisk
  • Windows: Linux version inside WSL (the testdisk package on chocolatey is extremely old, not recommended)
  • Verify: testdisk /?；photorec /?

dd / ewf-tools — image acquisition

  • dd: comes with coreutils (available on Linux/macOS/WSL)
  • ewf-tools (E01 evidence format, with checksum blocks): Debian/Ubuntu apt install ewf-tools / Fedora dnf install ewf-tools / Arch pacman -S ewf-tools; verify: ewfacquire -V
  • Windows: read-only imaging tool FTK Imager (GUI, free version on the exterro official site) or the Linux version inside WSL

Read-only mounting — loop + ro (when you need to read file contents directly)

  • mount is built in (util-linux); NTFS requires ntfs-3g: Debian/Ubuntu apt install ntfs-3g / Fedora dnf install ntfs-3g / Arch pacman -S ntfs-3g
  • Verify: mount -o ro,loop,noload ... then findmnt output contains ro

autopsy — optional GUI (team/visualization)

  • Debian/Ubuntu: apt install autopsy；Fedora: dnf install autopsy；Arch: pacman -S autopsy(AUR or extra); Windows: winget install SleuthKit.Autopsy；macOS: brew install --cask autopsy

Operating steps

Execute in order; archive each step's artifacts (image/extracted files/timeline) with sha256 + path (for reference in the [[re-ioc]] report).

  1. Read-only image acquisition (preserve evidence before acting)：

    sha256sum /dev/sdX > evidence.sha256     # 原始介质哈希存证（分析前后复核）
dd if=/dev/sdX of=evidence.dd bs=4M conv=noerror,sync status=progress
sha256sum evidence.dd >> evidence.sha256 # 镜像哈希复核，与源哈希一致才继续
    • For physical disks, prefer a write blocker (USB write-blocker); software write protection blockdev --setro /dev/sdX
    • Partition image: dd if=/dev/sdX1 ... image only the target partition; a full-disk image preserves the partition table and unallocated space (unallocated space often contains residual evidence, see step 5)
    • Evidence format: raw dd is the most universal; for long-term preservation use E01 (ewfacquire /dev/sdX, with built-in checksums and compression)
    • When multiple images already exist (a common incident response practice), go directly to step 2; do not re-acquire

  2. Partition and filesystem identification (ext4 / NTFS / APFS)：

    file evidence.dd                          # 常见文件系统魔数初判
mmls evidence.dd                          # 分区表布局（含 start 扇区偏移）
fsstat -o <分区start> evidence.dd         # 文件系统类型与元数据统计
    • sleuthkit's -o parameter issector offset, directly fill in the start column from mmls output; for loop mounting, convert to bytes offset=$((start*512))
    • ext4: fsstat outputs superblock/mgroup; NTFS: outputs $MFT location; APFS: mmls shows the Apple_APFS container partition (APFS internal volumes require apfs tools; sleuthkit's APFS support is limited, use native macOS tools when necessary)
    • No partition table (whole-disk filesystem / hidden partition / deleted partition table) → mmls has no output: run fsstat directly on the image; for partition table reconstruction use testdisk (step 3)
    • Identification fails and entropy is high → encrypted volume (BitLocker/FileVault/LUKS), see pitfall 2

  3. Deleted file recovery (metadata method + carving method)：

    # 元数据法（保留文件名/路径/时间）—— sleuthkit
fls -r -o <分区start> evidence.dd                       # 全部文件，含 [DELETED]
fls -o <分区start> evidence.dd <inode>                  # 指定目录 inode 下文件
icat -o <分区start> evidence.dd <inode> > rec.bin       # 按 inode 提取（含删除文件）
tsk_recover -o <分区start> evidence.dd out/             # 恢复已删除（未分配）文件——这是默认行为
tsk_recover -e -o <分区start> evidence.dd out_all/      # -e = 已分配 + 未分配全部导出（-a 则只导已分配）
    • fls outputs r/r 12345-128-1: 文件名 [DELETED]——the inode number at the start of the line is for icat; undeleted files can also be precisely extracted with icat (more controllable than mounting and copying)
    • Deleted recovery results are not 100% (SSD TRIM/overwrite), see pitfall 5
    • Partition lost/damaged, metadata method fails → testdisk / photorec (carving)： 
      testdisk evidence.dd          # 交互: 恢复丢失分区表 / Advanced → Undelete
photorec /d <输出目录> evidence.dd   # 雕刻: 按文件签名扫描恢复（无文件名，见坑 6）
    • photorec recovery types can be interactively filtered (only carve target extensions, narrowing the result set);/d specify output directory

  4. Timeline reconstruction (fls -m → mactime)：

    fls -r -m / -o <分区start> evidence.dd > bodyfile      # -m 生成 body file（挂载点写 /）
mactime -b bodyfile -d -z UTC > timeline.csv           # -d CSV、-z 指定时区
    • Timeline answers "when was it created/modified/deleted/accessed"——find anomalous windows (batch writes in the early morning, delete+copy combinations, abnormal access times)
    • Timestamps can be forged (timestomp), see pitfall 4——the timeline must be cross-validated with other sources (USN Journal, system logs, [[re-mem-forensics]] memory timeline)
    • Filter deletion actions by MAC time in the CSV: grep -i ',d,' timeline.csv(deletion records)

  5. Suspicious file extraction (unallocated space/hidden partitions)：

    # 未分配块（含删除文件残留、缓存、临时数据）
blkls -o <分区start> evidence.dd > unallocated.bin
strings -n 8 unallocated.bin | grep -iE 'key|password|flag|http' | head -50
# 分区表空隙（slack space）/隐藏分区: 按 mmls 相邻分区起止手工截取
dd if=evidence.dd of=gap.bin bs=512 skip=$((A_end+1)) count=$((B_start-A_end-1))   # mmls 的 End 是含端点的末扇区（Length=End-Start+1）；两分区之间的空白 = A_end+1 .. B_start-1。更省事：直接用 mmls 列出的 Unallocated 项 Start/Length
    • Unallocated space is the main battlefield of "deleted ≠ gone": credentials/keys/URLs/document fragments often remain there
    • Deleted/hidden partitions: after testdisk scans and reconstructs partition table entries, recover files from the reconstructed partitions following the step 3 procedure
    • For extracted objects (files/fragments), compute sha256 first before analysis; suspicious binaries go to [[re-binary-core]] for deeper investigation, sensitive strings go into the [[re-ioc]] IOC list

Database file formats

  • SQLite structure: page header (page header fields), btree pages (interior/leaf types), record format (varint length encoding / type codes), overflow pages (large fields spanning pages)
  • WAL recovery: WAL file frame parsing (transactions not yet checkpointed), checkpoint boundary determination (recovery point)
  • Forensic applications: browser/App databases——deleted record recovery (freelist page remnants), uncommitted transaction extraction (within WAL)
  • Tools：sqlite3 CLI read-only mode (sqlite3 -readonly), page-level parsing scripts (Python traversing by page structure)

Cross-domain federation

  • [[re-forensics]]: this skill is the disk-side forensics branch of that gateway (the memory side is [[re-mem-forensics]])——the gateway selection tree dispatches by "memory vs disk"
  • [[re-mem-forensics]]: Parallel forensic branch—memory remnants and disk evidence corroborate each other (process behavior ↔ file artifacts); the BitLocker key can first be obtained from the memory forensics plugin (then return to this skill to decrypt the volume)
  • [[re-ti]]: Extract objects (hashes/domains/IPs) for intelligence queries
  • [[re-ioc]]: Aggregate disk evidence (files/timeline/residual data) into IOCs and the evidence section of the report
  • [[re-binary-core]]: Deep dive into extracted suspicious binaries/scripts ([[re-ghidra]] / [[re-ida]])
  • [[re-crypto-keys]] / [[re-crypto-decrypt]]: Encrypted volume key extraction (BitLocker/LUKS) and encrypted file decryption
  • [[re-firmware]]: Firmware/embedded storage images are likewise handled via the "disk image" workflow (binwalk unpacking layers)
  • [[re-memdump]]: Memory dumps are upstream corroboration for disk forensics (keys/credentials/execution traces; dumping is preferred by default)
  • Reference the [[re-analyze/platform-tips]] WSL branch (Windows disk images handled with Linux forensic tools inside WSL) and the forensic evidence chain requirements

Common Pitfalls and Traps

  • Write operations contaminating evidence (must be read-only): Symptom—after analysis the image hash does not match, filesystem state is inconsistent before and after, and the report cannot self-verify; Cause—mount is writable by default (ext4/NTFS mounts replay the journal and update access times), or recovery tools were run directly on the original device; Countermeasure—always use mount -o ro,loop,noexec,nodev,nosuidfor images, add noloadfor ext4, use ntfs-3g -o ro,recover=no for NTFS to skip journal replay (see Pitfall 3); store a sha256 for evidence before analysis and re-verify after; use a write blocker for physical disks or blockdev --setro; for read-only data prefer sleuthkit tools (fsstat/fls/icat parse without writing) rather than mounting
  • Encrypted volumes (BitLocker/FileVault/LUKS): Symptom—fsstat/testdisk reports "unrecognized filesystem" and sectors are all high-entropy; Cause—the entire volume is encrypted, and without the key the contents are inaccessible; Countermeasure—key paths: ① obtain the key from a memory dump taken while the system was running ([[re-mem-forensics]]'s Bitlocker FVEK scanning plugin → dislocker mount) ② user password/recovery key (BitLocker 48-digit recovery key, FileVault recovery key, LUKS passphrase) ③ unencrypted boot partitions (UEFI/Boot partitions are not encrypted, allowing extraction of boot chain evidence); Tools: dislocker (BitLocker),cryptsetup luksOpen(LUKS); if the key cannot be obtained, the image can only undergo non-content forensics (partition structure/boot chain), and the limitations must be stated truthfully
  • Filesystem journal interference: Symptom—the file state seen by fls is inconsistent with that at analysis time (files "roll back" to an older state), or the image hash changes after mounting; Cause—ext4 jbd2 / NTFS journals are replayed on mount and uncommitted transactions are written back; Countermeasure—read-only mounts must include noload（ext4）/ recover=no(ntfs-3g); store two copies of the image (original + working copy), perform analysis on the copy, and never mount the original image
  • Timestamp forgery (timestomp): Symptom—in the timeline, batches of files have exactly identical or clearly unreasonable timestamps (e.g., deletion time earlier than creation time, or all changed to the same instant); Cause—the attacker/sample used timestomp-like techniques to rewrite MFT/inode timestamps (a common finishing move in [[re-malware]]); Countermeasure—cross-validate: the NTFS USN Journal (which records the true sequence of changes), ext4 access time vs crtime, system logs, [[re-mem-forensics]] memory timeline; discovering the forgery itself is an important forensic finding—write it into the report rather than filtering it out as dirty data
  • Deletion ≠ Recoverable (SSD TRIM/Overwrite): Symptom — fls lists a bunch of [DELETED] entries, but icat reads all zeros or retrieves nothing; Cause — SSD TRIM has erased the physical blocks, data has been overwritten by subsequent writes, or NTFS compressed/encrypted files; Countermeasure — first confirm the media type (HDD/SSD) and the deletion time window (the earlier, the higher the recovery probability); for unallocated space, use blkls to check for remnants, and if all zeros, report truthfully "already erased"
  • photorec carving false positives: Symptom — a large number of "files" are recovered but cannot be opened or their contents do not match the extensions; Cause — signature carving only recognizes file headers, and real files that are fragmented or overwritten get concatenated into fake files; Countermeasure — use the interactive menu to filter by file type (recover only the target types), prioritize verifying small files and key types, spot-check the recovered results' contents, and compute sha256 to store in the database ([[re-ioc]])