memory-forensic

一款内存取证工具包，可自行对 Windows 内核进行画像——并逐进程与 Volatility 3 交叉校验。

mem4n6 读取所有常见转储格式（LiME、AVML、ELF core、Windows 崩溃转储、休眠文件、VMware 保存状态、kdump、raw…），并遍历进程、线程、模块、网络连接和注入内存——这一切来自一个静态二进制：编译一次，随处复制；无需 Python、无需运行时、无需预置符号目录。在 Windows 上，它会自行构建 profile：在物理内存中定位 ntoskrnl，从 CodeView 记录中读取其 PDB GUID，解析匹配的 Volatility-3 ISF，在现代 KASLR 下恢复内核基址，并从符号表重建 PsActiveProcessHead——这是 Volatility 3 与 MemProcFS 所用的同一条自画像链路，现以 Rust 重新实现。

因为证据工具的衡量标准是正确性，进程遍历器在一个真实的 2 GB Windows 10 镜像上与独立参考实现——Volatility 3 进行交叉校验（参考实现的一致性是强有力的证据，而非证明；原始字节才是真相来源）：

windows.pslist 在 DESKTOP-SDN1RPT.mem 上	mem4n6 与 Volatility 3 对比
匹配到的进程	94 / 94 个共享 PID——PID、PPID、名称、创建时间完全一致
遗漏（vol3 发现，mem4n6 未发现）	0
误报（mem4n6 发现，vol3 未发现）	0

mem4n6 与 Volatility 3 完全匹配——包括通过双向 ActiveProcessLinks 遍历，恢复了因实时采集拖影而成为孤儿的 11 个进程。第二个独立的 oracle（MemProcFS）也确认了一个干净的子集——其 77 进程的 process_list 完全包含在 mem4n6 的集合中，且没有任何仅 MemProcFS 发现的进程（详情）。完整的差异对比和复现步骤见 docs/validation.md。

快速开始

使用 cargo install mem4n6 安装，或从最新发布获取预构建的静态二进制——Linux 构建为 static-PIE（musl：可随处复制，无需 glibc），同时提供 macOS、Windows 以及 SHA-256 checksums.txt。

或者从源码构建（约一条命令）：```bash git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic && cargo build --release ./target/release/mem4n6 --help

该开发构建动态链接 libc；要在本地复现发布版的完全静态二进制文件，请添加 musl 目标：`rustup target add x86_64-unknown-linux-musl && cargo build --release --target x86_64-unknown-linux-musl````bash
# Inspect any dump — format, ranges, embedded metadata (no symbols needed)
mem4n6 info win10.mem

# Windows process tree. The ISF is resolved from the kernel's own PDB GUID;
# raw .mem dumps take the page-table base via --cr3 (crash dumps carry their own).
mem4n6 ps --symbols ntkrnlmp.json --cr3 0x1ad000 --tree win10.mem

# Linux process tree from a LiME capture
mem4n6 ps --symbols linux.json --tree memdump.lime

# Air-gapped lab? Never touch the network for symbols:
mem4n6 ps --symbols ntkrnlmp.json --offline win10.mem

Symbol files are ISF JSON — the same packs Volatility 3 uses, so an existing symbol cache works as-is.

---

Why mem4n6

	mem4n6	Volatility 3	MemProcFS	MemNixFS
Deploy	Rust · single static binary	Python · interpreter + deps	C(+Rust) · libraries	C++ · filesystem mount
Windows self-profiling (scan → PDB GUID → symbols)	✅	✅	✅	n/a — Linux dumps
Header-less DTB via the boot low stub + page-granular kernel base	✅	self-ref PML4 + image scan	✅ low stub	n/a — Linux
Offline / air-gapped symbol mode	✅ --offline	ISF pack or network	symbols / network	✅ BTF-from-dump
Panic-free on untrusted dumps (unsafe-deny; unwrap/expect denied on parsing paths)	✅	—	—	— (C++)
Cross-checked against Volatility 3	✅ (docs/validation.md)	— (the reference)	—	—

