Auditoria da Trail of Bits no Miden Encontrou uma Falha no Falcon Depois que Agentes Criaram as Ferramentas Ausentes

A Trail of Bits passou seis meses se preparando para a auditoria do Miden e, então, encontrou uma falha de alta gravidade com ferramentas que seus agentes de IA haviam criado do zero. A auditoria da Trail of Bits no Miden envolveu mais do que apontar um modelo para o código-fonte. Seus agentes criaram um servidor LSP, um descompilador, um mecanismo de análise estática e um modelo em Lean antes do início da revisão formal.

Essa preparação expôs um valor sub-restrito que, segundo relatos, poderia permitir que um provador malicioso falsificasse assinaturas Falcon e esvaziasse contas afetadas. Os analisadores também identificaram mais de 400 locais onde a validação de tipos poderia ser aprimorada. Enquanto isso, o esforço de verificação formal produziu 95 provas de correção verificadas por máquina e revelou dois bugs não detectados pelos testes unitários existentes.

A disputa importante não é entre agentes de IA e auditores humanos. É entre a revisão direta de código por IA e a construção, assistida por agentes, da infraestrutura que torna possível revisar códigos difíceis. A Trail of Bits continuou a depender de supervisão humana, revisão manual de teoremas e julgamento convencional de segurança. Os agentes mudaram quais projetos de suporte eram economicamente viáveis.

A Auditoria da Trail of Bits no Miden Começou Seis Meses Antes

O trabalho decisivo começou antes de os auditores receberem um alvo finalizado para inspecionar.

A equipe do Miden procurou a Trail of Bits no fim de 2025, segundo o detalhado relato da auditoria do Miden publicado pela empresa. O Miden queria que partes de sua máquina virtual de conhecimento zero fossem revisadas antes do lançamento. Uma parte abrangia uma biblioteca central contendo primitivas criptográficas escritas em Miden Assembly, ou MASM.

Uma máquina virtual de conhecimento zero, frequentemente abreviada como zkVM, prova que um programa foi executado corretamente sem exigir que cada verificador repita esse cálculo. O Miden usa uma arquitetura de máquina de pilha. As instruções consomem valores de uma pilha e colocam seus resultados de volta nela.

Essa arquitetura importa porque entradas e saídas costumam ser implícitas no código MASM. Um revisor precisa acompanhar como cada instrução altera a pilha e, em seguida, transportar esse estado por ramificações, loops e chamadas de procedimento. Indícios familiares no nível do código-fonte podem desaparecer.

O MASM também não tinha grande parte das ferramentas que os auditores normalmente esperam. Havia pouco suporte em editores, nenhum servidor de linguagem maduro voltado para revisão e análise automatizada limitada para a biblioteca central. A Trail of Bits sabia que a implementação ainda não estava completa em funcionalidades, mas também sabia que a revisão ocorreria seis meses depois.

A empresa usou essa janela para criar seu próprio ambiente de revisão. Segundo a Trail of Bits, Claude produziu um protótipo inicial de servidor de linguagem em poucos dias. O servidor de linguagem MASM resultante oferece navegação, descoberta de referências, documentação ao passar o cursor, diagnósticos de sintaxe, descrições de instruções e informações sobre efeitos na pilha.

Esses recursos parecem conveniências comuns para desenvolvedores. Em uma linguagem assembly desconhecida, eles se tornam parte do método de segurança. A navegação ajuda os auditores a rastrear um valor através dos limites entre procedimentos. Efeitos de pilha em linha reduzem a reconstrução manual repetitiva. Os diagnósticos expõem pressupostos antes que se transformem em descobertas.

A Trail of Bits então ampliou o projeto para incluir descompilação, análise estática, ferramentas de linha de comando e modelagem formal. Claude cuidou de tarefas de planejamento e implementação, enquanto Codex participou da revisão de código. Os agentes também alternaram papéis, dando ao trabalho gerado uma etapa separada de revisão.

Não foi um processo de geração única. Depois de implementar um recurso, a equipe pediu aos agentes que descompilassem procedimentos aleatórios e comparassem os resultados com o MASM original. Regressões se tornaram testes, e o modelo passou então a trabalhar com base nesses testes.

