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.
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 ?
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.
[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 ?
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 ??
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.
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.
Pois, infelizmente , no mundo real não são todas as empresas que agem de maneira correta.
