hashcat Forum

Hi,
I have some more questions,

wlancap2hcx -o test.hccapx -e testlist -f testpmklist -u usernameslist -S hashinfo *.cap

after this completes through all my caps. I get the following files.
test.hccapx - the file with the handsshakes
testlist.txt - this file has a ton of lines some of them are ESSIDs but there are also unknown words not ESSIDs are those captured passwords ?
testpmklist.txt - this file has a lot of hashes but most of them are duplicates, if i remove the duplicates there are like 10-15 hashes, it is way less then the ESSIDs captured. What does this file and info mean?
hashinfo.txt - shows the hashes and ESSIDs

wlancap2hcx -O test.hccapx -> doesnt give me an output hccapx meaning there arent any handshakes without ESSIDs correct

My question is now since i have a testpmklist does that mean that I have capture 10-15 PMKs and I can use them with 12000 mode? Same with testlist?
General question is based on these outputs what do I do next what is the best I can utilize all these outputs. Will they help me crack the handshakes faster, or even better passwords catched, or all this is generally worthless and useful only for analysis.

Im sorry if my question is very stupid. I have red this entire thread a few times, but I couldnt find info on how to utilize the information regarding my situation

Hi sfw10625.

ok, let's answer your questions:
testlist.txt - this list includes all words (1 .. 32 characters) from the SSID field of the management frames
including networknames and passwords (if they are transmitted)

