Proteger bibliotecas Java

A criptografia de bibliotecas corresponde ao comando de baixo nível encode. Ela gera somente o arquivo protegido: não copia nenhum tempo de execução nem cria scripts de inicialização.

1. Pela interface gráfica

1. Na página do tipo de aplicativo, escolha Criptografia de bibliotecas. Se precisar de um pacote que possa ser iniciado diretamente, escolha Aplicação Java, Spring Boot ou Tomcat WAR.

   

2. Selecione o JAR de entrada, a versão do Java correspondente ao ambiente que vai carregá-lo e as plataformas-alvo, e escolha entre modo simples ou avançado. A saída de uma biblioteca não contém vlxjre, mas essas escolhas ainda determinam a identidade de tempo de execução ligada ao arquivo; por isso, não misture saídas de plataformas diferentes só para reduzir o número de artefatos.

   

3. O modo simples examina o JAR de entrada e aplica as recomendações de camada ZIP para scanners e de sufixo de arquivo que a criptografia de bibliotecas admite. Todas as entradas .class do JAR continuam sendo criptografadas e os demais recursos ficam intactos.

4. O modo avançado permite configurar:

   • Desativar o JIT para métodos protegidos: os métodos protegidos rodam apenas no interpretador.
   • Anexar camada ZIP para scanners: oferece recursos públicos e esboços de metadados às ferramentas que leem diretamente o diretório central do ZIP.
   • Verificação de compatibilidade...: procura riscos como acesso ao ZIP, suposições sobre sufixos, uso de classes JNI e nativas, e leitura de bytecode em tempo de execução.

5. Na página de saída, informe o nome completo do arquivo de saída, normalmente com o sufixo .p4jx. Use .jar apenas quando uma integração exigir. A configuração Sufixo do arquivo da página avançada, ou a recomendação da verificação, alterna o nome escolhido entre .p4jx e .jar. Confira a versão do Java, as plataformas-alvo, o ajuste do JIT e a camada para scanners, e clique em Executar proteção.

   Uma tarefa de plataforma única grava exatamente no caminho escolhido. Ao marcar várias plataformas-alvo, a interface cria uma subpasta por plataforma ao lado desse arquivo e grava em cada uma o arquivo correspondente.

2. Quando usar

• Para proteger JAR próprios que fazem parte de outro aplicativo P4JX sob seu controle;
• para carregar um arquivo P4JX a partir de um iniciador já existente;
• em integrações avançadas nas quais você mesmo administra toda a pasta de entrega.

Se estiver construindo um aplicativo executável comum, um aplicativo Spring Boot ou uma implantação do Tomcat, use o comando de empacotamento correspondente.

3. Comandos básicos

p4j encode library.jar library.p4jx

A forma abreviada também funciona:

p4j library.jar library.p4jx

encode grava exatamente o nome de saída informado, de modo que ambos os comandos produzem um arquivo P4JX:

p4j encode library.jar library.p4jx
p4j encode library.jar library.jar

4. Camada ZIP

p4j encode library.jar library.p4jx \
  --zip-overlay scanner

A camada contém apenas recursos públicos, diretórios e esboços de metadados, para que as ferramentas que leem diretamente o diretório central do ZIP continuem funcionando. Ela não expõe os métodos protegidos reais nem transforma o arquivo P4JX num JAR comum.

5. Requisitos do tempo de execução

O encode de baixo nível não gera vlxjre, então você precisa fornecer um tempo de execução VLX compatível com a identidade usada na codificação. Evite:

• carregar o arquivo com um OpenJDK ou Oracle JDK comum;
• copiar lib/modules ou bibliotecas nativas do pacote de outra versão;
• combinar o arquivo com um tempo de execução de outra plataforma-alvo, outra linha do JDK ou outra execução de codificação.

Em projetos de entrega comuns, prefira os comandos de empacotamento de nível mais alto, que mantêm essas correspondências por você.

6. Licença

Gerar um arquivo exige uma licença emitida pelo servidor, que fica embutida no resultado. Contas licenciadas e o modo de avaliação passam pela mesma verificação de arquivo. Em ambientes automatizados, nunca deixe a senha fixa num script de tarefa exportado.