Como Fazer Engenharia Reversa em um Aplicativo com o Claude Code

Engenharia reversa significa estudar um software já pronto para entender como ele funciona, geralmente sem ter seu código-fonte original ou qualquer um dos documentos de design que entraram na sua construção. Você observa o que ele faz, como foi montado, e com o que ele se comunica, e trabalha de trás para frente a partir disso até chegar a um modelo do seu comportamento.

As pessoas fazem isso por motivos que são, na maioria, pouco glamorosos e, na maioria, legítimos. Pesquisadores de segurança fazem engenharia reversa de programas para encontrar uma vulnerabilidade antes que alguém com intenções piores o faça. Desenvolvedores fazem engenharia reversa de formatos de arquivo e protocolos de rede para que um programa novo consiga interoperar com um antigo que ninguém vai documentar para eles. Arquivistas e hobbistas fazem engenharia reversa de software antigo para mantê-lo funcionando depois que o hardware original e a empresa por trás dele já desapareceram. E às vezes o motivo é simplesmente que um programa do qual você depende faz algo sem documentação, e você precisa saber o quê, antes de poder confiar nele ou contorná-lo.

Nada disso é novo. Pesquisadores de segurança e arquivistas de software fazem isso há décadas, com disassemblers e debuggers, muito antes de qualquer agente de IA existir. O que mudou foi a velocidade: um agente consegue ler uma listagem de disassembly ou um método decompilado e resumi-lo em segundos, um trabalho que antes levava horas de uma pessoa qualificada. Esse é um ganho real de capacidade, e é exatamente por isso que o limite legal e ético discutido mais adiante neste guia importa mais agora, não menos, já que o gargalo que antes freava as pessoas entre a curiosidade e a cópia praticamente desapareceu.

O restante deste guia é específico: ele percorre uma ferramenta, chamada REA, que conecta um agente como o Claude Code a esse tipo de análise, e os hábitos que vale a pena ter em prática antes de apontá-la para qualquer coisa.

A distinção que mais importa aqui é a que existe entre estudar como algo funciona e copiar sua expressão protegida. Fazer engenharia reversa para aprender uma interface, um formato de arquivo, ou um comportamento é, legalmente, um ato diferente de pegar o código ou os ativos de outra pessoa e colocá-los em um produto seu.

A prática construída em torno dessa distinção é chamada de clean-room design (desenvolvimento em sala limpa). Uma pessoa ou uma sessão estuda o original e escreve uma especificação simples do que ele faz: suas interfaces, seus formatos de dados, seu comportamento, com as próprias palavras, sem nenhum código original copiado para o documento. Uma pessoa ou sessão separada, que nunca viu o original, então constrói uma nova implementação a partir apenas dessa especificação. O ponto é que o resultado final pode ser demonstrado como tendo vindo de uma descrição escrita, não do trabalho original em si.

Duas decisões judiciais mais antigas dos EUA são citadas com frequência sobre esse ponto, e vale a pena conhecê-las, embora nenhuma delas seja uma licença geral para fazer engenharia reversa de qualquer coisa. Sega Enterprises Ltd. v. Accolade, Inc., decidido pelo Nono Circuito em 1992, envolveu uma empresa que fez engenharia reversa do sistema de bloqueio de um console de videogame para que seus próprios jogos funcionassem naquele console. O tribunal entendeu que a cópia intermediária envolvida nessa engenharia reversa, feita para alcançar elementos funcionais não protegidos necessários para que os jogos funcionassem no hardware, era fair use nos fatos específicos daquele caso. Sony Computer Entertainment, Inc. v. Connectix Corp., decidido pelo mesmo tribunal em 2000, chegou a uma conclusão parecida quando uma empresa fez engenharia reversa do software de inicialização de um console para construir um emulador para um tipo diferente de computador, tratando novamente a cópia ao longo do caminho como fair use em função de um produto interoperável escrito de forma independente.

