This file describes the changes made to the different versions of the
programs contained in this package.

Changes from 1.2.1 to 1.2.2
===========================

 * "Relf" has found and fixed a bug that caused pkcrack to fail under certain
   circumstances (roughly one out of 32 keys couldn't be found). Thanks!
 * Two more options for pkcrack, also by "Relf" (Thanks again!):
    -a will stop stage2 immediately when a combination of key0, key1, key2 has
       been found
    -n disables the (new!) progress indicator
 * corrected handling of 'data descriptor' in extract-functions 
   (Thanks to "Relf" and Andreas Lessig <andreas.lessig@bigfoot.de>!)
 * zipdecrypt now uses dynamic allocation for directory entries, which means
   the 200 files limit is gone
 * The extract program now has a -v flag to print a verbose description of the
   ZIP file
 * Considerable speedups in stage1
 * The source distribution now includes an automated test suite

Changes from 1.2 to 1.2.1
=========================

 * 1.2.1 is mainly a bugfix release.
 * Modifications for 32 bit Windows added by Dimitri Bragin. Thanks!
 * Several small bugfixes by Mats Lofkvist. Thanks!
 * Made findkey work again.
 * Mats also wrote the makekey program. Useful for hacking and testing. Thanks!
 * Stage 3 now also looks for passwords of length 1-3, again thanks to Mats!
   (I really like people sending me patches... :-)
 * Added option -i to pkcrack and extract to turn *off* case-*in*sensitive
   filename matching in ZIP archives. This is because certain Windows-packers
   use lowercase filenames. Lots of people complained about that. :-/
 * The zipdecrypt program as well as the -d option of pkcrack currently can't
   handle ZIP archives with more than 200 files. The limit is hardcoded, but
   can easily be increased by modifying zipdecrypt.c and recompiling.
   Pkcrack 1.2 would just crash, now you get a warning (at least...).

Changes from 1.1 to 1.2
=======================

 * included functionality of "extract" and "zipdecrypt" into pkcrack
 * input files can now be specified using a variety of options
 * if the known plaintext starts in the middle of the encrypted data,
   you can specify an offset where the cracker should start
 * lots of minor changes / code cleanups / small bugfixes, mostly due to
   user input (Thanks folks!)

