{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "Not a bug.",
    "ClosedDate": "2008-10-10T09:49:46.563-07:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "I posted another issue yesterday about ZipCrypto not passing an correct password and that were properly solved.\n \nIm testning this ZipLibary when Im playing with an Zip brute-force password breaker and now I experiencing another issue.\n \nWhen I have created a Zip file by winrar with the password \"t2\" im getting the password \"c9\" to be valid and its this row that allows it.\n \nIm not sure if have missed something but Im copied the method SetupCipher and modified it a little bit to work better with my solution cause if Im making a password brute force breaker I don't want any exception to be thrown but so here is the code I have been testing with, but it shouldn't be any differences.\n \n        public bool ValidatePassword(string password)\n        {\n            ZipCrypto cipher = null;\n            // decrypt the file header data here if necessary. \n            if (Encryption == EncryptionAlgorithm.PkzipWeak)\n            {\n                if (password == null)\n                    throw new BadPasswordException(\"This entry requires a password.\");\n \n                cipher = new ZipCrypto();\n                cipher.InitCipher(password);\n \n                // Decrypt the header.  This has a side effect of \"further initializing the\n                // encryption keys\" in the traditional zip encryption. \n                byte[] DecryptedHeader = cipher.DecryptMessage(_WeakEncryptionHeader, _WeakEncryptionHeader.Length);\n \n                // CRC check\n                // According to the pkzip spec, the final byte in the decrypted header \n                // is the highest-order byte in the CRC. We check it here. \n                if (DecryptedHeader[11] != (byte)((_Crc32 >> 24) & 0xff))\n                {\n                    // In the case that bit 3 of the general purpose bit flag is set to indicate\n                    // the presence of an 'Extended File Header', the last byte of the decrypted\n                    // header is sometimes compared with the high-order byte of the lastmodified \n                    // time, and not the CRC, to verify the password. \n                    //\n                    // This is not documented in the PKWare Appnote.txt.  \n                    // This was discovered this by analysis of the Crypt.c source file in the InfoZip library\n                    // http://www.info-zip.org/pub/infozip/\n \n                    if ((_BitField & 0x0008) != 0x0008)\n                    {\n                        return false;\n                    }\n                    else if (DecryptedHeader[11] != (byte)((_TimeBlob >> 8) & 0xff))\n                    {\n                        return false;\n                    }\n                }  \n            }\n            return true;\n        }\n \n \nThe error should be here:\n                    if ((_BitField & 0x0008) != 0x0008)\n                    {\n                        return false;\n                    }\n                    else if (DecryptedHeader[11] != (byte)((_TimeBlob >> 8) & 0xff)\n                    {\n                        return false;\n                    }\n \nIve even experienced once when it jumped out here\nif (DecryptedHeader[11] != (byte)((_Crc32 >> 24) & 0xff)) with the wrong password data that were used.",
    "LastUpdatedDate": "2013-05-16T05:32:37.25-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2008-10-10T02:56:07.067-07:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "private ZipCrypto SetupCipher(string password) approves an incorrect password",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 6416
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "What you describe is a feature of the PKWARE zip file protocol.\r\nThere are a couple of places during the unpack/extract operation where validation is used.  The CRC check on the password - which is done in the SetupCipher() method in my implementation - is one such place.   The CRC check of the plaintext is another validation step.  Only when all validations pass, can we conclude that the password is correct. \r\n\r\nThe SetupCipher() method can rule out a large set of incorrect passwords quickly.  But succeeding at this check does not guarantee that the password is correct.  The final guarantee that a password is correct is that the CRC matches after you decrypt. \r\n\r\nIt sounds to me like you are building a zip cracker.  If this is the case, the approach you are taking is not very efficient.   If you want to crack a zip, read the paper by Eli Biham  and Paul C. Kocher, circa 1995.  It describes a method to do it very efficiently. \r\n\r\n",
      "PostedDate": "2008-10-10T09:49:35.643-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2008-10-10T09:49:46.563-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:44:38.763-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:32:37.25-07:00",
      "Id": -2147483648
    }
  ]
}