Trate as duas decisões como contexto histórico, não como conselho para a sua situação. São duas decisões específicas de tribunais de apelação sobre fatos específicos, fair use é decidido caso a caso, outros países traçam essas linhas de forma diferente, e leis posteriores voltadas a contornar proteção contra cópia restringem isso bastante para software ligado a DRM. Qualquer pessoa planejando construir algo sobre esse tipo de trabalho, especialmente algo destinado a ser lançado ou vendido, deve conversar com um advogado de verdade antes de confiar em qualquer uma dessas decisões.

O REA traça sua própria linha, independentemente do que um tribunal possa eventualmente decidir sobre qualquer caso específico. Segundo o DISCLAIMER.md do projeto, o REA não apoia e não vai ajudar a contornar DRM, verificações de licença, sistemas anti-cheat, ou outras medidas técnicas de proteção, nem a copiar software proprietário ou seu código e ativos protegidos, e o projeto afirma claramente que o resultado da análise não concede nenhum direito sobre o programa original. A regra prática que resulta disso: analise apenas software que você possui, escreveu você mesmo, ou está de outra forma autorizado a examinar.

A versão do Node.js importa aqui. O próprio README do REA declara seu requisito exatamente como: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), ou 26.12.1+, além do npm. Confira isso no README em vigor antes de instalar, já que esse tipo de requisito muda entre versões.

O comando de configuração é npx rea-agents setup. Segundo o README, ele guia você na escolha de quais agentes registrar com o REA, mostra as mudanças que propõe fazer antes de você aprová-las, e mantém backups da sua configuração existente. Reinicie seu agente depois disso para que ele capte o novo servidor MCP; as próprias instruções do REA dizem isso claramente.

Para uma instalação de linha de comando persistente, em vez de uma execução única via npx, o README descreve npm install --global rea-agents, seguido de rea --help para ver o que está disponível. A partir de uma instalação global, rea update leva você a uma nova versão no seu próprio ritmo em vez de automaticamente, e executar npx rea-agents@latest setup depois atualiza o registro do agente para corresponder.

Antes de apontar o REA para qualquer coisa que você não possua totalmente, teste primeiro em um aplicativo pequeno que você mesmo escreveu. Com o REA configurado, peça ao Claude Code para abrir esse app pequeno e descrever o que ele vê, função por função, e compare com o que você já sabe que escreveu. Esse único exercício confirma se a configuração realmente funcionou, e dá a você uma noção de como a evidência do REA, um arquivo, uma função, uma chamada, se apresenta na prática antes de você confiar nela para algo que importa.

Transforme a ideia de clean-room apresentada antes em algo concreto, usando duas sessões separadas do Claude Code. A primeira é uma sessão de especificação: aponte o REA para o software que você está autorizado a estudar, e peça ao agente para escrever uma especificação em linguagem simples de suas interfaces, seus formatos de dados, e o comportamento de suas funções principais, totalmente com suas próprias palavras, sem nenhum código original ou pseudocódigo copiado literalmente no documento.

A segunda é uma sessão de build, iniciada do zero, sem nenhuma memória da primeira. Dê a ela apenas o arquivo de especificação, nada mais: não o binário original, não a transcrição da primeira sessão, não o resultado bruto do REA. Peça que ela construa uma implementação nova e independente que atenda à especificação, e que avise quando algo nessa especificação for ambíguo, em vez de simplesmente supor o que o programa original deve ter feito.

Manter essas sessões genuinamente separadas, não como duas fases de uma mesma conversa longa, é a parte que importa. Uma única sessão que estudou o original e depois escreveu o substituto borrou exatamente a fronteira que o clean-room design existe para manter nítida, já que não há como demonstrar, depois do fato, que a segunda metade não se apoiou na primeira.

Seja realista sobre o que isso garante. Um fluxo de trabalho disciplinado em duas sessões é uma prática que sustenta um argumento de clean-room posterior, caso alguém pergunte como algo foi construído. Não é uma garantia legal por si só, e não substitui ter um advogado de verdade olhando para qualquer coisa que você planeje lançar ou vender.