Jump to content

Brute forcing ZIP password


Neil Pate

Recommended Posts

I have a zipped file I need to get inside. For those curious I kept a diary of daily activities about 13 years ago, and now I want to read it. Luckily I have managed to get inside most of it, but the last file is proving stubborn (or rather my memory is just not what it used to be).

So... I need to brute force it. I have no idea the possible key length, all I know is I used a 12 character password on my main archive (but luckily I remember that one), I suspect the most recent entries have something less.

Does anybody have any nifty routines that can test a password against a file in an archive? The OpenG ZIP routines do not expose this, and inside them is just a DLL written by Rolf I think.

I am not really in a rush to get this done, so it will become another "academic exercise" that I will just keep chipping away in my spare time. I am aware of the rather large set of character combinations that could be possible :-)

Edit: actually it seems the OpenG ZIP library (DLL) does implement something like this, there is a function lvzip_unzOpenCurrentFilePassword. Now I just need to figure out the function call parameters.

Edit2: seems I am being daft. Password protection is implemented in the OpenG toolkit, I just needed to look for it!

Edited by Neil Pate
Link to comment
On 7.9.2016 at 10:55 PM, Neil Pate said:

(like how to write a recursive algorithm in LabVIEW without having a nervous breakdown)

The answer is generally to convert it to a stack based algorithm. Rather than calling the same function, push the data into a queue and dequeue it until the queue is empty.

Link to comment

The password protection used in a ZIP archive is not something you can just remove. The entire data stream for a specific file entry is completely encrypted with a hash that is generated from the password. The original password hashing in the original PkZip application has several weaknesses that make it less secure than the theoretical complexity given by the bit size of the hash key. Later versions have fixed some of these weaknesses and added other password algorithmes like AES encryption, which by modern standards aren't unbreakable either, but still quite an effort to brute force.

The principle of all the password removers simply is to generate various passwords (or use dictionaries), determine the used password encryption algorithme from the directory entry, then decrypt the stream with the according password hash and check if the CRC of the decrypted stream matches with the CRC stored in the directory entry. The OpenG ZIP library can do that by simply trying to retrieve a specific file with all possible passwords until you don't get an error. There is still a small chance that the CRC check matches, but the actual content is not correctly decrypted since the CRC is just a 32 bit integer, and there are of course possible collisions for multiple data streams producing the same CRC.

If your ZIP file uses the old non-AES password algortithme that should simply work with the currently released OpenG ZIP library. If it uses AES then the next version which is currently in the works will support that too.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.