Some Questions about the krack scripts

[harpyja]

Help!!!!Some Questions about scripts I have read the paper, test krack-test_client.py by set args and read it code. But there's just a connected log running this script on my kali(2018.3) when testing the wpa_supplicant_2.4 on centos7.1 connect in. my shell:

python krack-test-client.py Connected log like this:

[15:15:29] Reset PN for GTK wlan1: STA 00:21:5d:a8:4b:4e IEEE 802.11: authenticated wlan1: STA 00:21:5d:a8:4b:4e IEEE 802.11: associated (aid 1) wlan1: AP-STA-CONNECTED 00:21:5d:a8:4b:4e wlan1: STA 00:21:5d:a8:4b:4e RADIUS: starting accounting session 339C0B3AFAE0044C [15:15:29] 00:21:5d:a8:4b:4e: 4-way handshake completed (RSN) [15:15:31] Reset PN for GTK [15:15:33] Reset PN for GTK

But there's nothing but Reset PN for GTK after connected. Then I tests other args like --replay-broadcast, --group, --tptk.It's also report like above without useful info. Is anyone have the same problem?

I can't understand some places in code:

elif p.addr1 == self.apmac and Dot11WEP in p:

Why WEP? Means the reinstallation attacks changes WPA2 turn into WEP? These questions trouble me in a long time.Waiting for someone help me

[JustIdeas]

I'm facing the same problem here. The device are able to connect to the "Fake" AP, receives the IP ADDRESS from it, but nothing more, i'm not even able to ping from the device to the AP.

[harpyja]

I have the same problem when using the poc-scripts: https://github.com/vanhoefm/krackattacks-poc-zerokey When catching packets by wireshark, it seems that packets send to "Fake" AP but the device IP ADDRESS from the REAL AP. You can forward packets from "Fake" AP to REAL AP.

[JustIdeas]

Today I was able to use the script even with the RESET PN for GTK. The problem was with the hostapd configuration file. For now, just take a look in to your hostapd file to see if there is some mismatch configuration. If you have any AP router that uses Hostapd, try to copy his configuration and uses in to the hostapd from the krackattack.

I tested with the device without the patch and with the patch, and it's clear that the script is working, but you need to work hard to be able to run it.

[harpyja]

I have tested krackattack hostapd with a normal configureation file from an other AP router,which devices could connect with it. But there's nothing print out when connected over. May I see your log, please？

[JustIdeas]

follow below the log without patch (with error) and with it:

WITH ERROR:

