07-26-2018, 05:26 PM
in the hc2500.pot does not indicate the essid
hashcat Forum
›
Misc
›
User Contributions
hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
|
hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
|
You can't use the hc2500.pot in combination with -m 16800, because the output is completely different.
hc16800.pot should look like this: PMKID*MAC_AP*MAC_STA*ESSID (in HEX):password 2582a8281bf9d4308d6f5731d0e61c61*4604ba734d4e*89acf0e761f4*ed487162465a774bfba60eb603a39f3a:hashcat! as described here: https://hashcat.net/wiki/doku.php?id=example_hashes In other words: You entered the "Royal Class of WPA-cracking", so forget all about -m 2500/2501 formats (hccapx, potfile) $ hashcat -m 16800 --potfile-path=hc16800.pot hashfile16800 wordlist hashcat (v4.2.0) starting... Session..........: hashcat Status...........: Cracked Hash.Type........: WPA-PMKID-PBKDF2 Hash.Target......: 2582a8281bf9d4308d6f5731d0e61c61*4604ba734d4e*89acf...a39f3a Time.Started.....: Fri Jul 27 11:29:05 2018 (0 secs) Time.Estimated...: Fri Jul 27 11:29:05 2018 (0 secs) Guess.Base.......: File (wordlist) Guess.Queue......: 1/1 (100.00%) Speed.Dev.#1.....: 29 H/s (0.11ms) @ Accel:32 Loops:16 Thr:1024 Vec:1 Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.........: 1/1 (100.00%) Rejected.........: 0/1 (0.00%) Restore.Point....: 0/1 (0.00%) Candidates.#1....: hashcat! -> hashcat! HWMon.Dev.#1.....: Temp: 49c Fan: 37% Util: 53% Core:1657MHz Mem:5005MHz Bus:16 $ cat hc16800.pot 2582a8281bf9d4308d6f5731d0e61c61*4604ba734d4e*89acf0e761f4*ed487162465a774bfba60eb603a39f3a:hashcat! 
07-27-2018, 02:51 PM
(07-27-2018, 11:35 AM)ZerBea Wrote: You can't use the hc2500.pot in combination with -m 16800, because the output is completely different. OK, sorry. I am rookie. Thank you i am learning a lot with you.
Now problem, you're welcome.
But now, I could use a little help: hcxdumptool use raw sockets. Now I noticed, that the responds are too slow to attack an AP successfully. 1. AP responds to our proberequest 2. AP retry 3. AP retry 4. AP retry 5. hcxdumptool ack the response 6. hcxdumptool authenticates 7. AP ack authentication 8. AP confirms send authentication successfull 9. AP retry 10. AP retry 11. AP retry 12. hcxdumptool ack the authentication 13. hcxdumptool associates 14. AP ack the associationrequest 15. AP responds to the association 16. AP retry 17. AP retry 18. AP retry... and give up, because a snail (gastropod) tries to enter his b, g, n network!!!!!! It seems we must leave user space and dive into kernel space to handle this. We are too slow. Any help (or a solution) is welcome. 
rawsockettooslow.pcap.zip (Size: 765 bytes / Downloads: 3)
The next big issue is related to ATHEROS driver ath9k_htc:
ath9k_htc/htc_9271-1.4.0.fw FCS is calculated in a wrong way on transmitted ack frames. frame 1: ath9k_htc (the last two bytes are missing) frame 2: rt2x00_set_rt: Info - RT chipset 3070 (everything is fine) Any help (or a solution) is welcome.
atheroserror.pcapng.zip (Size: 292 bytes / Downloads: 7)
07-29-2018, 10:22 PM
How does that currently affect dumps produced with ath9k_htc adapters, would it corrupt the handshakes? Is it better to use RT 3070 instead?
07-29-2018, 10:37 PM
(This post was last modified: 07-29-2018, 10:51 PM by strike1953.)
(07-28-2018, 12:20 AM)ZerBea Wrote: The next big issue is related to ATHEROS driver ath9k_htc: I am using atheros and I do not find problems yet
07-30-2018, 06:44 AM
ZerBea, thanks for all these updates.
am curious, whats the advantage of mode 16800/16801 ? does hashcat bruteforcing speed increase over mode 2500 or is it something else ?
07-30-2018, 01:11 PM
(This post was last modified: 07-30-2018, 01:22 PM by strike1953.)
(07-30-2018, 06:44 AM)wakawaka Wrote: ZerBea, thanks for all these updates. same speed Advantage: only 2 packets required 1 associationrequest/reassociationrequest (proberesponse is ok, too) 2 EAPOL 1/4 (M1) with included RSN IE
hcxtools 4.2.0 released (https://github.com/ZerBea/hcxtools)
-added full support for hashcat hashmodes 16800/16801 -many bug fixes -default cap format now pcapng -moved WiFi dump stuff to hcxdumptool (https://github.com/ZerBea/hcxdumptool) $ hcxpcaptool -z test.16800 test.pcapng start reading from test.pcapng summary: file name....................: test.pcapng file type....................: pcapng 1.0 file hardware information....: x86_64 file os information..........: Linux 4.17.11-arch1 file application information.: hcxdumptool 4.2.0 network type.................: DLT_IEEE802_11_RADIO (127) endianess....................: little endian read errors..................: flawless packets inside...............: 66 skipped packets..............: 0 packets with FCS.............: 0 beacons (with ESSID inside)..: 17 probe requests...............: 1 probe responses..............: 11 association requests.........: 5 association responses........: 5 authentications (OPEN SYSTEM): 13 authentications (BROADCOM)...: 1 EAPOL packets................: 14 EAPOL PMKIDs.................: 1 1 PMKID(s) written to test.16800 Todo: hcxdumptool 4.2.0 will randomize ap-less attacks. hcxpcaptool converts this handshakes correctly, but will not detect them as ap-less attack. This feature will be added in hcxtools 4.2.1 Stay tuned for release of hcxdumptool 4.2.0 and client-less attack (hashmode -m16800/16801) on 802.11i |
|
« Next Oldest | Next Newest »
|