Resumo Técnico: Agulhas em Escala

Declaração do Problema

O principal gargalo na pesquisa de vulnerabilidades moderna para sistemas operacionais de código fechado não é a análise de funções individuais, mas a seleção de alvos. Uma imagem moderna do Windows contém milhões de funções (o "palheiro"), mas apenas uma fração ínfima é relevante para classes específicas de vulnerabilidades. Embora as ferramentas de análise (execução simbólica, fuzzers, agentes de LLM) tenham avançado, elas permanecem intensivas em recursos. Um agente de LLM, por exemplo, desperdiça janelas de contexto caras analisando código irrelevante (ex: inicialização do C-runtime) se não for direcionado para a função correta. O artigo argumenta que o campo deve mudar da pergunta "podemos analisar esta função?" para "quais das milhões de funções devemos analisar a seguir?". Esse processo de seleção é atualmente impulsionado por intuição, reputação e buscas simples de grep, carecendo de um substrato de priorização sistemático e escalável para escopos de todo o sistema operacional.

Metodologia: Simbolicação-Enriquecimento-Amostragem

Os autores propõem o Symbolicate-Enrich-Sample (Simbolicar-Enriquecer-Amostrar), um pipeline de processamento em lote de três estágios projetado para transformar um corpus de binários de produção do Windows em uma fila de pesquisa classificada por prioridade. O pipeline é projetado para ser de baixo custo e reprodutível, operando em toda a imagem do Windows sem exigir acesso ao código-fonte privado.

1. Simbolicação (Symbolicate)

Este estágio aborda a falta de símbolos em binários de produção (arquivos PE) sem símbolos.

• Mecanismo: O pipeline analisa o registro CodeView (RSDS) dentro de cada binário para extrair o GUID e a idade do PDB (Program Database). Ele constrói uma URL canônica para o servidor de símbolos público da Microsoft, busca o PDB correspondente e o armazena em cache.
• Recuperação: Uma passagem de descompilação recupera o conjunto de funções e o grafo de chamadas interprocedimentais. O pipeline então une os nomes de funções públicos do PDB aos endereços de funções recuperados.
• Resolução de API: Um catálogo de aproximadamente 20.000 protótipos de Win32/WDK é unido às importações chamadas para recuperar os protótipos dos chamados (callees) para os locais de chamada (call sites).
• Saída: Um grafo de chamadas nomeado. Funções sem nomes públicos permanecem como entradas sintéticas sub_<addr> e são excluídas da etapa de enriquecimento subsequente.

2. Enriquecimento (Enrich)

Este estágio anexa características estruturais determinísticas e rótulos gerados por LLM a cada função nomeada.

• Características Determinísticas: Para cada função, o sistema computa:
  • Status de exportação.
  • Contagens de chamadores/chamados e nomes dos principais chamadores/chamados.
  • Presença de APIs relevantes para risco (sinks de cópia/escrita como memcpy, RtlCopy*, alocadores de pool, sondas de ponteiros de usuário).
  • Contagem de blocos básicos e tamanho.
  • Profundidade de alcance breadth-first a partir de pontos de entrada (exports, rotinas de despacho).
• Rotulagem por LLM: Um LLM de baixo custo é instruído com o nome da função, protótipos de chamados recuperados e as características determinísticas. Ele é instruído a raciocinar a partir dessas características (não apenas do nome) para gerar:
  • Nível de Alcance (Reachability Tier): (Remoto, IPC-local, usuário-local, apenas-admin, interno-kernel, interno-biblioteca).
  • Nível de Risco: (Crítico, alto, médio, baixo, info).
  • Hipótese de Classe de Bug e Racional.
• Otimização: Funções que coincidem com padrões conhecidos de runtime/CRT-helper são filtradas por regra (forçadas para interno-biblioteca/info) para evitar chamadas desnecessárias ao modelo. O modelo vê apenas um resumo estruturado compacto, nunca bytes descompilados brutos.

3. Amostragem (Sample)

