Proteção de código no lado Servidor

Acredito que este é o melhor forum para perguntar isto.
Por favor, vamos deixar de lado todo o papo conceitual sobre software livre, venda de serviços e etc…

Preciso proteger de descompilação as classes da minha aplicação que rodam no servidor. Ou pelo menos, evitar que qualquer pessoa simplesmente baixe um descompilador e tenha acesso ao fonte original. Estou falando de dificultar as coisas e restringir o numero de pessoas capazes de conseguir o codigo fonte.

A minha idéia :idea: é criar uma biblioteca C++ que valide alguns parametros de instalação e faça uma criptografia de um bytearray (byte[]).
Esta biblioteca seria chamada por uma classe java.lang.instrument.Transformer via JNI.
A tal classe Transformer recebe como parametro um bytearray contendo a classe a ser instancia pela JVM. Este transformer é chamado pelo parametro da JVM5, -javaagent indicando um JAR com a classe PreMain.

Ou seja, para cada classe que será instanciada, será chamado a biblioteca C++ que irá validar a permissão de execução (por exemplo quem assinou o JAR da PreMain) e depois descriptografar a classe e devolve-la para a JVM carregar.

Assim, as minhas classes estariam criptografadas no servidor.
As únicas classes abertar seriam a PreMain e a Transformer. Como a rotina de permissão de execução e descriptografia estão dentro da biblioteca C++, não tem problema descompilar apenas estas duas.

O ponto negativo é o deploy. :frowning:
Será necessário criptografar as classes antes de enviar para o servidor e será necessário compilar uma biblioteca para cada servidor destino.

O que acham deste “padrão de projeto” ? :?:
A simples descompilação não funciona.
Testando o signer da classe chamadora evita re-compilação e depuração via IDE.

Qual a outra maneira de tentar descompilar uma classe ?

Será que consigo diminuir o numero de pessoas que irão descompilar a minha aplicação ?

Todos os comentário serão bem-vindos ! :!:

Juliano
Muito iniciante em JAVA

Procure por ofuscadores, essas ferramentas geralmente são pagas, não importa o que você faça uma hora ou outra as pessoas vão conseguir identificar é so questão de tempo.

Ofuscadores não resolvem por causa do deploy.
Cada cliente pode ter uma versão diferente, tanto entre si quanto com a versão em desenvolvimento.
Para cada nova correção/melhoria o resultado da “ofuscada” seria atualizar toda a aplicação (que nem sempre o cliente deseja).
Sem contar a diferença de versão do banco de dados.

Desta forma, a unica complicação do deploy é “criptografar” antes de enviar.

E se eu instanciar sua classe via um classloader customizado que pega o resultado da sua decriptação e salva em um arquivo no disco?

Não é papo filosófico, é realidade. Se encriptar fosse simples, eficiente ou eficaz IBM, Sun e Bea fariam isso. Ofuscação é uma saída para espantar 99% dos interessados, os 1% restantes não serão barrados.

Boa idéia. Isso vai cortar 99% dos espertos, mas vai sobrar 1% que vai sacar que o ClassLoader do java precisa receber um bytearray purinho, ou seja, não adianta o que vc faz escondido no JNI, eventualmnte vc vai ter que chamar os métodos do ClassLoader passando o bytearray descriptado, certo?

Talvez dê para fazer o loader da classe de dentro de JNI, talvez não.

Se não der o cara modifica o código logo antes dessa chamada e pega a classe.

Pois é justamente este tipo de quebra que eu não consegui testar.

Como faço para rodar a JVM com um classloader customizado ?

Reimplementa o classloader e joga dentro do rt.jar. e instala a JVM no cliente.

[quote=fmeyer][quote=saoj]
Boa idéia. Isso vai cortar 99% dos espertos, mas vai sobrar 1% que vai sacar que o ClassLoader do java precisa receber um bytearray purinho, ou seja, não adianta o que vc faz escondido no JNI, eventualmnte vc vai ter que chamar os métodos do ClassLoader passando o bytearray descriptado, certo?

Talvez dê para fazer o loader da classe de dentro de JNI, talvez não.

Se não der o cara modifica o código logo antes dessa chamada e pega a classe.

[/quote]

Reimplementa o classloader e joga dentro do rt.jar. e instala a JVM no cliente. [/quote]

Boa dica !
Basta assinar o rt.jar e incluir o teste do signer do classloader também.
Existe algum outro JAR faça isto ?

Obrigado

E tome um processo da Sun, ja que vc nao pode redistribuir a JVM modificada de acordo com os termos de uso. :wink:

Eu não posso apenas assinar o JAR ?

Qual jar? O rt.jar ja eh assinado pela Sun…

Então, ok !
Basta verificar se o classloader esta assinado pela Sun ou uma lista de fornecedores validos.
Se não estiver assinado, a biblioteca C++ não retornar o bytearray correto…

Logo, mais alguma sugestão de quebra desta ideia ??

:lol:

Quem vai tentar decompilar e entender a sua aplicação?

Nunca vi ninguem fazendo isso, é dificil e caro, mais vale te contratar para fazer algum upgrade.

Bom, se vc conseguir chamar o classloader de dentro do código JNI, o que deve ser complexo pra caramba, realmente vai ficar difícil de o cara quebrar.

Seria ainda mais impossível se vc dar um jeito de startar a VM de dentro de um código nativo, ou seja, vc controla o launch da VM nativamente e de forma protegida.

Se vc não fizer isso, acho que tem uma forma de vc iniciar a VM em modo PROFILER e fazer algumas maluquices, tipo introduzir proxies, etc e tal. Daí o cara daria um jeito de printar o bytearray. Mas ai realmente seria difícil de o cara perder tempo tentando fazer isso. Só se for um código da nasa mesmo. :slight_smile:

A ideia eh mais ou menos seguir essa ordem:

  1. Construir algo tao bom que outros vao tentar copiar
  2. Arrumar um bom advogado pra te proteger
  3. Proteger o codigo

E nao:

  1. Proteger o codigo
  2. Construir “algo”

Entao, vamo parah de conversa mole sobre ClassLoader e JNI: se fosse bom, possivel e barato, a IBM, BEA e Oracle ja tinham feito isso faz tempo.

Vao la escrever codigo que serve pra alguma coisa, ao inves de codigo que serve pra tornar o resto do codigo MENOS util.

O objetivo é justamente diminuir o universo de pessoas com tempo e conhecimento suficiente para fazer estas tentativas, sabendo que não é um código da nasa. :!:
Desta forma a sugestão de contratar o serviço para manter o fonte é valida. :slight_smile:
Pois, infelizmente :frowning: , no mundo real não são todas as empresas que agem de maneira correta.