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 - ciccio17 - 10-25-2020 i know, not a way to go on 5.4.xx and over kernels. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ciccio17 - 10-27-2020 hi zerbea any progress on 2.4 ghz? i expanded the range, the patch applied, but the range is 1-14 with The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) patch i'm not talking about hcxdumptool, the range of my phy is 1-14 with this patch. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 10-27-2020 You have to patch: regulatory domain common-init.c regd.c util.c hw.h RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ciccio17 - 10-27-2020 hi zerbea, i'm back on the (1-14) + 0 -1 -2 channels, i'm not sure if you made it working on 2.4 ghz extended range. but anyway the patches for me are totaly different, and i'm a common human, not an alien like you.Lol so back : i see that my phy on 2.4 ghz is able to use channel -1 and -2 as mesh point and monitor and injection. on 5.8 ghz my phy can do ap, station, until channel 179. and can do mesh point and monitor and injection until channel 184. i just love hcxdumptool, thats why i'm so insistent. so : my phy on 2.4 ghz is 2397-2484, hcxdumptool only see (1-14) on 5.8 ghz hcxdumptool work until channel 175. can we test this? for now? anyway thanks for your help! you are a great one. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 10-28-2020 That depend on the 2.4GHz modification. if made correct, there are no negative channels. The expanded range is added as 14...33 Code: + CHAN2G(2312, 33), /* Channel -19 */ This is only a comment: Code: /* Channel -3 */ If you are on 2397 it should be channel 17 Code: CHAN2G(2392, 17) No let's do a test to confirm expanded frequencies of the patch: set monitor mode by hcxdumptool: Code: $ sudo hcxdumptool -m <interface> open Wireshark and go to capture/options select your interface open the channel list how much channels (channel . frequency) do you see? please attach a screenshot of the opened channel list. Please notice: My committed changes only allow to set expanded channels, but it is possible that they don't show correct frequencies and channel numbers. You must modify hcxdumptool, too. hcxdumptool's frequency range must match to your patched driver: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L6462 Code: else if((frequency >= 2407) && (frequency <= 2474)) testchannel = (frequency -2407)/5; https://hashcat.net/forum/thread-6661-post-50509.html#pid50509 If not modified, hcxdumptool will show you false frequencies and false channel numbers. If the modification is working, please tell me the values (edge frequencies you used) and the output of hcxdumptool -C. This one is is responsible to show the correct frequency for channel 14: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L6465 This one handle 2.4GHz frequencies: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L6464 This one handle 5GHz frequencies: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L6466 hcxdumptool's edge frequencies must(!) match to the edge frequencies of your driver! RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - crappy.follower - 12-19-2020 Hey, Really enjoyed this tool and your work. I have gone through the entire process of using hcxdumptools to capture wifi network data. I have converted the captured data using hcxpcapngtool. I then use hashcat mode 22000 to start a dictionary attack. I need to take a step back and ensure I have collected the appropriate data. I was wondering if there were any obvious ways to tell whether or not the captured data can be cracked? My concern is I have captured "synthetic hashes" (I read a post about this) which aren't actually capable of being cracked. For example, I have collected WPA 01 and WPA 02 data which has unknown MAC AP and Client data (hcxhashtool -i example.22000 --info=stdout). When I enter the data into Hashcat, it starts the process, but not sure if its just making a bunch of sound and heat. Is $ hcxhashtool -i example.22000 --info=stdout the indicator as to what hashes can be cracked? Despite many lines not having Mac AP and Client data? RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 12-19-2020 Thanks. I'm glad to hear that the tools are working as expected. hcxhashtool is designed to show an information about the content of the hash file. Unfortunately it is not able to detect whether a PSK can be recovered by hashcat or not. But with the shown information you should be able to determine if it is useful to start a hashcat task on that hash or not. Also you can use this information to prepare/calculate the wordlist, mask or rule for this hash. I give you some examples based on the output of hcxhastool --info=stdout If the default PSK is based on the MAC_AP: search if there is an algo to calculate the default PSK for this MAC. If yes, use the tools to calculate the exact PSK https://github.com/routerkeygen or the complete keyspace: hcxpsktool If the default PSK is based on the ESSID use hcxpsktool or hcxeiutool -s option in combination with a rule (e.g. year) on hcxpcapngtool -EIU output If the default PSK is requested and captured by hcxdumptool use hcxpcapngtool -EIU option and feed hashcat with this list. Upload your captured dump file to wpa-sec to see if the PSK is inside of one of the default wordlists. The results of wpa-sec are continuously used to improve hcxtools, e.g.: https://github.com/ZerBea/hcxtools/pull/175 https://github.com/ZerBea/hcxtools/pull/172 Some words about the unknown MACs (AP and CLIENT): To prevent tracking, nearly all CLIENTS running MAC randomization and hcxhashtool will show this MACs as unknown. To prevent counter measures against us, hcxdumptool will randomize all MACs, too and hcxhashtool will show this MACs as unknown. Also you should know that hcxdumptool/hcxtools are analysis tools. Therefore Atom added the new hash formats WPA-PBKDF2-PMKID+EAPOL (22000) and WPA-PMK-PMKID+EAPOL (22001) to hashcat. This allow huge analyses on mass data! https://github.com/ZerBea/hcxtools/pulls?q=is%3Apr+is%3Aclosed RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - gentleforce - 01-22-2021 (02-06-2020, 01:57 PM)ZerBea Wrote: That is another amazing feature. what's the rationale behind this? how come the password gets broadcasted as SSID in a probe request? is it a common user mistake (input in the wrong form)? It's common to see brobe requests with SSIDs that really look like passwords, sometimes with multiple variations like "passwd123", "passwd 123", "Passwd123" but I cannot explain their origin. My best guess is that confused users trying to connect to a hotspot might be typing the password when asked for ESSID, but it amazes me that it could be such a frequent mistake. RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ZerBea - 01-23-2021 We can find PSKs in the clear in PROBEREQUEST and EAP-ID frames. Your guess that confused users typing their PSK instead of the ESSID is correct. But we can find much more PSKs than this typo related ones. So it could be related to misconfigured/damaged config files and/or IoT devices. Unfortunately we can't ask the user what he has done or take a look at his wpa_supplicant.conf. So if someone has an idea why this happens, please let us know. Running hcxdumptool 24/7, it is possible to recover the PSKs from 10% of the captured handshakes by this method. Code: $ sudo -i interface -o dump.pcapng --tot=1440 --bpfc=own.bpfc --disable_deauthentication --disable_ap_attacks --active_beacon -c 1,9,6,3,11 -t 3600 We disable all AP attacks. We stay a longer time on a channel to make sure every CLIENT will find us. Please notice: That depend on how much CLIENTs hcxdumptool attacked/received and on the attack mode: A nice example is here (converted to old pcap, to allow old scool tools to read it, too) : https://github.com/evilsocket/pwnagotchi/issues/835#issuecomment-598597214 BTW: hcxpcapngtool will detect if this kind of frames is missing in a cap/pcap/pcapng file and print a warning: Code: summary capture file RE: hcxtools - solution for capturing wlan traffic and conversion to hashcat formats - ciccio17 - 01-24-2021 i'm not sure about that but could be a bug in some version of wpa_supplicant? |