WPA/2-PSK --creds does not create hccapx file properly

[mamatb]

Describe the bug

hccapx files generated while in AP mode with --auth wpa-psk --creds as described in the 4th Modern Wireless Tradecraft post do not 100% follow the format specified in the hashcat wiki. This causes hashcat to exhaust the supplied wordlist without cracking the PSK (tested using password password and several rockyou wordlists).

Upon inspection, turns out the issue is located in the EAPOL section of the hccapx file, fields WPA Key Data Length and WPA Key Data of M2 (source of the EAPOL section when having only M1 and M2 of the handshake). The PSK can be cracked successfully after fixing the format (screenshots below), hope the fix doesn't pose much trouble.

To Reproduce

1. Start WPA/2-PSK fake AP using --auth wpa-psk --creds as described in the aforementioned post. I also use --psk-capture-file to specify where to save the hccapx file, doesn't really matter.
2. Start capturing network traffic in the corresponding wireless interface, the resulting pcap file will have the information needed to fix the hccapx later.
3. Connect to the fake AP using a predictable password such as password.
4. Try to crack the PSK using hashcat -m 2500 and the hccapx file generated by eaphammer, it will fail.
5. Fix fields WPA Key Data Length and WPA Key Data in the EAPOL section so that they look as described in the hashcat wiki (link above, screenshots below). During my testing I've shrinked the generated hccapx file to one half-handshake (M1 + M2) only to ease up the process, that is, 393 bytes worth of hccapx according to the wiki (my wireless client tries to connect up to 4 times before giving up on a bad PSK). Failing to crack the PSK can be reproduced with the full one as well though.
6. Try to crack the PSK using hashcat -m 2500 and the new hccapx file, it will succeed.

Expected behavior

hccapx files should be generated as stated by the hashcat wiki.

Screenshots

1. hccapx file generated by eaphammer (shrinked to one half-handshake only as explained before):
   

2. PSK cracking fail:
   

3. WPA Key Data Length and WPA Key Data in M2 of the pcap file:
   

4. hccapx file after fixing those fields in the EAPOL section:
   

5. PSK cracking success:
   

Command string(s) used

eaphammer --interface wlan0 --channel 1 --auth wpa-psk --creds --hw-mode g --essid testing --psk-capture-file testing.hccapx
tcpdump -i wlan0 -w testing.pcap
hashcat -m 2500 -O -w 3 -a 0 testing.hccapx rockyou-55.txt

EAPHammer verbose output (using the --debug flag)

N/A

EAPHammer Version (./eaphammer --version)

Version: 1.12.1
Codename: Power Overwhelming

OS (the OS from which you are running EAPHammer)

Linux kali 5.5.0-kali2-amd64 #1 SMP Debian 5.5.17-1kali1 (2020-04-21) x86_64 GNU/Linux

Configuration of Target Access Point (if known / applicable)

N/A

Configuration of Target Client Device (if known / applicable)

N/A

Additional context

All this was tested several times using two different trustworthy chipsets: Atheros AR9271 and Ralink RT3070.
Kudos to rsrdesarrollo for being able to craft a valid hccapx file manually by inspecting the pcap file.
Also I'd like to thank you for your time and your tool, it is my go-to during WPA-Enterprise assessments.

[rsrdesarrollo]

@mamatb @s0lst1c3

A valid Fix could be found at /pull/143

The hccapx file was wrong formatted in two ways. WPA Key Data Length is Big endian (and not little endian, causing a bigger memory dump to the file) and, the last part of the EAPOL segment is the WPA Key Data (and not the MIC)

Looks like nobody tested this feature before ¯\_ (ツ) _/¯ because there is no way hashcat cracked something coming from here.

Regards

[JBalanza]

Any update on this?

[edlovesiraq]

if there was an update it would be here... This is free software your free to pull and make it better yourself.

[rsrdesarrollo]

if there was an update it would be here... This is free software your free to pull and make it better yourself.

already did it and nobody is accepting the PR (/pull/143)

BR

[s0lst1c3]