I don't have the ability to determine/recover the master password for a production system that uses zip 2 archives. However, I need to be able to add new files to existing encrypted archives. 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 am not interested in recovering the contents.
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?
The goal, in layman's terms, is to add
08_14.dat, etc. to a backup file that the backend system can read.
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. If the current file that it wants to decrypt/decompress, matching the
##_##.dat signature, isn't encrypted then it bails too.
More specifics of the system shouldn't be necessary, but the reason this issue has occurred is because our front-end system that shared the symmetric key (and auto-appended the .dat files for us) has passed on to the otherworld where obsolete hardware goes once it malfunctions.
I'm open to possible solutions to the problem, but just a lively discussion on whether this is feasible/practical/etc. is more than enough - I'll build the solution if this line of reasoning appears possible.