[PrinceProcessor] Trying to change --pw-max - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat-utils, maskprocessor, statsprocessor, md5stress, wikistrip (https://hashcat.net/forum/forum-28.html) +--- Thread: [PrinceProcessor] Trying to change --pw-max (/thread-8659.html) |
[PrinceProcessor] Trying to change --pw-max - nullbyte - 09-22-2019 Hi, folks. I've been challenged to crack one of those dice-generated passphrases (portuguese words separated by spaces). I created an MD5 hash of the following string: "passaros banana montanha vista". I have this very short wordlist that I'm passing to pp64 (merely for testing): Code: sol Each line ends with a whitespace, which is removed only from the end of the candidate phrase with a hashcat rule. As you can see, the longest words are composed of 8 characters (9 characters if we count the trailing whitespace), and the maximum number of words in my combination is 4. So I need to set --pw-max to 36. This is what happens when I do: Code: >>> pp64 --pw-max=36 --elem-cnt-min=4 --elem-cnt-max=4 -o res.txt < shortlist.dict I don't understand the reason for this limitation, as we're not brute-forcing, we're simply giving it a few elements to rearrange - a few words. Why does the length of the candidate combination matters? If I set --pw-max to 32 or lower (and use smaller words to fit into that), pp64 will simply hang forever without errors. It creates an empty res.txt file and sits there, presumably stalled. It only runs successfully if I don't specify --pw-max, which keeps the default limit of 16 characters. Additional info: - pp64 was built from source, running on Arch Linux. RE: [PrinceProcessor] Trying to change --pw-max - royce - 09-22-2019 Modify the source. Code: --- pp.c-dist 2019-01-14 21:33:46.443328919 -0900 ... but pp64 will take a loooong time to start up. Also note that if the words really are separated by spaces, you'll need to do something to ensure they're inserted. princeprocessor doesn't have a separator concept, but you can shim the input words to do so. This is a hokey way to do it, but it works: https://gist.github.com/roycewilliams/18e3fb14b97cc05eb95a5645692bccc2 RE: [PrinceProcessor] Trying to change --pw-max - nullbyte - 09-22-2019 (09-22-2019, 05:17 PM)royce Wrote: Modify the source. I wonder if all I had to do was to wait patiently for pp64 to initialize. I think I didn't wait long enough before, as I assumed it wasn't going to work. Anyway, making those changes to the source code did it. It took about 5 minutes to start. When piping the output of pp64 directly to Hashcat, it aborted after about 2 minutes waiting; so instead I ran pp64 alone and feeded its output file later to Hashcat. It cracked the passphrase from this example in 0 seconds. Now I can try with a much larger wordlist. About the space separator, I got it working by using awk to append a space to every line in the wordlist, then used a Hashcat rule to remove the last character from every candidate passphrase, which removes the unintended space. At least for my use case, it is good enough. Thanks for the help. RE: [PrinceProcessor] Trying to change --pw-max - royce - 09-22-2019 Yeah, the startup time is non-trivial for sure. A big value of PRINCE is in keeping "state" about which words appear most frequently (based on their order in the original wordlist). So if that's not important, writing a simple shell script to generate all possible iterations will definitely start up faster. (09-22-2019, 07:09 PM)nullbyte Wrote: About the space separator, I got it working by using awk to append a space to every line in the wordlist, then used a Hashcat rule to remove the last character from every candidate passphrase, which removes the unintended space. At least for my use case, it is good enough. Yep - that's pretty much exactly what my gist does, too. Good enough is good enough! |