If the current file that it wants to decrypt/decompress, matching the #_#.dat signature, isn't encrypted then it bails too. Note that simply adding unencrypted files won't suffice - the system uses a hardware token for the encryption/decryption key (which is why I can't possibly recover it) AND it tries to decrypt each file individually using the logic: 1) lists archive 2) sorts by the above names where the first 2 digits represent the month 01-12 and the second 2 digits represent the year for 1997-2014 3) and then tries to extract the NEWEST file first - bail upon first decryption failure. to a backup file that the backend system can read. Since these tools recover key's 0-2 (3x 4-byte key triplet) per the zip 2.0 appnote (scroll to nearly the very end), in theory would it then be possible for those tools (or a modified open source zip utility that can write encrypted zip 2.0 archives) to initialize the keyset with the known-to-decrypt key triplet, generate a 12-byte 'random', and then use these values to add additional files to the existing archive? However, I am not interested in recovering the contents. There are various tools out there that can 'break' the zip 2.0 encryption with a known-plaintext attack, which allows recovery of the contents.
However, I need to be able to add new files to existing encrypted archives.
I don't have the ability to determine/recover the master password for a production system that uses zip 2 archives.
0 kommentar(er)
