If an application is reading from a password protected zip file, is there a way to intercept the key being sent to decrypt the zip file. Or, is there a way to dump the files being read themselves?

  • 2
    In what language has the binary been written? If it's a .NET binary (and not obfuscated) it can be debugged and/or reversed fairly easily. Perhaps also try to determine if a popular zip library is being used.
    – Remko
    Jun 24, 2019 at 12:02
  • I don't believe it is using .Net. The Zip is version 2.0 using AES 128 bit encryption 'I think Winzip' Inside an xml file which has a list of the encrypted files it has a 'partial encryption key' which I have no idea what it does with Jun 25, 2019 at 2:17
  • Can you share the file(s)?
    – Remko
    Jun 25, 2019 at 8:10
  • Are you sure this is all legal? You provided an .iso for what appears to be commercial software. Jun 25, 2019 at 12:59
  • @JohannAydinbas please read this ;)
    – 0xC0000022L
    Jun 27, 2019 at 11:48

1 Answer 1


I'm writing this answer under the assumption the OP is within his legal rights to share the binaries.

First of, I read up on password protected zip files. Apparently that is not part of the ZIP specification itself but an invention of WinZip. They have documented their format modifications and all details on this page:


Important to notice here is how key derivation works. It feeds the given password through PKBDF2 with an iteration count of 1000 to derive the real key used in AES.

Using PEiD I checked for crypto signatures and found 4 references to AES (via their sbox). I then checked the surrounding code where these AES functions are used and stumbled upon a function call that got 1000 as an argument.

So then I just ran the binary with an attached debugger, breaking on that call. Then I inspected passed arguments and the first argument appeared to be the key.

I successfully decompressed the female zip file with the key to confirm.

How to derive that key?

Note that the algorithm used by the program seems to be a bit more complex. If you check the zip files, not all files in there are encrypted.

Two XML files are unencrypted and contain an XML property named encryption key, which looks similar to the real one above, but different bytes.

The application probably uses this property to deduce the above key which is eventually fed to AES to decrypt the encrypted files in the same archive. I do not know how this internal derivation works. You would have to find the code, probably by following the XML parser if you want to write a generic tool to decompress these encrypted files.

  • May I ask what debugging software you use? Jun 25, 2019 at 14:31
  • I used x64dbg (or rather x32dbg for this target) and the actual code reading I've done in IDA Jun 25, 2019 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.