memory-forensic

Un toolkit di memory forensics che profila da sé i kernel Windows — e viene verificato in modo incrociato, processo per processo, contro Volatility 3.

mem4n6 legge tutti i comuni formati di dump (LiME, AVML, ELF core, crash dump di Windows, file di ibernazione, save-state di VMware, kdump, raw…) e attraversa processi, thread, moduli, connessioni di rete e memoria iniettata — da un unico binario statico che compili una volta e copi ovunque, senza Python, senza runtime, senza catalogo di simboli pre-caricato. Su Windows costruisce il proprio profilo: individua ntoskrnl nella memoria fisica, legge il suo PDB GUID dal record CodeView, risolve il corrispondente ISF di Volatility-3, recupera la base del kernel sotto il moderno KASLR e ricostruisce PsActiveProcessHead dalla tabella dei simboli — la stessa catena di auto-profilazione usata da Volatility 3 e MemProcFS, reimplementata in Rust.

Poiché lo standard per uno strumento forense è la correttezza, il walker dei processi viene verificato in modo incrociato contro un'implementazione di riferimento indipendente — Volatility 3 — su una reale immagine Windows 10 da 2 GB (il fatto che un riferimento concordi è una forte evidenza, non una prova; i byte grezzi sono la verità di fondo):

`windows.pslist` su DESKTOP-SDN1RPT.mem	mem4n6 vs Volatility 3
Processi corrispondenti	94 / 94 PID condivisi — PID, PPID, nome e create-time esatti
Persi (vol3 li ha trovati, mem4n6 no)	0
Falsi positivi (mem4n6 li ha trovati, vol3 no)	0

mem4n6 corrisponde a Volatility 3 esattamente — incluso il recupero di 11 processi rimasti orfani a causa di uno smear dell'acquisizione live, tramite una scansione bidirezionale di ActiveProcessLinks. Un secondo oracolo indipendente (MemProcFS) conferma un sottoinsieme pulito — la sua process_list di 77 processi è completamente contenuta nell'insieme di mem4n6, con zero processi presenti solo in MemProcFS (dettagli). Vedi docs/validation.md per il differenziale completo e i passaggi di riproduzione.

Avvio rapido

Installa con cargo install mem4n6, oppure scarica un binario statico precompilato dall'ultima release — le build Linux sono static-PIE (musl: copia ovunque, niente glibc), con versioni macOS, Windows e un checksums.txt SHA-256 accanto.

Oppure compila dal sorgente (circa un comando):```bash git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic && cargo build --release ./target/release/mem4n6 --help

Quella build di sviluppo linka libc dinamicamente; per riprodurre localmente il binario completamente statico della release, aggiungi il target 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

I file dei simboli sono JSON ISF — gli stessi pacchetti usati da Volatility 3, quindi una cache di simboli esistente funziona così com'è.

Perché mem4n6

mem4n6 è, a nostra conoscenza, l'unica implementazione Rust dell'intera catena dump → scansione del kernel → GUID PDB → risoluzione dei simboli → DTB. La discendenza tecnica — il server di simboli di WinDbg, pdbparse di Brendan Dolan-Gavitt, Rekall, Volatility 3 e MemProcFS di Ulf Frisk — è ben consolidata; mem4n6 la reimplementa in clean-room e valida il risultato rispetto al riferimento. MemNixFS porta la stessa idea memory-as-a-filesystem ai dump Linux — monta e naviga, con simboli derivati dal BTF del kernel quando non esiste un ISF; le celle n/a sopra indicano una differenza di ambito (immagini Linux e una UX basata su filesystem, rispetto al walker CLI validato su Windows di mem4n6), non una lacuna. L'ancoraggio boot low-stub / PROCESSOR_START_BLOCK segue Getting Physical di Alex Ionescu, REcon 2017.

Installazione```bash

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

---

## Riferimento rapido```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.

Verify kernel integrity — hooks invisible from the OS```bash

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

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

The input content for this chunk appears to be empty—no Markdown text was provided after "INPUT:". Please supply the actual chunk content so I can translate it.```
[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)