Esse ciclo de feedback é central para a história. Os agentes não foram tratados como autoridades cuja saída merecia confiança automática. Eles operaram dentro de um sistema de verificação em expansão, contendo testes, etapas de revisão, analisadores e, posteriormente, um verificador de provas.

Assim, a auditoria começou com uma pergunta diferente da habitual. A Trail of Bits não perguntou apenas se um agente poderia encontrar vulnerabilidades. Perguntou quais instrumentos ausentes impediam os auditores, incluindo os agentes, de entender o código em primeiro lugar.

Essa mudança de escopo criou as condições para as descobertas posteriores. Também pressionou equipes de segurança que promovem a revisão por IA principalmente como uma varredura mais rápida do código-fonte. A abordagem da Trail of Bits exigiu mais preparação, mas converteu essa preparação em infraestrutura técnica reutilizável.

O Descompilador Se Tornou Mais Valioso do que Sua Saída

O descompilador foi mais importante porque sua representação interna deu a outras análises um local confiável para operar.

Descompilar MASM não era simplesmente uma questão de substituir instruções assembly por expressões legíveis. A maioria dos procedimentos da biblioteca central não tinha assinaturas declaradas, de modo que as ferramentas frequentemente precisavam inferir suas entradas e saídas a partir do contexto. Os procedimentos também não tinham uma convenção de chamada uniforme.

Os loops criaram outro problema. Um loop while em MASM não precisa preservar o mesmo formato de pilha entre iterações. Sua condição pode se mover para outra posição na pilha, quebrando tentativas simples de atribuir nomes estáveis às entradas das instruções.

Ramificações condicionais também podem produzir efeitos diferentes na pilha. Se uma ramificação adiciona um item enquanto outra remove um, o descompilador não pode simplesmente mesclar seus estados. Erros na inferência de efeitos de pilha podem então se propagar por todos os procedimentos que chamam o código afetado.

A Trail of Bits respondeu limitando sua promessa. Seu descompilador MASM visa um subconjunto bem definido, em vez de alegar recuperação perfeita para todos os procedimentos. Essa escolha priorizou a correção em vez de uma cobertura superficial.

O descompilador se tornou o maior esforço de ferramentas do projeto. A Trail of Bits relata mais de 100 commits gerados por IA ao longo de vários meses. Ainda assim, o pseudocódigo finalizado não foi seu resultado mais importante.

O projeto criou uma representação intermediária, ou IR, que expressava entradas e saídas de procedimentos como expressões analisáveis. Uma IR é uma versão estruturada de código projetada para transformação ou análise. Quando as instruções MASM passaram a existir nessa forma, a equipe pôde aplicar técnicas estabelecidas de fluxo de dados e análise estática.

O analisador podia perguntar se valores fornecidos pelo provador eram validados antes do uso. Podia rastrear se o código impunha os tipos esperados, como inteiros de 32 bits ou valores Booleanos. Também podia determinar se variáveis locais eram inicializadas em todos os caminhos possíveis de execução.

A Trail of Bits usou interpretação abstrata em parte desse trabalho. A interpretação abstrata avalia categorias de valores possíveis em vez de executar um programa com uma entrada concreta. Um valor pode ser representado como um inteiro válido de 32 bits, um Booleano ou um valor desconhecido.

A análise se repete até alcançar um estado estável, no qual nenhuma informação nova aparece. Quando projetada de forma sólida, ela superaproxima o que execuções reais podem fazer. Isso pode produzir falsos positivos, mas não deve excluir silenciosamente um comportamento real coberto pelo modelo.

Isso ilustra por que a auditoria da Trail of Bits no Miden difere de uma demonstração genérica de programação com IA. O descompilador gerado por agentes não recebeu confiança para declarar o código seguro. Ele ajudou a construir uma base sobre a qual análises explícitas e inspecionáveis poderiam ser executadas.

O fluxo de trabalho também criou benefícios para humanos. Procedimentos descompilados tornaram o controle de alto nível e o fluxo de dados mais fáceis de revisar no editor. Anotações de pilha reduziram o controle mental necessário. Interfaces de linha de comando disponibilizaram as mesmas capacidades para processos automatizados de revisão.

