JavaScriptOfuscação VM

Há vários motivos para proteger seu código: impedir que qualquer pessoa simplesmente copie o seu trabalho (algo especialmente importante em projetos que rodam no cliente, como jogos em HTML5), tornar o código mais difícil de entender e modificar, e proteger um trabalho que ainda não foi pago, para que você possa mostrar ao cliente um build funcional sem entregar o código-fonte.

A ofuscação padrão reescreve seu JavaScript em um JavaScript mais difícil de ler: os nomes são substituídos, as strings são movidas e codificadas, o fluxo de controle é reestruturado, mas o resultado continua sendo JavaScript que um depurador consegue percorrer passo a passo. A ofuscação VM (máquina virtual) compila os corpos das suas funções em bytecode personalizado e inclui um interpretador embutido que o executa, de modo que a lógica protegida deixa de existir como JavaScript. Veja em Ofuscação VM quais funções são cobertas e como selecioná-las.

Sim. Defina vmTargetFunctionsMode como comment e marque cada função a proteger com /* javascript-obfuscator:vm */. Mantenha esses comentários em qualquer etapa de build que rode antes da ofuscação. Veja Selecionando funções específicas.

Não. Chaves de API, segredos e credenciais NUNCA devem ser armazenados em código de frontend. Mesmo com o maior nível de ofuscação, qualquer dado presente no JavaScript do frontend pode ser extraído por um atacante determinado. A ofuscação dificulta a engenharia reversa, mas não é criptografia e não deve ser usada para proteger segredos. Em vez disso, armazene os segredos no seu servidor de backend, use variáveis de ambiente no lado do servidor, faça proxy das chamadas de API pelo seu backend para esconder as chaves ou use tokens de curta duração emitidos pelo seu servidor.

A ofuscação aumenta o esforço para entender e modificar código, seja a análise feita por uma pessoa, por uma ferramenta ou por um assistente de IA; ela não garante que a engenharia reversa seja impossível. A execução continua observável em um ambiente controlado por um atacante. Mantenha segredos e decisões definitivas de segurança no servidor. Como a VM transforma o código.

Primeiro descarte as defesas de execução. VM Self Defending e VM Debug Protection interrompem a execução de propósito sob ferramentas de automação, navegadores headless e depuradores, e quando target não corresponde ao ambiente real, então rode os testes funcionais em um build de teste separado com elas desativadas. Se esse build ainda falhar, isole o problema com vmTargetFunctionsMode: 'comment', virtualizando uma função por vez. O guia de solução de problemas percorre cada etapa e lista o que incluir em um relatório de bug.

O ofuscador adiciona código: os identificadores recebem nomes gerados, as strings vão para um array de strings com funções de acesso (opcionalmente codificado) e, na ofuscação VM, um interpretador de máquina virtual inteiro é embutido junto com o seu bytecode. Não se preocupe demais com o tamanho - o código ofuscado comprime bem com gzip ou Brotli, que a maioria dos servidores já habilita por padrão.

Predefinições mais pesadas podem aumentar o tamanho da saída e o tempo de execução. Meça a inicialização, os caminhos frequentes e o tamanho comprimido do seu bundle em vez de confiar em multiplicadores fixos de lentidão. Referência de opções · Boas práticas

Não. Reescrever a saída pode quebrá-la, especialmente com Self Defending ou VM Self Defending, que detectam alterações no código. Você pode passar um minificador antes da ofuscação, desde que ele mantenha os comentários do javascript-obfuscator, como /* javascript-obfuscator:vm */.

Não guardamos o seu código-fonte. A ofuscação básica de JavaScript roda no seu navegador. A ofuscação VM e a de HTML enviam o código-fonte aos nossos servidores, que o processam e o descartam; quando uma requisição é maior que 4.4 MB, os planos Team e Business a enviam para um armazenamento temporário que é excluído após o processamento. Para lidar com abusos e analisar o uso, guardamos por três meses um hash SHA-256 de cada saída ofuscada e algumas das configurações usadas (como a predefinição, o target e as defesas da VM), nunca o código em si nem qualquer conteúdo dele. O histórico do painel fica armazenado apenas no seu navegador; gerencie-o em Histórico.

Não. O ofuscador não guarda os seus nomes originais, comentários ou formatação, então a saída não pode ser transformada de volta no seu código-fonte. Isso não é uma garantia de segurança (veja a pergunta sobre desofuscação acima), mas significa que você precisa guardar o original em local seguro.

Sim. Você pode selecionar "Node" como target nas opções de ofuscação para otimizar a saída para ambientes Node.js.

O suporte inclui sintaxe ES2015+, async/await, encadeamento opcional e campos privados de classe; teste sintaxe mais recente na versão do ofuscador que você selecionar. Compile TypeScript e JSX e empacote a aplicação antes de ofuscar - veja Compatibilidade de execução. Arquivos HTML são suportados por meio de parseHtml; veja Ofuscando arquivos HTML.

A saída ofuscada - incluindo o interpretador da VM e a camada Self Defending - tem suporte ativo e é testada em navegadores desktop evergreen e no iOS 16+ (aproximadamente os últimos 4 anos). Navegadores mais antigos funcionam em regime de melhor esforço, até um piso rígido de suporte a módulos ES2015; abaixo disso, incluindo o Internet Explorer, está fora de escopo.

Confira nossos planos e preços para proteção VM ou experimente o ambiente de testes online gratuito para ofuscação padrão. Leia o guia de primeiros passos para um passo a passo completo.