Date: Wed, 17 Aug 2011 14:34:52 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: pkzip encr Note, this email was done yesterday, but I got sidetracked, and did not release it. I will push it out now, and will post about the progress I have made since I wrote this yesterday. Benchmarking: pkzip [N/A]... DONE Raw: 6594M c/s NOTE, I am far from being done. PKZIP original encryption has a lot of things to work through. First, you only get a 1 or 2 byte checksum, after decrypting the first block. So, if you have 'enough' files in the same .zip file, all encrypted with the same password, then finding that password, can be done by simply finding a word which satisfies all checksums. That is the 'first' mode I am working on, and is the 'speed' listed above. I have plans on how to handle zip's if there is not enough files to allow the checksums to be enough. Examples would be the .zip files in the latest contest. In those files, there was only 1 internally encrypted file. Under these situations, you have to fully decrypt the file, and have it decrypt to the proper size, and then perform a CRC32 on the resultant data, and have it match. I do have some shortcuts in mind, so we may be able to get this working much faster. Programs such as FZC do not perform any tests like this (and simply output based only on the checksums), and programs such as FCrackZip spawn off to unzip using the -P and the password to 'test' the file. I have 4 'types' of cracks planned. Type 1 is simply checksum only. The test data will mostly perform this way. In this mode, if all the checksum match, then the word is 'cracked'. This can lead to false positives. Type 2, will take a file that is assumed to be ASCII. It will grab, a small part of the file (say, first 40 bytes of compressed data). Then, we decrypt it (when a 'possible' key is found), and uncompress the available data. We then make sure that all decompressed data is between 0x20 and 0x7F (and \r \n \t, etc). If we find a password that has proper checksum, and decrypts the file to valid ASCII, we assume we have found the password. This will make it easy to make a 'short enough' input hash line. Type 3 is 'binary_data'. In this mode, we do not have any knowledge that the file is all ascii. Such as a set of object files, a set of .zip files, a set of word documents, etc). In this mode, we do have a small enough file (to put on the LINE_BUFFER_SIZE line (along with any other hashes). We will also need to list the compressed size, the decompressed size, and the CRC32. In this mode, we still perform the checksum tests, and then when we have a hit, we fully decrypt the buffer, fully explode it, and if all was correct, we crc32 the resultant string. If everything checks out, we have found the password. The final type (type 4), will be .zip files which have data too large to put into a LINE_BUFFER_SIZE line. In this mode, we store the name of the .zip file. Then john will pull the required data out of the .zip file at run time (and will refuse to run if the .zip is not there). However, once this data is pulled out of the .zip file (at load time), then this really becomes similar to the type3. I am close to having the type 1 working. It will be setup where up to 8 files (hashes and checksums), can be loaded in a single line. This way, once built, you can be pretty sure the password is correct. Some things I have found, is: 1. pkzip > 2.0 will only checksum 1 byte. This is from the CRC32. 2. Winzip (in pkware encryption), also only uses 1 byte checksum, from the CRC32 2. infozip (unix) checksums 2 bytes. These are from the timestamp of the file. Also, it appears that (headerflags & 8) is set by infozip. There is also other information in the 'extra data' section of the main header, which is set by infozip. The 2 byte checksums are MUCH weaker in cracking (i.e. john will be able to run much faster, or closer to 'type 1' cracking). Jim. Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.