Bom dia,
Descobri agora o site de vocês, e quero parabenizá-los pela qualidade que você imprimiram nesse trabalho.
Sempre encontrei bons sites no exterior, mas agora vejo que finalmente posso ficar em casa.
Gostaria de poder ajudar no que for necessário para que esse site continue crescendo.
Minha satisfação por tê-los encontrado vem, também, do fato de ter passado o carnaval todo procurando uma maneira de convencer os gerentes de desenvolvimento da empresa em que trabalho a mudar de plataforma (usamos VB6, VB.NET, ASP).
Reprogramei uma parte do sistema atual em Java, e todos gostaram do resultado final (querem esquecer Windows e partir pra Linux nas máquinas dos usuários, entre outras coisas). Aceitaram o Java, mas…
O problema: Ninguém aceitou o fato de se obter o código fonte descompilando um arquivo .class. Nosso sistema fica instalado em máquinas de usuários que poderiam entender nossos programas e alterá-los. o obfuscamento não foi satisfatório como regra de segurança.
Haveria alguma forma de impedir o acesso ao código fonte?
Eu sugeri colocar o sistema em Java em um servidor de arquivos, com privilégio apenas de leitura. Os usuários iriam "pegar" nosso sistema, mas não poderiam alterá-lo (meio feio, mas foi meu único argumento).
Compilar e gerar um executável parece ir de encontro a natureza Java e tiraria a facilidade de atualização das classes do sistema.
Existiria uma arquitetura (Jini, EJB?) que permitiria colocar as telas do sistema em um servidor, a apenas um programa chamador no cliente que carregaria essas telas diretamente daquele servidor, preservando o anonimato daqueles arquivos .class?
Por favor, gostaria de contar com a experiência de vocês. Acredito que nossa empresa serviria como vitrine da tecnologia Java aqui no centro-oeste.
Obrigado pela atenção.
Olá,
Ficamos felizes em saber que gostou do site e mais ainda que conseguiu convencer os gerendes de desenvolvimento de sua empresa a darem uma chance ao Java.
Antes de entrar na questão de computação distribuída, gostaria de ressaltar que os programas de obfuscamento diferem bastante em relação a suas técnicas. Alguns apenas trocam nomes de métodos e variáveis, enquanto outros parecem realmente tornar o arquivo class mais difícil de ser descompilado. Talvez o resultado para vocês não tenha sido satisfatório simplesmente porque você utilizou um programa mais fraco.
Mas respondendo a sua questão sobre carregar classes presentes em outro servidor, acredito que a arquitetura mais simples e recomendada seria através do uso de RMI-IIOP. O site oficial sobre esse assunto é o seguinte:
http://java.sun.com/products/rmi-iiop/
E só para esclarecer essas outras siglas levantadas, JINI serve como um serviço de lookup em máquinas remotas, que você poderá estar utilizando também. Há até um tutorial aqui no Portal Java que fala um pouco sobre como utilizar tanto JINI como RMI simples. Ele pode ser lido em <a href="http://www.portaljava.com/home/modules.php?name=Sections&op=listarticles&secid=18" target="_blank" target="_new">http://www.portaljava.com/home/modules.php?name=Sections&op=listarticles&secid=18
E EJB é uma arquitetura um tanto polêmica (alguns acham ótima, outros odeiam) que é especialmente útil para criar um sistema que precise ser bastante escalável e que precise de um bom controle de transações. Definitivamente não é o caso para o seu sistema.
Desde ontem quando vi sua resposta, li e implementei o tão famoso RMI.
No JBuilder tive uns problemas com o versionID das classes, daí tive que fazer na mão (no DOS).
Funcionou que foi uma beleza.
E pra minha surpresa, ele copiou e trouxe pra máquina cliente os .class que estavam no servidor (tive até que configurar o .policy e o security manager para que ele fizesse a cópia do diretódio do servidor e funcionasse).
Acredito que ele faz isso pra poder executar o .class, o problema é que ele traz o arquivo do jeito que ele está no servidor. Bem que poderia ser mais escondido pra que ninguém percebesse a presença dos .class no cliente.
O RMI desse jeito não ajudou muito em segurança.
Ontem a tarde, peguei um compilador Excelsior JET 3.0, e ele compilou os .class e tudo funcionou perfeitamente.
Código nativo rapidinho, mas sem a possibilidade de carregar dinamicamente novas classes (usei or forName()), pois o compilador cria DLLs pra cadas classe mas não consegue mapear uma nova DLL depois do executável estar linkado e pronto (velho esquema de executáveis do Windows).
A pergunta: depois de todos esses anos que o Java está na estrada, qual foi a melhor maneira de fazer um programa e colocá-lo nas máquinas de uma empresa de maneira que os fontes (ou .class) não possam se alterados, corrompendo assim a integridade do sistema, dos dados, etc?
O obfuscation seria mesmo o único recurso?
Grandes empresas usam o obfuscation e confiam a segurança nele?
Os links abaixo talvez ajudem:
http://www.ddj.com/documents/s=906/ddj9902m/9902m.htm
http://www.newarchitectmag.com/archives/2001/08/travis/
Para ser franco, estou tentando aplicar as técnicas do artigo da ddj no meu sistema sem sucesso. Quando eu aplico num pequeno programa, tudo bem, mas o sistema real tem 50.000 linhas de java. Aí a coisa pega!
Existia um site (http://www.jarsafe.com) que tinha um produto para isso. Mas acho que saiu do ar.
Em todo o caso, boa sorte!