hcxdumptool v 6.3.0 - new style

[ukscone]

just upgraded from a version from last year and whilst the new version works I do miss the old style --enable_status=XXX stuff as it was much easier to keep an eye on while doing other stuff

[ZerBea]

The old status function is very CPU cycle intensive. It show status when an event occurs.
The new version collect events and show them timer controlled. That is much (much) faster.
The entire engine is now based on epoll() and timerfd() instead of pselect() and counters, which is ultra fast.
If you take a look at Makefile, you'll notice that the entire status display and the GPS handling can be commented out, e.g.:
#DEFS += -DSTATUSOUT -DNMEAOUT
This is for headless operation and speed up hcxdumptool again a lot.

Compared to the old WIRELESS EXTENSION version, the NL80211 version is trimmed for effectiveness and speed.
Everything that cost CPU cycles is removed. To increase range, bandwidth is reduced to 20MHz and bit rate is reduced to 1MB/s 2.4GHz or 6MB/s above 5GHz.

But I leave this request open.
If the entire transformation from WIRELESS EXTENSIONS to NL80211 is finished, I try to add a real time waterfall status display (show EAPOL only) that can be selected by option.

Active RCASCAN is still missing, too as well as requesting EAP-IDs. I have to add this before the next release.

BTW:
At anytime (even though if hcxdumptool is still running), you can do

$ hcxpcapngtool -o /tmp/current.22000 dump.pcapng
$ hcxhashtool -i /tmp/current.22000 --info=stdout
$ rm /tmp/current.22000

To simplify it, you can add this commands to a bash script, e.g.: showeapol

#!/bin/bash

hcxpcapngtool -o /tmp/current.22000 dump.pcapng
hcxhashtool -i /tmp/current.22000 --info=stdout
rm /tmp/current.22000

[ZerBea]

By last commit I added a new option:

--rds=<digit>                  : sort real time display
                                  default: sort by time (last seen on top)
                                  1 = sort by status (last PMKID/EAPOL on top)

on rds=1 last last last AP of which a PMKID/EAPOL M1M2M3 was received is on top

[ukscone]

thanks and now you've explained why it makes sense

[ZerBea]

Compared to the old WIRELESS EXTENSION version, NL80211 version is a thousand times more effective.

[Cyolos]

where can I contact you ZerBea?

[ZerBea]

You can get my email address via git API:
https://api.github.com/users/ZerBea/events/public

[Cyolos]

wow, I didnt know that API, thanks!

[YuryKomar]

can someone share an Android version of this tool for capturing PMKID to file

[ZerBea]

hcxdumptool should run fine on Android:
#313 (comment)

Unfortunately I don't have an Android environment to compile it. Maybe some Android users can help.

[YuryKomar]

hcxdumptool should run fine on Android: #313 (comment)

Unfortunately I don't have an Android environment to compile it. maybe some Android users can help.

Ok. thanks.

[DirtyOptics]

With the introduction of 6.3.0 I can't seem to get it to run in the background with '&' at the end of the command line. Or maybe it is running, but It does disappear from htop. Thus I assume its not running.... But I could be wrong.

[ZerBea]

I'll check it. Could be related to the new real time display.
For headless operation this can be completely disabled by uncomment the feature in Makefile:
move:
DEFS += -DSTATUSOUT -DNMEAOUT
to
DEFS += -DNMEAOUT

[ZerBea]

Ok, tested it.
Terminal 1:
$ sudo hcxdumptool -i wlp5s0f3u3 &

Terminal 2:

$ ps -All | grep hcxdumptool
4 S     0    4262    4261  0  80   0 -   769 -      pts/1    00:00:00 hcxdumptool

Doing exactly what expected.

Terminating in terminal 2:

$ sudo killall hcxdumptool
$ ps -All | grep hcxdumptool
$

Terminal 1 ctrl+c:

exit on sigterm

bye-bye
^C
[1]+  Fertig                  sudo hcxdumptool -i wlp5s0f3u3

And now the funny part:
top doesn't show hcxdumptool task!

According to this:
https://superuser.com/questions/377341/linux-top-not-showing-all-processes
top only showing the most cpu heavy tasks.
To run on small machines(e.g. first generation of RPI), hcxdumptool is highly optimized. That could be the reason why top ignore it.

