Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
memory-forensic — Esamina qualsiasi memory dump. Trova ciò che è nascosto. Analisi forense del kernel Linux + Windows da un singolo binario Rust statico — nessun Python richiesto. | Kitploit
Strumenti/GitHubGitHub/securityronin/memory-forensic
Gestione degli Indicatori di Compromissione (IOC)Memory ForensicsNetwork ForensicsRecupero DatiAnalisi MalwareDigital ForensicsAnalisi di BinariThreat IntelligenceRisposta agli Incidenti

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Escape dal Container
GitHubsecurityronin/memory-forensic

memory-forensic

Esamina qualsiasi memory dump. Trova ciò che è nascosto. Analisi forense del kernel Linux + Windows da un singolo binario Rust statico — nessun Python richiesto.

Vedi RepositorySito web
121311 mese faNon ancora revisionato
Condividi

License: Apache-2.0 CI Rust 1.75+ Platform unsafe: bounded Sponsor

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.memmem4n6 vs Volatility 3
Processi corrispondenti94 / 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

mem4n6Volatility 3MemProcFSMemNixFS
DistribuzioneRust · singolo binario staticoPython · interprete + dipendenzeC(+Rust) · librerieC++ · 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 stubn/d — Linux
Modalità simboli offline / air-gapped✅ --offlinepacchetto ISF o retesimboli / 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)——

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
Scarica lo strumento