Engenharia reversa com I.A.: o que fica exposto no seu aplicativo e como proteger

O que mudou com a I.A.

Analisar um aplicativo sempre foi possível, mas exigia tempo e um conhecimento raro. Com ferramentas como o REA, que viralizou em outubro de 2026, um agente de I.A. opera programas de análise como Ghidra e JADX, lê aplicativos em JavaScript, Electron, .NET e Android e devolve conclusões em linguagem comum.

Isso não cria vulnerabilidades novas. Torna as antigas mais fáceis de encontrar, por quem defende e por quem ataca. A pergunta para quem publica software passou a ser: o que alguém consegue extrair do meu aplicativo em uma tarde?

O que fica exposto no seu aplicativo

Tudo o que roda no aparelho do usuário pode ser lido: o aplicativo de celular, o programa de computador, a extensão de navegador e o JavaScript do seu site. Os achados mais comuns:

• ✓Chaves de API e tokens escritos no código, inclusive de serviços pagos de I.A.
• ✓Endereços e parâmetros das suas APIs internas.
• ✓Regras de negócio que deveriam estar no servidor, como limites de plano, cálculo de desconto e liberação de recursos pagos.
• ✓Recursos escondidos e em teste, ativados por chaves no próprio aplicativo.
• ✓Mensagens de depuração e comentários que revelam a estrutura do sistema.
• ✓Bibliotecas de terceiros e suas versões, que podem ter vulnerabilidades conhecidas.

O tamanho do problema

Credencial exposta no código é um problema antigo que só cresce. O relatório State of Secrets Sprawl 2026, da GitGuardian, contou 28,65 milhões de novos segredos (chaves, senhas e tokens) expostos em repositórios públicos do GitHub em 2025, alta de 34% sobre o ano anterior. Os segredos de serviços de I.A. somaram 1,27 milhão, alta de 81%.

O mesmo relatório mostrou que os commits feitos com ajuda do Claude Code vazaram segredos em 3,2% dos casos, contra 1,5% da média do GitHub público. A leitura não é que uma ferramenta seja pior que outra: código escrito mais rápido precisa de mais revisão.

O que dizem as referências de segurança

O OWASP Mobile Top 10, principal referência de riscos para aplicativos móveis, coloca o uso inadequado de credenciais (M1) em primeiro lugar e inclui a proteção insuficiente do binário (M7), que trata justamente da engenharia reversa e da adulteração de aplicativos.

A lição está na ordem dos itens: proteger o binário com ofuscação e verificações de integridade aumenta o custo da análise, mas não a impede. O que resolve é não colocar no aplicativo aquilo que não pode vazar.

Checklist de proteção

Antes da próxima versão, confira estes oito pontos:

• ✓Nenhum segredo no aplicativo: chaves de serviços pagos ficam no servidor, que faz as chamadas em nome do usuário.
• ✓Regras no servidor: preço, desconto, limite de plano e permissões são decididos no back-end, nunca no aplicativo.
• ✓Autorização em toda requisição: o servidor confere quem é o usuário e o que ele pode fazer, sem confiar no que o aplicativo diz.
• ✓Varredura de segredos: ative a detecção de segredos no repositório e na esteira de publicação, e troque imediatamente qualquer chave exposta.
• ✓Ofuscação como camada extra: em aplicativos móveis, ofuscação e verificação de integridade dificultam a análise e a adulteração.
• ✓Limpeza antes de publicar: remova mensagens de depuração, comentários internos e recursos de teste do pacote final.
• ✓Dependências em dia: atualize as bibliotecas e acompanhe os alertas de vulnerabilidade.
• ✓Monitoramento: limites de uso e alertas para padrões anormais de chamadas às suas APIs.

Use a mesma I.A. a seu favor

Se qualquer pessoa pode analisar o seu aplicativo com um agente, a primeira deve ser alguém do seu time. Rodar uma análise autorizada no próprio produto, antes de cada versão importante, mostra o que um atacante veria. Para entender os limites legais de analisar software, inclusive de terceiros, veja engenharia reversa de software é crime?.

Também vale ter um canal para pesquisadores relatarem falhas. Um arquivo security.txt no site, padronizado pela RFC 9116, indica o contato da equipe responsável.

O fator humano

A maior parte dos vazamentos não vem de ataques sofisticados, e sim da rotina: a chave colada no código para testar, o recurso de depuração que ficou na versão final, o código gerado por I.A. que ninguém revisou. Isso se resolve com processo e treinamento.

No treinamento em I.A. para equipes, incluímos o uso seguro de assistentes de código, e na consultoria em I.A. ajudamos a definir a política de uso e a revisar os riscos com dados. Para o panorama completo do tema, leia o guia de engenharia reversa com I.A..

• ServiçoConsultoria em I.A. para EmpresasMapeamento de processos, identificação de oportunidades e roadmap de implementação de I.A. no seu negócio, com estratégia antes da execução.
• ServiçoTreinamento de Equipes em I.A.Capacitação prática para o seu time aprender a usar I.A. no dia a dia, direto no contexto da sua empresa, não em teoria genérica.
• BlogEngenharia reversa com I.A.: o guia completo sobre o REA, os clones da Adobe e o que muda de verdadeO que é engenharia reversa com I.A., o que o REA e os apps do ArtCraft realmente entregam, o que diz a lei brasileira e o que muda para a sua empresa.
• BlogEngenharia reversa de software é crime no Brasil? O que diz a leiO que a Lei do Software e a Lei de Direitos Autorais dizem sobre engenharia reversa, quando analisar um programa vira problema e o que muda com a I.A.