How to find constant string in PDF

[akhmarov]

Hello!

I have a question

I have an archive ARCHIVE.ZIP (ZipCrypto+Deflate) with contents: FOLDER\FILE1.BIN [index 0] FOLDER\FILE2.PDF [index 1]

I have plaintext file: FILE2.PDF (about 4-5 MB size)

CRC32 of compressed FOLDER\FILE2.PDF and non-compressed FILE2.PDF files are the same I do not know the archiver and compression level used for compression+encryption. I tried several utilities with no luck

I checked various archived variants of FILE2.PDF using HEX editor, but unfortunately headers and footers are not constant

Do I need to construct the same FOLDER structure in the plain archive or I could use just single FILE2.PDF?

[kimci86]

Hi, as you have understood, having ARCHIVE.ZIP (ZipCrypto+Deflate) and the original FILE2.PDF file means cracking the archive is a matter of compressing FILE2.PDF with the good tool and settings. I would try different compression tools and different compression levels to try to get the expected compressed size (packed size in encrypted archive minus 12) and run the attack.

I tried several utilities with no luck

Then, if you do not manage to find the correct tool and settings to get the expected compressed size, you can try to use only a part of the compressed data for various tools and settings, hoping that this part matches compression in encrypted archive for some combination of tool and compression level you tried. For example, only load the first kilobyte with -t 1000 option when running bkcrack.

I checked various archived variants of FILE2.PDF using HEX editor, but unfortunately headers and footers are not constant

I understand you looked at various zip archives containing FILE2.PDF in an hexadecimal editor. Then, note that zip metadata is not important. I mean local file header and central directory file header for example are not directly used to run the attack. Only compressed data is relevant. This is what you could have a look at to try and find a recurring pattern to better guess what the compressed data might be in encrypted archive. Even though you do not see a constant prefix or suffix, maybe there are just a few of them to try. I admit this is rather technical to do and requires a little bit of knowledge about how zip files are structured.

Do I need to construct the same FOLDER structure in the plain archive or I could use just single FILE2.PDF?

No, it makes no difference for bkcrack. It has an impact on zip headers containing metadata about the zip entry but not the entry data itself.

Please let me know if this helps.

[akhmarov]

Hi, kimci86

Thanks for answer!

According to your description I have to find any constant string and use it

Using HEX editor I found that all manually created Deflate archives from file FILE2.PDF contains the same 21-byte string (say \ABCD\EF... ASCII with "backslash" symbols)

I added found string to the file MATCH.BIN and tried to use bkcrack.exe with the following command bkcrack.exe -C ARCHIVE.ZIP --cipher-index 1 -p MATCH.BIN

Unfortunately no keys were found. Maybe I missed something important?

[kimci86]

Using HEX editor I found that all manually created Deflate archives from file FILE2.PDF contains the same 21-byte string (say \ABCD\EF... ASCII with "backslash" symbols)

I find it surprising that deflate outputs such a sequence of printable characters. This could be a clue that deflate compression uses a stored block. That would make guessing compression much easier. Would you mind sharing the output of bkcrack -L ARCHIVE.ZIP to have a look at original and compressed sizes? And the first few bytes of deflated FILE2.PDF ? (or ideally the entire file if it is not private)

Anyways, if you found a probable piece of compressed data, then one important parameters you might have missed is the offset. Along with the sequence of bytes, you have to specify where they are located if it is not at the beginning of compressed data. If for example you noticed the 21-byte string you found starts after 42 bytes of less predicable data, then you would run this:

bkcrack.exe -C ARCHIVE.ZIP --cipher-index 1 -p MATCH.BIN -o 42

Does it help?

[akhmarov]

Hi

String offset is different for each file. The lowest one I saw was 0x000FAF70. I selected 0xFAD00 and converted it to decimal (1027328)

Result string was: bkcrack.exe -C ARCHIVE.ZIP --cipher-index 1 -p MATCH.BIN -o 1027328

Unfortunately that did not helped :(

Yes, I can share files with you, but using some kind of private channel

[kimci86]

Let's continue the discussion via email. I just sent you a message.

[kimci86]

Solved via email. For reference, it was a matter of finding the tool to apply the right compression to the known file. In this case using zlib via tools/deflate.py script did it.

If that had not been successful, an option would have been to look for a large stored block that appears in deflate output for various tools and parameters, hoping that it also appears in encrypted data, and bruteforce the offset. I don't know if some tool can help finding such stored block based on several deflate streams. Maybe I can make such a tool in the future.