WEP (arp replay attack) seems to stop sending replay packets after ~ 60 sec about wifite2

[derv82]

I can reproduce this easily by running the arpreplay attack at a very-low PacketsPerSecond:

./Wifite.py --wep --pps 10

IVs aren't incrementing at the previous rate (essentially a trickle at this point).

The CPU usage of the aireplay-ng process decreases gradually, then drops when the packets stop.

I'll look into this...

[derv82]

Ok, I don't see anything that would cause the command to stop after 60 seconds... And it's not exactly 60 seconds for me (more like 2minutes).

Looking at the subprocess.Popen documentation:

Warning
This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data.

The script does use stdout=PIPE, and aireplay-ng does generate a lot of output when replaying packets...

I made a change to redirect stdout to /dev/null for the aireplay attacks. It seems to work for arpreplay -- I got to 10,000 IVS at 10 PPS (took ~20 minutes).

But this change may break other aireplay-ng attacks.... There's no option to specify the aireplay-ng attacks (--chopchop, --fragment, etc), so it's hard for me to test. I'll leave this open until the issue (arpreplay PPS degradation) is resolved.

[vom513]

Wow - thanks for the quick work on this. ARP replay attack now works as expected. I even kicked pps down to 100 and it ran for > 10 min - but completed successfully.

[derv82]

Sweet! Closing as fixed. I'll work on user-specified attacks (--arpreplay, --fragment, --chopchop) separately.