securityronin/memory-forensicPercorra qualquer dump de memória. Encontre o que está oculto. Forense de kernel Linux + Windows a partir de um único binário Rust estático — sem necessidade de Python.
-green.svg){kind=icon}
Um kit de ferramentas de forense de memória que cria perfis dos kernels do Windows por conta própria — e é verificado de forma cruzada, processo a processo, contra o Volatility 3.
mem4n6 lê todos os formatos de dump comuns (LiME, AVML, ELF core, dumps de crash do Windows, arquivos de hibernação, save-states do VMware, kdump, raw…) e percorre processos, threads, módulos, conexões de rede e memória injetada — a partir de um único binário estático que você compila uma vez e copia para qualquer lugar, com sem Python, sem runtime, sem catálogo de símbolos pré-carregado. No Windows, ele cria seu próprio perfil: localiza ntoskrnl na memória física, lê seu GUID PDB do registro CodeView, resolve o ISF correspondente do Volatility 3, recupera a base do kernel sob o KASLR moderno e reconstrói PsActiveProcessHead a partir da tabela de símbolos — a mesma cadeia de autoperfilamento usada pelo Volatility 3 e MemProcFS, reimplementada em Rust.
Como o padrão para uma ferramenta de evidência é a correção, o percorredor de processos é verificado de forma cruzada contra uma implementação de referência independente — Volatility 3 — em uma imagem real de 2 GB do Windows 10 (uma referência que concorda é uma forte evidência, não uma prova; os bytes brutos são a fonte da verdade):
windows.pslist em DESKTOP-SDN1RPT.mem | mem4n6 vs Volatility 3 |
|---|---|
| Processos coincidentes | 94 / 94 PIDs compartilhados — PID, PPID, nome e hora de criação exatos |
| Perdidos (vol3 encontrou, mem4n6 não) | 0 |
| Falsos positivos (mem4n6 encontrou, vol3 não) | 0 |
mem4n6 corresponde exatamente ao Volatility 3 — incluindo a recuperação de 11 processos órfãos causados por um smear de aquisição ao vivo por meio de uma varredura bidirecional de ActiveProcessLinks. Um segundo oráculo independente (MemProcFS) confirma um subconjunto limpo — sua process_list de 77 processos está totalmente contida no conjunto do mem4n6, com zero processos exclusivos do MemProcFS (detalhes). Consulte docs/validation.md para a análise diferencial completa e as etapas de reprodução.
Instale com cargo install mem4n6 ou baixe um binário estático pré-compilado na última versão — as compilações Linux são static-PIE (musl: copie para qualquer lugar, sem glibc), acompanhadas de macOS, Windows e um checksums.txt SHA-256.
Ou compile a partir do código-fonte (aproximadamente um comando):```bash git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic && cargo build --release ./target/release/mem4n6 --help
Essa compilação de desenvolvimento vincula a libc dinamicamente; para reproduzir localmente o binário totalmente estático da release, adicione o alvo 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
Symbol files are ISF JSON — os mesmos pacotes que o Volatility 3 usa, portanto um cache de símbolos existente funciona como está.
mem4n6 é, tanto quanto sabemos, a única implementação em Rust de toda a cadeia dump → kernel-scan → PDB-GUID → symbol-resolution → DTB. A linhagem da técnica — o servidor de símbolos do WinDbg, o pdbparse de Brendan Dolan-Gavitt, Rekall, Volatility 3 e o MemProcFS de Ulf Frisk — é bem estabelecida; o mem4n6 a reimplementa em clean-room e valida o resultado contra a referência. MemNixFS traz a mesma ideia de memória-como-filesystem para dumps Linux — montar-e-navegar, com símbolos derivados do próprio BTF do kernel quando não existe ISF; as células n/a acima marcam uma diferença de escopo (imagens Linux e uma UX de filesystem, vs o walker de CLI validado para Windows do mem4n6), não uma lacuna. A âncora boot low-stub / PROCESSOR_START_BLOCK segue o Getting Physical de Alex Ionescu na REcon 2017.
git clone https://github.com/SecurityRonin/memory-forensic.git cd memory-forensic cargo build --release ./target/release/mem4n6 --help
---
## Referência Rápida```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
Os arquivos de símbolos são ISF JSON, compatíveis com os pacotes de símbolos do Volatility 3.
mem4n6 check --symbols linux.json --hooks --idt --syscalls memdump.lime
Não foi fornecido conteúdo para tradução no campo "INPUT". Envie o texto do chunk 11 para que eu possa traduzi-lo.```
[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)
Três tipos de hook — tabela de syscalls, ftrace e LSM — todos resolvendo para o mesmo módulo do kernel. O cruzamento de referências com a lista de módulos confirma que ele não está no conjunto de confiáveis.
A correspondência por padrão de nome não detecta variantes de rootkit recompiladas ou renomeadas. A análise de símbolos dinâmicos do ELF as detecta independentemente do nome:```bash mem4n6 check --symbols linux.json --elf-hooks memdump.lime
No input content was provided to translate. Please supply the Markdown chunk.```
[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 examina cada biblioteca mapeada na memória do processo em busca de:
.rodata (por exemplo, UID:%d:, silly.txt) que sobrevivem à remoção de símbolos e a alterações de nomemem4n6 check --symbols ntkrnlmp.json --dpapi-keys memdump.dmp
mem4n6 check --symbols ntkrnlmp.json --browser-cookies memdump.dmp
I don't see any content to translate in the input. The chunk appears to be empty. Please provide the text for chunk 19 of 47.```
[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
Os walkers de credenciais do Windows cobrem:
g_MasterKeyCache no LSASS, extrai GUID + blob criptografado para cada chave-mestre em cachev10/v20 + nonce de 12 bytes); descriptografados quando o material da chave está disponívelmem4n6 framebuf --symbols ntkrnlmp.json --png screen.png memdump.dmp
Extrai o framebuffer de um dump de memória ativo ou de hibernação e o grava como PNG. Funciona tanto no Linux (walker `drm_framebuffer` do DRM/KMS) quanto no Windows (framebuffer de sessão via varredura de pool do `win32k`). Útil para capturar o estado da tela no momento da aquisição sem inicializar a imagem.
---
## Recuperar arquivos que nunca tocaram o disco
Atacantes que usam tmpfs ou `memfd_create(2)` não deixam artefatos no sistema de arquivos — o binário existe apenas na 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 content for chunk 25 is empty — no text was provided to translate. Please supply the chunk content and I'll translate it into Portuguese.``` [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)
A recuperação tmpfs percorre a tabela `vfsmount` do kernel e reconstrói o conteúdo dos inodes a partir das páginas do page-cache. A detecção de memfd percorre a tabela de descritores de arquivos abertos de cada processo e sinaliza inodes anônimos criados com `memfd_create(2)`.
---
## Detectar evasão de EDR e supressão de logs
Ferramentas ofensivas modernas aplicam patches na instrumentação de segurança do Windows em memória para evadir a detecção sem tocar no 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
Nenhum conteúdo Markdown foi fornecido.``` [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 de interfaces inovadoras do kernel Linux
Além dos clássicos hooks de syscall, rootkits modernos abusam de subsistemas de kernel mais recentes. O `memory-forensic` cobre todos os três:```bash
mem4n6 check --symbols linux.json --io-uring --netfilter --perf-event memdump.lime
[No input text provided. Please paste the Markdown content you wish to have translated.]``` [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)
---
## Indicadores de escape de container```bash
mem4n6 check --symbols linux.json --container-escape memdump.lime
A flag --watch
No entanto, esta flag pode não funcionar como esperado devido às opções --watch e --max-memory, que podem impactar o desempenho. Use --no-serve e --no-watch para desativar operações desnecessárias.
Para gerar a saída final, execute:
python -m nbconvert --to html --output-dir output notebook.ipynb
Isso gera arquivos HTML reduzidos sem células de código. Os arquivos de saída são colocados no diretório output/. Se necessário, eles podem ser revisados manualmente com um visualizador de Markdown.
Percorre os namespaces de user, mount, PID, net e cgroup para cada processo e sinaliza processos que deveriam estar isolados, mas compartilham namespaces de nível de host — a assinatura estrutural de uma fuga de contêiner, independentemente de como foi alcançada.
---
## Correlação ATT&CK entre artefatos
`memf-correlate` junta os resultados de todos os walkers em uma linha do tempo, pontua anomalias por gravidade e mapeia cada uma para as técnicas do MITRE ATT&CK sem executar os walkers um de cada vez:```bash
mem4n6 correlate --symbols ntkrnlmp.json --output json memdump.dmp > findings.json
I don't see any content to translate — the input after "INPUT:" is empty. Please provide the Markdown chunk text.```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 } }
Os resultados dos walkers de processo, rede, módulo, hook e credenciais são correlacionados por processo e tempo antes da pontuação — produzindo descobertas com tags ATT&CK em vez de saída por walker que um analista precisa unir manualmente.
---
## Formatos de Memória Suportados
| Formato | Origem | Detecção automática |
|---|---|---|
| LiME (`.lime`) | Módulo do kernel Linux | Sim |
| AVML v2 | Azure AVML | Sim |
| ELF Core | QEMU, `gcore` | Sim |
| Windows Crash Dump (`.dmp`) | DumpIt, WinDbg | Sim |
| Hiberfil.sys | Hibernação do Windows / inicialização rápida | Sim |
| VMware State (`.vmss`, `.vmsn`) | VMware Workstation / ESXi | Sim |
| kdump / diskdump | `makedumpfile` | Sim |
| Raw / flat | Qualquer fallback | Sim |
O formato é detectado a partir dos cabeçalhos dos arquivos — nenhuma flag é necessária.
---
## O Que é Diferente
As alternativas mais próximas são **Volatility 3** (Python, arquitetura de plugins), **MemProcFS** (C com bindings para Rust, principalmente Windows), **Rekall** (Python, sem manutenção) e **MemNixFS** (C++, despejos Linux montados como um sistema de arquivos). A comparação abaixo reflete o núcleo oficial de cada ferramenta e o repositório de plugins conhecido. O MemNixFS visa imagens *Linux* com uma UX de sistema de arquivos, portanto compartilha a recuperação de arquivos do page-cache do mem4n6, mas é `n/a` nas linhas relacionadas a auto-perfilagem no Windows e evasão de EDR.
### Paridade — capacidades compartilhadas com ferramentas maduras
| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Walkers de kernel Linux + Windows | ✅ | ✅ | Primeiro Windows | Somente Linux | ✅ |
| Enumeração de processos, módulos, rede | ✅ | ✅ | ✅ | ✅ | ✅ |
| Detecção de memória injetada | ✅ | ✅ | ✅ | ✅ | ✅ |
| Compatível com pacote de símbolos ISF | ✅ | ✅ | — | ✅ | — |
| Executa em Linux / macOS | ✅ | ✅ | parcial | Linux + Win | ✅ |
| Mantido ativamente | ✅ | ✅ | ✅ | ✅ | — |
| Gratuito e open source | ✅ | ✅ | ✅ | sem licença | ✅ |
### Capacidades ausentes das distribuições oficiais de outras ferramentas
| | memory-forensic | Volatility 3 | MemProcFS | MemNixFS | Rekall |
|--|:-:|:-:|:-:|:-:|:-:|
| Binário estático único — sem Python, sem runtime | ✅ | — | — | parcial | — |
| API de biblioteca para incorporação em ferramentas Rust | ✅ | — | ✅ | — | — |
| Fingerprinting comportamental de rootkits ELF | ✅ | — | — | — | — |
| Recuperação de arquivos tmpfs / ramfs | ✅ | — | — | ✅ | — |
| Detecção de execução sem arquivo memfd | ✅ | — | — | — | — |
| Detecção de syscall direta / evasão de EDR | ✅ | plugin? | — | n/a | — |
| Detecção de evasão de ETW / AMSI / DSE | ✅ | plugin? | — | n/a | — |
| Abuso de io_uring / netfilter / perf\_event | ✅ | — | — | — | — |
| Indicadores de escape de contêiner | ✅ | — | — | — | — |
| Chaves DPAPI + extração de cookies do Chrome | ✅ | plugin? | — | n/a | — |
| Evidências de acesso a pastas Shellbags a partir da memória ‡ | ✅ | — | — | n/a | — |
| Captura de tela do framebuffer | ✅ | plugin? | — | — | — |
| Correlação entre artefatos ATT&CK | ✅ | — | — | — | — |
| Saída segura — RFC 4180, proteção contra injeção de fórmulas, remoção de bidi | ✅ | — | — | — | — |
> **`plugin?`** — A capacidade pode existir no ecossistema comunitário do Volatility 3, mas está ausente do núcleo oficial e do repositório de plugins no momento da redação. Verifique antes de concluir.
>
> **‡ Shellbags a partir da memória** — O Volatility 2 recuperava shellbags da RAM (o plugin `shellbags` da comunidade, Kovar e depois Lo); o Volatility 3 nunca o re-portou, então a recuperação de shellbags apenas pela memória regrediu na transição vol2→vol3. O mem4n6 percorre `Shell\BagMRU` diretamente no hive `UsrClass.dat`/`NTUSER.DAT` em memória — restaurando a capacidade da era vol2 para o caso de apenas RAM (sem disco adquirido), ou para corroborar o hive no disco. O caminho usual quando o disco *está* disponível é montar a imagem e executar SBECmd / RegRipper no arquivo de hive; a varredura de memória reduz o processo de duas etapas (despejar o hive e depois parsear) a uma única etapa. A validação é **nível 2**: ground truth derivado com `regipy` no hive extraído de `citadeldc01.mem` — não existe chave de respostas de shellbags publicada por terceiros para o caso Szechuan, portanto este é um oráculo autoderivado (ferramenta real + imagem real), não uma chave de terceiros.
---
## Confie, mas verifique
Uma ferramenta que parseia imagens de memória **não confiáveis e controláveis por atacantes** deve se recusar a mentir e se recusar a travar. O mem4n6 é construído para esse padrão:
- **Livre de pânico por lint em entrada hostil.** Os caminhos de parsing negam `unwrap`/`expect`/`panic!` e indexação sem verificação (`clippy::unwrap_used`/`expect_used` = deny); cada leitura de comprimento, deslocamento e ponteiro é verificada em limites e degrada graciosamente — uma lista de processos borrada retorna o que encontrou, não aborta. (APIs de construção entram em pânico em erro de programador — um campo obrigatório ausente — por construção, nunca em conteúdo do despejo.)
- **Seguro em relação à memória por padrão.** `unsafe_code = "deny"` em todo o workspace; o único `unsafe` é limitado a mapeamentos de arquivo `memmap2` (o despejo, pagefile e o banco de hashes conhecidos como bons), cada um justificado individualmente — daí o selo *bounded (mmap only)* em vez de *forbidden*.
- **Validado contra um oráculo independente, não apenas nossos próprios dados de teste.** O walker de processos do Windows é comparado com o Volatility 3 em uma imagem real de 2 GB do Win10 — concordância exata em todos os processos compartilhados, zero falsos positivos ([`docs/validation.md`](https://github.com/securityronin/memory-forensic/blob/HEAD/docs/validation.md)).
- **Saída segura.** Cada canal (tabela/CSV/JSON) aplica aspas de acordo com o RFC 4180, proteção contra injeção de fórmulas em planilhas e remoção de caracteres bidi/controle antes que strings controladas por atacantes cheguem ao seu terminal ou pipeline.
---
## Uso como Biblioteca```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 — o subcomando issen mem4n6 conduz a aquisição de memória e os relatórios de triagem diretamente a partir deste workspace.
Andrew Case e a Volatility Foundation, cujo formato ISF e arquitetura de plugins são compatíveis em nível de símbolos com este projeto.
Brendan Dolan-Gavitt cuja pesquisa sobre DKOM e ocultação de processos baseada em VAD informou os walkers de detecção de processos ocultos.
Ulf Frisk / MemProcFS cujo modelo de filesystem-como-interface-de-memória e o design do modo forense influenciaram a forma como esta biblioteca expõe os artefactos recuperados.
jam1garner pelo binrw — parsing declarativo de formatos binários que torna a camada de formatos segura e legível.
S12 — o artigo Kernel Dynamic Offset Resolution Using PDB Symbols, que documentou toda a cadeia de varrimento de um dump à procura do PE ntoskrnl, extração do GUID CodeView do PDB e obtenção do PDB correspondente a partir de msdl.microsoft.com em tempo de execução. Esta técnica inspirou diretamente a implementação do AutoProfile em memf-symbols.
Alex Ionescu — Getting Physical With USB Type-C: Windows 10 RAM Forensics and UEFI Attacks (REcon Bruxelas 2017), que documentou que o HalpLowStub da HAL é o PROCESSOR_START_BLOCK não documentado — a âncora de memória física baixa (detetada por assinatura em 0x1000–0x100000) que contém o CR3/DTB do kernel e uma dica de VA do kernel. Esta é a base para o find_low_stub e para a recuperação do DTB / base do kernel sem cabeçalho em memf-symbols.
Microsoft Symbol Server (msdl.microsoft.com) por alojar os ficheiros PDB públicos de todas as builds do kernel Windows, o upstream que torna possível a resolução de símbolos em tempo de execução sem ficheiros de símbolos pré-encenados.
Política de Privacidade · Termos de Serviço · © 2026 Security Ronin Ltd.
| mem4n6 | Volatility 3 | MemProcFS | MemNixFS |
|---|
| Deploy | Rust · binário estático único | Python · interpretador + dependências | C(+Rust) · bibliotecas | C++ · mount de filesystem |
| Auto-perfilamento do Windows (scan → PDB GUID → symbols) | ✅ | ✅ | ✅ | n/a — dumps Linux |
| DTB sem cabeçalho via boot low stub + base de kernel em granularidade de página | ✅ | self-ref PML4 + varredura de imagem | ✅ low stub | n/a — Linux |
| Modo de símbolos offline / air-gapped | ✅ --offline | pacote ISF ou rede | symbols / rede | ✅ BTF do dump |
Sem panics em dumps não confiáveis (negação de unsafe; unwrap/expect negados nos caminhos de parsing) | ✅ | — | — | — (C++) |
| Verificação cruzada contra o Volatility 3 | ✅ (docs/validation.md) | — (a referência) | — | — |
| Crate | Propósito |
|---|
memf-format | Detecção de formato e provedores de memória física. Parsers para LiME, AVML, ELF Core, Windows Crash Dump, hiberfil.sys, VMware state, kdump e imagens planas brutas. |
memf-core | Caminhamento de tabelas de páginas (x86_64 4 níveis/5 níveis, AArch64, x86 PAE/não-PAE), ObjectReader de alto nível para travessia de estruturas do kernel, acesso a pagefile, descompressão LZO e codificação de capturas de tela framebuffer→PNG (emparelhado com os walkers de framebuffer Linux EFI/VESA e Windows win32k). |
memf-linux | Walkers do kernel Linux: lista de processos task_struct, conexões de rede, módulos do kernel, arquivos abertos, programas eBPF, detecção de hooks em ftrace/IDT/syscall, enumeração de namespaces e cgroups, detecção de processos ocultos via DKOM, indicadores de escape de contêiner, análise de símbolos dinâmicos ELF e fingerprinting comportamental de rootkits LD_PRELOAD, detecção de prevalência global de bibliotecas e ~45 walkers adicionais. |
memf-windows | Walkers do kernel do Windows NT: enumeração de EPROCESS/ETHREAD, listas de DLLs e drivers, tabelas de handles, soquetes de rede, varredura de pool tags, tabelas de callbacks, SSDT, ETW, área de transferência, cache de DNS, tickets Kerberos, extração de chaves mestras DPAPI do g_MasterKeyCache do LSASS, detecção de cookies criptografados com AES-GCM do Chrome v10/v20, chaves BitLocker, hashes SAM/NTLM, detecção de memória injetada e ~55 walkers adicionais. |
memf-strings | Extração de strings (ASCII, UTF-8, UTF-16LE) com classificação por regex em categorias de IoC: URLs, endereços IP, domínios, chaves de registro, endereços de carteiras de criptomoedas, chaves privadas, comandos de shell. |
memf-symbols | Resolução de símbolos a partir de arquivos ISF JSON, BTF (Linux) e PDB. Inclui AutoProfile — resolução de estruturas do kernel do Windows zero-config: verifica o dump em busca de ntoskrnl, busca o PDB exato em msdl.microsoft.com, analisa-o e retorna um SymbolResolver. Nenhum arquivo de símbolos é necessário. |
memf-correlate | Correlação entre artefatos com marcação de técnicas MITRE ATT&CK, reconstrução da árvore de processos, pontuação de anomalias e geração de linha do tempo. |
forensic-hashdb | Bancos de dados de hashes Zero-FP: consulta de hashes conhecidos como bons do NSRL/CIRCL, consulta de hashes conhecidos como ruins do MalwareBazaar/VirusShare e hashes embutidos de drivers do Windows vulneráveis do loldrivers.io. |