Galera, como se faz para esconder a implementação de uma aplicação Java? o arquivo .jar pode ser descompactado e depois descompilado para se obter os fontes da aplicação. Há como esconder essa informação ou toda aplicação Java é implicitamente “open-source”???
Infelizmente é possivel descompilar um .class mas vc pode utilizar um ofuscador para mudar as legibilidade do codigo. Aqui vai alguns descompiladores e Ofuscadores:
Nunca vi ninguém que trabalha desenvolvendo softwares comerciais se preocupando em usar esse tipo de coisa, além do que, mexer no código (alterando nomes de propriedades, classes e métodos) pode deixar o código inútil pra bibliotecas que se baseiam em reflexão, como o Hibernate.
Nunca vi ninguém que trabalha desenvolvendo softwares comerciais se preocupando em usar esse tipo de coisa, além do que, mexer no código (alterando nomes de propriedades, classes e métodos) pode deixar o código inútil pra bibliotecas que se baseiam em reflexão, como o Hibernate.
Pra mim isso é uma bela duma furada. :shock: [/quote]
Dependendo do tipo de sistema não concordo… Tá, quando se utiliza reflexão até posso concordar, más quando não se utiliza é sempre bem vindo um ofuscador. Tanto é que que o sistema para declaração de Imposto de renda da RECEITA FEDERAL - BRASIL ou as applets do site do BANCO DO BRASIL utiliza-se de ofuscador em uma grande parte do seu código. E outra, se fosse furada te guaranto q a SUN não iria dar suporte a ofuscador de codigo no se seu Toolkit Wireless para j2me.
Eu me pergunto pq os sistemas feitos pela receita federal, com dinheiro que saiu dos seus bolsos (e costumava sair dos meus, tambem), nao tem o codigo aberto. Ja parou pra pensar que um ofuscador eh justamente o contrario do que voce quer do codigo vindo de uma instituicao governamental?
Uma outra razao importante (e que, nesse caso, tem muito mais influencia) para se usar ofuscadores eh que eles conseguem, em muitos casos, reduzir o tamanho do codigo compilado - coisa que, quando se tem alguns miseros kbytes de memoria pra brincar, eh extremamente relevante.
O ofuscador do J2ME não tem por objetivo “esconder” código não, ele está lá pra retirar código inútil, como métodos, propriedades e classes inúteis.
Isso realmente deveria ser mudado, mas o da receita federal não é feito por uma empresa privada não? Que botou até o framework que eles criaram como Open Source?
Quem sabe isso não termina acontecendo mesmo, o governo tá dando muito apoio a esse tipo de inciativa. Pelo menos nesse governo (na nossa área) agente não tem tanto o que reclamar né, tão dando uma força grande pra informática.
Espero ter entendido sua colocação, mas este exemplo da receita federal foi infeliz. vc imaginou se o codigo desses caras fossem abertos ?! A quantidade de fraude que poderia rolar (mais do que já rola).
E a seguranca por obscuridade vai mesmo nos proteger de fraudes, do mesmo jeito que protegeu a criptografia dos DVDs, do mesmo jeito que protegeu a Lexmark de cartuchos de impressao feitos por terceiros, do mesmo jeito que protegeu as falhas de seguranca do Windows, Internet Explorer, PDF, e tantas outras coisas… :roll:
O ponto aqui nao eh nem esse. O ponto eh que o dinheiro pra fazer esse software saiu, dentre tantos outros, DO SEU BOLSO, e se vc quiser saber se o servico foi bem feito, vc tem todo o direito de poder faze-lo, nao? Se voce quiser descobrir se existe uma possibilidade de fraude, qual maneira melhor do que olhar o codigo do bicho, e avisar os desenvolvedores, ou consertar vc mesmo, caso vc tenha o tempo/paciencia/vontade? Pq, pode ter certeza, pra quem ta interessado em fraude, um ofuscador nao faz a menor diferenca.
Galera, descobrio o exe4j ( http://www.ej-technologies.com/download/exe4j ). Excelente!!! Ele gera o .exe a partir dos .class ou dos .jar.
Dêem uma olhada e depois me contem o q acharam.
Como é que funciona o exe4j e outros programas (tais como o jar2exe do Apache Commons/Daemon):
Você cria um .jar (que é um .zip só que com outro nome)
Como você deve saber, existe uma variação do formato .zip que permite seu uso como executável (self-extractable zip files, por exemplo): basta modificar algumas estruturas de controle do arquivo .zip para que ele indique que o início do arquivo é X bytes depois. Então o início do arquivo pode conter, por exemplo, uma versão modificada do java.exe (ou javaw.exe) que ponha o próprio .exe no CLASSPATH (é esquisito mas funciona).
Isso é como funciona o exe4j, do jar2exe e de outros programas que não convertem os .class para código nativo.
Portanto qualquer pessoa que tenha o Winzip, ou PKZip, ou mesmo o zip.exe, consegue abrir um arquivo .exe que tenha sido gerado com o exe4j. Muito simples, não requer prática ou habilidade, só um pouco de conhecimento.
Se você quer algo que converta para código nativo (perdendo a portabilidade) veja www.excelsior-usa.com ou o próprio gcj (embora na prática não seja muito viável usar o gcj).