mem4n6 is, to our knowledge, the only Rust implementation of the full dump → kernel-scan → PDB-GUID → symbol-resolution → DTB chain. The technique lineage — WinDbg's symbol server, Brendan Dolan-Gavitt's pdbparse, Rekall, Volatility 3, and Ulf Frisk's MemProcFS — is well established; mem4n6 reimplements it clean-room and validates the result against the reference. MemNixFS brings that same memory-as-a-filesystem idea to Linux dumps — mount-and-browse, with symbols derived from the kernel's own BTF when no ISF exists; the n/a cells above mark a difference in scope (Linux images and a filesystem UX, vs mem4n6's Windows-validated CLI walker), not a gap. The boot low-stub / PROCESSOR_START_BLOCK anchor follows Alex Ionescu's REcon 2017 Getting Physical.

---

Install```bash

git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic cargo build --release ./target/release/mem4n6 --help

---

## 快速参考```bash
# Show dump format and physical memory ranges
mem4n6 info memdump.dmp

# Process tree with threads and DLLs
mem4n6 ps --symbols ntkrnlmp.json --tree --threads --dlls memdump.dmp

# Network connections (json / csv / table)
mem4n6 net --symbols ntkrnlmp.json --output json memdump.dmp

# Kernel integrity checks (SSDT, IDT, callbacks, hooks)
mem4n6 check --symbols ntkrnlmp.json --ssdt --callbacks memdump.dmp

# Linux syscall hook and malfind scan
mem4n6 check --symbols linux.json --hooks --malfind memdump.lime

# String extraction with YARA rules
mem4n6 strings --rules ./yara-rules/ --min-length 8 memdump.dmp

# Hash lookup against NSRL (known-good) and MalwareBazaar (known-bad)
mem4n6 hash --lookup memdump.dmp

# Extract framebuffer screenshot from live memory dump
mem4n6 framebuf --symbols linux.json --png screen.png memdump.dmp

# Recover files from tmpfs mounts + detect memfd fileless ELF execution
mem4n6 check --symbols linux.json --tmpfs-recovery --memfd memdump.lime

# Detect EDR bypass: direct syscalls, ETW patching, AMSI/DSE bypass
mem4n6 check --symbols ntkrnlmp.json --direct-syscalls --etw-patch --amsi-bypass memdump.dmp

# Novel kernel interface abuse: io_uring, netfilter hooks, perf_event
mem4n6 check --symbols linux.json --io-uring --netfilter --perf-event memdump.lime

# Cross-artifact ATT&CK correlation across all walkers
mem4n6 correlate --symbols ntkrnlmp.json --output json memdump.dmp

符号文件是 ISF JSON，与 Volatility 3 符号包兼容。

---

验证内核完整性 — 操作系统不可见的钩子```bash

SSDT, IDT, ftrace, LSM, and kernel callback checks in one pass

mem4n6 check --symbols linux.json --hooks --idt --syscalls memdump.lime

请提供需要翻译的 Markdown 内容。```
[HOOK]  sys_call_table[59]  execve  → 0xffffffffc0a2f3d0  (outside kernel text)
[HOOK]  ftrace_ops[0]  target: vfs_read  → 0xffffffffc0a2f410  (module: libymv_ko)
[HOOK]  security_inode_getattr  → 0xffffffffc0a2f450  (LSM hook patched)

三种钩子类型 — 系统调用表、ftrace 和 LSM — 都解析到同一个内核模块。交叉引用模块列表确认它不在已知良好集合中。

---

LD_PRELOAD rootkit 行为分析

名称模式匹配会漏掉重新编译或重命名的 rootkit 变种。ELF 动态符号分析无论名称如何都能捕获它们：```bash mem4n6 check --symbols linux.json --elf-hooks memdump.lime

（未检测到待翻译的Markdown内容。请提供完整的工具说明文本，我将严格按照规则进行翻译。）```
[ROOTKIT] /tmp/.x/libhider.so  signals=[elf.hooks.process_hiding, elf.hooks.pam_credential_theft]
  exports: readdir64, getdents64, pam_get_item, pam_authenticate
  MITRE: T1014 (Rootkit), T1556.003 (Modify Authentication Process)
  loaded in 100% of processes (23/23)

[ROOTKIT] /tmp/.x/libhider.so  .rodata match: "UID:%d:" (Father PAM hook format string, weight=90)

memf-linux 扫描进程内存中映射的每个库，以检测：

• 钩子表匹配 — 已知会被 rootkit 拦截的 17 个 libc/syscall 符号（readdir64、getdents64、pam_get_item、write、…），并依据 forensicnomicon 信号分类法进行分类
• Libc 影子导出 — 导出与 libc 符号同名的函数的库，会在链接时拦截所有调用者
• 父类字符串痕迹 — 烘焙在 .rodata 中的格式字符串（例如 UID:%d:、silly.txt），这些字符串在二进制剥离和改名后依然存在
• 全局流行度 — 在 ≥90% 的进程中被加载的库会被标记为可疑的 LD_PRELOAD 注入

---