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
| Área | v5 | v6 |
|---|---|---|
| Arquitetura de proteção | Usa o formato de criptografia e o ambiente de execução do v5 | Usa a nova arquitetura P4JX e um VLX JRE personalizado |
| Nível de proteção | Projetado para ferramentas tradicionais de engenharia reversa | Adiciona mais de cem medidas de segurança, com atenção especial à engenharia reversa assistida por IA |
| Configuração | Menos opções e uso principal de arquivos de tarefa | Mais opções de proteção e um modo de compatibilidade que simplifica a configuração |
| Linha de comando | p4j -t <type> -f <task.yml> | p4j <command> <input> <output> [options] |
| Arquivos de configuração | Usa arquivos de tarefa YAML do v5 | Os 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ções | Permite atualizar alguns arquivos com KeySeed e onlyEncryptJarFiles | Gere 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):
- Selecione o tipo de aplicação.
- Selecione o JAR ou WAR original.
- Selecione a versão do Java e as plataformas de destino.
- Permita que o Protector4J analise a aplicação e escolha automaticamente configurações de compatibilidade conservadoras.
- 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 v5 | Comando do v6 |
|---|---|
java | javaapp |
spring-boot | springboot |
tomcat | tomcat |
java-lib | encode |
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: