REA. A IA aprendeu a desmontar software. Seus segredos não podem estar lá dentro.

Neste mês, um projeto open-source chamado REA, Reverse Engineer Anything, chegou ao topo das tendências do GitHub. A proposta cabe numa linha. Dar a agentes de IA as ferramentas de engenharia reversa. Decompilar, entender, recriar. O agente abre o software, explica como ele funciona, mostra as evidências e constrói uma versão para o seu projeto.

Leia de novo. Constrói uma versão.

Quero falar sobre isso sem alarmismo e sem ingenuidade. Porque a maioria das empresas ainda trata o próprio código como cofre. E código nunca foi cofre. Agora, ele é uma vitrine com um agente de IA do lado de fora, lendo tudo.

O que é o REA, sem mistério

O REA é um servidor MCP, o Model Context Protocol, e uma linha de comando, de código aberto, licença MIT. Ele conecta agentes de codificação como Claude Code, Cursor, Codex e Gemini CLI a ferramentas clássicas de engenharia reversa. Ghidra, IDA e Hopper para binários nativos. JADX para aplicativos Android. Chrome DevTools para aplicações web e Electron.

O agente não precisa saber operar cada ferramenta. Ele pede, e o REA encaminha para a ferramenta certa. O alcance é amplo. Binários nativos, APKs, aplicações JavaScript com seus source maps, assemblies .NET, sites, WASM, contratos EVM, binários Go, firmware.

Na prática, o que antes exigia um especialista agora exige uma pergunta bem feita. “Como esse app faz isso?” E o agente vai buscar a resposta dentro do software.

O projeto deixa claro que nasceu para uso lícito. Pesquisa, educação, interoperabilidade, preservação de software, análise do que você possui ou está autorizado a examinar. E isso é verdade. A engenharia reversa é uma disciplina legítima. Pesquisadores usam para encontrar falhas. Empresas usam para garantir interoperabilidade. Eu mesmo, como designer, passei a vida desmontando produtos para entender por que funcionavam.

Mas ferramenta não escolhe quem a usa. O que o pesquisador faz numa tarde, o mal-intencionado também faz. E agora ambos fazem com um agente incansável trabalhando por eles.

A barreira caiu

Esse é o ponto que quero cravar. A engenharia reversa sempre foi possível. O que a protegia era o custo. Tempo, conhecimento, ferramentas. Muita empresa contava, sem admitir, com esse custo como camada de segurança.

O REA, e tudo o que virá depois dele, transforma esse custo em quase zero. Um aplicativo Android, um front-end web, um instalador desktop, um firmware. Tudo pode ser lido, explicado e reconstruído por um agente em uma fração do tempo.

E o problema começa quando o produto desmontado revela o que nunca deveria estar ali. Uma senha. Uma chave de API. Um token de acesso à nuvem. A lógica de licenciamento inteira. O endpoint interno que ninguém documentou. Um agente não se cansa de procurar. Ele vai achar.

Os perigos reais

O primeiro perigo é o óbvio. Clonagem. Quem entende como o seu produto funciona por dentro consegue reproduzi-lo, modificá-lo e redistribuí-lo. Com um agente fazendo o trabalho pesado, anos de construção viram uma tarde de cópia.

O segundo é mais silencioso e mais caro. Acesso. Uma credencial esquecida dentro do código não expõe só o aplicativo. Expõe o banco de dados, o storage, a conta de nuvem, os dados dos seus clientes. O atacante não precisa invadir nada. Ele usa a chave que você deixou na porta.

O terceiro é o ataque à confiança. Versões modificadas do seu app circulando com o seu nome, a sua marca, a sua cara, mas com código malicioso por dentro. O usuário não sabe a diferença. E quem paga a conta reputacional é você.

Software que já foi aberto, copiado e clonado

Isso não é teoria. A história recente é um catálogo de lições caras.

O WhatsApp convive há anos com versões modificadas como o GB WhatsApp, construídas a partir da engenharia reversa do aplicativo original. Elas prometem recursos extras e entregam riscos extras. O próprio WhatsApp passou a banir contas que usam esses clones, porque não há como garantir a segurança de um código que ninguém audita.

O Snapchat aprendeu em 2014. Pesquisadores fizeram a engenharia reversa da API privada do aplicativo, publicaram a documentação e alertaram sobre uma falha. Pouco depois, milhões de nomes de usuário e números de telefone foram extraídos e publicados. A API era privada só no nome.

O Pokémon GO, em 2016, viu sua comunicação ser desmontada em semanas. Surgiram mapas, bots e ferramentas de terceiros alimentados diretamente pelos servidores da Niantic, que precisou reagir endurecendo a proteção da API.

E em 2026, o caso que mais me fez pensar. A Anthropic publicou por engano, num pacote npm, um arquivo de source map do Claude Code. Era o mapa para reconstruir o código-fonte original. Cerca de 512 mil linhas ficaram expostas, espelhadas e estudadas pelo mundo inteiro em questão de horas. Uma das empresas mais sofisticadas de IA do planeta, derrubada por um arquivo de configuração de empacotamento esquecido. Se aconteceu lá, acontece em qualquer lugar.

O erro mais caro: segredos dentro do código

Agora o ponto central deste artigo. A maior vulnerabilidade não é a engenharia reversa. É o que ela encontra.

Em 2016, a Uber sofreu um vazamento que atingiu dados de 57 milhões de usuários e motoristas. O caminho dos atacantes passou por um repositório de código onde estavam credenciais de acesso à nuvem da empresa. A chave estava no código. O código foi acessado. O resto é história.

A Toyota revelou em 2022 que parte do código-fonte de um serviço conectado ficou público no GitHub por cerca de cinco anos. Dentro dele, uma chave de acesso a um servidor de dados. Quase 300 mil endereços de e-mail de clientes ficaram expostos.

No mesmo ano, a Symantec analisou aplicativos móveis e encontrou 1.859 apps com credenciais da AWS escritas diretamente no código. Em um dos casos, o acesso abria caminho para impressões digitais de centenas de milhares de pessoas. Biometria não se troca como senha.

E o problema só cresce. O relatório State of Secrets Sprawl 2025, da GitGuardian, contou cerca de 23,8 milhões de novos segredos expostos em repositórios públicos do GitHub em um único ano. E a maior parte dos segredos vazados continua válida muito tempo depois. Ninguém rotacionou. Ninguém percebeu.

Repare no padrão. Nenhum desses casos exigiu um gênio do crime. Exigiu só alguém olhando com atenção para algo que deveria ser privado e não era.

A regra que não se negocia

Então vou cravar a regra. Senha, chave de API, token, certificado, string de conexão, segredo de assinatura. Nada disso mora no código. Nunca. Nem no app, nem no front-end, nem no repositório privado, nem no commit de teste que você ia apagar depois.

Segredo mora no servidor. Em um cofre de segredos, um vault, um gerenciador de credenciais da nuvem. Ele é injetado em tempo de execução, no ambiente que você controla, com acesso restrito a quem precisa. O código pede. O servidor decide se entrega.

O aplicativo que roda na mão do cliente deve ser tratado como território público. Ele não guarda segredo. Ele não toma decisão sensível. Ele não fala direto com o banco de dados nem com a API paga. Ele fala com o seu back-end, e o back-end fala com o resto, autenticando, limitando, registrando. Se a regra de negócio importa, ela roda no servidor. Se a validação importa, ela roda no servidor. O que está no cliente pode e vai ser lido.

Segurança é arquitetura, não remendo

Ofuscar o código ajuda. Atrasa o curioso. Não para o determinado. Ofuscação é cortina, não parede.

A proteção de verdade é desenhada em camadas. Segredos centralizados em cofre e nunca no repositório. Credenciais de curta duração, que expiram sozinhas, em vez de chaves eternas. Rotação periódica, para que um vazamento antigo vire uma chave inútil. Privilégio mínimo, para que cada chave abra só a porta que precisa abrir. Varredura automática de segredos antes de cada commit e em cada pipeline, porque o erro humano vai acontecer e a máquina precisa pegá-lo antes do mundo. Atestação do aplicativo, para o servidor saber se está falando com o app legítimo ou com um clone. Monitoramento, para perceber o uso anômalo antes que ele vire manchete.

E um ponto que vejo pouca gente discutir. A IA aperta os dois lados da equação ao mesmo tempo. De um lado, ferramentas como o REA tornam a leitura do seu software barata para qualquer um. Do outro, times inteiros geram código com assistentes em velocidade inédita. Protótipos viram produção em dias. E é exatamente nessa pressa que a chave da API do modelo de linguagem vai parar no front-end, à vista de qualquer um, gerando uma conta que ninguém previu. Agentes de IA, por sua vez, operam com credenciais e acessam sistemas reais. Um agente com uma chave exposta não é um assistente. É uma porta aberta com autonomia.

Velocidade sem governança é só risco acelerado.

O olhar de quem constrói

Venho do design. E aprendi cedo que boa experiência é aquela que esconde a complexidade do usuário sem esconder a responsabilidade de quem constrói. Segurança é a mesma coisa. Ela não aparece na tela. Ninguém elogia o segredo que não vazou. Mas ela é parte da experiência tanto quanto o botão bem desenhado.

Na Mars, tratamos isso como fundamento. A maior barreira da IA corporativa é confiança, não tecnologia. E confiança não nasce de promessa. Nasce de arquitetura. De saber exatamente onde cada segredo mora, quem acessa, por quanto tempo e com qual rastro. LGPD by design começa aí, muito antes do primeiro dado pessoal entrar no sistema.

Governança não é burocracia. É o que permite crescer sem medo de abrir o próprio produto para o mundo. Porque você vai abrir. Toda vez que publicar.

O convite

Faça um exercício simples esta semana. Peça ao seu time para procurar senhas, chaves e tokens no código, no histórico do repositório e nos aplicativos publicados. Não para achar culpados. Para achar portas abertas.

Se a resposta for “não temos nada disso”, desconfie com carinho e peça uma varredura automática. Se a resposta for “temos algumas”, parabéns. Você acabou de descobrir antes do atacante.

Assuma que o seu código será lido. Não por uma pessoa. Por um agente, com paciência infinita. Construa como se já tivesse sido. E deixe os segredos onde eles pertencem. No servidor. Sob controle. Jamais no código.

O melhor modo de prever o futuro é criá-lo. E nenhum futuro digital se sustenta em cima de uma chave esquecida. Quanto do seu produto você ainda trata como cofre, quando ele já é vitrine?