memory-forensic

Windows カーネルを自己プロファイリングするメモリフォレンジックツールキット — Volatility 3 に対してプロセス単位で相互検証されています。

mem4n6 は、一般的なすべてのダンプ形式（LiME、AVML、ELF core、Windows クラッシュダンプ、ハイバネーションファイル、VMware セーブステート、kdump、raw…）を読み取り、プロセス、スレッド、モジュール、ネットワーク接続、インジェクションされたメモリを走査します。1 つの静的バイナリ から — 一度コンパイルすればどこへでもコピーでき、Python もランタイムも事前ステージング済みシンボルカタログも不要です。Windows では独自のプロファイルを構築します。物理メモリ内の ntoskrnl を特定し、CodeView レコードから PDB GUID を読み取り、一致する Volatility-3 ISF を解決し、最新の KASLR 下でカーネルベースを復元し、シンボルテーブルから PsActiveProcessHead を再構築します — Volatility 3 と MemProcFS が使用するのと同じ自己プロファイリングチェーンを Rust で再実装したものです。

証拠ツールの基準は 正確性 であるため、プロセスウォーカーは、実際の 2 GB Windows 10 イメージ上で 独立したリファレンス実装 — Volatility 3 — と相互検証されています（リファレンスが一致することは強力な証拠であり、証明ではありません。生のバイト列が真実の基準です）。

DESKTOP-SDN1RPT.mem 上の windows.pslist	mem4n6 vs Volatility 3
一致したプロセス	94 / 94 の共有 PID — PID、PPID、名前、作成時刻が完全一致
見逃し（vol3 で見つかり、mem4n6 では見つからなかったもの）	0
誤検出（mem4n6 で見つかり、vol3 では見つからなかったもの）	0

mem4n6 は Volatility 3 と 完全に一致 します — ライブ取得時のスミアによって孤立した 11 プロセスを、双方向の ActiveProcessLinks 走査で復元することも含みます。もう 1 つの独立したオラクル（MemProcFS）がクリーンなサブセットを確認しています。その 77 プロセスの process_list は mem4n6 の集合に完全に含まれており、MemProcFS のみのプロセスはゼロです（詳細）。完全な差分と再現手順については docs/validation.md を参照してください。

クイックスタート

cargo install mem4n6 でインストールするか、最新リリース からビルド済みの 静的バイナリ を入手してください。Linux ビルドは static-PIE（musl: どこへでもコピーでき、glibc 不要）で、macOS、Windows、併せて SHA-256 の checksums.txt も用意されています。

またはソースからビルド（約 1 コマンド）：```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

シンボルファイルは ISF JSON です — Volatility 3 が使用するものと同じパックなので、既存のシンボルキャッシュがそのまま機能します。

---

なぜ mem4n6 か

	mem4n6	Volatility 3	MemProcFS	MemNixFS
デプロイ	Rust · 単一の静的バイナリ	Python · インタープリタ + 依存関係	C(+Rust) · ライブラリ	C++ · ファイルシステムマウント
Windows セルフプロファイリング (スキャン → PDB GUID → シンボル)	✅	✅	✅	n/a — Linux ダンプ
ブート low stub + ページ粒度のカーネルベースによるヘッダーレス DTB	✅	self-ref PML4 + イメージスキャン	✅ low stub	n/a — Linux
オフライン / エアギャップのシンボルモード	✅ --offline	ISF パックまたはネットワーク	シンボル / ネットワーク	✅ BTF-from-dump
信頼できないダンプに対するパニックフリー (unsafe-deny; unwrap/expect は解析パスで拒否)	✅	—	—	— (C++)
Volatility 3 と相互検証済み	✅ (docs/validation.md)	— (リファレンス)	—	—

mem4n6 は、私たちの知る限り、完全なダンプ → カーネルスキャン → PDB-GUID → シンボル解決 → DTB チェーンの唯一の Rust 実装です。この技術の系譜 — WinDbg のシンボルサーバー、Brendan Dolan-Gavitt の pdbparse、Rekall、Volatility 3、そして Ulf Frisk の MemProcFS — は確立されています。mem4n6 はそれをクリーンルームで再実装し、その結果をリファレンスに対して検証しています。MemNixFS は、その同じ メモリをファイルシステムとして扱う アイデアを Linux ダンプに適用します — マウントしてブラウズでき、ISF が存在しない場合はカーネル自身の BTF からシンボルを取得します。上記の n/a セルは、(Linux イメージとファイルシステム UX 対 mem4n6 の Windows 検証済み CLI ウォーカーという) スコープの違いを示すものであり、ギャップではありません。ブート low-stub / PROCESSOR_START_BLOCK アンカーは、Alex Ionescu の REcon 2017 Getting Physical に従っています。

---

インストール```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

SymbolファイルはISF JSON形式で、Volatility 3シンボルパックと互換性があります。

---

カーネル整合性の検証 — OSからは見えないフック```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)

3つのフックタイプ — システムコールテーブル、ftrace、LSM — はすべて同じカーネルモジュールに解決される。モジュールリストを相互参照すると、それが既知の正常なセットに含まれていないことが確認できる。

---

LD_PRELOAD ルートキットの動作解析

名前パターンマッチングは、再コンパイルまたはリネームされたルートキットの亜種を見逃す。ELF動的シンボル解析は、名前に関係なくそれらを検出する：```bash mem4n6 check --symbols linux.json --elf-hooks memdump.lime

No input content was provided to translate.```
[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)