Validação dos analisadores¶
Os crates de analisadores mantidos pelo Juntei são testados com evidências públicas e implementações independentes. Essas comparações ajudam a detectar regressões e diferenças de interpretação; elas não tornam nenhum analisador infalível. Preserve as evidências de origem, analise os campos de problemas ou danos de cada registro e valide as constatações relevantes com outro artefato ou outra implementação.
As declarações abaixo preservam as informações de validação que antes ficavam no README principal do Juntei. Consulte os repositórios dos analisadores indicados para conhecer as fixtures de teste e os detalhes de implementação atuais.
Amcache¶
O Juntei usa o ys-amcache-parser, um fork sob Apache-2.0 do amcache-forensic da Security Ronin. Sua documentação de saída define todos os campos de executáveis, dispositivos, constatações e resumo.
Tabela Mestre de Arquivos¶
O crate mft do ys-ntfs-parser é um fork mantido do crate
mft de Omer Ben-Amram. Em oito arquivos $MFT — a amostra do
crate, o caso de invasão do NIST e seis arquivos do DFIR Artifact Museum —, 1.048.733 linhas e colunas CSV
coincidiram, na mesma ordem, com as de um analisador de referência. As comparações abrangeram a saída padrão, --all-times,
--short-names e --cutoff; a apresentação dos carimbos de data/hora foi a diferença intencional.
Log de transações NTFS ($LogFile)¶
O crate logfile do ys-ntfs-parser é mantido a partir do Sootmark ntfslog. Sua validação abrange seis logs completos do DFIR Artifact Museum, fixtures públicas das versões 1.1 e 2.0, metadados de redo/undo decodificados e gravações do diário comparadas com dados NTFS analisados de forma independente. Consulte o repositório do analisador para ver a cobertura detalhada e as diferenças conhecidas.
O Juntei adiciona testes de CLI que comparam cada campo CSV com o JSON e o JSONL no volume de teste público do go-ntfs
(2.129 registros), verificam os dados de redo/undo separados e os comprimentos dos payloads brutos, testam logs danificados,
recusam a sobrescrita de evidências e impedem que os caminhos atuais do MFT sigam números de registro reutilizados.
Os casos de regressão distinguem os registros do MFT afetados do atributo aberto pelo qual eles são gravados,
verificam os metadados planos de entradas de diretório/atributos de dados e impedem o pareamento de MFT entre volumes.
Os testes de auto-parse com vários volumes abrangem arquivos CSV separados e um único arquivo JSONL com procedência.
O comando também foi verificado em seis logs do Windows coletados de forma privada: todos os 708.465 registros CSV
exportados coincidiram campo a campo com o JSONL, e as exportações de auto-parse por host mantiveram as mesmas contagens
de registros. As evidências de origem não são distribuídas com o repositório. Essas verificações confirmam a consistência
da saída, não que toda transação registrada represente uma ação do usuário concluída.
Prefetch¶
O ys-prefetch-parser é um fork mantido do frnsc-prefetch da ForensicRS. Sua saída decodificada foi comparada com a libscca, a implementação independente de Prefetch da libyal.
Diário USN¶
O crate usn do ys-ntfs-parser é um fork mantido
do Sootmark usn. Em seis diários reais, os caminhos do pai do Juntei,
que levam em conta o tempo, coincidiram com os de um analisador independente sempre que esse analisador resolveu um caminho. O Juntei
também resolveu 4.321 registros que a comparação deixou sem resolução. Seu carver não produziu nenhum registro
falso nos testes com 880 MB de dados do $MFT.
Índices de diretórios ($I30)¶
O módulo i30 do crate mft do ys-ntfs-parser lê os registros INDX
e seu slack. Em dois fluxos $I30 de um volume criado com o ntfs-3g (o
test_files/i30/ do Juntei) e em três amostras públicas de $I30 gravadas pelo Windows, suas entradas em uso e no
slack coincidiram com as do dfir_ntfs de Maxim Suhanov, com os
mesmos nomes e horários. Quando o dfir_ntfs relata uma referência ao pai acima de 32 bits (bytes que sobrescreveram
o pai), o Juntei deixa o pai vazio.
Setor de inicialização ($Boot)¶
O crate boot do ys-ntfs-parser é de autoria própria da Yamato
Security. Nos cinco arquivos $Boot públicos do DFIR Artifact Museum (Windows 10, 11 e
Server 2012 R2), todos os campos coincidiram com os de um analisador de referência. Em volumes criados com mkntfs, com setores de 512,
1.024 e 4.096 bytes e clusters de 4 KiB a 64 KiB, os tamanhos, os clusters do $MFT e do $MFTMirr
e os números de série coincidiram com o fsstat do The Sleuth Kit. O $Boot do Windows 11 do Museum
tem o número de série do volume registrado pelo arquivo LNK do mesmo host, e os cinco arquivos têm o
mesmo código de inicialização.
Descritores de segurança ($Secure:$SDS)¶
O crate secure do ys-ntfs-parser é de autoria própria da Yamato
Security. Nos cinco fluxos $SDS do Museum (7.808 descritores, 60.781 ACEs), os
IDs de segurança, hashes, deslocamentos, proprietários, grupos, flags de controle e contagens de ACEs coincidiram com os de um analisador
de referência, e o tipo, os flags, a máscara, o SID e os tipos de objeto de cada ACE coincidiram com o dissect.ntfs. Cada
hash registrado é o do seu descritor, cada cópia espelhada coincide com sua entrada, e todo descritor tem
SDDL, incluindo as condições de suas 3.384 ACEs de callback.
SRUM¶
O ys-srum-parser se baseia nos crates
ese e srum do Sootmark. Em
11 bancos de dados reais, todas as colunas das 45.255 entradas emitidas coincidiram com uma decodificação independente dos
valores expostos pelo dissect.esedb.
Registro de acesso do usuário¶
O parse-ese ual lê os bancos de dados do UAL com o mesmo leitor ESE. Em 16 bancos de dados reais (308 linhas,
145 delas linhas de clientes), todos os valores coincidiram com uma decodificação independente dos valores expostos
pelo dissect.esedb. Em todas as linhas de clientes, o primeiro dia com contagem foi o dia UTC de InsertDate,
o último, o dia UTC de LastAccess, e as contagens somavam TotalAccesses.
Navegadores web¶
O ys-browser-parser é um fork mantido dos crates browser,
sqlite e plist do Sootmark, escolhido após compará-lo com outra biblioteca Rust e com o Plaso, o Velociraptor
(SQLiteHunter) e o Hindsight nos mesmos bancos de dados. O parse-sqlite browser foi comparado com a biblioteca
sqlite3 lendo uma cópia de cada banco de dados com seu arquivo -wal, em 38 bancos de dados públicos: os arquivos
de teste do Plaso (Chrome 8 a 68, Firefox 2 a 118), perfis criados pelo Chromium 150 e pelo Firefox 140, e os bancos
de dados de teste de histórico de formulários do ys-browser-parser. Todas as 293 visitas, 21 downloads, 692 cookies
e 41 entradas de formulários coincidiram. Entradas excluídas só foram recuperadas onde entradas haviam sido
excluídas: as duas páginas e as duas visitas excluídas do histórico do Firefox 140, com seus horários, URLs e
títulos, e as entradas de formulários excluídas dos bancos de dados de teste.
Internet Explorer e Edge legado (WebCache)¶
O parse-ese webcache lê o WebCacheV01.dat com o
ys-browser-parser. Ele foi comparado com o leitor ESE do
dissect.database nos dois bancos de dados WebCache públicos do Plaso: um do Internet Explorer 11 e um sujo do
Windows 10 com o histórico, os downloads e os cookies do Edge legado. Todas as 4.156 linhas coincidiram, valor por
valor: 44 contêineres, 182 entradas de histórico, 6 downloads, 170 cookies e 3.754 outras entradas. A comparação
decodificou os registros de download por conta própria. Os registros que os bancos de dados marcam como excluídos
ficaram de fora de ambos.
Outlook¶
O parse-file outlook lê arquivos PST, OST, .msg e .oft com o
ys-outlook-parser, cujo leitor de PST e OST é um fork do
outlook-pst-rs da Microsoft e cujo leitor de .msg foi escrito a partir
das especificações abertas da Microsoft.
- PST e OST: 66 arquivos PST e OST públicos (Apache Tika, artemis, os exemplos do Aspose.Email, o DFIR Artifact Museum, Enron, os exemplos do GroupDocs, java-libpst, os dados de teste da libyal, outlook-pst-rs e pst-extractor) foram comparados com a libpff, propriedade por propriedade: cada propriedade de cada repositório, pasta, mensagem, destinatário e anexo, e os dados de cada anexo. 324.175 valores foram iguais e nenhum diferiu sem explicação. Os demais são o que só o ys-outlook-parser lê (15.846 valores de mensagens, destinatários e anexos em que a libpff falha, e de um repositório que ela não consegue abrir; 8.223 de itens ocultos), células de destinatários que a libpff dá como vazias ou zero embora suas linhas digam que estão ausentes (49.077), IDs de entrada e tipos de pastas calculados como o MAPI faz (2.004), e objetos e mensagens incorporadas que a libpff dá como seus dados brutos (480). Nenhum dos dois leitores consegue ler dois dos arquivos.
.msge.oft: 214 arquivos públicos, com 2.404 mensagens, destinatários e anexos e 41.002 propriedades, foram comparados com o extract-msg: 110.114 valores foram iguais, e cada uma das 791 diferenças tem explicação: 601 são erros do extract-msg com horários, 35 vêm de arquivos ANSI que ele decodifica na página de código errada, e as demais são o que ele omite ou acrescenta.- Entrada danificada: mais de 260.000 arquivos
.msgmutados e 160.000 PSTs mutados, além de arquivos criados de propósito, foram lidos sem travamento, sem congelamento e sem uso ilimitado de memória.
Atalhos LNK¶
O ys-lnk-parser é um fork mantido do crate shell do Sootmark. Ele foi comparado em 1.118 atalhos públicos. Das 30 colunas CSV em comum com o analisador de referência, 16 valores individuais diferiram: 13 caminhos de destino envolvendo itens danificados, truncados, de espaço reservado, MTP ou do Painel de Controle; duas listas de blocos de dados extras envolvendo blocos desconhecidos ou truncados; e uma referência MFT que o analisador de referência leu a partir de bytes diferentes. O Juntei relata as estruturas danificadas em vez de normalizá-las silenciosamente.
Jump Lists¶
O ys-jump-lists-parser usa o trabalho do Sootmark sobre
arquivos compostos e Jump Lists, com os links incorporados decodificados pelo ys-lnk-parser. Em 77 Jump Lists
públicas, todas as 13.057 células de comparação em comum — incluindo carimbos de data/hora com precisão de 100 ns — coincidiram com o
analisador de referência. Seis arquivos que a referência recusou (listas personalizadas vazias, um rodapé ausente ou um arquivo
que não era uma Jump List) foram decodificados ou relatados explicitamente pelo Juntei.
ShimCache¶
O ys-shimcache-parser é um fork mantido
do shimcache-forensic da
Security Ronin, com suporte a hives do Registro e
logs de transação. Em 20 hives SYSTEM públicos (24 conjuntos de controles e 7.290 entradas), além de 17
valores AppCompatCache avulsos, todas as entradas coincidiram com o caminho, o horário, o flag de execução, os flags e a
posição emitidos pelo analisador de referência.
Quarentena do Microsoft Defender¶
O ys-defender-history-parser é um
fork mantido do crate
defender do Sootmark. Uma pasta de quarentena gravada no formato do Defender
pelas ferramentas de teste do analisador é decodificada de forma consistente pelo leitor de quarentena independente do
dissect.target.
Artefatos derivados do Registro¶
O ys-registry-parser é comparado com o yarp quanto a chaves e valores alocados, reprodução de transações de hives sujos, recuperação de células livres, slack de célula, dados além dos bins do hive e registros removidos ou substituídos pela reprodução. As comparações específicas de artefatos incluem:
- serviços, valores e ações de falha de hives
SYSTEMdo Windows 7 e de um Windows 11 sujo; - RecentDocs decodificado com o yarp e a libfwsi em nove hives
NTUSER.DATpúblicos; - tarefas agendadas decodificadas de forma independente com o yarp em sete hives
SOFTWAREpúblicos, abrangendo Windows 7–11, Server 2012 R2 e Server 2022; e - estruturas de contas do SAM comparadas com o
dissect.targetem sete hivesSAMpúblicos.
Consulte os Agradecimentos para ver a lista completa de ferramentas de referência, pesquisas sobre formatos, especificações e fontes de evidências públicas.