Há uma lição mais ampla para equipes que avaliam agentes de programação. O artefato gerado mais valioso pode não ser aquele que os usuários veem. Um descompilador parcialmente delimitado ainda pode justificar seu custo se seu analisador, modelo de fluxo de controle e IR desbloquearem várias verificações de maior valor.

Essa conclusão também muda como as equipes devem preservar o contexto do projeto. Prompts de agentes, casos de regressão, decisões arquiteturais e comentários de revisores se tornam insumos duradouros de engenharia. Uma base de conhecimento pesquisável pode ajudar a manter esses materiais disponíveis ao longo de projetos de segurança extensos.

A revisão direta por IA normalmente começa com o código-alvo e procura defeitos. A Trail of Bits usou agentes, em vez disso, para alterar a superfície de revisão. O resultado seguinte mostrou por que essa distinção importava.

Uma Verificação Ausente Chegou à Autenticação Falcon

Um único resto não validado teria transformado um auxiliar aritmético em um caminho para autenticação falsificada.

Durante a auditoria, as análises estáticas identificaram mais de 400 locais únicos onde a validação de tipos poderia ser aprimorada. A Trail of Bits afirma que todos eram acessíveis pela API pública da biblioteca central. Muitos surgiram porque procedimentos expostos publicamente podiam ser chamados sem os pressupostos esperados por seus autores originais.

Um procedimento público não pode depender com segurança de que cada chamador forneça um valor do tipo pretendido. Em um sistema de provas, é particularmente importante distinguir um valor fornecido pelo provador de um valor restringido pela prova. Apenas inserir dados em um cálculo não estabelece que eles representem o inteiro ou Booleano alegado.

A descoberta de alta gravidade se concentrou em mod_12289, um procedimento que reduz um valor de 64 bits módulo 12.289. O provador fornecia um quociente e um resto por meio de um mecanismo de advice. Valores de advice são dicas de execução calculadas fora da VM, frequentemente usadas para evitar trabalho caro dentro da VM.

O quociente recebeu uma verificação confirmando que se encaixava na representação esperada de 64 bits. O resto não recebeu validação equivalente antes de entrar em u32overflowing_sub, uma instrução de subtração de 32 bits.

A Trail of Bits afirma que um atacante poderia variar o quociente e o resto enquanto ainda satisfazia as restrições de subtração. Isso permitia que mod_12289 retornasse algo diferente do resto matematicamente correto.

O alcance do bug foi além de um resultado aritmético incorreto. O procedimento dava suporte à verificação de assinaturas Falcon. Falcon é um esquema de assinatura digital pós-quântica, e o Miden usava uma variante na autenticação de contas.

Segundo a Trail of Bits, um provador malicioso poderia explorar o valor sub-restrito para falsificar uma assinatura Falcon e esvaziar uma conta controlada por um par de chaves Falcon. Essa é a alegação técnica da empresa, não um exploit reproduzido de forma independente apresentado no artigo público.

A gravidade decorre do modelo de execução do Miden. O design da Miden VM oferece suporte a entradas não determinísticas fornecidas durante a geração de provas. Essas entradas podem melhorar a eficiência, mas o programa precisa restringi-las cuidadosamente.

Um verificador não infere a intenção do desenvolvedor. Ele verifica se a prova enviada satisfaz as restrições codificadas. Se essas restrições aceitarem um resto inválido, a prova poderá permanecer válida mesmo quando a relação aritmética alegada for falsa.

Essa é a inversão central. Provas de conhecimento zero podem estabelecer a execução fiel de um sistema especificado, mas não podem corrigir uma especificação incompleta. Uma prova criptográfica de um programa sub-restrito pode fornecer confiança na propriedade errada.

O contexto independente de uma posterior auditoria de contratos da Miden reforça o ponto geral. A OpenZeppelin descreveu as transações da Miden como válidas quando existe uma prova correspondente, tornando cada verificação MASM parte das restrições que um provador deve satisfazer.