testpmklist.txt - this list includes all words (32 bytes) from the SSID field of the management frames
including networknames and passwords and PMKs (if they are transmitted).
We assume that a 32 byte word could be a PMK (but it could also be a 32 byte networkname - we can't differ this)
You should collect both lists (sort them uniqe) and run them at regular intervals against your caps (sometimes you have a match)

If -O test.hccapx is empty you have all neccessary ESSIDs captured.

If you like to retrieve the plainkey (PSK) from the PMK you need a SALT (normally ESSID for WPA/WPA2) and a possible password (take a look at the hash examples how to do this).

-m 12000 us useless for your purpose (only usefull on the hunt for EAP)

This ones are usefull for you:
-m 2501 network_without_essid.hccapx testpmklist
-m 2500 convertedhashes.hccapx testlist

1. Is there a way for hccapx's to be merged to one file?
I have used wlanhcx2ssid -i test.hccapx -a
it divided the test.hccapx to around 200 hccapx's sorted by mac_ap, I have removed around 50-60 hccapx from which I have cracked.
Now I want to merge the left 150 hccapxs to one big like it was before, so I can run hashcat against it.

2. I have a situation where there are 5 handshakes from one AP, 1 of the handshakes is cracked with password 12345678 for example, but the 4 rest handshakes arent. When tested 12345678 is not the real password, so it appears that the cracked handshake doesnt contain the valid password. What does this mean?

1. Yes: cat test1.hccapx test2.hccapx ..... testn.hccapx > merged.hccapx
No need to remove cracked by hand - just use hashcat -m 2500 in combination with --remove

2. The one you cracked is an unauthenticated handshake. That means the client is not authorized and tries random passwords to get access to the network. You cracked one of them (M1M2). Authorized handshakes have M1M2M3M4.
AP-less attacks retrieve only M2 from a client - we do not know the real PSK, so we can't answer with M3 and will never get M4.
But nevertheless you can crack them, but it is possble that the retrieved PSK will not give you access to the network.

Therefore hcxpcaptool has the option -O to convert all(!) tries from a client.
If you crack them, you can see what PSKs the unauthorized client tries.

You can identify the message pair (M1...M4) using:
wlanhcxinfo -i yourhashfile.hccapx -p or -P (in combination with -a , -s or -e - if you like)

Keep in mind:
AP-less attacks always retrieve a valid and crackable (but sometimes not authorized) M2!!!!

Maybe you can create blacklisting/state saving for -E option in wlandump-ng?
I mean I want it not to deassociate/deauth clients which captured before, based on saved state from previous sessions.

PS. I created android-ndk compilable version of your tools https://github.com/JuniorJPDJ/hcxtools-android
You may want to integrate some changes
It works great with NexMon firmware patch

Hi JuniorJPDJ.
Nice to see hcxtools on ANDROID. Implementing this additional blacklisting/state for wlandump-ng isn't so easy.
Best way is to use the -F option (add the client or the AP to the BPF). All entries are skipped by a kernel filter.
Behind this filter, we do
- deauthentication of all clients,
- disassociation of an associated client
- make M4 invalid
- and more....
Implementing a soft coded filter will us make extreme slow here and we are no longer able to went into an authentication sequence.

I test another solution in hcxdumptool (soft coded AP filter on raw packets). Maybe we can add a filter for the client here too.

If hcxdumptool and hcxpcaptool work as expected, they will replace wlandump-ng and wlancap2hcx. I get rid of libpcap.
Both tools are much more effective than the older ones.

Did also many improvements on the 3. generation tools:

the conversion tool:
$ hcxpcaptool -h
hcxpcaptool 4.1.0 (C) 2018 ZeroBeat
usage:
hcxpcaptool <options>
hcxpcaptool <options> [input.pcap] [input.pcap] ...
hcxpcaptool <options> *.cap
hcxpcaptool <options> *.*

options:
-o <file> : output hccapx file (hashcat -m 2500/2501)
-O <file> : output raw hccapx file (hashcat -m 2500/2501)
-x <file> : output hccap file (hashcat -m 2500)
-X <file> : output raw hccap file (hashcat -m 2500)
-j <file> : output john WPAPSK-PMK file (john wpapsk-opencl)
-J <file> : output raw john WPAPSK-PMK file (john wpapsk-opencl)
-E <file> : output wordlist (autohex enabled) to use as input wordlist for cracker
-I <file> : output unsorted identity list
-U <file> : output unsorted username list
-P <file> : output possible WPA/WPA2 plainmasterkey list
-T <file> : output management traffic information list
         : european date   timestamp   mac_sta   mac_ap   essid
-H <file> : output dump raw packets in hex
-V        : verbose (but slow) status output
-h        : show this help
-v        : show version

--time-error-corrections=<digit>  : maximum allowed time gap (default: 600s)
--nonce-error-corrections=<digit> : maximum allowed nonce gap (default: 8)
                                 : should be the same value as in hashcat
--netntlm-out=<file>              : output netNTLMv1 file (hashcat -m 5500 / john netntlm)
--md5-out=<file>                  : output MD5 challenge file (hashcat -m 4800)
--md5-john-out=<file>             : output MD5 challenge file (john chap)


The raw option es very interesting:
If a user types a half of his PSK into his phone, this data will be stored and the client tries to connect "his" AP using only a part of a PSK.  hcxdumptool will answer the conncet attempt and store the M2 (from an uncomplete PSK). If you are able to retrieve this part of the PSK you can run a mask or rule to get the full PSK from an authenticated  M2M3M4. This attack requires that you convert all(!) M1M2 combinations!

If a user typed his PSK instead of his ESSID and his ESSID instead of his PSK you can use the raw option too (in combination with the -E -U -I option of hcxpcaptool) to retrieve the PSK.

With the -T option you are able to track clients (by timestamp) - we use tv_sec so that you are able to correlate with a GPS track.


The upcomming analysis tool:
$ hcxhashcattool -h
hcxhashcattool 4.1.0 (C) 2018 ZeroBeat
usage:
hcxhashcattool <options>

options:
-p <file> : input hashcat -m 2500 potfile
-P <file> : output PMK file (PMK : ESSID : PSK)
-h        : show this help
-v        : show version

hcxhashcattool calculates a PMK file from a 2500 potfile. Now you are able to check networks that occur more often much faster using hashmode 2501. I will add all wlanhcx2xxxx functions to this tool. (all john functions will move to hcxjohntool). Also you can share this PMK list, so that your share partners ‎do not have to recalculate the PMKs.
We only use CPU (multithread) because there are too few PMKs to calculate.


And the attack/dump tool:
$ hcxdumptool -h
hcxdumptool 4.1.0 (C) 2018 ZeroBeat
usage:
hcxdumptool <options>

options:
-i <interface> : interface
-o <dump file> : output file in pcapformat including radiotap header (LINKTYPE_IEEE802_11_RADIOTAP)
-c <digit>     : set channel (default = channel 1)
-C <digit>     : comma separated scanlist (1,3,5,7...)
-t <seconds>   : stay time on channel before hopping to the next channel
              : default = 5 seconds
-B <file>      : blacklist (do not deauthenticate clients from this hosts - format: xxxxxxxxxxxx)
-I             : show suitable wlan interfaces and quit
-T <maxerrors> : terminate after <xx> maximal errors
              : default: 1000000
-D             : enable to transmit deauthentication- and disassociation-frames
-l             : enable capture of IPv4/IPv6 packets
-P             : enable poweroff
-s             : enable status messages
-h             : show this help
-v             : show version

Blacklist option is included here.

Using this three tools, you can build up an environment for WPA EAPOL and EAP).
Only a few files/lists needed:
- PSK list (for example wpa-sec cracked.txt)
- 2500 potfile
- 2501 potfile
- PMK list (from hcxhashcattool)
and some simple bash scripts to do the correlation between this files.
This environment is very powefull an will bring you many PSKs:
https://forum.hashkiller.co.uk/topic-vie...323#159323
Amazing, how many PSKs retrieved.....
You can use the attachement to test your environment....

