Durchsuche jeden Speicherabbild. Finde, was verborgen ist. Linux + Windows-Kernel-Forensik aus einer einzigen statischen Rust-Binärdatei — kein Python erforderlich.
-green.svg){kind=icon}
Ein Speicherforensik-Toolkit, das Windows-Kernel selbst profiliert — und Prozess für Prozess gegen Volatility 3 abgeglichen wird.
mem4n6 liest jedes gängige Dump-Format (LiME, AVML, ELF core, Windows-Crash-Dumps, Ruhezustandsdateien, VMware-Save-States, kdump, raw…) und durchläuft Prozesse, Threads, Module, Netzwerkverbindungen und injizierten Speicher — aus einer einzigen statischen Binärdatei, die man einmal kompiliert und überallhin kopieren kann, ohne Python, ohne Laufzeitumgebung, ohne vorab bereitgestellten Symbolkatalog. Unter Windows erstellt es sein eigenes Profil: den ntoskrnl im physischen Speicher lokalisieren, seine PDB-GUID aus dem CodeView-Datensatz lesen, das passende Volatility-3-ISF auflösen, die Kernel-Basis unter modernem KASLR wiederherstellen und PsActiveProcessHead aus der Symboltabelle rekonstruieren — dieselbe Self-Profiling-Kette, die auch Volatility 3 und MemProcFS verwenden, neu implementiert in Rust.
Da die Messlatte für ein Beweiswerkzeug Korrektheit ist, wird der Prozess-Walker gegen eine unabhängige Referenzimplementierung — Volatility 3 — an einem echten 2-GB-Windows-10-Image abgeglichen (eine übereinstimmende Referenz ist starke Evidenz, kein Beweis; die Rohbytes sind die Ground Truth):
windows.pslist auf DESKTOP-SDN1RPT.mem | mem4n6 vs Volatility 3 |
|---|---|
| Übereinstimmende Prozesse | 94 / 94 gemeinsame PIDs — exakte PID, PPID, Name, Erstellungszeit |
| Nicht gefunden (vol3 hat sie gefunden, mem4n6 nicht) | 0 |
| False Positives (mem4n6 hat sie gefunden, vol3 nicht) |
mem4n6 stimmt exakt mit Volatility 3 überein — einschließlich der Wiederherstellung von 11 durch einen Live-Acquisition-Smear verwaisten Prozessen über einen bidirektionalen ActiveProcessLinks-Durchlauf. Ein zweites unabhängiges Orakel (MemProcFS) bestätigt eine saubere Teilmenge — seine process_list mit 77 Prozessen ist vollständig in der Menge von mem4n6 enthalten, ohne einen einzigen MemProcFS-only-Prozess (Details). Siehe docs/validation.md für die vollständige Differenzanalyse und die Reproduktionsschritte.
Installiere mit cargo install mem4n6 oder hole dir eine vorgefertigte statische Binärdatei aus dem neuesten Release — die Linux-Builds sind static-PIE (musl: überallhin kopierbar, ohne glibc), mit macOS, Windows und einer SHA-256-checksums.txt daneben.
Oder baue aus dem Quellcode (~ein Befehl):```bash git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic && cargo build --release ./target/release/mem4n6 --help
Diese Dev-Build verknüpft libc dynamisch; um das vollständig statische Binary des Releases lokal zu reproduzieren, füge das musl-Target hinzu: `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
Symboldateien sind ISF JSON — die gleichen Pakete, die Volatility 3 verwendet, sodass ein vorhandener Symbol-Cache unverändert funktioniert.
mem4n6 ist unseres Wissens die einzige Rust-Implementierung der vollständigen Kette Dump → Kernel-Scan → PDB-GUID → Symbolauflösung → DTB. Die technische Abstammungslinie — WinDbg-Symbolserver, Brendan Dolan-Gavitts pdbparse, Rekall, Volatility 3 und Ulf Frisks MemProcFS — ist gut etabliert; mem4n6 implementiert sie in einem Clean-Room neu und validiert das Ergebnis gegen die Referenz. MemNixFS bringt dieselbe Speicher-als-Dateisystem-Idee zu Linux-Dumps – einhängen und durchsuchen, mit Symbolen, die aus dem eigenen BTF des Kernels abgeleitet werden, wenn kein ISF existiert; die n/a-Zellen oben markieren einen Unterschied im Umfang (Linux-Images und eine Dateisystem-UX vs. mem4n6s Windows-validierter CLI-Walker), keine Lücke. Die Verankerung über den Boot-Low-Stub / PROCESSOR_START_BLOCK folgt Alex Ionescus REcon 2017 Getting Physical.
git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic cargo build --release ./target/release/mem4n6 --help
---
## Kurzreferenz```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
Symboldateien sind ISF JSON, kompatibel mit Volatility 3-Symbolpaketen.
mem4n6 check --symbols linux.json --hooks --idt --syscalls memdump.lime
<empty>```
[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)
Drei Hook-Typen — Syscall-Tabelle, ftrace und LSM — lösen alle in dasselbe Kernelmodul auf. Der Abgleich mit der Modulliste bestätigt, dass es nicht im Known-Good-Set enthalten ist.
Namensmuster-Abgleich übersieht neu kompilierte oder umbenannte Rootkit-Varianten. Die ELF-Dynamic-Symbol-Analyse erkennt sie unabhängig vom Namen:```bash mem4n6 check --symbols linux.json --elf-hooks memdump.lime
[No input content 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)
[ROOTKIT] /tmp/.x/libhider.so .rodata match: "UID:%d:" (Father PAM hook format string, weight=90)
memf-linux durchsucht jede Bibliothek, die im Prozessspeicher abgebildet ist, nach:
.rodata eingebacken sind (z. B. UID:%d:, silly.txt) und Binärdatei-Stripping sowie Namensänderungen überlebenmem4n6 check --symbols ntkrnlmp.json --dpapi-keys memdump.dmp
mem4n6 check --symbols ntkrnlmp.json --browser-cookies memdump.dmp
Der Eingabetext für dieses Chunk ist leer – es gibt keinen Inhalt, der übersetzt werden kann. Bitte stelle den Quelltext für Chunk 19 bereit.```
[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
The Windows Credential Walker umfassen:
g_MasterKeyCache-verkettete Liste in LSASS, extrahiert GUID + verschlüsselten Blob für jeden gecachten Masterschlüsselv10/v20 + 12-Byte-Nonce); entschlüsselt, wenn Schlüsselmaterial verfügbar istmem4n6 framebuf --symbols ntkrnlmp.json --png screen.png memdump.dmp
Extrahiert den Framebuffer aus einem Live- oder Ruhezustands-Speicherabbild und schreibt ihn als PNG. Funktioniert sowohl unter Linux (DRM/KMS `drm_framebuffer`-Walker) als auch unter Windows (Sitzungs-Framebuffer über `win32k`-Pool-Scan). Nützlich, um den Bildschirmzustand zum Zeitpunkt der Erfassung festzuhalten, ohne das Abbild zu booten.
---
## Dateien wiederherstellen, die nie die Festplatte berührt haben
Angreifer, die tmpfs oder `memfd_create(2)` verwenden, hinterlassen keine Dateisystem-Artefakte — die Binärdatei existiert nur im 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
I received no input to translate. Please provide the source text for chunk 25.``` [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)
Die tmpfs-Wiederherstellung durchläuft die Kernel-`vfsmount`-Tabelle und rekonstruiert Inode-Inhalte aus Page-Cache-Seiten. Die memfd-Erkennung durchläuft die Tabelle der geöffneten Dateideskriptoren jedes Prozesses und kennzeichnet anonyme Inodes, die mit `memfd_create(2)` erstellt wurden.
---
## Erkennung von EDR-Umgehung und Protokollunterdrückung
Moderne offensive Tools patchen die Windows-Sicherheitsinstrumentierung im Speicher, um der Erkennung zu entgehen, ohne das Laufwerk zu berühren.```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
I have no content to translate — the INPUT section is empty. Please provide the source Markdown text for chunk 29 of 47.``` [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)
---
## Neuartiger Missbrauch von Linux-Kernel-Schnittstellen
Jenseits klassischer Syscall-Hooks missbrauchen moderne Rootkits neuere Kernel-Subsysteme. `memory-forensic` deckt alle drei ab:```bash
mem4n6 check --symbols linux.json --io-uring --netfilter --perf-event memdump.lime
I don't see any source text in your message—it ends with "INPUT:" but no Markdown content follows. Please provide the actual chunk text so I can translate it into German.``` [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)
---
## Indikatoren für Container-Escape```bash
mem4n6 check --symbols linux.json --container-escape memdump.lime
(no input provided)``` [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)
Walks user, mount, PID, net, and cgroup namespaces for every process and flags processes that should be isolated but share host-level namespaces — the structural signature of a container escape regardless of how it was achieved.
---
## Artefaktübergreifende ATT&CK-Korrelation
`memf-correlate` führt die Ergebnisse aller Walker in einer Zeitleiste zusammen, bewertet Anomalien nach Schweregrad und ordnet jede den MITRE-ATT&CK-Techniken zu, ohne die Walker einzeln auszuführen:```bash
mem4n6 correlate --symbols ntkrnlmp.json --output json memdump.dmp > findings.json
Kein Inhalt bereitgestellt.```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 } }
Ergebnisse von Prozess-, Netzwerk-, Modul-, Hook- und Credential-Walkern werden vor der Bewertung nach Prozess und Zeit korreliert — so entstehen ATT&CK-markierte Befunde statt einer Ausgabe pro Walker, die ein Analyst manuell zusammenführen muss.
---
## Unterstützte Speicherformate
| Format | Quelle | Automatisch erkannt |
|---|---|---|
| LiME (`.lime`) | Linux-Kernelmodul | Ja |
| AVML v2 | Azure AVML | Ja |
| ELF Core | QEMU, `gcore` | Ja |
| Windows Crash Dump (`.dmp`) | DumpIt, WinDbg | Ja |
| Hiberfil.sys | Windows-Ruhezustand / Schnellstart | Ja |
| VMware State (`.vmss`, `.vmsn`) | VMware Workstation / ESXi | Ja |
| kdump / diskdump | `makedumpfile` | Ja |
| Raw / flat | Beliebiger Fallback | Ja |
Das Format wird aus den Dateiköpfen erkannt — keine Flags erforderlich.
---
## Was ist anders
Die nächsten Alternativen sind **Volatility 3** (Python, Plugin-Architektur), **MemProcFS** (C mit Rust-Bindings, hauptsächlich Windows), **Rekall** (Python, nicht mehr gewartet) und **MemNixFS** (C++, Linux-Dumps als Dateisystem gemountet). Der folgende Vergleich spiegelt den offiziellen Kern und das bekannte Plugin-Repository jedes Tools wider. MemNixFS zielt auf *Linux*-Images mit einer Dateisystem-UX ab, teilt also die Page-Cache-Dateiwiederherstellung von mem4n6, ist aber bei den Zeilen Windows-Self-Profiling und EDR-Bypass mit `n/a` versehen.
### Parität — mit ausgereiften Tools geteilte Fähigkeiten
| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Linux- + Windows-Kernel-Walker | ✅ | ✅ | vorrangig Windows | nur Linux | ✅ |
| Prozess-, Modul- und Netzwerk-Enumeration | ✅ | ✅ | ✅ | ✅ | ✅ |
| Erkennung injizierten Speichers | ✅ | ✅ | ✅ | ✅ | ✅ |
| ISF-Symbolpaket-kompatibel | ✅ | ✅ | — | ✅ | — |
| Läuft unter Linux / macOS | ✅ | ✅ | teilweise | Linux + Win | ✅ |
| Aktiv gewartet | ✅ | ✅ | ✅ | ✅ | — |
| Frei & Open Source | ✅ | ✅ | ✅ | keine Lizenz | ✅ |
### Fähigkeiten, die in den offiziellen Distributionen anderer Tools fehlen
| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Einzelne statische Binärdatei — kein Python, keine Laufzeitumgebung | ✅ | — | — | teilweise | — |
| Bibliotheks-API zur Einbettung in Rust-Tools | ✅ | — | ✅ | — | — |
| Verhaltensbasiertes Rootkit-Fingerprinting für ELF | ✅ | — | — | — | — |
| tmpfs-/ramfs-Dateiwiederherstellung | ✅ | — | — | ✅ | — |
| Erkennung dateiloser Ausführung über memfd | ✅ | — | — | — | — |
| Erkennung von Direct-Syscall-/EDR-Bypass | ✅ | plugin? | — | n/a | — |
| Erkennung von ETW-/AMSI-/DSE-Bypass | ✅ | plugin? | — | n/a | — |
| io_uring-/netfilter-/perf\_event-Missbrauch | ✅ | — | — | — | — |
| Container-Escape-Indikatoren | ✅ | — | — | — | — |
| DPAPI-Schlüssel + Chrome-Cookie-Extraktion | ✅ | plugin? | — | n/a | — |
| Shellbags-Spuren zu Ordnerzugriffen aus dem Speicher ‡ | ✅ | — | — | n/a | — |
| Framebuffer-Screenshot | ✅ | plugin? | — | — | — |
| Artefaktübergreifende ATT&CK-Korrelation | ✅ | — | — | — | — |
| Sichere Ausgabe — RFC 4180, Formel-Injektionsschutz, Bidi-Entfernung | ✅ | — | — | — | — |
> **`plugin?`** — Die Fähigkeit mag im Community-Ökosystem von Volatility 3 existieren, fehlt aber zum Zeitpunkt der Erstellung im offiziellen Kern und Plugin-Repository. Vor einer Schlussfolgerung verifizieren.
>
> **‡ Shellbags aus dem Speicher** — Volatility 2 stellte Shellbags aus dem RAM wieder her (das Community-Plugin `shellbags`, Kovar, später Lo); Volatility 3 hat es nie neu portiert, sodass die reine Speicher-Wiederherstellung von Shellbags beim Übergang vol2→vol3 zurückging. mem4n6 durchläuft `Shell\BagMRU` direkt in der In-Memory-Hive `UsrClass.dat`/`NTUSER.DAT` — das stellt die Fähigkeit aus der vol2-Ära für den Nur-RAM-Fall wieder her (keine Platte erfasst) oder bestätigt die On-Disk-Hive. Der übliche Weg, wenn die Platte *verfügbar* ist, besteht darin, das Image zu mounten und SBECmd / RegRipper auf der Hive-Datei auszuführen; der Speicher-Durchlauf fasst den zweistufigen Prozess „Hive dumpen, dann parsen“ zu einem Schritt zusammen. Die Validierung ist **Tier 2**: Ground Truth wurde mit `regipy` an der aus `citadeldc01.mem` extrahierten Hive abgeleitet — für den Szechuan-Fall existiert kein veröffentlichter Drittanbieter-Shellbag-Referenzschlüssel, daher ist dies ein selbst abgeleitetes Orakel (echtes Tool + echtes Image), kein Drittanbieter-Schlüssel.
---
## Vertrauen, aber prüfen
Ein Tool, das **nicht vertrauenswürdige, vom Angreifer kontrollierbare** Speicherabbilder parst, muss sich weigern zu lügen und sich weigern abzustürzen. mem4n6 ist für diesen Maßstab gebaut:
- **Panikfrei durch Lint bei feindseliger Eingabe.** Parsing-Pfade verbieten `unwrap`/`expect`/`panic!` und ungeprüfte Indizierung (`clippy::unwrap_used`/`expect_used` = deny); jede Längen-, Offset- und Zeiger-Lesung wird auf Grenzen geprüft und degradiert elegant — eine verschmierte Prozessliste gibt das zurück, was sie gefunden hat, und bricht nicht ab. (Builder-APIs geraten konstruktionsbedingt bei Programmierfehlern in Panik — einem fehlenden Pflichtfeld —, niemals bei Dump-Inhalten.)
- **Standardmäßig speichersicher.** `unsafe_code = "deny"` workspace-weit; das einzige `unsafe` sind begrenzte `memmap2`-Dateizuordnungen (der Dump, die Auslagerungsdatei und die Known-Good-Hash-Datenbank), jede einzeln begründet — daher das Badge *bounded (nur mmap)* statt *forbidden*.
- **Gegen ein unabhängiges Orakel validiert, nicht nur gegen unsere eigenen Testdaten.** Der Windows-Prozess-Walker wird gegen Volatility 3 auf einem echten 2-GB-Win10-Image abgeglichen — exakte Übereinstimmung bei jedem gemeinsamen Prozess, null Fehlalarme ([`docs/validation.md`](https://github.com/securityronin/memory-forensic/blob/HEAD/docs/validation.md)).
- **Sichere Ausgabe.** Jeder Kanal (Tabelle/CSV/JSON) wendet RFC-4180-Zitierung, einen Schutz gegen Formelinjektion in Tabellenkalkulationen sowie die Entfernung von Bidi-/Steuerzeichen an, bevor vom Angreifer kontrollierte Zeichenfolgen dein Terminal oder deine Pipeline erreichen.
---
## Bibliotheksnutzung```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()?);
}
issen — der Unterbefehl issen mem4n6 steuert die Speichererfassung und Triage-Berichterstattung direkt aus diesem Workspace.
Andrew Case und die Volatility Foundation, deren ISF-Format und Plugin-Architektur dieses Projekt symbolkompatibel ist.
Brendan Dolan-Gavitt, dessen Forschung zu DKOM und VAD-basierter Prozessversteckung die Walker zur Erkennung versteckter Prozesse beeinflusst hat.
Ulf Frisk / MemProcFS, dessen Modell „Dateisystem als Speicherschnittstelle" und das Design des forensischen Modus beeinflusst haben, wie diese Bibliothek wiederhergestellte Artefakte zugänglich macht.
jam1garner für binrw — deklaratives Parsen von Binärformaten, das die Formatebene sicher und lesbar macht.
S12 — der Artikel Kernel Dynamic Offset Resolution Using PDB Symbols, der die vollständige Kette dokumentierte: das Durchsuchen eines Dumps nach der ntoskrnl-PE, das Extrahieren der CodeView-PDB-GUID und das Abrufen der passenden PDB von msdl.microsoft.com zur Laufzeit. Diese Technik inspirierte direkt die AutoProfile-Implementierung in memf-symbols.
Alex Ionescu — Getting Physical With USB Type-C: Windows 10 RAM Forensics and UEFI Attacks (REcon Brussels 2017), in dem dokumentiert wurde, dass das HalpLowStub der HAL der undokumentierte PROCESSOR_START_BLOCK ist — der Anker im niedrigen physikalischen Speicher (per Signaturscan in 0x1000–0x100000 gefunden), der die Kernel-CR3/DTB und einen Kernel-VA-Hinweis trägt. Dies ist die Grundlage für find_low_stub und die headerlose Wiederherstellung von DTB und Kernelbasis in memf-symbols.
Microsoft Symbol Server (msdl.microsoft.com) für das Hosten öffentlicher PDB-Dateien für jeden Windows-Kernel-Build, die Upstream-Quelle, die die Symbolauflösung zur Laufzeit ohne vorab bereitgestellte Symboldateien ermöglicht.
Datenschutzrichtlinie · Nutzungsbedingungen · © 2026 Security Ronin Ltd.
| mem4n6 | Volatility 3 | MemProcFS | MemNixFS |
|---|
| Bereitstellung | Rust · eine einzelne statische Binärdatei | Python · Interpreter + Abhängigkeiten | C(+Rust) · Bibliotheken | C++ · Dateisystem-Mount |
| Windows-Selbstprofiling (Scan → PDB-GUID → Symbole) | ✅ | ✅ | ✅ | n/a — Linux-Dumps |
| Header-loses DTB über den Boot-Low-Stub + Kernel-Basis mit Seitengranularität | ✅ | selbstreferenzierende PML4 + Image-Scan | ✅ Low-Stub | n/a — Linux |
| Offline-/Air-Gapped-Symbolmodus | ✅ --offline | ISF-Paket oder Netzwerk | Symbole / Netzwerk | ✅ BTF-from-dump |
Panikfrei bei nicht vertrauenswürdigen Dumps (unsafe verboten; unwrap/expect auf Parsing-Pfaden verboten) | ✅ | — | — | — (C++) |
| Gegen Volatility 3 geprüft | ✅ (docs/validation.md) | — (die Referenz) | — | — |
| Crate | Zweck |
|---|
memf-format | Formaterkennung und Provider für physischen Speicher. Parser für LiME, AVML, ELF Core, Windows-Crash-Dump, hiberfil.sys, VMware-State, kdump und rohe Flat-Images. |
memf-core | Page-Table-Walking (x86_64 4-Ebenen/5-Ebenen, AArch64, x86 PAE/non-PAE), ObjectReader auf hoher Ebene für die Traversierung von Kernel-Strukturen, Pagefile-Zugriff, LZO-Dekomprimierung und Framebuffer→PNG-Screenshot-Kodierung (gepaart mit den Linux-EFI/VESA- und Windows-win32k-Framebuffer-Walkern). |
memf-linux | Linux-Kernel-Walker: task_struct-Prozessliste, Netzwerkverbindungen, Kernelmodule, geöffnete Dateien, eBPF-Programme, ftrace/IDT/Syscall-Hook-Erkennung, Namespace- und Cgroup-Aufzählung, Erkennung DKOM-verborgener Prozesse, Container-Escape-Indikatoren, ELF-Dynamiksymbol-Analyse und LD_PRELOAD-Rootkit-Verhaltens-Fingerprinting, Erkennung der globalen Verbreitung von Bibliotheken und ~45 weitere Walker. |
memf-windows | Windows-NT-Kernel-Walker: EPROCESS/ETHREAD-Aufzählung, DLL- und Treiberlisten, Handle-Tabellen, Netzwerk-Sockets, Pool-Tag-Scanning, Callback-Tabellen, SSDT, ETW, Zwischenablage, DNS-Cache, Kerberos-Tickets, DPAPI-Masterkey-Extraktion aus dem LSASS-g_MasterKeyCache, Erkennung Chrome-v10/v20-AES-GCM-verschlüsselter Cookies, BitLocker-Schlüssel, SAM/NTLM-Hashes, Erkennung injizierten Speichers und ~55 weitere Walker. |
memf-strings | String-Extraktion (ASCII, UTF-8, UTF-16LE) mit Regex-Klassifizierung in IoC-Kategorien: URLs, IP-Adressen, Domains, Registry-Schlüssel, Krypto-Wallet-Adressen, Privatschlüssel, Shell-Befehle. |
memf-symbols | Symbolauflösung aus ISF-JSON, BTF (Linux) und PDB-Dateien. Enthält AutoProfile — Windows-Kernel-Strukturauflösung ohne Konfiguration: durchsucht den Dump nach ntoskrnl, lädt die exakte PDB von msdl.microsoft.com herunter, parst sie und gibt einen SymbolResolver zurück. Keine Symboldatei erforderlich. |
memf-correlate | Artefaktübergreifende Korrelation mit MITRE-ATT&CK-Technik-Tagging, Prozessbaum-Rekonstruktion, Anomalie-Bewertung und Timeline-Erstellung. |
forensic-hashdb | Zero-FP-Hashdatenbanken: Known-Good-Abfrage über NSRL/CIRCL, Known-Bad-Abfrage über MalwareBazaar/VirusShare sowie eingebettete Hashes verwundbarer Windows-Treiber aus loldrivers.io. |