Esse trabalho separado cobriu um escopo de repositório diferente e não deve ser confundido com a revisão da Trail of Bits. Ainda assim, ambos os relatos mostram por que a lógica de autenticação, as entradas controladas pelo provador e as premissas on-chain exigem tratamento explícito.

As mais de 400 localizações de validação de tipo também devem ser interpretadas com cuidado. Elas não foram descritas como 400 vulnerabilidades exploráveis. Representavam pontos em que a validação poderia melhorar, incluindo uma questão de alta gravidade reportada entre elas.

Essa distinção importa porque a análise estática frequentemente encontra condições que exigem triagem. Um analisador sólido pode relatar intencionalmente mais casos do que aqueles que acabam se tornando falhas de segurança. Seu valor está em localizar sistematicamente premissas que merecem inspeção.

Para equipes de segurança, o resultado coloca pressão sobre um atalho comum: usar um agente para resumir funções suspeitas sem antes modelar as regras de valor da linguagem-alvo. Um modelo pode explicar o que o código aparentemente faz. O analisador pode perguntar se toda execução permitida realmente respeita o tipo exigido.

A descoberta do Falcon resultou da combinação dessas duas capacidades. Os agentes aceleraram a construção, enquanto a semântica estática transformou uma intuição sobre dados controlados pelo provador em uma verificação repetível.

Provas em Lean Encontraram o Que os Testes Unitários Não Viram

A verificação formal não substituiu os testes, mas obrigou a equipe a declarar o comportamento com precisão suficiente para expor duas falhas não testadas.

A Trail of Bits buscou modelagem formal mesmo depois de criar o editor e as ferramentas de análise estática. A pergunta era deliberadamente diferente: se um procedimento de biblioteca não continha um defeito óbvio, a equipe conseguiria provar que sua implementação correspondia ao comportamento aritmético pretendido?

A empresa criou um executor mínimo da Miden VM em Lean. Lean é um provador interativo de teoremas cujo pequeno núcleo confiável verifica se uma prova enviada decorre de suas definições e premissas. Claude também ajudou a criar um tradutor de procedimentos MASM para representações em Lean.

Vários agentes trabalharam então, em paralelo, nas provas dos procedimentos. O modelo MASM em Lean resultante contém semântica executável da VM, procedimentos traduzidos, suporte compartilhado a provas e teoremas individuais de correção.

O repositório lista 95 provas de procedimentos verificadas: 31 para operações de 64 bits, 36 para operações de 128 bits, 17 para operações de 256 bits e 11 para operações de palavras. Juntas, elas cobrem as partes de aritmética binária descritas pela Trail of Bits.

Essas não eram provas de que toda a Miden era segura. Elas abordavam propriedades definidas de correção para procedimentos específicos. Esse limite é essencial porque um provador de teoremas verifica o teorema que lhe é fornecido, não a intenção não declarada na mente de um desenvolvedor.

A Trail of Bits diz que os revisores humanos, portanto, concentraram-se em auditar as declarações dos teoremas. Se um agente provasse um teorema que omitisse uma pré-condição crítica ou expressasse o resultado errado, a aceitação pelo núcleo, por si só, não tornaria o software correto.

Em alto nível, muitos teoremas seguiam um padrão reconhecível. Dada uma pilha com entradas específicas, a execução de um procedimento deve terminar e deixar o resultado matematicamente esperado no topo. Valores não relacionados da pilha, pertencentes ao chamador, devem permanecer nas posições esperadas.

Essa pressão de especificação expôs dois defeitos que os testes unitários existentes não detectaram. O primeiro afetava um procedimento de rotação à direita de 64 bits chamado rotr. Ele se comportava incorretamente para entradas grandes acima do primo Goldilocks quando a quantidade de rotação era múltipla de 32.

O primo Goldilocks define o campo usado pela VM, portanto valores próximos ou além desse limite exigem representação cuidadosa. Durante o trabalho de prova, o teorema desejado não podia ser demonstrado sem adicionar uma premissa que excluísse o caso problemático de deslocamento.

Uma prova que falha não é automaticamente evidência de um bug no código. O teorema, o modelo ou os lemas de suporte também podem estar errados. Neste caso, a revisão manual da obstrução levou a equipe ao caso-limite da implementação.