Oh, you are right.
Think about auto generating BFP of already captured nets as additional output of wlandump - it would be nice idea.
If it will not be added to your code, I'll probably write python or bash script wrapping it and auto-skipping "done" networks.

Also I think, you should consider adding something similar to this "-E <digit>: stop deauthentications and disassociations if xx complete handshakes received", but less strict, allowing to stop it when got only part of handshake.
It's problematic when client has not enough power to reach our device, but enough to reach AP and it can hear us.
My log is flooded with at least one device like this and probably I'm a bit DOSing them :/

Well, you're right too. In this case, wlandump-ng and hcxdumptool will work like an intelligent WiFi jammer!
Normally APs and clients use a retry counter (we do the same). Default value is 6 retries, then the AP or the client should stop. Some of them have a very high retry counter value - so your log is flooded. I saw some of them which have an unlimited(!) value.
One single packet from us is enough to to start this process. Right now, an attack stops if we received the matching M2 to our M1. That is more than enough for us, because we get a valid and crackable combination M1M2.

By the way: This is one of the reasons why I didn't recommend a high power WiFi dongle like the ALFAs. It is much, much better to use a common low power device and(!) a high gain external antenna like a panel (>12 dBi) or an omni (> 7dBi). This make shure, that you receive all packets within your transmit range.

Please tell me more about the contence of your flooded log:
Is it flooded with our M1 or the M2 from the client? In both cases we do not DOS.
If the log is flooded with M3 or M4 we're working like an intelligent jammer! In that case the AP is under heavy DOS from his own clients.
Take also a look at the cap file:
If the clients (or the APs) retry bit (in frame control field of mac frame) is set, we can't prevent that behavior - it's an issue of the client (or the AP), even if we stop the attack!
In that case the attacker status display will inform you about this behavior:  (retransmitted)

The tools are designed to be used ‎if you are highly mobile (that's a reason why I like your Android solution) to capture as much M2 as possible. All important packets (we need them to do forensics and client tracking - I do not mean BEACONs, as the information contained therein is much too general) are saved to the capture file. If you take a look into the source from hcxpcaptool you'll see that ‎the analyzed data went in there (new frame header). Same with the PSKs (cracked.txt from wpa-sec). We we strictly follow the "intelligence cycle".  Well, your post (feedpack/feature request) is also a part of this cycle. I'll try to find a solution - but it's still an issue of the client / AP (retry counter value).

For example:
Use a mobile device (raspberry)  and sit down on a main street near of a traffic light.
In the phase of red light you will receive many M2s from the clients in the stopped cars (incl. AndroidCar WiFi systems).
Same on a bus stop or a railway station.
A crowded downtown or a department store will bring you also many M2s.
Collect this M2s and(!) the output of the  -e -u (wlancap2hcx) or -E -I -U options (hcxpcaptool).
We found many PSKs using a rule on this collected data.

It's also important to analyze the contence of the cap file to find more interesting packets (or packets out of protocol).

If you use hcxtools stationary, you must configure the BPF (-F wlandump-ng) or the blacklist (-B hcxpcaptool)

I'm trying to use it with Samsung Galaxy S4 (without any external wifi or antenna) as a stationary device and don't want to kill internet access to any of my neighbors :/

I need to create BPF for wlandump-ng, but what with keeping disconecting everyone who's I'm not abled to hear while reconnecting? I've got part of handshake and for me it's enough, why still keeping this client disconnecting?

Also is there possibility to channel hop behind all supported (by interface) bands? I only can it make to hop in one band at once (of 3 supported)

Also I've just spotted problem with hopping:
It's not changing channel if it is 52 or more