Tre tipi di hook — tabella delle syscall, ftrace e LSM — tutti risolti nello stesso modulo del kernel. Il controllo incrociato dell'elenco dei moduli conferma che non è nel set noto-affidabile.

Analisi comportamentale del rootkit LD_PRELOAD

La corrispondenza per pattern di nome non rileva le varianti di rootkit ricompilate o rinominate. L'analisi dei simboli dinamici ELF le individua indipendentemente dal nome:```bash mem4n6 check --symbols linux.json --elf-hooks memdump.lime

Input chunk is empty — there is no content to translate. Please provide the chunk text for chunk 15/47.```
[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 analizza ogni libreria mappata nella memoria di processo per:

Corrispondenza hook table — 17 simboli libc/syscall noti per essere intercettati dai rootkit (readdir64, getdents64, pam_get_item, write, …) classificati secondo la tassonomia dei segnali di forensicnomicon
Esportazioni shadow libc — le librerie che esportano una funzione con lo stesso nome di un simbolo libc intercettano tutti i chiamanti in fase di link
Artefatti di stringhe di classe Father — stringhe di formato incorporate in .rodata (es. UID:%d:, silly.txt) che sopravvivono allo stripping del binario e ai cambi di nome
Prevalenza globale — le librerie caricate in ≥90% dei processi vengono segnalate come probabili iniezioni LD_PRELOAD

Segreti DPAPI ed estrazione delle credenziali```bash

Extract DPAPI master keys from LSASS g_MasterKeyCache linked list

mem4n6 check --symbols ntkrnlmp.json --dpapi-keys memdump.dmp

Detect Chrome cookies (v10/v20 encrypted blobs) from heap memory

mem4n6 check --symbols ntkrnlmp.json --browser-cookies memdump.dmp

[Input appears to be missing. Please provide the Markdown content to translate.]```
[DPAPI] GUID={A1B2C3D4-...}  blob_len=680  source=lsass.exe
[COOKIE] msedge.exe  domain=.github.com  name=user_session  value=secretvalue...
[COOKIE] chrome.exe  (v10-encrypted)  — key material required for decryption

I walker delle credenziali di Windows coprono:

chiavi master DPAPI — scorre la lista collegata g_MasterKeyCache in LSASS, estrae GUID + blob crittografato per ogni chiave master in cache
cookie Chrome v10/v20 — scansione binaria dell'heap di Chromium per blob di cookie crittografati AES-GCM (prefisso v10/v20 + nonce di 12 byte); decrittati quando il materiale della chiave è disponibile
hash SAM/NTLM, ticket Kerberos, chiavi BitLocker, segreti LSA — suite completa di credenziali

Estrazione screenshot dal framebuffer```bash

mem4n6 framebuf --symbols ntkrnlmp.json --png screen.png memdump.dmp

Estrae il framebuffer da un dump di memoria live o da ibernazione e lo scrive come PNG. Funziona sia su Linux (walker DRM/KMS `drm_framebuffer`) sia su Windows (framebuffer di sessione tramite scansione pool `win32k`). Utile per catturare lo stato dello schermo al momento dell'acquisizione senza avviare l'immagine.

---

## Recupera file che non hanno mai toccato il disco

Gli attaccanti che usano tmpfs o `memfd_create(2)` non lasciano artefatti nel filesystem — il binario esiste solo in RAM.```bash
# Recover inodes and file content from Linux tmpfs/ramfs mounts
mem4n6 check --symbols linux.json --tmpfs-recovery memdump.lime

# Detect ELF binaries running from anonymous memfd file descriptors
mem4n6 check --symbols linux.json --memfd memdump.lime

Please provide the Markdown content to be translated.``` [TMPFS] /tmp/.x (dev=tmpfs) 3 inodes recovered inode 12: ELF x86_64 size=847KB sha256=deadbeef... (no disk copy) inode 13: config.sh size=1.2KB content recovered inode 14: keys.txt size=512B content recovered

[MEMFD] pid=2341 (python3) fd=4 name="" size=3.4MB ELF x86_64 No path on disk — binary executed entirely from anonymous memory. MITRE: T1620 (Reflective Code Loading)

