Having plaintext but not the original zipper

[dkdlv]

Hi!

I am facing more or less the same issue than #50 (#50) : I have an encrypted file with Deflate, I have a full file with matching CRC in plaintext which is 13131 bytes uncompressed but don't get to find a zipper who bring me to the compressed size-12bytes.

I understood that there is a solution searching with "the last kilobyte of compressed data" but I have trouble to realize it... Can you give more details on this or give hints on how to go further?

Thanks in advance!

[kimci86]

Hello,

As you understood, the general approach for this situation is to try many zip compression tools with various compression levels hoping to use the right combination to get correct compressed plaintext. A quick criteria to discard combinations is not having: known file compressed size = packed size in encrypted archive - 12.

Then, if we can't find the right combination of tool and settings, another approach, the one which was used to solve #50, is to inspect closely how the known file gets compressed with various tools and settings, hoping to see some pattern.
You may use an hexadecimal editor to inspect compressed bytes and the tool infgen to inspect the compressed data structure.

In the case of #50, it was then apparent that the compressed file ended the same regardless of the compression tool or compression level. So what I did was to copy the last kilobyte of the compressed known file (the exact suffix size is arbitrary but looked sensible from my observations) into a file and use it as plaintext (parameter -p) with an offset (parameter -o) being: packed size in encrypted archive - 12 - known suffix size.
Using infgen, it could be explained because the deflate data was ending with a stored block (i.e. uncompressed, so easy to get right). This scenario might not repeat itself for your file because it is rather small and is probably compressed as a single block. For reference, the file in #50 was about half a megabyte.

I suggest you have a look at the beginning and the end of the compressed file with various compression tools and settings to see if there is some pattern. Let me know how it goes and do not hesitate to ask if you have more questions.

[dkdlv]

My first tries were with an hexadecimal editor, but without success.
I will try with a bigger file I have.
Thanks a lot for the time taken!

I will let you know.

[kimci86]

Thinking more about it, this process of looking for patterns in several compressed versions of a known file could be automated to some extent. I opened #99 about it.

[nikkopt]

I have the same problem as op and noticed that my different zip files all end with the same text but i don't know if it's part of the compressed stream or the container (it's the name of the file itself, IMG_20230929_192353.PNG and other crap). The files also share A LOT of the same plaintext around the middle but not in the exact same place and i can't seem to know how the offset parameter works in this case (hell, not even in the end of the file)

[kimci86]

Hi @nikkopt,

noticed that my different zip files all end with the same text but i don't know if it's part of the compressed stream or the container (it's the name of the file itself, IMG_20230929_192353.PNG and other crap).

I guess you have been looking at the end of the ZIP files (the container as you say) instead of the compressed streams. You can learn about ZIP file structure to get a better understanding of what you see.
https://en.wikipedia.org/wiki/ZIP_(file_format)#Structure
https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html
There are also tools that show the format structure in a hexadecimal editor such as Kaitai Struct WebIDE to make it easy.

This is a case where extracting deflated file from unencrypted ZIP could be convenient (#93, not implemented yet but will be eventually).

The files also share A LOT of the same plaintext around the middle but not in the exact same place

Then, I suggest using an hexadecimal editor to get deflate streams of your known file from ZIP files of various settings. Look for a large part that appears in all deflate streams, or at least most of them. The larger the part you get is, the faster the following steps will be. Save that part in a file on its own. Check at what position in appears in each deflate stream to get a range of possible offsets. Then use the common part as known plaintext to run the attack specifying an offset in the possible range, trying many offset values in the range to guess the good one. Note this is not guaranteed to work as it involves making guesses.

I hope to make those steps easy in the future (#99), but for now it is not. Let me know if you need more details.

[nikkopt]

Ouch, that sounds like a lot of trouble. It's a shame it can't be more automated.
If it was really something I needed (like lost personal files) I probably would give it a go, but it's just a zip file that my phone created with several logs/dumps/configs for me to send to the devs so they can troubleshoot a bug I was having.
I found it strange for them to encrypt such files and was curious to see if there was something personal inside.
Thanks for your help anyway!

[kimci86]

@dkdlv Do you need further help? If not I will close this issue.

[dkdlv]

Hello ! Thanks for your help, someone on my team found a way to recover the password with another strategy.

You can close the issue, thanks again for the work you achieved!