Parcourez n'importe quel dump mémoire. Trouvez ce qui est caché. Forensique du noyau Linux + Windows à partir d'un seul binaire Rust statique — aucun Python requis.
-green.svg){kind=icon}
Une boîte à outils de forensique mémoire qui profile elle-même les noyaux Windows — et qui est recoupée, processus par processus, avec Volatility 3.
mem4n6 lit tous les formats de dump courants (LiME, AVML, core ELF, crash dumps Windows, fichiers d'hibernation, save-states VMware, kdump, raw…) et parcourt les processus, threads, modules, connexions réseau et mémoire injectée — depuis un seul binaire statique que vous compilez une fois et copiez n'importe où, avec pas de Python, pas d'environnement d'exécution, pas de catalogue de symboles pré-étagé. Sur Windows, il construit son propre profil : il localise ntoskrnl en mémoire physique, lit son GUID PDB depuis l'enregistrement CodeView, résout le ISF Volatility-3 correspondant, retrouve la base du noyau sous le KASLR moderne, et reconstruit PsActiveProcessHead à partir de la table des symboles — la même chaîne d'auto-profiling que Volatility 3 et MemProcFS utilisent, réimplémentée en Rust.
Parce que le niveau d'exigence pour un outil de preuve est la justesse, le parcours des processus est recoupé avec une implémentation de référence indépendante — Volatility 3 — sur une image Windows 10 réelle de 2 Go (un accord de référence est une preuve solide, pas une démonstration ; les octets bruts sont la vérité de terrain) :
windows.pslist sur DESKTOP-SDN1RPT.mem | mem4n6 vs Volatility 3 |
|---|---|
| Processus correspondants | 94 / 94 PID partagés — PID, PPID, nom, heure de création exacts |
| Manqués (vol3 trouvés, pas mem4n6) | 0 |
| Faux positifs (mem4n6 trouvés, pas vol3) | 0 |
mem4n6 correspond exactement à Volatility 3 — y compris la récupération de 11 processus orphelins dus à un étalement d'acquisition à chaud, via un parcours bidirectionnel de ActiveProcessLinks. Un second oracle indépendant (MemProcFS) confirme un sous-ensemble propre — son process_list de 77 processus est entièrement contenu dans l'ensemble de mem4n6, avec zéro processus exclusif à MemProcFS (détails). Voir docs/validation.md pour le différentiel complet et les étapes de reproduction.
Installez avec cargo install mem4n6, ou récupérez un binaire statique précompilé depuis la dernière version — les builds Linux sont en statique-PIE (musl : copie n'importe où, pas de glibc), avec macOS, Windows, et un checksums.txt SHA-256 à côté.
Ou compilez depuis les sources (~une commande) :```bash git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic && cargo build --release ./target/release/mem4n6 --help
Cette build de développement lie libc dynamiquement ; pour reproduire localement le binaire entièrement statique de la release, ajoutez la cible 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
Les fichiers de symboles sont au format JSON ISF — les mêmes packs qu'utilise Volatility 3, donc un cache de symboles existant fonctionne tel quel.
mem4n6 est, à notre connaissance, la seule implémentation Rust de la chaîne complète dump → scan du noyau → PDB-GUID → résolution de symboles → DTB. La lignée technique — le serveur de symboles de WinDbg, pdbparse de Brendan Dolan-Gavitt, Rekall, Volatility 3, et MemProcFS d'Ulf Frisk — est bien établie ; mem4n6 la réimplémente en clean-room et valide le résultat par rapport à la référence. MemNixFS apporte cette même idée de mémoire comme système de fichiers aux dumps Linux — montage et parcours, avec des symboles dérivés du BTF propre au noyau lorsqu'aucun ISF n'existe ; les cellules n/a ci-dessus marquent une différence de périmètre (images Linux et une UX de système de fichiers, contre le walker CLI de mem4n6 validé sous Windows), pas une lacune. Le point d'ancrage boot low-stub / PROCESSOR_START_BLOCK s'appuie sur le Getting Physical d'Alex Ionescu à la REcon 2017.
git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic cargo build --release ./target/release/mem4n6 --help
---
## Référence rapide```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
Les fichiers de symboles sont au format ISF JSON, compatibles avec les packs de symboles Volatility 3.
mem4n6 check --symbols linux.json --hooks --idt --syscalls memdump.lime
Le contenu de ce chunk est vide — rien à traduire.```
[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)
Trois types de hooks — table des appels système, ftrace et LSM — aboutissant tous au même module kernel. La mise en correspondance avec la liste des modules confirme qu'il ne se trouve pas dans l'ensemble connu comme fiable.
La correspondance par motif de noms ne détecte pas les variantes de rootkits recompilées ou renommées. L'analyse des symboles dynamiques ELF les détecte indépendamment du nom :```bash mem4n6 check --symbols linux.json --elf-hooks memdump.lime
I don't see any content to translate in the input you've provided — the chunk appears to be empty. Please supply the actual Markdown text for chunk 15 and I'll translate it into French following all the specified rules.```
[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 analyse chaque bibliothèque mappée dans la mémoire des processus pour :
.rodata (p. ex. UID:%d:, silly.txt) qui survivent à la suppression des symboles et aux changements de nomsmem4n6 check --symbols ntkrnlmp.json --dpapi-keys memdump.dmp
mem4n6 check --symbols ntkrnlmp.json --browser-cookies memdump.dmp
Les **identifiants** sont :
| Service | URL | Nom d'utilisateur | Mot de passe |
|---------|-----|----------|----------|
| Jenkins | `https://jenkins.example.com` | `admin` | `admin123` |```
[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 walkers cover:
g_MasterKeyCache dans LSASS, extrait le GUID + le blob chiffré pour chaque clé principale mise en cachev10/v20 + nonce de 12 octets) ; déchiffrés lorsque le matériel de clé est disponiblemem4n6 framebuf --symbols ntkrnlmp.json --png screen.png memdump.dmp
Extrait le framebuffer d'un dump mémoire en direct ou en hibernation et l'écrit au format PNG. Fonctionne à la fois sur Linux (parcours `drm_framebuffer` DRM/KMS) et sur Windows (framebuffer de session via l'analyse du pool `win32k`). Utile pour capturer l'état de l'écran au moment de l'acquisition sans démarrer l'image.
---
## Récupérer les fichiers qui n'ont jamais touché le disque
Les attaquants utilisant tmpfs ou `memfd_create(2)` ne laissent aucun artefact sur le système de fichiers — le binaire n'existe qu'en 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
The input chunk appears to be empty. No content was provided to translate. Please supply the Markdown text for chunk 25 of 47.``` [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)
La récupération tmpfs parcourt la table `vfsmount` du noyau et reconstruit le contenu des inodes à partir des pages du cache de pages. La détection de memfd parcourt la table des descripteurs de fichiers ouverts de chaque processus et signale les inodes anonymes créés avec `memfd_create(2)`.
---
## Détecter l'évasion EDR et la suppression de journaux
Les outils offensifs modernes modifient en mémoire l'instrumentation de sécurité de Windows pour échapper à la détection sans toucher au disque.```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)
---
## Abus des nouvelles interfaces du noyau Linux
Au-delà des hooks d'appels système classiques, les rootkits modernes abusent de sous-systèmes du noyau plus récents. `memory-forensic` couvre les trois :```bash
mem4n6 check --symbols linux.json --io-uring --netfilter --perf-event memdump.lime
Aucun contenu source n'a été fourni dans l'entrée.``` [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)
---
## Indicateurs d'évasion de conteneur```bash
mem4n6 check --symbols linux.json --container-escape memdump.lime
[No input text provided to translate.]``` [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, et cgroup namespaces pour chaque processus et signale les processus qui devraient être isolés mais partagent des namespaces au niveau de l'hôte — la signature structurelle d'une évasion de conteneur, quelle que soit la manière dont elle a été réalisée.
---
## Corrélation ATT&CK inter-artefacts
`memf-correlate` regroupe les résultats de tous les walkers dans une chronologie, évalue les anomalies selon leur sévérité, et les associe à des techniques MITRE ATT&CK sans exécuter les walkers un par un :```bash
mem4n6 correlate --symbols ntkrnlmp.json --output json memdump.dmp > findings.json
The input content for chunk 41 is empty — no text was provided to translate. Please supply the chunk content, and I will translate it into French following the chunk-specific rules.```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 } }
Les résultats des walkers de processus, de réseau, de modules, de hooks et d’identifiants sont corrélés par processus et par heure avant la notation — produisant des constats étiquetés ATT&CK plutôt qu’une sortie par walker que l’analyste doit joindre manuellement.
---
## Formats mémoire pris en charge
| Format | Source | Détection automatique |
|---|---|---|
| LiME (`.lime`) | Module noyau Linux | Oui |
| AVML v2 | Azure AVML | Oui |
| ELF Core | QEMU, `gcore` | Oui |
| Windows Crash Dump (`.dmp`) | DumpIt, WinDbg | Oui |
| Hiberfil.sys | Hibernation Windows / démarrage rapide | Oui |
| VMware State (`.vmss`, `.vmsn`) | VMware Workstation / ESXi | Oui |
| kdump / diskdump | `makedumpfile` | Oui |
| Raw / flat | Tout repli | Oui |
Le format est détecté à partir des en-têtes de fichier — aucune option requise.
---
## Ce qui est différent
Les alternatives les plus proches sont **Volatility 3** (Python, architecture de plugins), **MemProcFS** (C avec liaisons Rust, principalement Windows), **Rekall** (Python, non maintenu) et **MemNixFS** (C++, dumps Linux montés comme système de fichiers). La comparaison ci-dessous reflète le noyau officiel de chaque outil et son dépôt de plugins connu. MemNixFS cible les images *Linux* avec une UX de système de fichiers, il partage donc la récupération de fichiers du cache de pages de mem4n6, mais il est `n/a` sur les lignes d’auto-profiling Windows et de contournement d’EDR.
### Parité — capacités partagées avec les outils matures
| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Walkers de noyau Linux + Windows | ✅ | ✅ | Windows d’abord | Linux uniquement | ✅ |
| Énumération des processus, modules, réseau | ✅ | ✅ | ✅ | ✅ | ✅ |
| Détection de mémoire injectée | ✅ | ✅ | ✅ | ✅ | ✅ |
| Compatible pack de symboles ISF | ✅ | ✅ | — | ✅ | — |
| Fonctionne sous Linux / macOS | ✅ | ✅ | partiel | Linux + Win | ✅ |
| Maintenu activement | ✅ | ✅ | ✅ | ✅ | — |
| Gratuit et open source | ✅ | ✅ | ✅ | sans licence | ✅ |
### Capacités absentes des distributions officielles des autres outils
| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Binaire statique unique — pas de Python, pas de runtime | ✅ | — | — | partiel | — |
| API de bibliothèque pour l’intégration dans des outils Rust | ✅ | — | ✅ | — | — |
| Empreinte comportementale des rootkits ELF | ✅ | — | — | — | — |
| Récupération de fichiers tmpfs / ramfs | ✅ | — | — | ✅ | — |
| Détection d’exécution fileless memfd | ✅ | — | — | — | — |
| Détection des syscalls directs / contournement EDR | ✅ | plugin? | — | n/a | — |
| Détection de contournement ETW / AMSI / DSE | ✅ | plugin? | — | n/a | — |
| Abus d’io_uring / netfilter / perf\_event | ✅ | — | — | — | — |
| Indicateurs d’évasion de conteneur | ✅ | — | — | — | — |
| Extraction des clés DPAPI + cookies Chrome | ✅ | plugin? | — | n/a | — |
| Preuve d’accès aux dossiers Shellbags depuis la mémoire ‡ | ✅ | — | — | n/a | — |
| Capture d’écran du framebuffer | ✅ | plugin? | — | — | — |
| Corrélation ATT&CK inter-artefacts | ✅ | — | — | — | — |
| Sortie sûre — RFC 4180, garde anti-injection de formules, suppression bidi | ✅ | — | — | — | — |
> **`plugin?`** — La capacité peut exister dans l’écosystème communautaire de Volatility 3, mais elle est absente du noyau officiel et du dépôt de plugins au moment de la rédaction. Vérifiez avant de conclure.
>
> **‡ Shellbags depuis la mémoire** — Volatility 2 récupérait les shellbags depuis la RAM (le plugin communautaire `shellbags`, Kovar puis Lo) ; Volatility 3 ne l’a jamais re-porté, si bien que la récupération des shellbags en mémoire seule a régressé lors de la transition vol2→vol3. mem4n6 parcourt `Shell\BagMRU` directement dans la ruche mémoire `UsrClass.dat`/`NTUSER.DAT` — rétablissant la capacité de l’ère vol2 pour le cas RAM seule (aucun disque acquis), ou pour corroborer la ruche sur disque. La voie habituelle lorsque le disque *est* disponible consiste à monter l’image et à exécuter SBECmd / RegRipper sur la ruche ; le parcours mémoire réduit en une seule étape le processus en deux temps « extraire la ruche puis l’analyser ». La validation est de **niveau 2** : la vérité terrain est dérivée avec `regipy` sur la ruche extraite de `citadeldc01.mem` — il n’existe aucune clé de réponse shellbag tierce publiée pour le cas Szechuan, il s’agit donc d’un oracle auto-dérivé (outil réel + image réelle), et non d’une clé tierce.
---
## Faire confiance, mais vérifier
Un outil qui analyse des images mémoire **non fiables et contrôlables par un attaquant** doit refuser de mentir et refuser de planter. mem4n6 est conçu pour atteindre ce niveau :
- **Sans panique grâce au lint sur entrée hostile.** Les chemins d’analyse interdisent `unwrap`/`expect`/`panic!` et l’indexation non contrôlée (`clippy::unwrap_used`/`expect_used` = deny) ; chaque lecture de longueur, d’offset et de pointeur est vérifiée aux limites et se dégrade proprement — une liste de processus incohérente renvoie ce qu’elle a trouvé, elle n’avorte pas. (Les API de construction paniquent en cas d’erreur de programmation — un champ obligatoire manquant — par construction, jamais sur le contenu du dump.)
- **Sûreté mémoire par défaut.** `unsafe_code = "deny"` à l’échelle du workspace ; la seule `unsafe` est limitée aux mappages de fichiers `memmap2` (le dump, le fichier d’échange et la base de hachages connus), chacun étant justifié individuellement — d’où le badge *limitée (mmap uniquement)* plutôt que *interdit*.
- **Validé contre un oracle indépendant, pas seulement nos propres fixtures.** Le walker de processus Windows est comparé à Volatility 3 sur une image Win10 réelle de 2 Go — accord exact sur chaque processus partagé, zéro faux positif ([`docs/validation.md`](https://github.com/securityronin/memory-forensic/blob/HEAD/docs/validation.md)).
- **Sortie sûre.** Chaque canal (tableau/CSV/JSON) applique les guillemets RFC 4180, une protection contre l’injection de formules dans les tableurs, et la suppression des caractères bidi/de contrôle avant que des chaînes contrôlées par un attaquant n’atteignent votre terminal ou votre pipeline.
---
## Utilisation de la bibliothèque```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 — la sous-commande issen mem4n6 pilote l'acquisition mémoire et la génération de rapports de triage directement depuis cet espace de travail.
Andrew Case et la Fondation Volatility dont le format ISF et l'architecture de plugins sont compatibles au niveau symbolique avec ce projet.
Brendan Dolan-Gavitt dont les recherches sur le DKOM et le masquage de processus basé sur la VAD ont inspiré les walkers de détection de processus cachés.
Ulf Frisk / MemProcFS dont le modèle de système de fichiers comme interface mémoire et la conception du mode forensique ont influencé la manière dont cette bibliothèque présente les artefacts récupérés.
jam1garner pour binrw — l'analyse déclarative de formats binaires qui rend la couche de format sûre et lisible.
S12 — l'article Kernel Dynamic Offset Resolution Using PDB Symbols qui a documenté la chaîne complète consistant à analyser un dump à la recherche du PE ntoskrnl, à extraire le GUID CodeView du PDB, puis à récupérer le PDB correspondant depuis msdl.microsoft.com à l'exécution. Cette technique a directement inspiré l'implémentation AutoProfile dans memf-symbols.
Alex Ionescu — Getting Physical With USB Type-C: Windows 10 RAM Forensics and UEFI Attacks (REcon Bruxelles 2017), qui a documenté que HalpLowStub du HAL est le PROCESSOR_START_BLOCK non documenté — l'ancre mémoire physique basse (recherchée par signature dans 0x1000–0x100000) portant le CR3/DTB du noyau et un indice d'adresse virtuelle du noyau. C'est la base de find_low_stub et de la récupération du DTB sans en-tête et de la base du noyau dans memf-symbols.
Serveur de symboles Microsoft (msdl.microsoft.com) pour héberger les fichiers PDB publics de chaque build du noyau Windows, la source en amont qui rend possible la résolution de symboles à l'exécution sans fichiers de symboles pré-stagés.
Politique de confidentialité · Conditions d'utilisation · © 2026 Security Ronin Ltd.
| mem4n6 | Volatility 3 | MemProcFS | MemNixFS |
|---|
| Déploiement | Rust · binaire statique unique | Python · interpréteur + dépendances | C(+Rust) · bibliothèques | C++ · montage de système de fichiers |
| Auto-profilage Windows (scan → GUID PDB → symboles) | ✅ | ✅ | ✅ | n/a — dumps Linux |
| DTB sans en-tête via le boot low stub + base du noyau à granularité de page | ✅ | PML4 auto-référencé + analyse d'image | ✅ low stub | n/a — Linux |
| Mode symboles hors ligne / air-gapped | ✅ --offline | pack ISF ou réseau | symboles / réseau | ✅ BTF-from-dump |
Sans panique sur les dumps non fiables (unsafe interdit; unwrap/expect interdits sur les chemins de parsing) | ✅ | — | — | — (C++) |
| Recoupé avec Volatility 3 | ✅ (docs/validation.md) | — (la référence) | — | — |
| Crate | Description |
|---|
memf-format | Détection de format et fournisseurs de mémoire physique. Analyseurs pour LiME, AVML, ELF Core, Windows Crash Dump, hiberfil.sys, état VMware, kdump et images brutes plates. |
memf-core | Parcours des tables de pages (x86_64 4/5 niveaux, AArch64, x86 PAE/non-PAE), ObjectReader de haut niveau pour le parcours des structures du noyau, accès au pagefile, décompression LZO, et encodage de captures d'écran framebuffer→PNG (associé aux parcours de framebuffer Linux EFI/VESA et Windows win32k). |
memf-linux | Parcours du noyau Linux : liste des processus task_struct, connexions réseau, modules du noyau, fichiers ouverts, programmes eBPF, détection de hooks ftrace/IDT/syscall, énumération des espaces de noms et des cgroups, détection des processus cachés par DKOM, indicateurs d'évasion de conteneur, analyse des symboles dynamiques ELF et empreinte comportementale des rootkits LD_PRELOAD, détection de la prévalence globale des bibliothèques, et environ 45 parcours supplémentaires. |
memf-windows | Parcours du noyau Windows NT : énumération EPROCESS/ETHREAD, listes des DLL et des pilotes, tables de handles, sockets réseau, analyse des balises de pool, tables de callbacks, SSDT, ETW, presse-papiers, cache DNS, tickets Kerberos, extraction des clés maîtresses DPAPI depuis g_MasterKeyCache de LSASS, détection des cookies chiffrés AES-GCM de Chrome v10/v20, clés BitLocker, hachages SAM/NTLM, détection de mémoire injectée, et environ 55 parcours supplémentaires. |
memf-strings | Extraction de chaînes (ASCII, UTF-8, UTF-16LE) avec classification par regex en catégories d'IoC : URLs, adresses IP, domaines, clés de registre, adresses de portefeuilles crypto, clés privées, commandes shell. |
memf-symbols | Résolution de symboles à partir de fichiers ISF JSON, BTF (Linux) et PDB. Inclut AutoProfile — résolution sans configuration des structures du noyau Windows : analyse le dump pour trouver ntoskrnl, récupère le PDB exact depuis msdl.microsoft.com, le parse et renvoie un SymbolResolver. Aucun fichier de symboles requis. |
memf-correlate | Corrélation inter-artefacts avec étiquetage des techniques MITRE ATT&CK, reconstruction de l'arborescence des processus, score d'anomalie et génération de chronologie. |
forensic-hashdb | Bases de données de hachages sans faux positif : recherche de fichiers sains NSRL/CIRCL, recherche de fichiers malveillants MalwareBazaar/VirusShare, et hachages intégrés des pilotes Windows vulnérables de loldrivers.io. |