Custom Ruleset, Correct word but exhausted
#1
Hello,
  I am wanting to test out created rules for myself.

For my first rule I want to make the first letter of word a capital and for every word I want to add three numbers to the end

so for example, password -> Password123 (Password389, Password486, etc etc)


mine.rule

Code:
T0$0$0$0
T0$0$0$1
T0$0$0$2

...(continued)

test.bat
Code:
hashcat64.exe -w 1 -m 2500 -a 0 -r rules\mine.rule C:\Pen\hs\mywifi.hccap C:\Pen\word\test.txt --stdout --gpu-temp-retain=66

Now when I run this in order to get a text file I do this

Command Prompt
Code:
test.bat > test.text

In my dictionary I have only the base word (password)
Looking at the output, it correctly has the correct output (again this is using --stdout)


Code:
Password430
Password431 <-- correct password
Password432

Taking out the --stdout (to crack the password) is always exhausted


Hashcat output (not --stdout)

Code:
Session.Name...: hashcat
Status.........: Exhausted
Rules.Type.....: File (rules\mine.rule)
Input.Mode.....: File (C:\Pen\word\test.txt)
Hash.Target....: mywifi ( <-> )
Hash.Type......: WPA/WPA2
Time.Started...: Tue Aug 23 19:10:59 2016 (34 secs)
Speed.Dev.#1...:       29 H/s (0.60ms)
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 2000/2000 (100.00%)
Rejected.......: 1000/2000 (50.00%)

Started: Tue Aug 23 19:10:59 2016

                                  
Stopped: Tue Aug 23 19:11:35 2016

Would anyone be able to help me understand what I am missing?  (Also, why is it trying 2000 guesses when it should only be 1000 guesses)  Password000 - Password999


Note that if I use the --stdout of hashcat as the new wordlist, it works.  But I thought that was the point of the rules so I wouldn't need to make a custom wordlist
#2
Here's the md5sum of it: 1090d12545fd444f0a70d617d69a4d50

Try to crack it the same way. If it works, your handshake is broken
#3
It's crucial knowing that your 4-way handshake is correct. You can use this small bash script that i did and it helps you doing this: http://pastebin.com/8ySg8ikT (requires tshark, so "sudo apt-get install tshark"). Alternatively you can do the same with a GUI in wireshark. Anyways, for doing it on the command line with that script, this is what you can do:

eapol_dump.sh yourcap.cap <WIFI_MAC_ADDRESS>
or
eapol_dump.sh yourcap.cap

It will show all eapol frames including the frame numbers #, here is an example output for a correct handshake:

Frame Tstamp Src MAC -> Dest MAC Type, Info
----------------------------------------------------------------------
<possibly many packets before>
1209 276.501341 AsustekC_xx:xx:xx -> IntelCor_yy:yy:yy EAPOL 155 Key (Message 1 of 4)
1211 276.504411 IntelCor_yy:yy:yy -> AsustekC_xx:xx:xx EAPOL 155 Key (Message 2 of 4)
1213 276.512604 AsustekC_xx:xx:xx -> IntelCor_yy:yy:yy EAPOL 213 Key (Message 3 of 4)
1215 276.514138 IntelCor_yy:yy:yy -> AsustekC_xx:xx:xx EAPOL 133 Key (Message 4 of 4)
<possibly many packets after>

When you select a handshake for later use with hashcat, you have to make sure the frame # (and/or tstamp's) are consecutive. Something like the following example won't work, that's a broken handshake:

1209 176.501341 AsustekC_xx:xx:xx -> IntelCor_yy:yy:yy EAPOL 155 Key (Message 1 of 4)
1511 296.504411 IntelCor_yy:yy:yy -> AsustekC_xx:xx:xx EAPOL 155 Key (Message 2 of 4)
6913 899.512604 AsustekC_xx:xx:xx -> IntelCor_yy:yy:yy EAPOL 213 Key (Message 3 of 4)
9115 946.514138 IntelCor_yy:yy:yy -> AsustekC_xx:xx:xx EAPOL 133 Key (Message 4 of 4)

A typical source for broken handshake is when multiple 4-ways for the same wifi/client were captured inside one .cap file. When using "aircrack-ng capfile.cap -J eapol" to extract the 4-way handshake(s), it CAN happen that it mixes messages 1,2,3,4 from different wifi connection attempts. You want to avoid this. In such a case, the resulting .hccap file will be broken because the data was mixed from different connection attempts, and, thus you will have no chances with that.

To make sure you have a correct 4-way, you can hand select the consecutive (!) frame # from eapol_dump.sh and then do something like this:

# Note: (wlan.fc.type_subtype == 0x08 exports the beacons so the SSID can be identified)
tshark -r ./bla-01.cap -Y "wlan.fc.type_subtype == 0x08 || frame.number==1209 || frame.number==1211 || frame.number==1213 || frame.number==1215" -w eapol.cap

So when you use the new "eapol.cap" that only has ONE known clean 4-way handshake , you convert it using "aircrack-ng eapol.cap -J eapol" and it will write "eapol.hccap" for hashcat.

If your .cap had no proper consecutive 4-way frames, you are unlucky. ;-)


p.s. just to have mentioned it for completeness: you don't necessarily need all four messages. If you only got messages 2,3 it also works. The key however is that they are a matching pair (i.e. they have to be consecutive)
#4
Thanks for the replies.  The hccaps work with the correct password in the wordlist.   Using the rules it does not however crack the MD5 hash either (since it works correctly with the correct password in the wordlist I assume the handshake is correct) 

Code:
hashcat64.exe -w 1 -m 0 -a 0 md5hash.txt -r rules\myrule.rule C:\Pen\word\test.txt