tmpfs recovery scorre la tabella `vfsmount` del kernel e ricostruisce il contenuto degli inode dalle pagine della page-cache. Il rilevamento di memfd scorre la tabella dei descrittori di file aperti di ogni processo e segnala gli inode anonimi creati con `memfd_create(2)`.

---

## Rileva l'evasione EDR e la soppressione dei log

Gli strumenti offensivi moderni applicano patch alla strumentazione di sicurezza di Windows in memoria per eludere il rilevamento senza toccare il disco.```bash
# Direct syscalls — Syswhispers/Hell's Gate bypass Win32 API entirely
mem4n6 check --symbols ntkrnlmp.json --direct-syscalls memdump.dmp

# ETW patching — log suppression via ret/xor at ETW write functions
mem4n6 check --symbols ntkrnlmp.json --etw-patch memdump.dmp

# AMSI bypass — script-scanning suppression via amsi.dll patch
mem4n6 check --symbols ntkrnlmp.json --amsi-bypass memdump.dmp

# DSE bypass — Driver Signature Enforcement disabled for unsigned drivers
mem4n6 check --symbols ntkrnlmp.json --dse-bypass memdump.dmp

Please provide the Markdown content to translate.``` [DIRECT-SYSCALL] powershell.exe (PID 4412) stub at 0x7ff800a1000 mov r10,rcx / mov eax,0x3c / syscall — NtCreateThreadEx bypassing ntdll MITRE: T1055.012 (Process Injection: Process Hollowing)

[ETW-PATCH] svchost.exe (PID 1200) EtwEventWrite → ret at offset +0 Expected: 4C 8B DC Got: C3 90 90 (patched to immediate return) MITRE: T1562.006 (Impair Defenses: Indicator Blocking)

[AMSI-BYPASS] powershell.exe (PID 4412) AmsiScanBuffer → xor eax,eax / ret MITRE: T1562.001 (Impair Defenses: Disable or Modify Tools)

[DSE-BYPASS] g_CiEnabled=0 CipInitialize patch detected MITRE: T1014 (Rootkit), T1553.006 (Subvert Trust Controls)

---

## Abuso innovativo delle interfacce del kernel Linux

Oltre ai classici hook delle syscall, i rootkit moderni abusano dei sottosistemi del kernel più recenti. `memory-forensic` copre tutti e tre:```bash
mem4n6 check --symbols linux.json --io-uring --netfilter --perf-event memdump.lime

Translate the following Kitploit tool content. This is chunk 33 of 47 from a longer Markdown document being translated in sequence. The source language is en. Target language: it. Content type: README chunk 33/47.

CHUNK-SPECIFIC RULES:

Translate ONLY natural language text. NEVER translate: code blocks, shell commands, file paths, URLs, package names, technical identifiers, CVE IDs, environment variable names.
Preserve ALL Markdown syntax EXACTLY as-is.
DO NOT add introductory headings like "## Chunk N", "## Part N", "## Continued from..." or "## Translation of chunk...". DO NOT add "End of chunk N" or "Content continues..." markers.
DO NOT add "..." ellipsis markers to indicate omission. Translate ONLY the exact text provided, character for character in structure.
Chunk boundaries are intentional. Preserve structure so chunks can be concatenated seamlessly without visual artifacts.
Return ONLY the translated text. No preamble, no commentary, no wrapping in code blocks, no JSON/YAML/XML, no arrays, no objects, no schemas, no key/value wrappers.
If the chunk starts mid-paragraph, continue translating from that point. Do not add a leading newline or indent unless it exists in the source.

INPUT:

Il contenuto di questo blocco è vuoto. Non c'è testo da tradurre.``` [IO_URING] pid=3311 (malware) ring at 0x7f0000000000 ops=1024 pending SQPOLL thread pinned to cpu=0 — I/O continues without process context MITRE: T1071 (Application Layer Protocol)

[NETFILTER] NF_INET_PRE_ROUTING hook[0] → 0xffffffffc0b31240 (outside kernel text) Module not in module list — DKOM-hidden or manually unmapped MITRE: T1014 (Rootkit)

