Combinator attack missing correct candidate on large wordlist
#1
Hey y'all.

I am teaching myself the ropes of Hashcat by specifically working on creating and refining wordlists to test against Comcast Xfinity modems and WPA2.  The default format of these passphrases is a five letter word, four digit number, and a six letter word.  An example would be build2373guitar.  I've captured handshakes from two separate modems for which I know the passphrase for testing.

For the left side wordlist, I parsed the Google 20k list for 5 letter words and used combinator to create the list with all 5 letter words, each with a number 0000-9999.  Call this left.txt.  For the right side, I parsed the same Google 20k list for 6 letter words.  Call this right.txt  For the example above, I can use the command "cat left.txt | grep build2373" and see that the matching left side is in the file.  Same for the right side.

From here, I can test the combinator within hashcat to ensure my command will encounter the correct candidate:

hashcat -m 22000 -a 1 -w 3 --stdout left.txt right.txt | grep build2373guitar

The list is large, so this takes a while, but it always finds the correct candidate.

Where the rubber meets the road is the problem.  An example of the command I've used is as follows:

hashcat -m 22000 -a 1 -w 3 comcast.hccapx left.txt right.txt

I've put two separate hccapx's through knowing the correct candidate will be created, and it has exhausted both times.  I've also split the left side in half to create smaller batches of candidates and still no luck.

In an effort to ensure my captures are good and hashcat is working I have verified successful cracks with the following:

Create text file with the correct candidate, call it winner.txt.  Run the following command with success:

hashcat -m 22000 -a 0 -w 3 comcast.hccapx winner.txt

Create left side with only the correct 5 letter word and digits 0000-99999, call it build.txt.  Combine that with my usual right side with success:

hashcat -m 22000 -a 1 -w 3 comcast.hccapx build.txt right.txt

So this seems to be an issue relating to processing a large amount of candidates.  My GPUs are an RX580 and a Vega 56.  Is it possible that one or both is putting out bad hashes under load?  They're not overheating, and output otherwise seems good.  Is there a way to test this?  Is there something else I am missing here?

Thanks for the input in advance!
Mike
Reply
#2
I don't think the grep test is a good/valid test.

There could be any other (even non-printable) character within that line and therefore the combined (concatenated) result is different.

You could test it maybe like this:
Code:
grep build2373 left.txt | xxd -p | tr -d '\n'

and
Code:
grep guitar right.txt | xxd -p | tr -d '\n'

the combined hexadecimal output (maybe just stripping the newline characters \n) must be the same as
Code:
echo -n build2373guitar | xxd -p | tr -d '\n'

So what I mean is, even if you think the combination is within the file... you could just have a space or anything similar after the words and the grep will still work, while the combination will be wrong (e.g. "build2373 guitar" instead of "build2373guitar")

BTW: also your -m 22000 --stdout command doesn't make much sense (remember --stdout is a special "mode", you can't combine it with a -m x parameter, -m 2000 = STDOUT internally)
Reply
#3
(03-26-2020, 06:31 PM)philsmd Wrote: I don't think the grep test is a good/valid test.

There could be any other (even non-printable) character within that line and therefore the combined (concatenated) result is different.

You could test it maybe like this:
Code:
grep build2373 left.txt | xxd -p | tr -d '\n'

and
Code:
grep guitar right.txt | xxd -p | tr -d '\n'

the combined hexadecimal output (maybe just stripping the newline characters \n) must be the same as
Code:
echo -n build2373guitar | xxd -p | tr -d '\n'

So what I mean is, even if you think the combination is within the file... you could just have a space or anything similar after the words and the grep will still work, while the combination will be wrong (e.g. "build2373 guitar" instead of "build2373guitar")

BTW: also your -m 22000 --stdout command doesn't make much sense (remember --stdout is a special "mode", you can't combine it with a -m x parameter, -m 2000 = STDOUT internally)

This is a fantastic response.  Helps me learn and troubleshoot at the same time.  I'll check into this.  Thanks!
Reply
#4
I am looking for a list with 5 letters length as well.

could you share the wordlist please?

thank you in advance.
Reply
#5
(03-26-2020, 06:31 PM)philsmd Wrote:
Code:
grep build2373 left.txt | xxd -p | tr -d '\n'

and
Code:
grep guitar right.txt | xxd -p | tr -d '\n'

the combined hexadecimal output (maybe just stripping the newline characters \n) must be the same as
Code:
echo -n build2373guitar | xxd -p | tr -d '\n'

I did some checking against my list.  I am a little confused on the order of the pipes you've got.  I understand that xxd -p gives us a plaintext hexdump and tr -d '\n' removes new lines.  If I flip flop those, it should theoretically remove the new line from the end of the grep and then perform hexdump.  I gather that's what we're after.

Results are as follows:

grep build2373 left.txt | tr -d '\n' | xxd -p
6275696c6432333733

grep guitar right.txt | tr -d '\n' | xxd -p
677569746172

echo build2373guitar | tr -d '\n' | xxd -p
6275696c6432333733677569746172

That's correct, no?  To be certain, the new lines are the proper demarcation of words for Hashcat, right?

Thanks again.
Reply
#6
(03-26-2020, 09:37 PM)amdeusace Wrote: I am looking for a list with 5 letters length as well.

could you share the wordlist please?

thank you in advance.

I'll send you over what I've got once I know it's clean and functional.
Reply
#7
(03-26-2020, 10:19 PM)antimatterizer Wrote:
(03-26-2020, 09:37 PM)amdeusace Wrote: I am looking for a list with 5 letters length as well.

could you share the wordlist please?

thank you in advance.

I'll send you over what I've got once I know it's clean and functional.

I am talking just for the list.

I've got one with 6k words. Do you have with more?
Reply
#8
(03-26-2020, 10:23 PM)amdeusace Wrote:
(03-26-2020, 10:19 PM)antimatterizer Wrote:
(03-26-2020, 09:37 PM)amdeusace Wrote: I am looking for a list with 5 letters length as well.

could you share the wordlist please?

thank you in advance.

I'll send you over what I've got once I know it's clean and functional.

I am talking just for the list.

I've got one with 6k words. Do you have with more?

The one I am using is quite a bit smaller than that, but I have had good luck with it having what I want for this purpose.
Reply
#9
This command:
Code:
xxd -p

... unfortunately adds newlines within the hexadecimal output if a certain line line was reached. Try it yourself

Code:
echo -n aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | xxd -p

The tr -d '\n' removes the newline and will guarantee that the hexadecimal output is within one line. The order of the commands in the pipe was therefore correct, but it might not be necessary because the words "guitar" etc are quite short and therefore the newline is never added.
Reply
#10
Can you try cracking your hccapx file with -m 2500 (for testing purposes) ?
Reply