You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, the problem you face is to guess some compressed plaintext. Your files were compressed and then encrypted when added to the zip file. The known plaintext attack uses a portion of data right before encryption, that is to say compressed data in your case.
Now, you may wonder how to guess such compressed data?
Compressing the first few bytes of a file as you tried generally does not give the first few bytes of the compressed file. For files of a size like yours, deflate compressed data most probably starts with a statistical model (Huffman tree, itself encoded in a compact format) of a large chunk of data. You cannot guess such compressed data without knowing a big part of the file.
On the other hand, if you have a big part of a file, or event better, a complete file, it is more likely that compressing it will give suitable compressed data. Even when the whole file is known, getting correct compressed plaintext can be a challenge because deflate compression can be tweaked with some parameters.
Another approach is to study docx file format to see there is some pattern that would make compression predictable, but I doubt it.
For more information about deflate compression, you can check this article on zlib's website An Explanation of the Deflate Algorithm and RFC1951 - DEFLATE Compressed Data Format Specification for all the details.
If you cannot guess plaintext, then you might consider using a password cracker such as john the ripper or hashcat.
Hi, the problem you face is to guess some compressed plaintext. Your files were compressed and then encrypted when added to the zip file. The known plaintext attack uses a portion of data right before encryption, that is to say compressed data in your case.
Now, you may wonder how to guess such compressed data? Compressing the first few bytes of a file as you tried generally does not give the first few bytes of the compressed file. For files of a size like yours, deflate compressed data most probably starts with a statistical model (Huffman tree, itself encoded in a compact format) of a large chunk of data. You cannot guess such compressed data without knowing a big part of the file. On the other hand, if you have a big part of a file, or event better, a complete file, it is more likely that compressing it will give suitable compressed data. Even when the whole file is known, getting correct compressed plaintext can be a challenge because deflate compression can be tweaked with some parameters. Another approach is to study docx file format to see there is some pattern that would make compression predictable, but I doubt it. For more information about deflate compression, you can check this article on zlib's website An Explanation of the Deflate Algorithm and RFC1951 - DEFLATE Compressed Data Format Specification for all the details.
If you cannot guess plaintext, then you might consider using a password cracker such as john the ripper or hashcat.
First of all @kimci86 what for a response time do you have ?!?!?
Wow - Thank you very much for the detailed answer and for getting into it.
I figured that without a complete file this would be difficult to impossible.
bkcrack I tried today with a demo.zip | CompressionMethod: Store |, without problems bkcrack was able to recover the keys for the docx.
Would it be theoretically possible for bkcrack to have one of the two docx files as original and create this as a ZIP, using the method Deflate Maximum?
Can I see if I zipped the file exactly the same by the CRC number?
Can I see if I zipped the file exactly the same by the CRC number?
No, the CRC value is computed on uncompressed data, so it does not give information about compression.
However, it is useful to check that your uncompressed file has great chances to actually be the right file.
If the CRC matches, then you have to guess how the file was compressed: what compression program with what parameters. Looking at the compressed size is a simple way to discard wrong parameters. Note that encryption adds a 12 bytes encryption header to ciphertext, so the compressed size you would try to get is the encrypted file's size minus 12.
Would it be theoretically possible for bkcrack to have one of the two docx files as original and create this as a ZIP, using the method Deflate Maximum?
Yes, this process of trying compression tools and parameters could be automated to some extent. It is not implemented at the moment but it would be nice to have. It would not be exhaustive but at least trying with zlib deflate implementation could be a good start.
I am closing this as I believe your questions have been answered. Feel free to reopen if I am mistaken or open a new issue if you have other questions or feedback.
Activity
kimci86 commentedon Oct 14, 2022
Hi, the problem you face is to guess some compressed plaintext. Your files were compressed and then encrypted when added to the zip file. The known plaintext attack uses a portion of data right before encryption, that is to say compressed data in your case.
Now, you may wonder how to guess such compressed data?
Compressing the first few bytes of a file as you tried generally does not give the first few bytes of the compressed file. For files of a size like yours, deflate compressed data most probably starts with a statistical model (Huffman tree, itself encoded in a compact format) of a large chunk of data. You cannot guess such compressed data without knowing a big part of the file.
On the other hand, if you have a big part of a file, or event better, a complete file, it is more likely that compressing it will give suitable compressed data. Even when the whole file is known, getting correct compressed plaintext can be a challenge because deflate compression can be tweaked with some parameters.
Another approach is to study docx file format to see there is some pattern that would make compression predictable, but I doubt it.
For more information about deflate compression, you can check this article on zlib's website An Explanation of the Deflate Algorithm and RFC1951 - DEFLATE Compressed Data Format Specification for all the details.
If you cannot guess plaintext, then you might consider using a password cracker such as john the ripper or hashcat.
trustinveritas commentedon Oct 14, 2022
First of all @kimci86 what for a response time do you have ?!?!?
Wow - Thank you very much for the detailed answer and for getting into it.
I figured that without a complete file this would be difficult to impossible.
bkcrack I tried today with a demo.zip | CompressionMethod: Store |, without problems bkcrack was able to recover the keys for the docx.
Would it be theoretically possible for bkcrack to have one of the two docx files as original and create this as a ZIP, using the method Deflate Maximum?
Can I see if I zipped the file exactly the same by the CRC number?
kimci86 commentedon Oct 15, 2022
No, the CRC value is computed on uncompressed data, so it does not give information about compression.
However, it is useful to check that your uncompressed file has great chances to actually be the right file.
If the CRC matches, then you have to guess how the file was compressed: what compression program with what parameters. Looking at the compressed size is a simple way to discard wrong parameters. Note that encryption adds a 12 bytes encryption header to ciphertext, so the compressed size you would try to get is the encrypted file's size minus 12.
Yes, this process of trying compression tools and parameters could be automated to some extent. It is not implemented at the moment but it would be nice to have. It would not be exhaustive but at least trying with zlib deflate implementation could be a good start.
kimci86 commentedon Dec 4, 2022
I am closing this as I believe your questions have been answered. Feel free to reopen if I am mistaken or open a new issue if you have other questions or feedback.