[PERF-EVENT] pid=1 (systemd) type=HARDWARE cpu=-1 overflow_handler patched → 0xffffffffc0b31500 MITRE: T1056 (Input Capture)

---

## Indicatori di fuga dal container```bash
mem4n6 check --symbols linux.json --container-escape memdump.lime

The input content is empty — no Markdown text was provided for chunk 37/47 to translate. Please supply the chunk content so I can translate it into Italian.``` [CONTAINER-ESCAPE] pid=8801 (bash) shares host user namespace uid_map: 0 0 4294967295 (full host UID range — privileged mapping) cgroup: / (host root cgroup, not namespaced) mount ns: host (same as pid 1) MITRE: T1611 (Escape to Host)

Esamina gli namespace user, mount, PID, net e cgroup per ogni processo e segnala i processi che dovrebbero essere isolati ma condividono gli namespace a livello di host — la firma strutturale di una container escape indipendentemente da come sia stata ottenuta.

---

## Correlazione ATT&CK tra artefatti

`memf-correlate` unisce i risultati di tutti i walker in una timeline, assegna un punteggio alle anomalie in base alla gravità e mappa ciascuna di esse alle tecniche MITRE ATT&CK senza eseguire i walker uno alla volta:```bash
mem4n6 correlate --symbols ntkrnlmp.json --output json memdump.dmp > findings.json