[DirtyOptics]

Awwwww I have a lot to learn....yea what confused me is the fact you can see the process in top until you close the session..... I'll give it another few runs. I just checked out the timestamps in the .pcapng and it does seem to still be running. I guess I was just after something visual to ensure it was up.

[DirtyOptics]

Wait wait....im still not having much luck here. Maybe I am not understanding it properly.

It is my understanding that I should be able to close 'Terminal 1' and the process will continue to run in the background. I am still not seeing that behaviour. As soon as I close terminal 1 (Simulating putting my laptop away) the process seems to stop. (I confirm this by running the 'ps -All | grep hcxdumptool' command again which shows no process running.

Apologies if this does not make sense. Love your work by the way! its incredible!

[ZerBea]

Is the target MAC in addr1, addr2 and addr3 of the filter?
$ tcpdump -i INTERFACE wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66 -ddd > attack112233445566_pr.bpf
addr1 = to address
addr2 = from address
addr3 = BSSID

BTW:
I sent you a PM.

[OscarAkaElvis]

The tcpdump command I'm launching was this:

tcpdump -i "${interface}" wlan addr1 "${bssid}" -ddd > "${tmpdir}pmkid.bpf"

That part I think is ok because the file is well generated and contains the right content.

after some testing trial and error... I decided to generate traffic to the AP just authenticating a real user to the PMKID vulnerable AP and something was shown, but I think that doesn't mean a PMKID was captured yet

I need to do more tests because my first thoughts about this is that it is not very reliable. At least for the purpose in airgeddon which is to get just a single pmkid from a single target. It is supposed that airgeddon is a pentest tool to be launched over a specific target. That is one of the main reasons to not having "massive or random" attacks to surrounding APs and it's focused on a single target. The reason is that I want to be used mainly in legal and tailored wifi penetration tests. Let's see if this version finally is able to do what airgeddon needs. Need to do more testing to confirm but for now, I had bad results.

I have no more time today to keep testing. I'll keep trying other day.

[ZerBea]

The BPF is merciless.
wlan addr1 means that all frames are filtered out that are not addressed to the target MAC.

This frames are filtered out:
BEACON (target must be in wlan addr2)
PROBERESPONSE (target must be in wlan addr2)
AUTHENTICATION RESPONSE (target must be in wlan addr2)
ASSOCIATION RESPONSE (target must be in wlan addr2)
EAPOL M1, that contain the PMKID (target must be in wlan addr2)

Explanation is here:
https://networkengineering.stackexchange.com/questions/25100/four-layer-2-addresses-in-802-11-frame-header

[ZerBea]

An example to reproduce wrong BPF techniques.

To reproduce get the PMKID example hash from:
https://hashcat.net/wiki/doku.php?id=example_hashes

store it to hc22000 file:
$ echo "WPA*01*4d4fe7aac3a2cecab195321ceb99a7d0*fc690c158264*f4747f87f9f4*686173686361742d6573736964***" > example.hc22000

hc22000 line in detail:

$ hcxhashtool --info=stdout -i example.hc22000
SSID.......: hashcat-essid
MAC_AP.....: fc690c158264 (Unknown)
MAC_CLIENT.: f4747f87f9f4 (Unknown)
PMKID......: 4d4fe7aac3a2cecab195321ceb99a7d0
HASHLINE...: WPA*01*4d4fe7aac3a2cecab195321ceb99a7d0*fc690c158264*f4747f87f9f4*686173686361742d6573736964***

or

$ whoismac -x 686173686361742d6573736964
hashcat-essid

connvert it to cap file:
$ hcxhash2cap --pmkid-eapol=example.hc22000

$ ls
f4747f87f9f4.cap

For this example:

tshark filter syntax	tcpdump filter syntax
wlan.ra			wlan addr1
wlan.ta			wlan addr2
wlan.bssid		wlan.addr3

unfiltere output:

$ tshark -r f4747f87f9f4.cap
    1 06:16:33,207219 fc:69:0c:15:82:64 → ff:ff:ff:ff:ff:ff 802.11 111 Beacon frame, SN=996, FN=0, Flags=........, BI=100, SSID="hashcat-essid" 
    2 06:16:33,207220 fc:69:0c:15:82:64 → f4:74:7f:87:f9:f4 EAPOL 155 Key (Message 1 of 4)

Correct filtering (by e.g. wlan.bssid):

$ tshark -r f4747f87f9f4.cap -Y "wlan.bssid==fc:69:0c:15:82:64"
    1 06:16:33,207219 fc:69:0c:15:82:64 → ff:ff:ff:ff:ff:ff 802.11 111 Beacon frame, SN=996, FN=0, Flags=........, BI=100, SSID="hashcat-essid" 
    2 06:16:33,207220 fc:69:0c:15:82:64 → f4:74:7f:87:f9:f4 EAPOL 155 Key (Message 1 of 4)

Now the impact of wrong filtering - we set the BSSID as wlan.ra (tcpdump syntax = wlan addr1):

$ tshark -r f4747f87f9f4.cap -Y "wlan.ra==fc:69:0c:15:82:64"
$

The impact is huge. All wanted frames are filtered out!
This is what happened to you.

Why do I prefer the BPF? The user can decide which tool he would like to use and the way how he will use it.

Different filtering, but same result. We filter by transmitter address instead of BSSID:

$ tshark -r f4747f87f9f4.cap -Y "wlan.ta==fc:69:0c:15:82:64"
    1 06:16:33,207219 fc:69:0c:15:82:64 → ff:ff:ff:ff:ff:ff 802.11 111 Beacon frame, SN=996, FN=0, Flags=........, BI=100, SSID="hashcat-essid" 
    2 06:16:33,207220 fc:69:0c:15:82:64 → f4:74:7f:87:f9:f4 EAPOL 155 Key (Message 1 of 4) 

Now it's up to you to turn your good script into a fantastic script.

[OscarAkaElvis]

So you think I'm not getting the PMKID because the filter is not well prepared? ok, maybe... now let's create the right bpf file using tcpdump. Data and stuff the user have in airgeddon on PMKID menu:

BSSID of the target
channel of the target
ESSID of the target
A card set into monitor mode used previously to get the target's data

Let's suppose they are:
Card: wlan0mon
BSSID: 11:22:33:44:55:66
Channel: 6
ESSID: demoPMKID

How could be the tcpdump right command to be used later on hcxdumptool to get a PMKID?

Right now I have this:
tcpdump -i wlan0mon wlan addr1 11:22:33:44:55:66 -ddd > "/tmp/pmkid.bpf"

And then my hcxdumptool looks like this:
hcxdumptool -i wlan0mon -c 6a -F --rds=1 --bpf=/tmp/pmkid.bpf -w /tmp/pmkid.pcapng

Can you help me to generate a better or more precise bpf file to be able to get a PMKID of a target?

I'm guessing based on your comments that a better bpf file could be this way:
tcpdump -i wlan0mon wlan addr1 11:22:33:44:55:66 wlan addr2 11:22:33:44:55:66 wlan addr3 11:22:33:44:55:66 -ddd > "/tmp/pmkid.bpf

Configuring it and testing it in some minutes...

EDIT

Tested but it seems I'm not doing well something...

[OscarAkaElvis]

Ok, I was missing the "or" ... I added them and it worked!!!!

Finally the tcpdump filter creation command was:
tcpdump -i wlan0mon wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66 -ddd > "/tmp/pmkid.bpf

And my tshark transformation over the right file worked flawlessy. So I think I have all I need. Thanks for the help and the patience 😄

[ZerBea]

You're welcome. Would be nice if all this is helpful to improve airgeddon.

Correct, this is the "all-in-one" solution that covers the target MAC in addr1 (ra) addrs 2 (ta) and addr 3 (bssid):
$ sudo tcpdump -i wlan0mon wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66 -ddd > "/tmp/pmkid.bpf
Everything else is filtered out.

[OscarAkaElvis]

great, it works like a charm now. And I must admit it is faster now.

I needed to perform so many changes, but it was worth in the end I think, you were right. The hardest part was to prepare the "structure" to keep it robust validating all and adding the new dependency to be checked only if version >=6.3.0 , etc etc... but now it is done, commit here: v1s1t0r1sh3r3/airgeddon@ef71d96

Regards.

[ZerBea]

I fully agree.

BTW:
You can play with BPF, e.g. remove unwanted ctrl frames:
$ sudo tcpdump -i wlp5s0f3u2 "(wlan addr3 11:22:33:44:55:66) and (not type ctl subtype ack and not type ctl subtype rts and not type ctl subtype cts)" -ddd > /tmp/pmkid.bpf
Cheers
Mike

[OscarAkaElvis]

not sure if it worths to tune in more. Do you think could be interesting? as you know, we want only to get the needed stuff to get a valid PMKID and then it is supposed that is going to be cracked offline. That changes that you are suggesting could improve this in any way?

[ZerBea]

Le't say your hunting for three PMKIDs of three different NETWORKs:

00:00:00:00:00:01
00:00:00:00:00:02
00:00:00:00:00:03

create on filter for the three NETWORKs:
$ sudo tcpdump -i INTERFACE wlan addr3 00:00:00:00:00:01 or wlan addr3 00:00:00:00:00:02 or wlan addr3 00:00:00:00:00:03 -ddd > /tmp/pmkid.bpf

and let hcxdumptool hunt for them:
$ sudo hcxdumptool -F --bpf=/tmp/pmkid.bpf

[OscarAkaElvis]

Ok but as I said, in airgeddon everything is done intentionally only for a concrete target. It is designed to perform professional wifi audits.

I removed the wlan addr1 and the wlan addr2 leaving only wlan addr3 in the filter whichs seems to be the only needed to get the PMKID.

[ZerBea]

Exactly that is the purpose of the BPF.
Create your filter code and tell hcxdumptool to attach it. From now on your filter is running inside the kernel space.
There is no longer need to walk through endless filter lists or to change hcxdumptool base code.

[ZerBea]

BTW:
I noticed that you run wpaclean inside your script.

You should know that it destroy timestamps and remove the M3 and M4 eapol frames (AUTHORIZATION) and leave M1 and M2 only (CHALLENGE).

Example and wpaclean are taken from latest git head aircrack-ng:

$ tshark -r test/wpa2.eapol.cap
    1 23:12:30,635085 00:14:6c:7e:40:80 → ff:ff:ff:ff:ff:ff 802.11 96 Beacon frame, SN=113, FN=0, Flags=........, BI=250, SSID="Harkonen" 
    2 23:15:39,628922 00:14:6c:7e:40:80 → 00:13:46:fe:32:0c EAPOL 131 Key (Message 1 of 4) 
    3 23:15:40,077500 00:13:46:fe:32:0c → 00:14:6c:7e:40:80 EAPOL 153 Key (Message 2 of 4) 
    4 23:15:40,081089 00:14:6c:7e:40:80 → 00:13:46:fe:32:0c EAPOL 187 Key (Message 3 of 4) 
    5 23:15:40,092350 00:13:46:fe:32:0c → 00:14:6c:7e:40:80 EAPOL 131 Key (Message 4 of 4)

we do a clean:
$ wpaclean test.cap test/wpa2.eapol.cap

And this happens:

$ tshark -r test.cap
    1 23:15:40,077500 00:14:6c:7e:40:80 → ff:ff:ff:ff:ff:ff 802.11 96 Beacon frame, SN=113, FN=0, Flags=........, BI=250, SSID="Harkonen" 
    2 23:15:39,628922 00:14:6c:7e:40:80 → 00:13:46:fe:32:0c EAPOL 131 Key (Message 1 of 4) 
    3 23:15:40,077500 00:13:46:fe:32:0c → 00:14:6c:7e:40:80 EAPOL 153 Key (Message 2 of 4)

M3 and M4 are removed. After the cleaning procedure the user doesn't know if it is a challenge or if the CLIENT is authorized to join the NETWORK.
TIMESTAMP of packet 1 is exactly the same as TIMESTAMP of PACKET 3. That is impossible.

[OscarAkaElvis]

yeah, don't worry. We know it's not very reliable and sometimes may cause problems in the .cap file. It is warned always to the user before using it