O segundo bug apareceu no procedimento wrapping_mul de 256 bits. A Trail of Bits afirma que ele removia valores pertencentes ao chamador da pilha antes de retornar. Testes comuns do resultado da multiplicação podiam passar sem verificar a preservação do estado ao redor da pilha.

Esse defeito mostra por que pós-condições precisas importam. Um procedimento pode calcular a resposta numérica correta enquanto viola seu contrato de chamada. Em uma máquina de pilha, danificar o estado adjacente pode afetar a execução posterior mesmo quando o item no topo parece correto.

Os testes unitários continuam tendo um papel central. Eles são executados rapidamente, protegem contra regressões conhecidas e cobrem o comportamento de integração que talvez ainda não tenha um modelo formal. O esforço em Lean forneceu um tipo diferente de garantia para propriedades explicitamente declaradas.

A principal vantagem foi composicional. Os agentes puderam produzir tentativas de prova em escala, enquanto o núcleo do Lean rejeitava derivações inválidas. Os humanos não precisavam confiar na confiança expressa em prosa por um modelo. Precisavam examinar as definições e confirmar que os teoremas aceitos representavam as garantias pretendidas.

Esse é um limite de controle mais forte do que pedir a outro modelo de linguagem que avalie se um código gerado parece correto. Isso não elimina o julgamento humano, mas direciona esse julgamento para especificações e premissas.

Para líderes de engenharia, o caso sugere uma divisão prática de trabalho. Agentes podem gerar estruturas repetitivas de provas, tradutores e lemas candidatos. Especialistas humanos decidem o que deve ser provado e investigam por que declarações importantes falham.

O Resultado Não Torna Auditorias Autônomas Confiáveis

O projeto apoia a engenharia de auditoria assistida por agentes, não a certificação de segurança sem supervisão.

A Trail of Bits apresenta diretamente a mudança econômica. Alguns anos antes, teria tido dificuldade para justificar meses de ferramentas exploratórias para um único trabalho. Esses projetos paralelos tinham resultados incertos e eram difíceis de vender antes que seu valor se tornasse visível.

A empresa argumenta que os agentes reduziram o custo da exploração o suficiente para mudar esse cálculo. Experimentos malsucedidos custam cada vez mais tokens e tempo de supervisão, em vez de uma alocação completa de trabalho especializado de engenharia.

Essa afirmação merece uma leitura cuidadosa. Ainda transcorreram seis meses antes da auditoria, e apenas o decompilador acumulou mais de 100 commits gerados por IA. O relato público não fornece uma comparação controlada entre horas da equipe, custos totais de modelos ou rendimento de defeitos e um trabalho convencional.

Também não estabelece que agentes possam criar ferramentas equivalentes para toda linguagem incomum. MASM oferecia propriedades favoráveis à análise e à modelagem formal. A Miden VM possui um conjunto compacto de instruções, e muitas operações evitam efeitos colaterais complexos.

Mesmo nesse alvo favorável, o decompilador não conseguiu cobrir com segurança todos os procedimentos. A Trail of Bits restringiu seu subconjunto suportado porque efeitos de pilha inconsistentes e assinaturas ausentes tornavam a descompilação completa e confiável impraticável.

O fluxo de trabalho em Lean trouxe outro limite. Provas verificadas pelo núcleo estabelecem apenas o teorema declarado sob a semântica modelada. Uma instrução traduzida incorretamente, um modelo incompleto da VM ou um teorema fraco podem manter uma lacuna entre o comportamento provado e a implantação real.

A revisão humana permaneceu visível durante todo o processo. Auditores revisaram código gerado por agentes, transformaram regressões em testes, inspecionaram declarações de teoremas e analisaram provas falhas. Claude e Codex alternaram entre desenvolvimento e revisão, em vez de operar como uma autoridade não observada.

Isso torna a comparação principal mais nítida. A revisão direta por IA pede a um modelo que reconheça vulnerabilidades em uma representação existente. Agentes que criam ferramentas ajudam especialistas a produzir uma representação em que restrições ausentes, tipos inválidos e pós-condições incorretas se tornam explícitos.

