Olá pessoal, é o seguinte um amigo meu me questionou quanto a segurança do código de uma aplicação, dizendo que com progrmas que revertem os arquivos .class obtendo assim o código desta classe. Eu gostaria de saber como isso funciona.
Rocha
Olá
Segura em que sentido? Com Java conseguimos fazer com relativa facilidade sistemas muito complexos com muitos milhares de instruções. Mesmo que um cara seja muito paciente para usar um decompiler e abrir o código fonte, ele ainda terá muitas dificuldades para usar. Aliás é assim que me sinto quando começo a trabalhar com código escrito por outros e sem documentação.
Há outras linguagens que a gente só consegue fazer uns sisteminhas simples que por serem compiladas são mais difíceis de abrir o código fonte. Mas na prática se consegue abrir o código do mesmo jeito.
Se tem preocupações quanto a segurança contrate um bom advogado e solicite um contrato adequado.
Este assunto já foi muito discutido aqui no GUJ, dê uma pesquisada.
[]s
Luca
Use obfuscadores, eles “sujam” o codigo quando decompilado
Funciona assim: vc pega um programinha desses, seleciona um .class ou vários e ele gera um arquivo(s) .java com o quase o código original.
Se você usar um obfuscador ele vai voltar o código tb, mas com nomes cabulosos e pequenas alterações, nada demais.
Por isso Java não é seguro, vou correndo tirar meu dinheiro do Banco do Brasil pq qualquer zé-mané pode fazer engenharia reversa no código deles e descobrir os ifs que tem por lá … pensando bem vou tirar de qualquer banco porque a merda do banco central tb gosta de Java :?
[quote=smota]
Por isso Java não é seguro, vou correndo tirar meu dinheiro do Banco do Brasil pq qualquer zé-mané pode fazer engenharia reversa no código deles e descobrir os ifs que tem por lá … pensando bem vou tirar de qualquer banco porque a merda do banco central tb gosta de Java :? [/quote]
Smota eu não afirmei que java não é seguro estou querendo saber como isso funciona, pois me questionaram a seguinte situação, em um sw feito em java existe uma classe que cuida da validação do sistema, uma pessoa usa um decompiler conseguiria muito bem mudar o método q cuidada disso idaí como ficaria. Lembrando que qdo falamos da métodologia q hj é usada no planejamento das classes até facilia essa cituação pois provavelmente essa classe chamaria algo do tipo: Validacao ou tempoValidacao então a pessoa já teria um bom caminho bom onde começar, lembrando q este é apenas um exemplo.
Rocha
eu tava pensando num jeito de criptografar um código fonte…
Até aí deve-se proteger as partes que fazem a validação. Por exemplo, se quer uma validação segura, ela deve ficar em um sistema central protegido, não na máquina do usuário.
Só para dar um exemplo: quando você se loga no mail.yahoo.com, por exemplo, todos sabem que o hash MD5 de sua senha é enviada via http (opcionalmente via https). É só ler o Javascript (não é nem Java, o código está lá pra todo mundo ver). Mas nem por isso o login é tão inseguro assim.
Para começar, a senha não é enviada em claro, nem criptografada com uma chave fixa; e o Yahoo guarda muito bem as senhas em alguma base bastante protegida.
Na verdade, o segredo não é esconder como é feita uma determinada coisa (alguém acaba sempre descobrindo…), mas sim esconder (proteger) apenas as partes que devem ser protegidas. Isso é um serviço para profissionais…
Ok concordo e nessa solução eu já tinha pensado só q existem profissionais e “profissionais”, tem muita gente fq é mau carater e por qualquer merreca faria uma sacanagem de abriru um codio aleio para modificalo, imaginem eu aqui em SP vendo minha aplicação para um cara do RS daí o cara decide parar de me pagar um “profissional” (funcionário da empresa) vai decompila me código muda o método de validação daí como fica.
Rocha
Olá
Este problema sempre existiu desde que apareceram os programas que editavam código binário nos primórdios do uso do PC. Mas como disse o Thingol, quem seria louco suficiente para deixar o código de validação aberto para olhos estranhos?
Mas há muitas maneiras de vc se defender.
Vou contar algumas que já usei:
-
Esta usei há uns 10 ou 12 anos atrás. Calculei o CRC do total dos bytes do trecho da minha aplicação que não admitia modificação e coloquei dentro da aplicação uma verificação de CRC deste trecho. Isto era feito em vários lugares e da forma mais disfarçada possível.
-
Como a solução anterior dava trabalho, em outras aplicações resolvi adquirir trava de hardware e lá fazer o controle.
-
Em uma determinada aplicação que era alugada o cliente precisava solicitar mensalmente uma chave e um patch que era usado em um trecho do programa (isto hoje seria feito com java web start).
-
Atualmente as aplicações web podem se autenticar no nosso servidor para obter a tal autorização.
[]s
Luca
Rocha, descompiladores existem para todas as grandes linguagem de programação que conheço.
E ofuscadores (obfuscator, google it) que já vi funcionam muito bem; ao descompilar as classes ofuscadas o código fica, além de ilegível, “errado”. Nem compila de novo 
Só para você ter uma idéia. Algumas versões do JBuilder precisavam de uma chave de ativação, que era enviada via email (era uma chave enorme, acho que era uma assinatura digital.)
Um fulano qualquer simplesmente escreveu uma classe que você copia sobre a instalação do JBuilder e ele passa a não checar mais a chave de ativação. (Se bobear você também tem esse JBuilder piratado, não?)
Por isso é que o tal sistema tem de funcionar conectando-se periodicamente com um servidor seu, para pegar uma chave de ativação, e explodir se não conseguir se conectar. Tem gente também que vende aqueles “dongles”, que são chaves de hardware que você liga na USB e que o software tem de ficar checando periodicamente se estão lá. (Obviamente já quebraram a segurança de muitos “dongles”, portanto consulte antes de comprar)
acho que é por isso que o java pegou mesmo para a web e não para desktop…
Não acho não.
Na minha opinião não pegou porque Swing é difícil.
lipe, que começou a tentar usar Swing
pow… nem é… só ter o javadoc na mão e mandar bala
Hey Luca, lembra do classloader que lia .class encriptografado? 
Claro que dava pra desconpilar o classloader e etc… etc… etc… mas era algo bem complexo, foi divertido.
Olá
Fábio, já mostrei aqui no GUJ como se faz isto de usar ClassLoaders que zipam e criptografam. Inclusive apontei os possíveis problemas do cracker obter um dump da memória para pegar a classe descriptografada. Na época alerlei que objetos de classes muito sensíveis deveriam ser retirados da memória tão logo tivessem sido usados.
Na minha mensagem anterior coloquei toda a minha experiência neste tipo de problema. A solução do CRC era bacaninha, um só byte trocado e a aplicação não rodava mais. CRC é melhor do checksum porque a ordem dos bytes influi no resultado final. Mas hoje há novas facilidades como autenticação em servidor remoto e toda minha experiência ficou “deprecated” (como quase tudo que sei…hehehe).
[]s
Luca
[quote=LIPE]Não acho não.
Na minha opinião não pegou porque Swing é difícil.
lipe, que começou a tentar usar Swing[/quote]
Pois é. Como eu aprendi Swing antes de aprender qualquer coisa sobre J2EE, eu achava que J2EE era difícil.
Simples e genial. Le um class no formato que voce quiser. Alias, ele pode ler tudo de um .dat e tudo la criptografado, voce le, descriptografa e manda o array de bytes bonitinho.
rsrs… não eu uso netBeans.
Bom galera esse post foi bem produtivo deu para ter uma idéia de como lidar com tais cituações… Valeu :lol:
Rocha