[13:21:51] Reset PN for GTK [13:21:53] Reset PN for GTK wlan0: STA 00:19:3b:06:4d:02 IEEE 802.11: authenticated wlan0: STA 00:19:3b:06:4d:02 IEEE 802.11: associated (aid 1) [13:21:55] Reset PN for GTK wlan0: AP-STA-CONNECTED 00:19:3b:06:4d:02 wlan0: STA 00:19:3b:06:4d:02 RADIUS: starting accounting session 4549D91598953815 [13:21:56] 00:19:3b:06:4d:02: 4-way handshake completed (RSN) [13:21:56] 00:19:3b:06:4d:02: transmitted data using IV=1 (seq=2) [13:21:56] 00:19:3b:06:4d:02: transmitted data using IV=2 (seq=3) [13:21:56] 00:19:3b:06:4d:02: transmitted data using IV=3 (seq=4) [13:21:56] 00:19:3b:06:4d:02: transmitted data using IV=4 (seq=5) wlan0: STA 58:10:8c:5e:7d:b0 IEEE 802.11: authenticated [13:21:57] 00:19:3b:06:4d:02: transmitted data using IV=5 (seq=0) [13:21:57] 00:19:3b:06:4d:02: transmitted data using IV=6 (seq=1) [13:21:57] Reset PN for GTK [13:21:57] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:21:57] 00:19:3b:06:4d:02: received a new message 4 [13:21:57] 00:19:3b:06:4d:02: transmitted data using IV=7 (seq=6) [13:21:59] Reset PN for GTK [13:21:59] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:21:59] 00:19:3b:06:4d:02: transmitted data using IV=1 (seq=7) [13:21:59] 00:19:3b:06:4d:02: IV reuse detected (IV=1, seq=7). Client reinstalls the pairwise key in the 4-way handshake (this is bad) [13:22:01] 00:19:3b:06:4d:02: transmitted data using IV=1 (seq=2) [13:22:01] 00:19:3b:06:4d:02: transmitted data using IV=2 (seq=8) [13:22:01] Reset PN for GTK [13:22:03] 00:19:3b:06:4d:02: transmitted data using IV=3 (seq=3) [13:22:03] Reset PN for GTK [13:22:05] Reset PN for GTK [13:22:05] 00:19:3b:06:4d:02: transmitted data using IV=4 (seq=9) [13:22:07] Reset PN for GTK [13:22:09] Reset PN for GTK [13:22:11] Reset PN for GTK [13:22:13] Reset PN for GTK [13:22:14] 00:19:3b:06:4d:02: transmitted data using IV=5 (seq=4) [13:22:15] Reset PN for GTK [13:22:16] 00:19:3b:06:4d:02: transmitted data using IV=6 (seq=5) [13:22:16] 00:19:3b:06:4d:02: DHCP reply 192.168.100.2 to 00:19:3b:06:4d:02 [13:22:16] 00:19:3b:06:4d:02: DHCP reply 192.168.100.2 to 00:19:3b:06:4d:02 [13:22:16] 00:19:3b:06:4d:02: transmitted data using IV=7 (seq=6) [13:22:16] 00:19:3b:06:4d:02: transmitted data using IV=8 (seq=7) [13:22:17] Reset PN for GTK [13:22:18] 00:19:3b:06:4d:02: client has IP address -> now sending replayed broadcast ARP packets [13:22:18] 00:19:3b:06:4d:02: sending broadcast ARP to 192.168.100.2 from 192.168.100.1 (sent 0 ARPs this interval) [13:22:18] 00:19:3b:06:4d:02: received 0 replies to the replayed broadcast ARP requests [13:22:18] 00:19:3b:06:4d:02: transmitted data using IV=9 (seq=8) [13:22:19] 00:19:3b:06:4d:02: transmitted data using IV=10 (seq=9) [13:22:19] 00:19:3b:06:4d:02: transmitted data using IV=11 (seq=10) [13:22:19] 00:19:3b:06:4d:02: transmitted data using IV=12 (seq=11) [13:22:20] Reset PN for GTK [13:22:20] 00:19:3b:06:4d:02: sending broadcast ARP to 192.168.100.2 from 192.168.100.1 (sent 1 ARPs this interval) [13:22:20] 00:19:3b:06:4d:02: transmitted data using IV=13 (seq=10) [13:22:20] 00:19:3b:06:4d:02: received 1 replies to the replayed broadcast ARP requests [13:22:22] Reset PN for GTK [13:22:22] 00:19:3b:06:4d:02: sending broadcast ARP to 192.168.100.2 from 192.168.100.1 (sent 2 ARPs this interval) [13:22:22] 00:19:3b:06:4d:02: transmitted data using IV=14 (seq=11) [13:22:22] 00:19:3b:06:4d:02: received 2 replies to the replayed broadcast ARP requests [13:22:24] Reset PN for GTK [13:22:24] 00:19:3b:06:4d:02: sending broadcast ARP to 192.168.100.2 from 192.168.100.1 (sent 3 ARPs this interval) [13:22:24] 00:19:3b:06:4d:02: received 3 replies to the replayed broadcast ARP requests [13:22:24] 00:19:3b:06:4d:02: transmitted data using IV=15 (seq=12) [13:22:26] Reset PN for GTK [13:22:26] 00:19:3b:06:4d:02: sending broadcast ARP to 192.168.100.2 from 192.168.100.1 (sent 4 ARPs this interval) [13:22:26] 00:19:3b:06:4d:02: transmitted data using IV=16 (seq=13) [13:22:26] 00:19:3b:06:4d:02: received 4 replies to the replayed broadcast ARP requests [13:22:27] 00:19:3b:06:4d:02: transmitted data using IV=17 (seq=14) [13:22:28] Reset PN for GTK [13:22:28] 00:19:3b:06:4d:02: got a reply to broadcast ARPs during this interval [13:22:28] 00:19:3b:06:4d:02: sending broadcast ARP to 192.168.100.2 from 192.168.100.1 (sent 1 ARPs this interval) [13:22:28] 00:19:3b:06:4d:02: transmitted data using IV=18 (seq=15) [13:22:28] 00:19:3b:06:4d:02: received 5 replies to the replayed broadcast ARP requests [13:22:28] 00:19:3b:06:4d:02: Client reinstalls the group key in the 4-way handshake (this is bad). [13:22:28] Or client accepts replayed broadcast frames (see --replay-broadcast). [13:22:29] 00:19:3b:06:4d:02: transmitted data using IV=19 (seq=16) [13:22:30] Reset PN for GTK [13:22:32] Reset PN for GTK [13:22:34] Reset PN for GTK [13:22:36] Reset PN for GTK

