how do you get the password hash of a zip file?

Question

I was doing a capture the flag sample, and they gave me the file's hash. I ran it through John The Ripper and I got my password for the sample.

The thing is, the hash was given to me. Is there a way to find the hash of that file if it weren't given?

There are two points that need to be resolved to beat a password: The hash and the encryption algorithm.

I have been practicing with password protected zip files, so I figured it was using zip 2.0 or something or some sort of AES, I can figure that out with the help of Google.

What I can't find out however, is how to access the metadata for the zip file for that hashed data. Since it is a standard, zipping something doesn't need to have the algorithm in it for when storing the password. However, there needs to be some sort sort of hash.

Does anyone know how, with this example of a password protected zip file, this is done?

I'm using a MacBook Pro right now.

Answer 1

Password hashes are not extracted from the file. John the Ripper (JtR) does not really do this. You can download the code for JtR to figure out how it is done. Here is a little article on how to get the so called "non-hash" info for .zip and .rar files using zip2john and rar2john: http://www.cybercrimetech.com/2014/07/how-to-cracking-zip-and-rar-protected.html

To correct the misnomer, JtR does not actually "retrieve the hash" from the file. It extracts certain information from the file, for example, as documented in the rar2john code:

Output Line Format:
 *
 * For type = 0 for files encrypted with "rar -hp ..." option
 * archive_name:$RAR3$\*type\*hex(salt)\*hex(partial-file-contents):type::
       ::archive_name
 *
 * For type = 1 for files encrypted with "rar -p ..." option
 * archive_name:$RAR3$\*type\*hex(salt)\*hex(crc)\*PACK_SIZE\*UNP_SIZE\*0\*
       archive_name\*offset-for-ciphertext\*method:type::file_name
 *
 * or
 *
 * archive_name:$RAR3$\*type\*hex(salt)\*hex(crc)\*PACK_SIZE\*UNP_SIZE\*1\*
       hex(full encrypted file)\*method:type::file_name

So, as shown above, the "password hash" is not extracted. Also, it is a complete fail to believe that the file is "entirely" encrypted (as suggested by others answering similar questions). Instead, critical unencrypted and encrypted file items, such as the salt, are retrieved to generate a "non-hash". These items are used by JtR with various password guesses to test decryption. It uses the zip or rar password hash generation functions to create a hash from the guess that is in turn used to generate the crypt key values. The generated crypt key values are then used to test against a small, extracted, and well-defined portion of the encrypted file.

So, while JtR is not "extracting a password hash" that can be sent to any ol' password-hash-checker-rainbow-table-lookup-thingy, it is doing the next best thing--extracting critical cracking information. The steps to crack are essentially: 1) a hash is generated from a password guess, 2) a few extra steps are added to check that decryption succeeds or fails (a lot of fails), and 3) repeat. What makes rar cracking so difficult is a different salt for each rar file and, more importantly, the large and variable number of hash iterations that are needed before the decryption test can be performed. The newer zip process is similar, but the iterations are not variable--last I checked--making it somewhat easier.

This is the nut of "how it is done" as asked and the answer is "you don't" get the real password hash of a zip file until just before the file is cracked.

The example from the question's CTF exercise is misleading. The given "hash" could have been a simple password hash prepared for the exercise to simplify the cracking process for the student by any ol' cracker OR it could have been a specific zip2john "non-hash" that resulted in a fairly easy password for JtR to guess--short, common, or both. The questioner did not provide a "hash" or "hash file" to verify either way.

Answer 2

Why would there need to be a hash? The zipped file is compressed and then encrypted. This does not require storing a hash in the file because it's not authenticating, it's decrypting. The only thing that may be stored in the file is a salt, depending on the encryption used.