![]() |
hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Misc (https://hashcat.net/forum/forum-15.html) +--- Forum: User Contributions (https://hashcat.net/forum/forum-25.html) +--- Thread: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats (/thread-6661.html) |
RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 02-23-2020 Hi ciccio17. Thanks, I'm fine. You too? This is my test environment: Arch Linux x86 (archlinux-2020.02.01-x86_64) hcxdumptool, hcxtools, hashcat, JtR $ uname -r 5.5.5-arch1-1 Arch Linux Arm (ArchLinuxARM-rpi-latest) hcxdumptool, hcxtools $ uname -r 4.19.102-1-ARCH Regarding Kernel 5.5.5 many issues are still unsolved: https://bugzilla.kernel.org/show_bug.cgi?id=202541 -> mostly USB3.0 related, mostly on AMD RYZEN systems as well as most of the ath9k issues https://bugzilla.kernel.org/buglist.cgi?quicksearch=ath9 https://bugs.openwrt.org/index.php?do=details&task_id=2537&string=ath9k&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= As of today, I only use/test devices running mt76 and rt2800usb driver. Both chipsets running fine and out of the box on Raspberry PI A, B, A+, B+, Zero and x86 systems. The maintainers of this drivers are doing an excellent good job! I won't do any more tests and I will not carry out any further optimizations (hcxdumptool) on other drivers unless they are fixed. That includes the Broadcom chipset (Raspberry's onboard SOC) because the native driver doesn't support monitor mode and packet injection. ath9k_htc log (as of today): Code: $ hcxdumptool -v I used your last git on kernel 4.19 and is totally a different tool for me -> hcxdumptool refactoring is in progress. Next version will get a different look. I noticed that the RPI drops packets when the system is busy (real time display). So we have to reduce this output to a minimum. Latest git head of hashcat and hcxdumptool contain a lot of new features. It is a good idea to test them. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - MrShannon - 03-15-2020 Can someone help me find the field order in the .22000 hashlist format? I'm having a heck of a time tracking down the format description, and after digging through the .c code in hcxtools I am just not convinced that I understand what I am looking at :/ I am trying to extract the MAC Address of Clients and APs that were captured to build macfilters for hcxdumptool. Before the .22000 format was introduced, I was using hcxpcaptool to convert .pcapng's to the .hccapx and older .16800 hashlist formats, then processing those with wlanhcxinfo or awk to get the mac addresses. Of course, now that this tool and these formats are deprecated, I want to move to 22000, but here's how I was doing it: Code: # these tools/formats are now deprecated! Since the .22000 format combines both PMKID and EAPOL captures, I was hoping I could sift the MAC addresses out of the file with tools like awk/grep/sed, but since I don't know the format I am really just making guesses. Can someone confirm my suspicions below? Code: # Convert the .pcapng to the new .22000 format (PMKID+EAPOL) Did a quick compare the contents of the GOTMACSCLI.txt and GOTMACSAPS.txt lists by grep'ing for a few examples
Code: # Get Client MAC addresses to filter and Count how many we've got This looks pretty good, but there is a discrepancy in the number of Access Point MAC addresses. I've found other differences in the count of hashes when comparing .hccapx with .22000 before, so I am not totally surprised. That said, this new format seems to have fewer results that the older format. Maybe that's ok... Am I doing this right? RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 03-15-2020 The format of a 22000 hashline is: Code: SIGNATURE*TYPE*PMKID/MIC*MACAP*MACSTA*ESSID*ANONCE*EAPOL*MESSAGEPAIR Your bash commands to count CLIENT and AP MACs are ok. You can use bash commands as well as hcxhashtool to work on 22000 lines. And you can run hcxhashtool to verify the results of your script. The discrepancy between hccapx converted with hcxpcaptool and 22000 converted with hcxpcapngtool is ok, too, because hcxpcangtool is running a better dupe detection. If you need all possible EAPOL message pair combinations you can use --all to retrieve them. Also you should know, that hcxdumptool use randomized MACs as well as real MACs from received CLIENTs and received APs. It is a pretty good stealth feature to prevent counter measures against hcxdumptool, but will falsify the result of your count. Also keep in mind that filtering of CLIENTs is mostly useless if the CLIENT use randomized MACs. Additional hcxdumptool v6.0.2 has an option to run BPF code, which is much faster then the old filter modes. BTW: hcxdumptool v6.0.2 add ROGUE to received PMKIDs and/or M1M2 message pairs if they are the result of a "CLIENT-LESS" or AP-LESS attack vector. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - MrShannon - 03-17-2020 Thank you for confirming the format / field order in 22000! That makes me feel a lot better about the method I am using and confidence to remove the scripting I was doing with the older tools and formats. (03-15-2020, 11:51 PM)ZerBea Wrote: Also you should know, that hcxdumptool use randomized MACs as well as real MACs from received CLIENTs and received APs. It is a pretty good stealth feature to prevent counter measures against hcxdumptool, but will falsify the result of your count. Also keep in mind that filtering of CLIENTs is mostly useless if the CLIENT use randomized MACs. I knew that hcxdumptool used random MACs but didn't know it would re-use captured MACs too, that is pretty great! But I am extracting the MACS for EAPOL and PMKID separately, so I don't think that shouldn't be an issue right? I'm sorting specifically for captured MACs on EAPOL and then for MACs on PMKID captures, so I should only be getting "genuine" MACs of attacked clients/aps. To restate:
(03-15-2020, 11:51 PM)ZerBea Wrote: Additional hcxdumptool v6.0.2 has an option to run BPF code, which is much faster then the old filter modes. I'm currently using 6.0.1 with both the "--filterlist_client" and "-filterlist_ap" switches. I know in older version BPF was used but I wasn't sure if I was formatting that right. Looking at the changelog for 6.0.2, it looks like I would need to use tcpdump to create the new list. There is a 256 line limit on the current Client and AP filter lists.
RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 03-17-2020 Yes, you are right. The BPF is a nice and fast kernel feature to filter out unwanted packets. You can combine everything (MAC_AP, MAC_CLIENT, rx branch, tx branch). The best way to use BPFC is to protect APs and CLIENTs. Example to protect AP and CLIENT in tx branch and rx branch: 001122334455 == AP aabbccddeeff == CLIENT run hcxdumptool -m to set monitor interface for tcpdump (tcmpdump need this to now how to generate BPFC) create filtercode as follows: Code: $ tcpdump -i <interface> not wlan addr1 00:11:22:33:44:55 and not wlan addr2 00:11:22:33:44:55 and not wlan addr1 aa:bb:cc:dd:ee and not wlan addr2 aa:bb:cc:dd:ee -ddd > protect.bpf Notice: You will loose PSKs transmitted in plain, if you use attack filters due to MAC randomization of most of the CLIENTs. The PSK transmitted with MAC x used by the CLIENT will not match to the authentication with MAC z used by the CLIENT Due to your attack filter z, x is filtered out!!!! I dropped BPF support in old wlandump-ng, because it was very limited. But now BPFC is restricted to 65535 code blocks. That should be more than enough for every purpose. A good reason to re-add this feature. -> But I am extracting the MACS for EAPOL and PMKID separately, so I don't think that shouldn't be an issue right? that could be a problem if you feed hashcat with either EAPOL or PMKID we can have two (or more - depend on count of the CLIENTs) valid but different PSKs for a combination of MAC and ESSID, if the essid is a common ESSID like "default", "home", "Home", .... - one PSK belongs to the AP - one PSK belongs to the CLIENT A - one PSK belongs to the CLIENT B - one PSK belongs to the CLIENT C ... The PSKs will only match if the CLIENT belongs to the AP This does not necessarily have to be the case. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - MrShannon - 03-18-2020 > But now BPFC is restricted to 65535 code blocks. Wow, that is significant. Right now I am generating filter lists that cuts off at 256 entries after adding the "user defined" set of addresses to ignore. I also add the interfaces of the raspi (wlan0 and wlan1) just to be sure it doesn't attack itself. I'm wondering about the length of the command being sent to tcpdump. Let's pretend we have roughly 10% of the maximum number of mac addresses to filter, that's about 6550 mac addresses. Assuming we has to pass "and not wlan addr1 00:11:22:33:44:55" for each mac address to include, that's 37 characters per mac address, equating to more than 242,350 characters on the command line. Can you actually do that? A cursory web search says the limit is around 5,200 characters, so at 37 characters per mac address, out upper limit is actually around 140 mac addresses. Which is a lot worse than using the mac filter list switches... Am I misunderstanding how this works? RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 03-18-2020 That depend on the environment variables of your system. $ getconf ARG_MAX 2097152 I haven't tested it exactly , because I have not so much entries. BTW: It is allowed to use BPFC and filtermode options (filterlist_ap/filterlist_client) together. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - strike1953 - 03-27-2020 Hello, question how to view 22000 format, essid and essid mac Thank you RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - Mem5 - 03-27-2020 Format 22000 is easily readable, just explained at the top of this thread : (03-15-2020, 11:51 PM)ZerBea Wrote: The format of a 22000 hashline is: RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - strike1953 - 03-27-2020 My question is how do I view the essid and its mac from a xxx.22000 file in plain text? |