hashcat Forum

Thank you ZerBea for the great work and discussion. Give me a week to digest and I will be back with more. I am really trying to get a clear mental picture of my daily captures and how to organize my data.

There are only a few things to consider:
KISS (Keep it Simple, Stupid)
good TTP (Tactics, Techniques and Procedures)
follow the traditional Intelligence Cycle

If your hashcat.2500.pot file contains not so much data to analyze you can build a bigger one based on wpa-sec cracked data:

Download the python client from here:
https://wpa-sec.stanev.org/hc/help_crack.py
It's open source (https://github.com/RealEnder/dwpa), so no virus inside.

run the client with this options (see ./help_crack.py --help for more options):
./help_crack.py --potfile wpasec.2500.pot
Now you will get a copy of all cracked networks (from your client) - incl. PSK! That is usefull for your analysis of keyspace
Upload your caps (wlancap2wpasec or via web interface) - so they will go threw this wordlists, too

finally got hcxdumptool running after many issues.
what's the difference between -O & -o for hcxpcaptool ?, which would be better for use with hashcat for below cap ?

hcxpcaptool & wlanhcxinfo details below
==================================
file type..............: pcap 2.4
network type...........: DLT_IEEE802_11_RADIO (127)
endianess..............: little endian
read errors............: flawless
packets inside.........: 2090
skipped packets........: 0
packets with FCS.......: 423
beacons................: 5
probe requests.........: 10
probe responses........: 2
association requests...: 8
association responses..: 77
reassociation requests.: 1
reassociation responses: 11
EAPOL packets..........: 1966
raw handshakes.........: 11 (ap-less: 5)
best handshakes........: 6 (ap-less: 5)
====================================
total hashes read from file.......: 11
handshakes from clients...........: 5
little endian router detected.....: 3
big endian router detected........: 0
zeroed ESSID......................: 0
802.1x Version 2001...............: 11
802.1x Version 2004...............: 0
WPA1 RC4 Cipher, HMAC-MD5.........: 0
WPA2 AES Cipher, HMAC-SHA1........: 11
WPA2 AES Cipher, AES-128-CMAC.....: 0
group key flag set................: 0
message pair M12E2................: 10 (0 not replaycount checked)
message pair M14E4................: 0 (0 not replaycount checked)
message pair M32E2................: 1 (0 not replaycount checked)
message pair M32E3................: 0 (0 not replaycount checked)
message pair M34E3................: 0 (0 not replaycount checked)
message pair M34E4................: 0 (0 not replaycount checked)
nonce-error-corrections is working on that file
=======================================

Hi wakawaka.
Nice, that the tools are working for you, now.
The difference between hcxpcaptool -o and -O is:
-o will convert only one handshake each mac_ap, mac_sta, ESSID combination. The handshake with the lowest timegap between M1 and M2, M2 and M3, M3 and M4 (if M4 isn't zeroed) or M1 and M4 (if M4 isn't zeroed) is used.
-O will convert all combinations (usefull if a client did a typo, like half of the PSK, for example)

Here is an explanation of the fields of your status output:
you captured a total of 1966 EAPOL frames, but only 11 handshakes are valid (matching replycount, matching timegap between the frames). 1966 frames means, you are not really in range of the AP and/or clients or your tx power is to high. Long range adapters like the ALFAs cause something like that. The have one or two watts and an AP or a client have only 10...100 milliwatts.

5 frames are captured from a client (connection hcxdumptool <-> client). AP-less attack
we have only the combination M1/M2, because we can't calculate a valid M3
you can strip them for a further going analysis and/or a hashcat run using
wlanhcx2ssid -i yourtest.hccapx -w apless.hccapx
wlanhcx2ssid -i apless.hccapx -N hashtotest.hccapx
hashcat -m 2500 --nonce-error-corrections=0 hashtotest.hccapx yourwordlist

1 frame is caputured from an AP (you attacked an established connection between an AP and a client)
you can strip this handshakes using:
wlanhcx2ssid -i yourtest.hccapx -2 established.hccapx
hashcat -m 2500 hashtotest.hccapx yourwordlist
hcxpcaptool detected that nonce-error-correction is possible and you should use at least the default value (8) on this hanshake(s), because we can't be shure whether there is a packetloss or not.

The question which option to use (hcxpcaptool -o -O) isn't easy to answer and depends on what result you expect.
As an analyst and in that case, I prefer -O to determine wheter the client tries several PSKs to connect to an AP or not.