No input text was provided for chunk 41. Please supply the content to translate.```json { "technique": "T1055.012", "name": "Process Hollowing", "severity": "critical", "evidence": [ { "source": "vad", "detail": "svchost.exe VAD 0x140000–0x160000 RWX, no backing file" }, { "source": "ldrmodules","detail": "module in VAD but absent from InLoadOrderList" }, { "source": "iat_hooks", "detail": "CreateRemoteThread IAT entry patched → 0x14001a30" } ], "process": { "name": "svchost.exe", "pid": 1200, "ppid": 508 } }

Process, network, module, hook, and credential walker results are correlated by process and time before scoring — producing ATT&CK-tagged findings rather than per-walker output that an analyst must join manually.

---

## Formati di memoria supportati

| Formato | Sorgente | Auto-rilevato |
|---|---|---|
| LiME (`.lime`) | Modulo kernel Linux | Sì |
| AVML v2 | Azure AVML | Sì |
| ELF Core | QEMU, `gcore` | Sì |
| Windows Crash Dump (`.dmp`) | DumpIt, WinDbg | Sì |
| Hiberfil.sys | Windows ibernazione / avvio rapido | Sì |
| VMware State (`.vmss`, `.vmsn`) | VMware Workstation / ESXi | Sì |
| kdump / diskdump | `makedumpfile` | Sì |
| Raw / flat | Qualsiasi fallback | Sì |

Il formato viene rilevato dagli header dei file — non sono richiesti flag.

---

## Cosa c'è di diverso

The nearest alternatives are **Volatility 3** (Python, plugin architecture), **MemProcFS** (C with Rust bindings, primarily Windows), **Rekall** (Python, unmaintained), and **MemNixFS** (C++, Linux dumps mounted as a filesystem). The comparison below reflects each tool's official core and known plugin repository. MemNixFS targets *Linux* images with a filesystem UX, so it shares mem4n6's page-cache file recovery but is `n/a` on the Windows self-profiling and EDR-bypass rows.

Le alternative più vicine sono **Volatility 3** (Python, architettura a plugin), **MemProcFS** (C con binding Rust, principalmente Windows), **Rekall** (Python, non mantenuto) e **MemNixFS** (C++, dump Linux montati come filesystem). Il confronto seguente riflette il core ufficiale e il repository di plugin noto di ciascuno strumento. MemNixFS prende di mira immagini *Linux* con una UX da filesystem, quindi condivide il recupero dei file dalla page cache di mem4n6 ma è `n/a` sulle righe relative all'auto-profilazione di Windows e al bypass EDR.

### Parità — capacità condivise con strumenti maturi

| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Walker del kernel Linux + Windows | ✅ | ✅ | principalmente Windows | solo Linux | ✅ |
| Enumerazione di processi, moduli e rete | ✅ | ✅ | ✅ | ✅ | ✅ |
| Rilevamento di memoria iniettata | ✅ | ✅ | ✅ | ✅ | ✅ |
| Compatibile con i pacchetti di simboli ISF | ✅ | ✅ | — | ✅ | — |
| Funziona su Linux / macOS | ✅ | ✅ | parziale | Linux + Win | ✅ |
| Mantenuto attivamente | ✅ | ✅ | ✅ | ✅ | — |
| Gratuito e open source | ✅ | ✅ | ✅ | nessuna licenza | ✅ |

### Capacità assenti dalle distribuzioni ufficiali di altri strumenti

| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Singolo binario statico — niente Python, niente runtime | ✅ | — | — | parziale | — |
| API di libreria per l'integrazione in strumenti Rust | ✅ | — | ✅ | — | — |
| Fingerprinting comportamentale dei rootkit ELF | ✅ | — | — | — | — |
| Recupero file da tmpfs / ramfs | ✅ | — | — | ✅ | — |
| Rilevamento esecuzione fileless via memfd | ✅ | — | — | — | — |
| Rilevamento syscall dirette / bypass EDR | ✅ | plugin? | — | n/a | — |
| Rilevamento bypass ETW / AMSI / DSE | ✅ | plugin? | — | n/a | — |
| Abuso di io_uring / netfilter / perf\_event | ✅ | — | — | — | — |
| Indicatori di evasione dai container | ✅ | — | — | — | — |
| Estrazione di chiavi DPAPI + cookie di Chrome | ✅ | plugin? | — | n/a | — |
| Evidenze di accesso alle cartelle tramite shellbags dalla memoria ‡ | ✅ | — | — | n/a | — |
| Screenshot del framebuffer | ✅ | plugin? | — | — | — |
| Correlazione ATT&CK tra artefatti | ✅ | — | — | — | — |
| Output sicuro — RFC 4180, protezione contro l'iniezione di formule, rimozione bidi | ✅ | — | — | — | — |

> **`plugin?`** — La funzionalità può esistere nell'ecosistema community di Volatility 3, ma è assente dal core ufficiale e dal repository di plugin al momento della scrittura. Verificare prima di trarre conclusioni.
>
> **‡ Shellbags dalla memoria** — Volatility 2 recuperava le shellbags dalla RAM (il plugin community `shellbags`, Kovar e poi Lo); Volatility 3 non ne ha mai effettuato il porting, quindi il recupero delle shellbags da sola memoria ha subito una regressione nella transizione vol2→vol3. mem4n6 percorre direttamente `Shell\BagMRU` nell'hive in memoria `UsrClass.dat`/`NTUSER.DAT` — ripristinando la capacità dell'era vol2 per il caso di sola RAM (nessun disco acquisito) o per corroborare l'hive su disco. Il percorso usuale quando il disco *è* disponibile è montare l'immagine ed eseguire SBECmd / RegRipper sul file dell'hive; il walk in memoria comprime il processo in due passaggi — dump dell'hive e poi parsing — in uno solo. La validazione è **tier-2**: ground truth derivato con `regipy` sull'hive estratto da `citadeldc01.mem` — non esiste una chiave di risposta shellbag di terze parti pubblicata per il caso Szechuan, quindi questo è un oracolo auto-derivato (strumento reale + immagine reale), non una chiave di terze parti.

---

## Fidati ma verifica

Uno strumento che analizza **immagini di memoria non attendibili e controllabili dall'attaccante** deve rifiutarsi di mentire e rifiutarsi di crashare. mem4n6 è costruito per raggiungere questo standard:

- **Senza panic grazie al lint su input ostile.** I percorsi di parsing negano `unwrap`/`expect`/`panic!` e l'indicizzazione non controllata (`clippy::unwrap_used`/`expect_used` = deny); ogni lettura di lunghezza, offset e puntatore è sottoposta a controllo dei limiti e degrada con grazia — una lista di processi alterata (smeared) restituisce ciò che ha trovato, non si interrompe. (Le API builder vanno in panic su errore del programmatore — un campo obbligatorio mancante — per costruzione, mai sul contenuto del dump.)
- **Memory-safe di default.** `unsafe_code = "deny"` a livello di workspace; l'unico `unsafe` è costituito dai mapping di file `memmap2` limitati (il dump, il pagefile e il database di hash noti come validi), ciascuno giustificato singolarmente — da qui il badge *bounded (solo mmap)* anziché *forbidden*.
- **Validato contro un oracolo indipendente, non solo le nostre fixture.** Il walker dei processi Windows viene confrontato (diff) con Volatility 3 su una reale immagine Win10 da 2 GB — concordanza esatta su ogni processo condiviso, zero falsi positivi ([`docs/validation.md`](https://github.com/securityronin/memory-forensic/blob/HEAD/docs/validation.md)).
- **Output sicuro.** Ogni canale (tabella/CSV/JSON) applica l'quoting RFC 4180, una protezione contro l'iniezione di formule nei fogli di calcolo e la rimozione dei caratteri bidi/di controllo prima che le stringhe controllate dall'attaccante raggiungano il terminale o la pipeline.

---

## Uso della libreria```rust
use mem4n6_format::open;
use mem4n6_core::vas::{TranslationMode, VirtualAddressSpace};
use mem4n6_core::object_reader::ObjectReader;
use mem4n6_symbols::isf::IsfResolver;

