vol-rs

Uma adaptação do framework de forense de memória Volatility 3 de Python para Rust. Ele lê as mesmas imagens de memória, executa os mesmos plugins com as mesmas opções e imprime a mesma saída, byte por byte, consideravelmente mais rápido.

Licença

Este projeto é uma adaptação do Volatility 3 e, portanto, é uma "Adição" sob a Volatility Software License 1.0, sendo publicado sob essa mesma licença. O texto completo está em LICENSE e online em https://www.volatilityfoundation.org/license/vsl-v1.0. Cada arquivo de código-fonte mantém o aviso registrando de onde foi derivado.

Este projeto não é afiliado nem endossado pela Volatility Foundation. O nome Volatility é usado apenas para indicar do que este projeto é uma adaptação.

Compilação

Rust 1.85 ou mais recente e, em seguida:

cargo build --release

O binário fica em target/release/vol-rs. Nada opcional é necessário. Descompressão de símbolos, RC4, DES, AES, correspondência YARA, desmontagem x86, escrita de PNG e arquivos tar estão todos integrados, onde a versão em Python recorre a pycryptodomex, yara-python, capstone e pillow.

Como usar

./target/release/vol-rs -f memory.raw windows.pslist.PsList
./target/release/vol-rs -f memory.lime linux.bash.Bash
./target/release/vol-rs -f memory.raw -r csv windows.netscan.NetScan
./target/release/vol-rs windows.malfind.Malfind --help
./target/release/vol-rs --list-plugins

Toda opção que a versão em Python aceita também é aceita aqui, com os mesmos nomes e os mesmos padrões, incluindo -o, -r, -s, -c, -e, --filters, --hide-columns, --save-config, --stackers e --single-swap-locations. As opções específicas de cada plugin também correspondem, como mostram as páginas de ajuda: todas as 197 são idênticas às da versão em Python, caractere por caractere.

Símbolos

Os pacotes de símbolos vão em $XDG_DATA_HOME/vol-rs/symbols, ou ~/.local/share/vol-rs/symbols quando essa variável não está definida. Um pacote em outro local é especificado com --symbol-dirs ou por meio da variável de ambiente VOLRS_SYMBOL_PATH. Os símbolos do Windows são obtidos do servidor de símbolos da Microsoft sob demanda e armazenados em cache em ~/.cache/vol-rs.

O que foi verificado

Ambos os lados foram executados contra as mesmas capturas e comparados, incluindo o cabeçalho do quadro e as quebras de linha finais:

Os oito arquivos que não foram comparados como iguais são os dois casos listados em Diferenças conhecidas abaixo. Sete são arquivos parciais que a versão em Python deixa no disco após relatar que não conseguiu despejá-los, os quais esta adaptação não cria, e um é um tarball cujo conteúdo corresponde, mas cujos carimbos de data/hora registram quando cada execução ocorreu.

Os dois plugins ausentes dessas contagens são aqueles que a versão em Python não consegue concluir na máquina de teste. windows.memmap.Memmap é encerrado pelo eliminador de falta de memória após 7,8 milhões de linhas, e linux.pscallstack.PsCallStack é encerrado antes de terminar. Em ambos os casos, cada linha que a versão em Python conseguiu gravar primeiro é reproduzida exatamente.

Em todos os plugins que são executados sem argumentos, a varredura do Windows leva 273 segundos aqui contra 5.723 segundos, e a varredura do Linux 68 segundos contra 3.130 segundos.

Velocidade

As dez maiores diferenças em cada captura, entre todos os plugins que são executados sem argumentos:

Windows

Linux

BENCHMARKS.md tem o restante: todos os plugins em ambas as capturas, as execuções que recebem argumentos e a máquina em que os números foram medidos.

Diferenças conhecidas

Algumas coisas não podem corresponder, e cada uma é intencional:

• linux.pagecache.RecoverFs carimba cada arquivo no tarball que grava com o momento em que o plugin foi executado, então duas execuções nunca concordam, nem mesmo duas execuções em Python. A tabela corresponde e a árvore descompactada também.
• --save-config e timeliner --record-config registram todas as configurações que descrevem a imagem, mas não as verificações da versão em Python de que um componente importado é novo o suficiente, porque esta adaptação não tem tais verificações para registrar.
• linux.mountinfo --mount-format une um conjunto do Python, então a ordem das colunas muda entre duas execuções em Python. Esta adaptação lista as opções de montagem primeiro e as opções do sistema de arquivos depois, na ordem em que o kernel as mantém.
• frameworkinfo e isfinfo descrevem a ferramenta em vez da imagem, então relatam as próprias camadas, plugins e arquivos de símbolos desta adaptação.
• windows.dumpfiles não deixa para trás os arquivos parciais que a versão em Python cria antes de descobrir que não consegue lê-los. As tabelas concordam, os diretórios diferem por esses arquivos.
• A linha em --help que nomeia o diretório de cache nomeia o próprio cache desta adaptação.

A fazer

Tudo abaixo está adaptado e compila, mas ainda não foi executado contra evidências reais:

• Testar os 23 plugins do macOS contra uma captura real de um Mac. Todos os 23 foram lidos linha por linha em relação ao código-fonte em Python, e cada tipo, membro e símbolo que eles acessam foi verificado em relação aos 129 arquivos de símbolos Darwin publicados cobrindo 10.10 a 10.15, portanto, os fallbacks de versão são conhecidos por estarem completos. O que resta é uma imagem real de um Mac para executá-los.
• Testar imagens de 32 bits. Toda a verificação até agora usou capturas de 64 bits, portanto, os caminhos de paginação Intel32 e PAE têm apenas cobertura de teste de unidade.
• Testar os outros formatos de imagem. Apenas capturas VMware e LiME foram usadas, portanto, as camadas crash dump, AVML, QEMU, ELF core e Xen ainda não foram comprovadas em arquivos reais.
• Testar mais versões de kernel. Uma captura de Windows 10 19045 e uma de Linux 6.8 é uma base estreita, e plugins que leem estruturas específicas de versão são onde uma adaptação tem maior probabilidade de se desviar.
• Adicionar os renderizadores arrow e parquet. Eles são aceitos na linha de comando e recusados, que é o que a versão em Python faz quando sua biblioteca de tabelas está ausente.

Crédito

O Volatility 3 é obra da Volatility Foundation e de seus colaboradores. Esta é uma adaptação de seu design, de seu conjunto de plugins e de seu formato de saída, e existe porque esse trabalho é aberto.