WITHOUT ERROR:

[13:33:28] 00:19:3b:06:4d:02: transmitted data using IV=31 (seq=14) [13:33:29] Reset PN for GTK [13:33:29] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:33:29] 00:19:3b:06:4d:02: received a new message 4 [13:33:29] 00:19:3b:06:4d:02: transmitted data using IV=32 (seq=18) [13:33:31] Reset PN for GTK [13:33:31] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:33:31] 00:19:3b:06:4d:02: received a new message 4 [13:33:31] 00:19:3b:06:4d:02: transmitted data using IV=33 (seq=19) [13:33:33] Reset PN for GTK [13:33:33] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:33:33] 00:19:3b:06:4d:02: received a new message 4 [13:33:33] 00:19:3b:06:4d:02: transmitted data using IV=34 (seq=20) [13:33:33] 00:19:3b:06:4d:02: no pairwise IV resets seem to have occured for one interval [13:33:33] 00:19:3b:06:4d:02: client DOESN'T reinstall the pairwise key in the 4-way handshake (this is good) (used standard attack). [13:33:35] Reset PN for GTK [13:33:35] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:33:35] 00:19:3b:06:4d:02: received a new message 4 [13:33:35] 00:19:3b:06:4d:02: transmitted data using IV=35 (seq=21) [13:33:37] Reset PN for GTK [13:33:37] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:33:37] 00:19:3b:06:4d:02: received a new message 4 [13:33:38] 00:19:3b:06:4d:02: transmitted data using IV=36 (seq=22) [13:33:39] 00:19:3b:06:4d:02: transmitted data using IV=37 (seq=15) [13:33:39] Reset PN for GTK [13:33:39] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:33:39] 00:19:3b:06:4d:02: received a new message 4 [13:33:39] 00:19:3b:06:4d:02: transmitted data using IV=38 (seq=23) [13:33:41] Reset PN for GTK [13:33:41] 00:19:3b:06:4d:02: sending a new 4-way message 3 where the GTK has a zero RSC [13:33:41] 00:19:3b:06:4d:02: received a new message 4 [13:33:42] 00:19:3b:06:4d:02: transmitted data using IV=39 (seq=24) [13:33:42] 00:19:3b:06:4d:02: transmitted data using IV=40 (seq=16) [13:33:43] Reset PN for GTK

[JustIdeas]

What kind of device (smartphone...) you are trying to test? tomorrow I can send you my hostapd configuration, and a print of my wireless interfaces. By the way, i'm using a TENDA w522U as dongle device, with a virtual machine with Kali Linux on it.

Maybe your monitor interface is not able to capture the exchanges. have you tried with another wifi dongle?

[harpyja]

Thank you very much for help me. I used to test smartphone(Android 5.1 with wpa_supplicant2.6) and kali linux with the krackattack's wpa_supplicant. And I also deal with it by kali virtual machine, and my dongle device is ARGtek GM5 and TPLINK WN722N. All above print out nothing when using test-client script with any args. I tested my monitor mode interface to capture 80211, it works. So I can't located what's wrong and why my test-client script doesn't work.

[JustIdeas]

Follow the hostapd file used to test a Samsung S7 Edge with android 7.0. hostapd.conf.2GHZ.txt

Obs: just change the Country code if you need to.

Maybe, today at night I will upload my virtual machine with all configurations done, and from that, you just need to install your wireless dongle

[harpyja]

So kind of you. But it also doesn't work using this file. Nothing print out without Reset PN for GTK if connected. I'm thinking about that whether my way to test client losts some steps or not. Or maybe my wireless dongle does not support to do this krackattack test.

My steps: sh disable-hwcrypto.sh reboot python krack-test-client.py --tptk

My client device: Nokia6 with android 8.1 (wpa_supplicant 2.6 patched) m3 note with android 5.1 (wpa_supplicant 2.3) htc hd2 with android 4.2.2 (wpa_supplicant 2.0) kali 2018.3 , centos7.1 with wpa_supplicant 2.4

[JustIdeas]

Did you run the command rfkill unblock all?

[harpyja]

yoop, if not do that, macchanger will have an exception.

[JustIdeas]

Have you checked if you are able to capture the 4 way handshake? Using wireshark or tcpdump

[JustIdeas]

Ifor what im seeing, your moniyor interface are not able to capture the traffic

