Artigo: Zip com Java: Compressão e Descompressão de Dados

O link está errado, está apontando pro artigo sobre axis.

Correto = http://www.guj.com.br/java.tutorial.artigo.181.1.guj

danieldestro, gostei do seu tutorial.

Vc sabe como trabalhar com arquivos ZIP com senha?

Não achei muita informação sobre esse assunto…

Não achei nada a respeito!

“Arquivos zip” com senha são difíceis de trabalhar, porque há pelo menos três ou quatro tipos desses arquivos.

O primeiro e o que está devidamente documentado na definição do formato ZIP original por Phil Katz, usa um algoritmo ligeiramente inseguro.

Os outros tipos dependem do fabricante - o Winzip tem um formato desses, a PKWare (dona do PKZip original) tem um outro formato, e o 7-Zip tem ainda outro formato. Acho que o BraZip tem ainda outro formato.

Pelo menos a PKWare documentou seu formato.

É um pouco chato escrever um programa que implemente um dos formatos documentados (principalmente porque você tem de testar se eles são compatíveis com os pacotes originais - sabe como é especificação ), portanto é por isso que só achei compressão Zip com senha em pacotes pagos.

thingol, o senhor é o dono da verdade absoluta. Não tem explicação para saber tanto de tudo. Parabéns!

É que eu tive de implementar um arquivo .zip que era dividido em disquetes, e eu tinha lido a especificação. Como era interessante que esse arquivo fosse criptografado, tentei implementar a especificação da PKWare, mas por falta de tempo usei um método mais simples mesmpo.

EDIT - não que o método fosse muito complexo, mas infelizmente era o famoso problema de “interoperabilidade”. Não achei tempo para fazer os testes, e além disso, como sabia que o método original da PKWare era ligeiramente inseguro, não o usei.

Pelo que eu pesquisei só achei uma solução paga da empresa IP*Works.

falando em arquivo zip, senha,

alguem ja fez algum classloader para bytecodes criptografados ?

Preciso achar esse artigo de novo na JavaWorld. Esse artigo ao mesmo tempo mostra como montar esse classloader e porque ele é inseguro

EDIT - É este: http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html

Olá

Compressão de dados já foi minha paixão. Cheguei a escrever 4 capítulos de um livro que nunca foi lançado porque abortei o projeto ao saber que o Mark Nelson ia lançar o dele. Aprendi compressão com métodos tipo dicionário (usado pelo PKZIP e afins) com o famoso artigo do Mark lá na Dr Dobbs.

Usei em um programa de comunicação serial tipo laplink que comprimia os dados antes de enviar.

Sobre o artigo do JavaWorld, se é o que estou pensando, o problema de ClassLoader que criptografa, é que a carga na memória é aberta não criptografada (e descomprimida se for o caso). Se alguém fizer o dump da memória obtem a informação que se queria esconder. Mas eu ainda acho boa solução pois pelo menos do ladrão mais bobinho a gente se protege. Já usei em um sistema que fazia hot deploy de atualizações de versão sem tirar o sistema do ar.

[]s
Luca

Vou dar uma olhada no artigo, valeu thingol.
Isso pq estes dias estava discutindo com meu gerente a melhor forma de proteger codigo para mandar pro cliente mal intencionado.

vamos la …

fiz ambos os testes que o Vladimir propos no artigo. o mais interessante é a intercepcao do metodo defineClass (…) que na minha opiniao pode ser resolvida de 2 formas.

distribuir o JRE com a aplicacao ( no caso é meio chato pois a sun tem um contrato pra poder fazer isso)

e o mais viavel que eu acho, é fazer um checksum do rt.jar levando em conta as diferentes versoes de JVM. caso nao bata o checksum … o programa ou serviço aborta. e pra evitar hotdeploy da classe … ele faz verificacao de tempos em tempos …

paranoico ? hehehe

Olá

fmeyer:

e o mais viavel que eu acho, é fazer um checksum …
paranoico ? hehehe

Não é não! Eu fazia quase assim já em 1994. Só que eu não usava checksum pois trocando bytes, o checksum é o mesmo. Eu usava CRC.

Meu antigo método (acho que já descrevi aqui em outra pasta):

1. No meu programa Clipper havia uma constante logo como primeira coisa no sistema.

2. Eu fiz um programinha que calculava o CRC do trecho de programa da linha seguinte à constante até o fim.

3. Usando um editor de binário, alterava a tal constante pelo valor do CRC calculado.

Meu programa tinha uma função que recalculava o CRC do mesmo modo que meu programinha e comparava com o valor do CRC. Se o cliente alterasse 1 byte, o CRC não batia mais.

Além disso, meus programas eram vendidos com relatórios personalizados para cada cliente. No topo de cada relatório saia o nome do cliente. Assim, mesmo que um funcionário do cliente roubasse o sistema, ele não podia alterar o nome que aparecia no topo dos relatórios. Este nome ficava dentro do sistema BEM ESCONDIDO.

No Java onde não existe um arquivo .exe monolítico como era o caso do Clipper, você pode pensar qualquer coisa. Mas nunca com checksum que não vale nada. Use sempre CRC, se possível CRC32. Para melhorar a performance do cálculo do CRC se deve fazer como a turma que escreve programas de comunicação e seguir os conselhos do grande Joe Campbell: armazenar uma tabela de lookup ao invés de calcular tudo na raça.

