4-Way Handshake vs PMKID - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat (https://hashcat.net/forum/forum-45.html) +--- Thread: 4-Way Handshake vs PMKID (/thread-8285.html) Pages:
1
2
|
RE: 4-Way Handshake vs PMKID - kryplasemv - 06-16-2019 why i run hcxdumptool -i wlan0mon -o test16-6.pcapng --enable_status=1 and run convert to file m 16800 it has many PBKDF2 for one ESSiD 47865d98b3c92be870908df37f070fb4*f4b8a7b83ee0*acde484f6c5f*5048554f4e47 67b8a828b7fa5df40bb6e8d9540762ce*f4b8a7b83ee0*7836cc004cd5*5048554f4e47 4c7c4d3088acc5493cc9c7a3a48cd9ee*f4b8a7b83ee0*c83c8568479b*5048554f4e47 may i run corect ? please help me! RE: 4-Way Handshake vs PMKID - Mem5 - 06-16-2019 (04-05-2019, 03:53 PM)ZerBea Wrote: $ time hashcat -m 2500 test.hccapx --nonce-error-corrections=0 digit08 Atom Wrote:The main time for computation is in the PBKDF2 (99.99999%, well not exactly but you get the point), not anything after that. Therefore anything after that PBKDF2 can be seen as almost not existent. So why mode 16800 is faster - almost 2 times - than mode 2500 if the main painpoint is PBKDF2 for both ? RE: 4-Way Handshake vs PMKID - ZerBea - 06-17-2019 @kryplasemv every client will receive its own (calculated) PMKID from the access point because the MAC addresses are part of the calculation PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA) If you receive 3 of them and MAC_AP and ESSID is the same, you can delete 2 of them and keep only one for calculation, that will make hashcat a little bit faster. If MAC_AP, MAC_STA and ESSID are the same, but the PMKID is different, the access point changed the PMK or it is a Authentication Key Mangement PMKID (EAP, RADIUS, WPA3,...) hashline: PMKID:MAC_AP:MAC_STA:ESSID where MAC_AP is your target access point and the (E)SSID is in HEX-ASCII. We have some good reasons to use HEX-ASCII: "These SSIDs can be zero to 32 octets (32 bytes) long, and are, for convenience, usually in a natural language, such as English. The 802.11 standards prior to the 2012 edition did not define any particular encoding/representation for SSIDs, which were expected to be treated and handled as an arbitrary sequence of 0–32 octets that are not limited to printable characters. The IEEE 802.11-2012 defines a tag that the SSID is UTF-8 encoded and when interpreting could contain any non-ISO basic Latin characters within it. Wireless network stacks must still be prepared to handle arbitrary values in the SSID field." BTW: Do not run hcxdumptool on monitor interfaces created by airmon-ng. hcxdumptool run its own monitor mode (without using netlink library libnl). RE: 4-Way Handshake vs PMKID - ZerBea - 06-17-2019 @Mem5 The construction (PBKDF2 calculation) of the plainmasterkey (PMK) is for both hash modes (2500 and 16800) the same and take long period of CPU/GPU time. This first part is a really slow part. BTW: We need to calculate PBKDF2 once and can use it for PMKID and MIC (EAPOL) calculation: https://github.com/hashcat/hashcat/issues/1816 In the second part, PMKID calculation (16800) is much faster: PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA) than calculating a MIC from EAPOL (2500): calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA1: HMAC(EVP_sha1(), pmk, 32, pkedata, 100, ptk + p * 20, NULL); HMAC(EVP_md5(), &ptk, 16, eapol, eapol_len, mic, NULL); or calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA2: HMAC(EVP_sha1(), pmk, 32, pkedata, 100, ptk + p * 20, NULL); HMAC(EVP_sha1(), &ptk, 16, eapol, eapol_len, mic, NULL); or calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA2 key version 3: HMAC(EVP_sha256(), pmk, 32, pkedata_prf, 2 + 98 + 2, ptk, NULL); omac1_aes_128(&ptk, eapol, eapol_len, mic); That is a simple and quick answer, but you can read more here: https://www.ins1gn1a.com/understanding-wpa-psk-cracking/ RE: 4-Way Handshake vs PMKID - Mem5 - 06-17-2019 I see. Thanks a lot! |