Nenhuma das abordagens deve funcionar isoladamente. Modelos podem revelar hipóteses que analisadores estáticos não codificam. A análise estática pode cobrir caminhos de execução que um revisor probabilístico talvez ignore. A prova formal pode então abordar propriedades selecionadas com um padrão verificável por máquina.

O processo também cria obrigações de manutenção. Parsers devem acompanhar mudanças na linguagem. Analisadores precisam de suítes de regressão. Modelos formais devem permanecer alinhados à semântica da VM. Ferramentas geradas que se tornam obsoletas podem criar falsa garantia.

A Trail of Bits relata que a equipe da Miden adotou o mecanismo de análise estática para futuras atualizações da biblioteca principal. Esse é um sinal importante porque leva as ferramentas além de um retrato de auditoria único. O uso contínuo testará se o analisador permanece útil à medida que a linguagem e a biblioteca evoluem.

Organizações que considerem um fluxo de trabalho semelhante também devem planejar a proveniência. As equipes precisam saber qual modelo gerou uma alteração, qual humano a revisou, quais testes foram executados e quais premissas entraram em uma prova. Um fluxo de trabalho de engenharia só é tão revisável quanto os registros preservados ao seu redor.

As evidências públicas, portanto, apoiam uma conclusão delimitada. Os agentes tornaram viável um programa ambicioso de preparação para esse trabalho. A garantia de segurança ainda veio do sistema combinado de especialistas do domínio, testes, análises explícitas e verificação de provas.

Esse sistema é mais interessante do que a alegação de que uma IA encontrou um bug. Ele oferece um modelo concreto para usar agentes imperfeitos sem tratar sua confiança como evidência.

Três Sinais Testarão se Este Modelo de Auditoria Perdura

O próximo teste é saber se ferramentas de garantia criadas por agentes permanecem corretas, adotadas e produtivas após as descobertas de destaque.

O primeiro sinal é a integração contínua do analisador MASM ao processo de desenvolvimento da Miden. A Trail of Bits afirma que a equipe da Miden adotou o mecanismo de análise estática para futuras alterações na biblioteca principal. O uso rotineiro em integração contínua fortaleceria o argumento de que as ferramentas de auditoria podem se tornar infraestrutura preventiva.

A medida importante não é quantos alertas ele emite. É se novos procedimentos públicos recebem a validação exigida antes do lançamento e se as atualizações do analisador acompanham mudanças na semântica de MASM. Falsos positivos persistentes ou modelos obsoletos enfraqueceriam o resultado.

O segundo sinal é a expansão e a manutenção das 95 provas em Lean. Procedimentos verificados adicionais mostrariam que o modelo inicial sustenta trabalho contínuo, em vez de uma demonstração fixa. Mudanças no código aritmético existente também devem acionar atualizações ou falhas nas provas.

Observe o limite entre código traduzido e especificações revisadas manualmente. A automação que amplia a contagem de provas sem fortalecer a cobertura dos teoremas não ofereceria a mesma garantia. Documentação clara das premissas será tão importante quanto o total bruto.

O terceiro sinal é a replicação por outras equipes de auditoria e ecossistemas de linguagem. A Miden apresentou uma combinação incomumente adequada: uma linguagem personalizada, ferramentas ausentes, semântica explícita de prova e meses de tempo de preparação.

Um padrão repetido em diferentes zkVMs ou linguagens de baixo nível apoiaria a alegação econômica mais ampla da Trail of Bits. A incapacidade de reproduzi-lo em sistemas com concorrência, memória complexa ou grandes grafos de dependências revelaria seus limites.

A auditoria da Trail of Bits na Miden já produziu mais do que um fluxo de trabalho especulativo. Ela entregou uma integração de editor, decompilador, analisador, modelo da VM, provas verificadas e descobertas concretas de segurança.

A questão duradoura é se as equipes conseguem manter esses artefatos alinhados aos sistemas que protegem. Desenvolvedores que avaliam a segurança assistida por agentes devem examinar os repositórios, inspecionar as premissas modeladas e perguntar onde controles verificáveis por máquina substituem a confiança no modelo. Esse é o padrão que vale levar para a próxima auditoria.