[harpyja]

[JustIdeas]

the output using --debug is the same? take a look if there is a wlan0mon created by the script. try to change the channel to another one

[JustIdeas]

try to uncomment this lines:

ht_capab=[HT40+] This one you maybe dont need to use

ieee80211n=1

require_ht=1

just remember that if you use these arguments, you need to recompile you hostapd from the hostapd/.config with N capabilitie enabled.

[harpyja]

Yes, there is a wlan0mon created on monitor mode. Always print nothing with --debug.

I changed the compile config file by uncomment this to enable the 80211n capability:

CONFIG_IEEE80211N=y

When I'm trying to connect the recompiled hostapd, it says my client station does not support mandatory HT PHY if I uncommented the "require_ht" line and it will reject the associateion log:

[11:09:59] Reset PN for GTK [11:10:01] Reset PN for GTK wlan0: STA cc:9f:7a:1a:74:e0 IEEE 802.11: authenticated wlan0: STA cc:9f:7a:1a:74:e0 IEEE 802.11: Station does not support mandatory HT PHY - reject association [11:10:03] Reset PN for GTK [11:10:05] Reset PN for GTK

I have already attemp to change wlan0mon channel, but there's no use for go on this script. So I have a question about to use Dot11WEP in determine statements in the script because I can't catch any WEP packet. Whether WPA2 turn into WEP after reinstalled msg3?

[JustIdeas]

Maybe they are using the encryptation method of DOT11WEP to encrypt de data that you reinstall the key. as the log says, hi is transmiting data usin IV, that is 24 bit IV (initialization vector) from the Dot11WEP. But I don't think that this is cause any trouble.

A interesting thing about your log, is if your device doesnt support HT PHY, automatically doesn't work on 802.11n. have you tried changing the hwmode to "g"?

About hardware encryptation: You dongle driver is on the file /etc/modprobe.d/nohwcrypt.conf? that may be your problem to, if your driver is not there.

[harpyja]

Emmmmmm, but I don't think a WPA2 Frame's Radiotap could include WEP layers or WEP FCField flags. They're different of encryptions mode event initialization vector from Dot11WEP.

Then I check the hwmode on "g" and my dongle driver.It seems hwmode "g" also could establish a connection with client device .

My dongle driver file /etc/modprobe.d/nohwcrypt.conf do exists and my wireless dongle also in the options:

options ath5k nohwcrypt=1 options ath9k nohwcrypt=1 options ath9k_htc nohwcrypt=1 options rt2800usb nohwcrypt=1 options carl9170 nohwcrypt=1 options b43 nohwcrypt=1 options p54common nohwcrypt=1 options rt2500usb nohwcrypt=1 options rt2800pci nohwcrypt=1 options rt2800usb nohwcrypt=1 options rt73usb nohwcrypt=1 options iwlwifi swcrypto=1 options iwl3945 swcrypto=1 options iwl4965 swcrypto=1 options ipw2200 hwcrypto=0

Maybe I should change one more dongle from TENDA or other manufacturers

[JustIdeas]

I was looking about this DOT11WEP, and it's not WEP, it's just uses the IV method of encrypation with ECB method, it's not a WEP encryptation.

About the virtual machine, follow the link below:

https://www.dropbox.com/s/l4gxsk9r3r97cit/KrackAttack_Test.ova?dl=0

[JustIdeas]

Have you tried to use the virtual machine?

[harpyja]

Sorry, I just saw your message. Thank you for share your virtual machine. But my network speed is too slow, it will take some time to download. I will try it immidiatly if download over. Thanks a lot.

[JustIdeas]

let me know if you need any other help.

[harpyja]

Sorry for my junk net speed. Download off and on many times these days. At last I saw the log like this:

There's no problems with my tests. So kind of you for help me.

[JustIdeas]

Probably is your dongle device that is messing with your test, try other one, like this one below: https://www.ebay.com/itm/Tenda-Wireless-WiFi-USB-Adapter-Dongle-for-Samsung-TV-Television-WIS12ABGNX/122297619417?hash=item1c798193d9:g:1ekAAOSw2xRYbC4B

This is the one that I was using on the test.

Sorry that I couldn't help you. :(

[harpyja]

Nothing, you have helped me much and I changed the wireless dongle to TP_LINK, it works. It seems really related to the wireless dongle status and support mode. Cheers for it works.[]~ (￣▽￣) ~*

[JustIdeas]

I'm really happy for you dude!! Nice!!

[sumukh5]

what is the VM password @JustIdeas