Este estágio converte o corpus enriquecido em uma fila diversificada e priorizada.

• Pontuação (Scoring): Uma pontuação de prioridade é calculada usando uma fórmula heurística: prioridade = w_alcance · w_risco · w_conf · bônus. O termo de bônus recompensa evidências determinísticas (ex: chamar um sink de cópia, ser exportado) e penaliza stubs triviais.
• Estratégia de Amostragem: Um amostrador de importância ponderada pela prioridade (usando um algoritmo de reservatório ponderado) extrai funções sem reposição. Isso garante que uma sessão de pesquisa cubra o espaço de alto valor com diversidade, em vez de retornar repetidamente os mesmos resultados top-k.
• Flexibilidade: O sistema suporta diferentes regimes: varreduras amplas "estilo fuzzer" (extração ponderada) ou trabalho direcionado por hipóteses (filtros rigorosos com seleção top-N).

Principais Resultados e Avaliação

O pipeline foi aplicado a um corpus de 5.888 binários assinados x86-64 do Windows 11 (build 10.0.26100), recuperando 7.231.419 funções.

• Recuperação de Símbolos: 76,8% das funções recuperadas (5.553.074) receberam nomes de PDB públicos e foram enriquecidas. Os 23,2% restantes eram stubs sem nome e foram excluídos do enriquecimento.
• Seletividade: O processo de rotulagem é altamente conservador.
  • Apenas 0,18% das funções foram rotuladas como críticas.
  • Apenas 1,83% foram rotuladas como voltadas para o remoto.
  • A maioria das funções foi corretamente rebaixada para interno-biblioteca ou info (ex: mecanismos de exceção C++, boilerplate).
• O Funil: Ao empilhar os rótulos do modelo com filtros determinísticos (Risco: alto/crítico E Alcance: remoto/IPC-local E Chama um primitivo de memória inseguro), o espaço de busca é reduzido em aproximadamente 2,5 ordens de magnitude, de 7,23 milhões de funções para uma lista curta de ~22.000 funções.
• Modos de Falha: Os autores identificaram duas fraquezas sistemáticas no nível superior:
  1. Sobre-alcance (Over-reach): Atribuir classes de bugs específicas (ex: use-after-free) a funções que carecem dos vetores de características necessários (ex: sem um sink de cópia/escrita).
  2. Inflação de Alcance (Reachability Inflation): Rotular funções de parser profundas como remoto mesmo quando a profundidade do grafo de chamadas sugere o contrário.
     Mitigação: Guardas simples (ex: proibir rótulos concretos de classe de cópia sem um sink correspondente) podem mitigar o primeiro modo de falha sem reexecutar o modelo.

Significância e Alegações

O artigo enquadra explicitamente sua contribuição como um substrato de seleção, não um detector de bugs. Não alega ter descoberto novas vulnerabilidades. Em vez disso, fornece a camada de priorização sobre a qual um detector ou agente de LLM a jusante deve operar.

• Escalabilidade: Demonstra que a pesquisa de vulnerabilidades de todo o SO é viável na escala de milhões de funções usando LLMs de baixo custo, desde que o LLM seja fundamentado em características estruturais determinísticas em vez de código bruto.
• Mudança Metodológica: Reenquadra a pesquisa de vulnerabilidades de um problema de análise pura para um problema de recuperação de informação e classificação de candidatos.
• Política de Dados: Os autores retêm o conjunto de dados derivado (anotações ao nível de função) por razões legais (direitos autorais de binários da Microsoft) e preocupações de duplo uso (fornecer um mapa de superfície de ataque classificado pode auxiliar atacantes). No entanto, a metodologia é totalmente reproduzível usando binários públicos do Windows e servidores de símbolos.

O artigo conclui que, embora a lista curta melhore a tratabilidade do problema, a questão central permanece sendo se essa lista curta priorizada realmente melhora o rendimento da descoberta de bugs reais em comparação com a busca não informada, uma questão deixada para trabalhos futuros envolvendo loops de calibração e verificação humano-no-circuito.