Migração do Protector4J v5 para o v6

⚠️ Pela segurança do seu código, atualize para o v6 o quanto antes

A engenharia reversa assistida por IA está reduzindo rapidamente a barreira para a análise de código. A força de proteção do v5 já não é suficiente diante do cenário atual de ameaças, e permanecer nele expõe seu código a um risco maior de divulgação. Recomendamos fortemente migrar suas aplicações protegidas para o Protector4J v6 o quanto antes.

1. Por que atualizar para o v6

As ferramentas de IA estão tornando a análise de código e a engenharia reversa cada vez mais fáceis. A ofuscação tradicional de bytecode e a criptografia simples já não são suficientes para os novos desafios de segurança.

Para oferecer uma proteção mais forte ao código Java, reformulamos completamente o Protector4J v6. Sua nova arquitetura P4JX introduz mais de cem medidas de segurança em criptografia de código, carregamento de classes, validação em tempo de execução, proteção contra depuração e outras camadas. Mesmo com ferramentas avançadas de análise por IA, a engenharia reversa do código protegido continua extremamente difícil.

Por isso, o v6 difere significativamente do v5 na arquitetura de proteção, na configuração, na sintaxe da linha de comando e no formato de saída.

2. Principais diferenças entre v5 e v6

Áreav5v6
Arquitetura de proteçãoUsa o formato de criptografia e o ambiente de execução do v5Usa a nova arquitetura P4JX e um VLX JRE personalizado
Nível de proteçãoProjetado para ferramentas tradicionais de engenharia reversaAdiciona mais de cem medidas de segurança, com atenção especial à engenharia reversa assistida por IA
ConfiguraçãoMenos opções e uso principal de arquivos de tarefaMais opções de proteção e um modo de compatibilidade que simplifica a configuração
Linha de comandop4j -t <type> -f <task.yml>p4j <command> <input> <output> [options]
Arquivos de configuraçãoUsa arquivos de tarefa YAML do v5Os arquivos do v5 não são mais aceitos; o v6 pode ser executado apenas com argumentos da linha de comando
Publicação e atualizaçõesPermite atualizar alguns arquivos com KeySeed e onlyEncryptJarFilesGere novamente e publique todo o diretório de saída em conjunto

A mudança mais importante é que os arquivos criptografados, os ambientes de execução e os arquivos de tarefa YAML do v5 não podem ser reutilizados diretamente no v6.

3. Configuração simples com o modo de compatibilidade

Uma proteção mais forte exige mais opções para o escopo de proteção, o ambiente de execução, o layout, a compatibilidade e as plataformas de destino. Para evitar que o usuário tenha de entender todas as opções antes de começar, o v6 oferece um modo de compatibilidade.

Na interface gráfica, use o modo Simple (recomendado):

  1. Selecione o tipo de aplicação.
  2. Selecione o JAR ou WAR original.
  3. Selecione a versão do Java e as plataformas de destino.
  4. Permita que o Protector4J analise a aplicação e escolha automaticamente configurações de compatibilidade conservadoras.
  5. Confirme o diretório de saída e inicie a proteção.

Mude para o modo Advanced somente quando precisar controlar com precisão o escopo de proteção, o layout do Spring Boot, as opções da JVM, o JavaFX ou outras configurações.

Na linha de comando, use --compat-apply. Essa opção analisa a aplicação, aplica recomendações de compatibilidade conservadoras e gera o pacote protegido:

p4j javaapp app.jar dist --compat-apply

O modo de compatibilidade simplifica a configuração, mas não substitui testes reais. Depois de gerar o pacote, verifique a inicialização, os principais recursos, a reflexão, a serialização, o acesso ao banco de dados e o comportamento de frameworks de terceiros.

4. A sintaxe da linha de comando mudou completamente

A CLI do v5 depende de um arquivo de tarefa YAML:

p4j -t java -f java-task.yml

O v6 pode ser executado sem arquivo de configuração e receber todas as opções como argumentos da linha de comando:

# Aplicação Java comum
p4j javaapp app.jar dist --compat-apply

# Aplicação Spring Boot
p4j springboot app.jar dist --compat-apply

# WAR do Tomcat
p4j tomcat app.war dist --compat-apply --context /app

# Biblioteca Java
p4j encode library.jar library.p4jx

Correspondência entre tipos de aplicação:

Tipo do v5Comando do v6
javajavaapp
spring-bootspringboot
tomcattomcat
java-libencode

Observe que encode no v6 protege todas as classes da biblioteca e requer um VLX JRE para carregá-las. Ele não é um substituto equivalente ao fluxo do v5, que convertia métodos selecionados em código nativo e continuava permitindo o uso de um JRE padrão.

O v6 ainda oferece suporte a arquivos de tarefa, mas é necessário exportar um novo p4j-task.yml pela interface gráfica do v6:

p4j --task-file p4j-task.yml

Não tente editar e reutilizar um arquivo YAML do v5. Os formatos de tarefa do v5 e do v6 são incompatíveis. Reconfigure a tarefa na interface gráfica ou reescreva o comando com base na documentação mais recente da CLI.

Para ver todos os comandos e opções, consulte a Referência da CLI do v6.

5. Migrar do v5 para o v6

Siga este único fluxo de migração:

Manter um backup do v5 → localizar o JAR/WAR original → gerar novamente no modo de compatibilidade do v6 → testar → mudar

Etapa 1: manter o ambiente do v5

Mantenha o diretório de saída funcional do v5 e o procedimento de inicialização para poder reverter, se necessário. Não substitua o diretório do v5.

Etapa 2: preparar a entrada original

Localize o JAR, o JAR do Spring Boot ou o WAR original que não tenha sido criptografado pelo v5. O diretório vlxlib, os JARs criptografados e o vlxjre gerados pelo v5 não podem ser usados como entrada do v6.

Etapa 3: gerar novamente com o v6

Para uso interativo, comece com o modo Simple da interface gráfica. Para automação, use diretamente argumentos da linha de comando com --compat-apply. Grave a saída em um novo diretório e não a misture com arquivos do v5.

Etapa 4: validar a saída do v6

Inicie a aplicação com o arquivo gerado run.sh, run.command ou run.bat. Publique o vlxjre gerado junto com a aplicação. Não o substitua pelo JRE do sistema nem pelo ambiente de execução de outra tarefa.

Verifique pelo menos se:

  • a aplicação inicia e encerra normalmente;
  • as principais funções de negócio operam corretamente;
  • reflexão, serialização, ORM, proxies do Spring e carregamento de recursos funcionam corretamente;
  • o pacote foi executado em cada sistema operacional de destino.

Etapa 5: mudar o pacote completo

Após a validação, mude para todo o diretório de saída do v6. Nas atualizações futuras, gere novamente um pacote completo a partir do JAR ou WAR original, em vez de usar a atualização parcial do v5 KeySeed + onlyEncryptJarFiles.

6. Recomendação de atualização

A engenharia reversa assistida por IA está reduzindo rapidamente a barreira para a análise de código. Continuar usando o v5 aumenta o risco de exposição do código. Por motivos de segurança, recomendamos atualizar do v5 para o v6 o mais rápido possível.

Faça uma migração paralela: mantenha o v5 disponível para reversão, gere um novo pacote com o modo de compatibilidade do v6, valide-o e somente então mude o ambiente de produção.

Documentação relacionada: