Como o Protector4J funciona?
Problemas da solução atual de proteção de código Java
Antes de entender como o Protector4J funciona, vamos primeiro conhecer os problemas que existem em outras soluções de proteção de código Java.
Ofuscação de código
Devido à alta natureza semântica do bytecode JVM, é muito fácil analisar e ler. Com depuração dinâmica, sua lógica de execução pode ser facilmente analisada, portanto a ofuscação não é uma solução de proteção confiável.
Para mais informações, consulte o artigo: https://protector4j.com/pt/articles/the-issues-of-code-obfuscation/
Criptografia de arquivos class
Devido à existência do mecanismo de attachment da JVM, todos os chamados códigos criptografados que não foram desvinculados do JRE normal podem ser facilmente obtidos através de ferramentas de attachment. Portanto, esta é a solução de proteção mais ineficaz.
Para mais informações, consulte o artigo: https://protector4j.com/pt/articles/the-issues-of-class-encryption/
Proteção VMP
A proteção por virtualização é a forma mais segura de proteção de código, mas devido ao seu severo impacto no desempenho, só pode ser aplicada a código crítico em um programa. Outros códigos ainda permanecem em risco de exposição. Ao direcionar outras partes do código, o cracker ainda pode obter informações funcionais do código virtualizado.
Consulte o artigo para detalhes específicos: https://protector4j.com/pt/articles/the-issues-of-vm-protection/
Compilação AOT
A configuração e compilação AOT é muito difícil, e há uma alta probabilidade de falha na compilação. Mesmo que a compilação seja bem-sucedida, a lógica do código é apenas transformada da representação em bytecode para a representação em código de máquina, e sua lógica inerente ainda existe sem nenhuma proteção especial. Se alguém conseguir entender seu mecanismo de compilação e execução, código legível ainda pode ser obtido por engenharia reversa.
Para mais informações, consulte o artigo: https://protector4j.com/pt/articles/the-issues-of-aot-protection/
Como o Protector4J funciona?
Definimos um formato de pacote de compressão privado: JARX
Para proteger o código Java, criamos um formato de documento compactado privado chamado JARX e o integramos ao runtime da JVM. Um arquivo JAR processado pelo Protector4J é transformado no formato JARX.
Fizemos personalização e modificação profunda na JVM
Através de um estudo aprofundado da JVM, fizemos personalizações e modificações profundas nela. Removemos todos os mecanismos adicionais e aplicamos muitas medidas de fortalecimento e otimização no nível de segurança binária. Isso impede que crackers usem métodos existentes para exportar suas informações de classe. Acreditamos que, com a força atual, a aplicação criptografada protegida pelo Protector4J tem um alto nível de segurança. No entanto, a batalha entre cracking e anti-cracking está sempre em constante melhoria. Continuaremos a melhorar nossas soluções de criptografia e proteção para aprimorar constantemente a segurança da aplicação.