Add warning message about large outputs of zip2john

[gartikis]

Sometimes zip2john would produce a large output and confuse the user. A warning message has been added to explain to the user that this is normal behavior.

[solardiz]

Hi. Thanks. This would partially fix issue #4051.

Please squash the commits into one (with a commit message that would reflect what it does, and without the john2zip typo), and force-push.

Please replace the word "WARNING" with "Note". We use "warning" for things that are potentially not normal, whereas this is always normal.

zip2john does not always produce large output - this varies by ZIP archive sub-type. Ideally, we'd only output this Note when the output is (or will be) actually large. But this can be taken care of with a separate PR.

Ideally, we'd also implement similar for some other *2john programs (need to identify exactly which and under what conditions).

[gartikis]

Thanks! I squashed the commits into one and wrote a cleaner message with no errors. I wrote NOTE in uppercase since that is how it was written on the other stderr messages.

If you are able identify which *2john programs cause a similar behavior I am more than happy to apply the same changes to those scripts. As well as setting the conditions for when this message would be shown to the user in another PR.

[solardiz]

I wrote NOTE in uppercase since that is how it was written on the other stderr messages.

Actually, it is "Note" in many other messages, and "NOTE" in only 3 other messages (but one of them is in zip2john). So we may want to get the rest of them changed to "Note". Also, we generally omit the trailing dot in one-line one-sentence messages.

But I don't mind accepting this as-is.

If you are able identify which *2john programs cause a similar behavior I am more than happy to apply the same changes to those scripts. As well as setting the conditions for when this message would be shown to the user in another PR.

Maybe @magnumripper can help here.

[gartikis]

Thanks for letting me know! I appreciate it. I made the changes and left the other capitalized NOTEs since it wasn't part of this case and I don't know how the issues are structured for this project.

[magnumripper]

If you are able identify which *2john programs cause a similar behavior I am more than happy to apply the same changes to those scripts. As well as setting the conditions for when this message would be shown to the user in another PR.

Maybe @magnumripper can help here.

"grep -l FMT_HUGE *plug.c" will show potential format sources but the threshold for that is very low - 900 bytes or so.

RAR (old RAR, not RAR5) may do this, unless file was made with "rar -hp". pkzip and Zip (winzip) may too. Also DMG, CryptoSafe, Keepass and DMG, as well as some other non-archive formats.

None of them will unless really needed - for archive files this means when there's no smaller file to pick as the victim.

BTW a silly problem is we convert to hex so a 1 GB archive will produce a 2 GB input file. We should at least convert to Base64 instead (1.3 GB), or even support binary input files. A format could autodetect whether hex or Base64 is used - already at 20 characters, the risk that Base64 looks like hex by chance is all but impossible. Edit: It's one in almost 10^14 or 2^46.

magnum