john

john copied to clipboard

Please allow for multiple --wordlist options on CLI. This will be useful for users having multiple dictionaries, without the need to combine them in one. Also allows for single kernel initialization in one execution cycle over multiple dictionaries. Currently this can be achieved through pipes, either with --stdin (no rules) or --pipe (memory allocation errors in some builds). Inbuilt support will yield max performance in this situations.

I endorse this but am not sure what syntax we'd use: Shell wildcard expansion of eg. -w:wordlist* hashfile* will result in eg. -w:wordlist1.txt wordlist2.txt wordlist3.txt hashfile1.in hashfile2.in and our options parser can not know which is what. @solardiz (or anyone) do you have any ideas?

We could allow for -w:directory for a half-assed workaround (we'd use ALL files in that directory as wordlists).

Of course, simply allowing -w:wordlist1.txt -w:wordlist2.txt -w:wordlist3.txt would be easier - but wouldn't support wildcards. It'd be great to support wildcards if we do this.

In my experience dicts come from different places (leaks, named by pentest task and etc.) and they are not renamed just to keep the source where it came from. This means wildcards will not be that useful IMO.

The easiest way to implement this would be to allow -w:file1.txt,file2.txt[,...] - that is, any number of files separated by commas. We'd use existing list code. I think it would be fairly trivial to implement but it would still not allow for wildcards.

Wildcards are good to have, but not essential. Even comma separated(which will be great option) can have wildcards, just the argument have to be quoted, so then internally we can glob. This will be a bit counter-intuitive, but find does similar.