Acho que você deve encontrar várias APIs free de cálculo de CRC ou usar o que já vem com o Java na classe java.util.zip.CRC32. Compare os desempenhos pois isto pode demorar um tiquinho se nãofor bem escrito.

[]s
Luca

Que tal distribuir todo código dentro de um binário (exe) e colocar toda lógica de classloading em código nativo? AOP não funciona com métodos natívos.

Olá pessoal, tudo bem?
Bom eu estou com um problema já fazem alguns dias, e estou com dificuldades para resolver.
pesquisando por aí, escontrei esse “forum”, e percebi que vocês são as pessoas certas para tentar me ajudar.
Alguns dias atras eu “zipei” um arquivo com senha, e não consigo me lembrar dessa maldita senha de maneira alguma, e são arquivos extremamente importantes para mim.
Eu tambem já tentei programas que tentam combinações de senhas, mas o mais rapido testa cerca de 15 milhões de senhas por segundo, apesar de ser muito rapido, eu posso ficar meses ou até mesmo anos para conseguir descobrir essa senha.
Eu gostaria de saber se tem como abrir esse zip, “quebrando o binario” dele, ou qualquer outra forma que me ajude.
Eu não entendo nada sobre isso, e só disse do “binario” por que li em outros foruns.
Bem se vocês puderem me ajudar ficarei muito grato mesmo, pois os arquivos, como eu já disse são extremamente importantes para mim.

Grato desde já!

Os algoritmos que tentam abrir um arquivo, tentando todas as senhas possíveis, usam uma vulnerabilidade do algoritmo de criptografia original (de 80 bits se não me engano) que diminui a quantidade de operações possíveis para checar se a senha está correta.
Portanto, esses programas crackers russos de senhas (provavelmente foi o que você baixou da Internet) já usam uma forma bastante avançada de tentar abrir o arquivo .zip com senha.
Creio que não é possível ser mais rápido que esses quinze milhões de senhas por segundo. Talvez compartilhando esse trabalho por várias máquinas

Luca:

Olá

fmeyer:

e o mais viavel que eu acho, é fazer um checksum …
paranoico ? hehehe

Não é não! Eu fazia quase assim já em 1994. Só que eu não usava checksum pois trocando bytes, o checksum é o mesmo. Eu usava CRC.

Meu antigo método (acho que já descrevi aqui em outra pasta):

1. No meu programa Clipper havia uma constante logo como primeira coisa no sistema.

2. Eu fiz um programinha que calculava o CRC do trecho de programa da linha seguinte à constante até o fim.

3. Usando um editor de binário, alterava a tal constante pelo valor do CRC calculado.

Meu programa tinha uma função que recalculava o CRC do mesmo modo que meu programinha e comparava com o valor do CRC. Se o cliente alterasse 1 byte, o CRC não batia mais.

Além disso, meus programas eram vendidos com relatórios personalizados para cada cliente. No topo de cada relatório saia o nome do cliente. Assim, mesmo que um funcionário do cliente roubasse o sistema, ele não podia alterar o nome que aparecia no topo dos relatórios. Este nome ficava dentro do sistema BEM ESCONDIDO.

No Java onde não existe um arquivo .exe monolítico como era o caso do Clipper, você pode pensar qualquer coisa. Mas nunca com checksum que não vale nada. Use sempre CRC, se possível CRC32. Para melhorar a performance do cálculo do CRC se deve fazer como a turma que escreve programas de comunicação e seguir os conselhos do grande Joe Campbell: armazenar uma tabela de lookup ao invés de calcular tudo na raça.

Acho que você deve encontrar várias APIs free de cálculo de CRC ou usar o que já vem com o Java na classe java.util.zip.CRC32. Compare os desempenhos pois isto pode demorar um tiquinho se nãofor bem escrito.

[]s
Luca

Oi Luca, esotu precisando saber fazer o seguinte:

Tenho uma aplicação cliente/servidor o cliente enviar arquivos para o servidor e preciso criar um calculo CRC no cliente a partir do polinomio
gerador que será utilizado, no meu caso:

x8 + x6 + x3 + x + 13

Acho que n aparte cliente ele pega esse polinomio + o binario do arquivo enviado (Que eu nem sei como pega um binario de um arquivo em java gostaria de saber) e envia no cabecalho.

No servidor é pego essa informacao e recalculado para ver se tem erro ou nao. (Não sei tb como pego essa informacao no servidor)

Em sockets tem como fazer isso para o controle de erros ? Ou so da pra saber os erros pelas exceptions geradas ?

Desculpe mas ta meio confuso, to lendo a respeito mas

Ainda tenho que fazer um controle de fluxo na parte servidor com Go-back-n ou Selective Reject.

Sabe me dar alguma dica quanto a isso.
Agradeco muito.
Abraços

Gente, desculpem por reviver o tópico, mas achei um trecho interessante para adicionar.

Pesquisando na internet sobre CRC32, encontrei que, apesar de utilizar todos os bits do arquivo para fazer o cálculo polinomial, é possível alterar os dados sem que o CRC seja modificado. Sendo assim, o melhor mesmo é usar hash pra fazer a tarefa.

Fonte: http://pt.wikipedia.org/wiki/CRC