test.txt
Code:
password
Password

Something unexpected

Generating a rule that only does two digits
Code:
mp64.exe -o twoDigit.rule $?d$?d

which outputs
Code:
$0$0
$0$1
$0$2
...

This works every time

So in my wordlist, if I have the words
Code:
password
Password
Password1 <-- The rule will work on this one

The rule will work as expected
The rule also will work as expected with just one digit

Code:
$0
$1
...

Three, Four digits do not work

Note that I tried generating my own rules for the 4 digit and also (seperately) tried using KoreLogicRulesAppend4Num.rule



The versions of hashcat I've tried are 3.10 and 3.00

Thanks again for the responses
#5
I discovered several problems here:

1. This command makes absolutely no sense:
Code:
hashcat64.exe -w 1 -m 2500 -a 0 -r rules\mine.rule C:\Pen\hs\mywifi.hccap C:\Pen\word\test.txt --stdout --gpu-temp-retain=66

What it does is use the .hccap file and apply rules to that binary file.

To summarize, these command line arguments make no sense here:
* -m 2500: --stdout does not need any hash type since --stdout is not used to crack hashes
* C:\Pen\hs\mywifi.hccap: this normally suggests that the file is a hashcat cap file and therefore in binary format. It can be seen as a "hash file" and therefore shouldn't be there at all when you use --stdout
* --gpu-temp-retain=66: This argument will enable monitoring of your GPU and since --stdout does use your CPU only it also doesn't make sense at all and should be omitted

2. You say that you are trying to crack "Password431" (without quotes) but at the same time you say "I tried generating my own rules for the 4 digit and also (seperately) tried using KoreLogicRulesAppend4Num.rule". I see a problem here, the password that you want to crack only has 3 digits. It can't be crack with a rule file that appends 4 numbers.

3. You ask "why is it trying 2000 guesses when it should only be 1000 guesses", but later on you say that the content of your word list contains 2 words "password" and "Password" (both without quotes). Those 2 words multiplied by 1000 rules would end up with 2000 password candidates. So everything seems to be fine.

Maybe exactly this is your problem, i.e. you don't understand what the toggle rule does: it changes an uppercase letter to a lowercase one, and vice versa, i.e. if the letter is already lowercased it will be uppercased.
That means, if you only have "Password" within your word list and apply the rule "T0$4$3$1" it will end up trying the password candidate "password431" which doesn't match "Password431" (because the first character is lowercase but should be uppercase to be cracked).
I suspect that you are experiencing some problem like this.

Why do you not try a much more simple/minimal example and investigate and perform more test starting with this e.g.:

md5hash.txt:
Code:
1090d12545fd444f0a70d617d69a4d50

test.txt (make sure there are no leading or trailing white spaces such as space, tab etc):
Code:
Password

myrule.rule:
Code:
$4$3$1

and than run:
Code:
hashcat64.exe -m 0 -a 0 -r myrule.rule md5hash.txt test.txt

it should output:
Code:
1090d12545fd444f0a70d617d69a4d50:Password431
#6
Thanks for the help and sorry for the confusion and the clutter in what i posted.

I have followed philsmd's suggestion and tried to keep everything very simple

the MD5 hashes now correctly use the rules and crack them


Code:
hashcat64.exe -m 0 -a 0 -r myrule.rule md5hash.txt test.txt


This works exactly as expected.  (And using any rule works just fine for MD5)

Password431
Code:
1090d12545fd444f0a70d617d69a4d50

myrule
Code:
$4$3$1

test.txt
Code:
Password


Works great for MD5



Using WPA/WPA2 hash type still fails
Code:
hashcat64.exe -m 2500 -a 0 -r rules\myrule.rule mywifi.hccap test.txt

text.txt
Code:
Password

myrule.rule
Code:
$4$3$1

output
Code:
Session.Name...: hashcat
Status.........: Exhausted
Rules.Type.....: File (rules\myrule.rule)
Input.Mode.....: File (test.txt)
Hash.Target....: mywifi (22:02:71:28:56:a8 <-> 10:a5:d0:ec:59:91)
Hash.Type......: WPA/WPA2
Time.Started...: 0 secs
Speed.Dev.#1...:        0 H/s (0.00ms)
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 1/1 (100.00%)
Rejected.......: 1/1 (100.00%)

If I change the rules to this
Code:
$3$1
And then I change my wordlist to this
Code:
Password4


Code:
Session.Name...: hashcat
Status.........: Cracked
Rules.Type.....: File (rules\myrule.rule)
Input.Mode.....: File (test.txt)
Hash.Target....: mywifi (22:02:71:28:56:a8 <-> 10:a5:d0:ec:59:91)
Hash.Type......: WPA/WPA2
Time.Started...: 0 secs
Speed.Dev.#1...:        0 H/s (0.40ms)
Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 1/1 (100.00%)
Rejected.......: 0/1 (0.00%)

Is there anyway I can find out why hashcat has rejected the hash on the first WPA?  Using -m 0 works as expected (on an MD5 hash), using -m 2500 doesn't (on a hccap).  As atom said, I'd be inclined to believe the hccap isn't good but it works with only using a two digit rule.  I am stumped
#7
What's strange here is that you get this line:

Quote:Rejected.......: 1/1 (100.00%)

That's why it's not cracking. But that shouldn't occur if the content is "Password", because Password it's of length 8. I tried to reproduce locally but for me it did not reject. So the only explanation is that your test.txt doesn't include the word "Password".
#8
Thanks atom. I was curious about that too. I am using an GTX 960, I will try a different card just because. Thanks for the help, I'm sure I'll figure it out eventually
#9
As I said, it's about your wordlist. The GPU model doesn't matter.