I suggest to use 2 databases: one (-o) for the best handshakes and one (-O) for all handshakes. All your handshakes should went inside this 2 databeses.
Then strip, what ever you like to test from this databases using wlanhcx2ssid and run hashcat on this:
capture all you can get using hcxdumptool
convert all you captured into the 2 databases using hcxpcaptool
analyze the content using wlanhcxinfo (various options: -a, -s, -e,...)
strip what you like to test using wlanhcx2ssid
and run hashcat on this hashes

wlanhcxinfo and wlanhcx2ssid should be your "main" tools.

Hello ZerBea!
Hope you are doing great

Q1 What does nonce error correction mean? How is it introduced into a capture? Does converting a cap file to hccapx file causes it. What does hasncat do when we tell it to do a nonceerrorcorrection? Can John handle nonce errors? Googled the term and could not find much material.
Q2 hcxdump and wlandump show different amount of status messages on my system (The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali)). hcxdump only outputs info when it captures a handshake while wlandump outputs screen fulls of outputs like beacons, probe requests, associations etc. Why is one tool so quiet while other so verbose? Is it by design or is it related to my system being more favorable towards one?

Hi Zerbea,

thank you for your detailed explanation. and yes was using an high power rtl8187l adaptor for that cap.
will try out more options in the hcxtools suite.

cheers,

Hi RashidMalik.

Q1:
I analyzed several handshakes and found out that the anonce (nonce of an AP) isn't random.
If we captured more than on M1 and/or M3 we are able to calculate a complete anonce for that case, if we have a packetloss (wireshark, tcpdump, aircrack-ng, kismet didn't capture that M1 and/or M3 we need to calculate a valid hash). The value of --nonce-error-corrections determines how many packetlosses we are able to correct (depending on the type of the router: big endian or lower endian router type). Default value for hashcat and hcxtools is 8 * (+/-/LE/BE).

Does converting a cap file to hccapx file causes it.
Not, if you use hcxtools.

What does hashcat do when we tell it to do a nonceerrorcorrection?
it multipies the hashes by nonce-error-corrections  8 *  (+/-/LE/BE). In other words: the compare kernel has more to do and speed will drop a little bit.
hcxpcaptool AP-less handshakes doesn't requiere nonce-error-corrections. You can set this value to 0
john requiere an external tool to handle this (Magnum called it nonce fuzzing):
https://github.com/magnumripper/JohnTheR...ssues/2773
https://github.com/magnumripper/JohnTheRipper/pull/3187

Q2 is simple to answer:
hcxdumptool is designed for primary use on a raspberry (display less and speed optimzed for smaller CPUs).
That includes also a limited status output. I count in cpu cycles to perform some attacks, so I haven't the time
for a beautiful status output and some nice (but not for an attack necessary) additional functions.

Let me also explain "AP-less" in that content:

AP-less means that a client responds to an anonce from us. That will happen if a client tries to connect to us.
Either
if there is no AP in range of the client and he choose us (case 1)
or
if we are in range of AP and client and the client tries to conncet to the AP for the for time and chooses us first (case 2)
(a reason, why we must be fast - faster than an AP)
or
if we disconnect an established connection between an AP and his client and the client choose us for the next connect (case3) attempt

In both cases is the result a M2 from a client which is 100% valid and crackable wit nonce-error-corrections=0. It may be an unauthorized M2
But in case 2 and case 3 an AP-less handshake by hcxdumptool is 100% valid, 100% authorized and 100% crackable!

A wireshark dump will show this:
authentication (from client)
authentication (from AP)
association (case 2) or reassociation (case 3) request (from client)
association (case 2) or reassociation (case 3) response (from AP)
M1 from hcxdumptool
M1 from AP
M2 from client in response to M1 from hcxdumptool
M2 from client in response to M1 from AP
M3 from AP
M4 from client

or, if we are too slow (because of beautiful status output):
M1 from AP
M1 from hcxdumptool (we must send M1 before client ack M1 from AP)
M2 from client in response to M1 from AP
M2 from client in response to M1 from hcxdumptool
M3 from AP
M4 from client

Oh, I'm so stupid, please forgive me. I didn't explain why I'm doing this:

Well, usually APs are in the middle of a flat, an apartment or a house.
Let's say we have a hot summer day and our target client is in the garden or on the balcony. You receive the client, but you do not receive the AP. You capture the taffic an wireshark will show you this:
M1 from hcxdumptool
M2 from client in response to M1 from hcxdumptool
M2 from client in response to M1 from AP
M4 from client
or
M1 from hcxdumptool
M2 from client in response to M1 from AP
M2 from client in response to M1 from hcxdumptool
M4 from client

In that case you captured a 100%valid, 100% authorized and 100% crackable handshake (without receiving the legal AP).