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

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

Conheça a API do Java que dá a possibilidade de manipular e criar arquivos com dados compactados.

Artigo escrito por: Daniel Destro

Confira aqui: http://www.guj.com.br/java.tutorial.artigo.181.1.guj

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!

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

"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!

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

É 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 ?

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

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 wrote: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.

Notícias, artigos e o maior fórum brasileiro sobre Java