// Open any supported format — detected from file headers
let dump = open("memdump.dmp")?;
let symbols = IsfResolver::from_file("ntkrnlmp.json")?;

// Walk the x86_64 4-level page table
let vas = VirtualAddressSpace::new(dump.clone(), TranslationMode::X64, cr3);
let reader = ObjectReader::new(vas, Box::new(symbols));

// Walk EPROCESS list
for proc in reader.eprocess_list()? {
    println!("{} (PID {})", proc.image_name()?, proc.pid()?);
}

Struttura del Crate

Mostra la struttura del crate

```toml # Use individual crates in your own tooling [dependencies] memf-core = "0.1" memf-linux = "0.1" memf-windows = "0.1" ``` ---

Usato da

issen — il sottocomando issen mem4n6 gestisce l'acquisizione della memoria e il reporting di triage direttamente da questo workspace.

Ringraziamenti

Andrew Case e la Volatility Foundation con il cui formato ISF e architettura dei plugin questo progetto è compatibile a livello di simboli.

Brendan Dolan-Gavitt la cui ricerca su DKOM e sull'occultamento dei processi basato su VAD ha influenzato i walker di rilevamento dei processi nascosti.

Ulf Frisk / MemProcFS il cui modello di filesystem come interfaccia di memoria e il design della modalità forense hanno influenzato il modo in cui questa libreria espone gli artefatti recuperati.

jam1garner per binrw — il parsing dichiarativo di formati binari che rende il livello di formato sicuro e leggibile.

S12 — l'articolo Kernel Dynamic Offset Resolution Using PDB Symbols che ha documentato l'intera catena di scansione di un dump per il PE ntoskrnl, l'estrazione del GUID CodeView del PDB e il recupero del PDB corrispondente da msdl.microsoft.com in fase di esecuzione. Questa tecnica ha ispirato direttamente l'implementazione di AutoProfile in memf-symbols.

Alex Ionescu — Getting Physical With USB Type-C: Windows 10 RAM Forensics and UEFI Attacks (REcon Brussels 2017), in cui ha documentato che HalpLowStub dell'HAL è il non documentato PROCESSOR_START_BLOCK — l'ancora di memoria fisica bassa (scansionata tramite firma in 0x1000–0x100000) che trasporta il CR3/DTB del kernel e un suggerimento di kernel-VA. Questa è la base per find_low_stub e per il recupero di DTB / base del kernel senza header in memf-symbols.

Microsoft Symbol Server (msdl.microsoft.com) per l'hosting dei file PDB pubblici per ogni build del kernel Windows, l'upstream che rende possibile la risoluzione dei simboli in fase di esecuzione senza file di simboli pre-caricati.

