How do you crack a ZipCrypto deflate archive with an mp4? (I know the compression method used)

[RzfX15]

Hi there! I wanted to see if it was possible to crack the password for an old zip archive (ZipCrypto deflate) containing a single large mp4 file. I have tried using brute force through johntheripper but it took too long since the password seems to be a long string and the person who created the password has long forgotten it.

I realize that doing a plaintext attack on a file with deflate compression is difficult since we cannot just compress the mp4 header as plaintext.

However, the key here is that I have multiple other single mp4 zip files from the same person that are all deflate compressed in the exact same way but are NOT encrypted. Because of this, I was able to extract those files and open them in notepad++ to figure out that the mp4 video uses this file type box.

Hexadecimal:
00000018667479706d7034320000000069736f6d6d703432

ASCII
....ftypmp42....isommp42

So then in hopes of getting some plaintext to work with, I tried opening these unencrypted compressed files in notepad++ as well, but it extracts the file first and then opens up the uncompressed file in notepad++ and now I'm quite lost as I'm still somewhat new to all of this. How can I use the data from those other unencrypted deflate compressed zip files in order to find some sort of pattern that could potentially help me do a plaintext attack on the encrypted file?

EDIT: After playing around with the other files more, I was able to match the exact deflate compression. The method used for the deflate is when you right click a file -> 7-zip -> add to archive.zip

I still don't know how to translate this information into usable plaintext however.

[kimci86]

Hi, here is the first thing I would try:

For each of the single mp4 unencrypted zip files you have, use the first few bytes of the compressed entry as known plaintext, hoping that mp4 header would match and compressed output would start the same as in the encrypted zip file before encryption.

For example, running a command like this would use 12 bytes from compressed entry:
bkcrack -C encrypted.zip -c encrypted_entry.mp4 -P compressed.zip -p compressed_entry.mp4 -e -t 12
You could try to use a little more that 12 bytes to be faster (for example using -t 100 to use 100 bytes instead of 12), but that could miss solutions where the common prefix is shorter than the specified length.

If you have many such zip files, chances are some compressed entries start the same and running the attack with each of those zip files would be repeating the exact same work. You could inspect zip files with an hexadecimal editor to compare compressed data and avoid repeating work. There will eventually be a feature in a future version of bkcrack to show compressed data from zip file (see #93).

Please, let me know how it goes.

[RzfX15]

Alright, so the good news is that the code you gave me worked! On just my second attempt with one of the other zip files, I was able to get the keys for the encrypted zip file.

However, now I'm encountering a different issue with the compressed data.

After getting the keys, I tried
bkcrack -C encrypted.zip -k dd386e6e 5cbb6c44 bd188bac -U encrypted_new_password.zip easy

bkcrack 1.5.0 - 2022-07-07
[21:15:30] Writing unlocked archive encrypted_new_password.zip with password easy
100.0 % (1 / 1)
Wrote unlocked archive.

I then tried extracting the new archive using the new password "easy" using 7-zip but it gave me
Data error : Wrong password? : filename.mp4

Trying another method of extraction gave me the error:
Windows cannot complete the extraction.
The destination file could not be created.

So I figured that maybe this was because the file is compressed? So I followed the steps in the tutorial to deal with a compressed file using the inflate.py script

bkcrack -C encrypted.zip -c compressed.mp4 -k dd386e6e 5cbb6c44 bd188bac -d encrypted_deciphered.deflate

This gave me the deflate file, which I then used the inflate.py script on, but it gave me this message:

C:\Users\Name\Desktop>python3 inflate.py < C:\Users\Name\Desktop\encrypted_deciphered.deflate > encrypted_deciphered.mp4
Traceback (most recent call last):
  File "C:\Users\Name\Desktop\inflate.py", line 15, in <module>
    main()
  File "C:\Users\Name\Desktop\inflate.py", line 12, in main
    sys.stdout.buffer.write(inflate(sys.stdin.buffer.read()))
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Name\Desktop\inflate.py", line 8, in inflate
    return zlib.decompress(data, -zlib.MAX_WBITS)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
zlib.error: Error -3 while decompressing data: invalid literal/lengths set

Did I make a mistake somewhere? I'm not quite sure what this all means or what to do next, but at least we have the keys now!

[kimci86]

The errors you get show the data after decryption is not a valid deflate stream. That means you are in the unlikely but possible case where deciphering data with the keys bkcrack found would generate the first 12 expected bytes of a valid deflate stream you provided as known plaintext, but then followed by pseudo-random garbage. Basically, it means the solution is wrong.
Make sure you pass -e flag when you run bkcrack so that you get all the solutions in case there are several solutions that generate the expected first 12 bytes. Chances are one of them would be the right one and allow to correctly decipher data.
If that does not work, I suggest you continue trying with other files.

[magnumripper]

the unlikely but possible case where deciphering data with the keys bkcrack found would generate the first 12 expected bytes of a valid deflate stream you provided as known plaintext, but then followed by pseudo-random garbage.

I guess this shows the flaws in the encryption scheme: With good encryption, finding 12 bytes of known plain using an incorrect key should occur on average after 256¹² / 2 == 39,614,081,257,132,168,796,771,975,168 tries. Apparently this is called 39 octillions (or quadrilliards). 🤣

[RzfX15]

Man, that's a shame that it ended up being incorrect. So I reran the code you gave me earlier a couple times just to make sure that the -e flag was active.

bkcrack -C encrypted.zip -c encrypted_entry.mp4 -P compressed.zip -p compressed_entry.mp4 -e -t 12

Unfortunately, it just gave me the same single set of keys I mentioned in the previous post. So then I tried using a bunch of the other zip files I had, but none of them generated any keys. Are there any other alternatives for us to use in this case, or is this a case where we have to concede?

EDIT: Wait, hold on. I noticed one last zip file lying around and that got me some other keys. I'll let you know how it goes

[RzfX15]

Okay! Success!!! That last zip file gave me a new set of keys that allowed me to just create an archive with a new password that I was then able to extract easily.

I had no idea that keys could be "wrong" just going by the tutorial, and now I know how to use bytes from other compressed zip files in case this comes up again in the future.

Thank you so much for all the help! I learned a lot from this experience.

[kimci86]

Glad it worked!
I close this issue then. Feel free to open other issues if you have questions or suggestions.