memory-forensic

Windows 커널을 스스로 프로파일링하는 메모리 포렌식 툴킷 — Volatility 3과 프로세스 하나하나 대조 검증됩니다.

mem4n6는 모든 일반적인 덤프 형식(LiME, AVML, ELF core, Windows crash dumps, hibernation files, VMware save-states, kdump, raw…)을 읽고 프로세스, 스레드, 모듈, 네트워크 연결, 그리고 인젝션된 메모리를 탐색합니다 — 한 번 컴파일하면 어디든 복사해 사용할 수 있는 단일 정적 바이너리로, Python도, 런타임도, 사전에 준비된 심볼 카탈로그도 필요 없습니다. Windows에서는 자체 프로필을 구축합니다: 실제 메모리에서 ntoskrnl을 찾고, CodeView 레코드에서 PDB GUID를 읽고, 일치하는 Volatility-3 ISF를 해석하고, 최신 KASLR 환경에서 커널 베이스를 복구하며, 심볼 테이블에서 PsActiveProcessHead를 재구성합니다 — Volatility 3와 MemProcFS가 사용하는 동일한 자체 프로파일링 체인을 Rust로 재구현한 것입니다.

증거 도구의 기준은 정확성이므로, 프로세스 워커는 독립적인 참조 구현 — Volatility 3 — 과 실제 2 GB Windows 10 이미지에서 대조 검증됩니다 (참조 구현이 일치한다는 것은 강력한 증거이지 증명은 아니며, 원본 바이트가 진실입니다):

windows.pslist on DESKTOP-SDN1RPT.mem	mem4n6 vs Volatility 3
일치한 프로세스	공유 PID 94 / 94 — PID, PPID, 이름, 생성 시간 정확히 일치
놓친 프로세스 (vol3가 찾았지만 mem4n6는 못 찾음)	0
오탐 (mem4n6가 찾았지만 vol3는 못 찾음)	0

mem4n6는 Volatility 3와 정확히 일치합니다 — 양방향 ActiveProcessLinks 탐색을 통해 라이브 수집 스미어(smear)로 고아가 된 11개 프로세스까지 복구합니다. 두 번째 독립 오라클(MemProcFS)도 깨끗한 하위 집합을 확인해 줍니다 — 그 77개 프로세스 process_list는 mem4n6의 집합에 완전히 포함되며, MemProcFS 전용 프로세스는 0개입니다 (상세 내역). 전체 차등 분석 및 재현 절차는 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

심볼 파일은 ISF JSON입니다 — Volatility 3가 사용하는 것과 동일한 팩이므로 기존 심볼 캐시를 그대로 사용할 수 있습니다.

---

왜 mem4n6인가

	mem4n6	Volatility 3	MemProcFS	MemNixFS
배포	Rust · 단일 정적 바이너리	Python · 인터프리터 + 의존성	C(+Rust) · 라이브러리	C++ · 파일시스템 마운트
Windows 자체 프로파일링 (스캔 → PDB GUID → 심볼)	✅	✅	✅	n/a — Linux 덤프
부트 로우 스텁 + 페이지 단위 커널 베이스를 통한 헤더 없는 DTB	✅	자체 참조 PML4 + 이미지 스캔	✅ 로우 스텁	n/a — Linux
오프라인 / air-gapped 심볼 모드	✅ --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는 동일한 memory-as-a-filesystem 아이디어를 Linux 덤프에 적용합니다 — 마운트 후 탐색이며, ISF가 없을 때 커널 자체의 BTF에서 심볼을 파생합니다. 위의 n/a 셀들은 (Linux 이미지 및 파일시스템 UX 대비 mem4n6의 Windows 검증 CLI 탐색기) 범위 차이를 나타내며, 결함이 아닙니다. 부트 로우 스텁 / 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 files are ISF JSON, compatible with Volatility 3 symbol packs.

---

커널 무결성 검증 — OS에서 보이지 않는 후크```bash

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

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

I need to translate chunk 11 of 47 of a Markdown document from English to Korean, but the input content provided is empty. There is no text to translate.```
[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)이 모두 동일한 커널 모듈로 귀결됩니다. 모듈 목록을 상호 참조하면 해당 모듈이 알려진 정상(known-good) 집합에 포함되지 않음을 확인할 수 있습니다.

---

LD_PRELOAD 루트킷 행동 분석

이름 패턴 매칭은 재컴파일되거나 이름이 변경된 루트킷 변종을 놓칩니다. ELF 동적 심볼 분석은 이름과 관계없이 이를 탐지합니다.```bash mem4n6 check --symbols linux.json --elf-hooks memdump.lime

Please provide the Markdown content 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)