Distribuzione	Rust · singolo binario statico	Python · interprete + dipendenze	C(+Rust) · librerie	C++ · mount del filesystem
Self-profiling di Windows (scansione → GUID PDB → simboli)	✅	✅	✅	n/d — dump Linux
DTB senza header tramite boot low stub + base del kernel a granularità di pagina	✅	PML4 self-ref + scansione immagine	✅ low stub	n/d — Linux
Modalità simboli offline / air-gapped	✅ `--offline`	pacchetto ISF o rete	simboli / rete	✅ BTF dal dump
Senza panic su dump non attendibili (`unsafe` negato; `unwrap`/`expect` negati sui percorsi di parsing)	✅	—	—	— (C++)
Verifica incrociata con Volatility 3	✅ (`docs/validation.md`)	— (il riferimento)	—	—

`memf-format`	Rilevamento del formato e provider di memoria fisica. Parser per LiME, AVML, ELF Core, Windows Crash Dump, hiberfil.sys, stato VMware, kdump e immagini flat grezze.
`memf-core`	Camminamento delle tabelle di pagine (x86_64 a 4/5 livelli, AArch64, x86 PAE/non-PAE), `ObjectReader` di alto livello per l'attraversamento delle strutture del kernel, accesso al pagefile, decompressione LZO e codifica di screenshot da framebuffer a PNG (in abbinamento con i walker framebuffer Linux EFI/VESA e Windows win32k).
`memf-linux`	Walker del kernel Linux: elenco processi `task_struct`, connessioni di rete, moduli del kernel, file aperti, programmi eBPF, rilevamento hook ftrace/IDT/syscall, enumerazione di namespace e cgroup, rilevamento processi nascosti da DKOM, indicatori di fuga dal container, analisi dei simboli dinamici ELF e fingerprinting comportamentale dei rootkit LD_PRELOAD, rilevamento della prevalenza globale delle librerie e ~45 walker aggiuntivi.
`memf-windows`	Walker del kernel Windows NT: enumerazione `EPROCESS`/`ETHREAD`, elenchi di DLL e driver, tabelle degli handle, socket di rete, scansione dei pool tag, tabelle di callback, SSDT, ETW, appunti, cache DNS, ticket Kerberos, estrazione delle chiavi master DPAPI da LSASS `g_MasterKeyCache`, rilevamento dei cookie crittografati AES-GCM di Chrome v10/v20, chiavi BitLocker, hash SAM/NTLM, rilevamento di memoria iniettata e ~55 walker aggiuntivi.
`memf-strings`	Estrazione di stringhe (ASCII, UTF-8, UTF-16LE) con classificazione tramite regex in categorie IoC: URL, indirizzi IP, domini, chiavi di registro, indirizzi di portafogli crypto, chiavi private, comandi shell.
`memf-symbols`	Risoluzione dei simboli da file ISF JSON, BTF (Linux) e PDB. Include `AutoProfile` — risoluzione delle strutture del kernel Windows a configurazione zero: esegue la scansione del dump per ntoskrnl, recupera il PDB esatto da `msdl.microsoft.com`, lo analizza e restituisce un `SymbolResolver`. Nessun file di simboli richiesto.
`memf-correlate`	Correlazione tra artefatti con etichettatura delle tecniche MITRE ATT&CK, ricostruzione dell'albero dei processi, punteggio delle anomalie e generazione di timeline.
`forensic-hashdb`	Database di hash a zero falsi positivi: ricerca known-good NSRL/CIRCL, ricerca known-bad MalwareBazaar/VirusShare e hash incorporati dei driver Windows vulnerabili di loldrivers.io.

Più Popolari

memory-forensic

memory-forensic

Avvio rapido

Perché mem4n6

Installazione```bash

Verify kernel integrity — hooks invisible from the OS```bash

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

Analisi comportamentale del rootkit LD_PRELOAD

Segreti DPAPI ed estrazione delle credenziali```bash

Extract DPAPI master keys from LSASS g_MasterKeyCache linked list

Detect Chrome cookies (v10/v20 encrypted blobs) from heap memory

Estrazione screenshot dal framebuffer```bash

Struttura del Crate

Usato da

Ringraziamenti