r69 unable to recover wpa2 key given the pin, while reaver 1.3 can do it

[GoogleCodeExporter]

Answer the following questions for every issue submitted:

0. What version of Reaver are you using?  (Only defects against the latest
version will be considered.)
      svn r69 and reaver 1.3
1. What operating system are you using (Linux is the only supported OS)?
      backtrack 5r1
2. Is your wireless card in monitor mode (yes/no)?
      yes
3. What is the signal strength of the Access Point you are trying to crack?
      about -25 dbm
4. What is the manufacturer and model # of the device you are trying to
crack?
      rtl8187
5. What is the entire command line string you are supplying to reaver?
      reaver -i mon0 -b 08:76:FF:XX:XX:XX --pin=62XXXX60 -vv
6. Please describe what you think the issue is.
      reaver r69 is unable to recover the wpa/wpa2 pass given the correct pin, while this worked with reaver 1.3

7. Paste the output from Reaver below.

-WITH REAVER R69:

root@root:~/reaver-wps-read-only/src# ./reaver -i mon0 -b 08:76:FF:XX:XX:XX 
--pin=62XXXX60 -vv

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

[+] Waiting for beacon from 08:76:FF:XX:XX:XX
[+] Switching mon0 to channel 1
[+] Associated with 08:76:FF:XX:XX:XX (ESSID: Thomsonxx6AAx)
[+] Trying pin 62XXXX60 
[+] Trying pin 62XXXX60 
[+] Trying pin 62XXXX60 
[+] Trying pin 62XXXX60 
[!] WARNING: Detected AP rate limiting, waiting 60 seconds before re-trying
^C
[+] Session saved.

-WITH REAVER 1.3:

root@root:~/Desktop/reaver-1.3/src# ./reaver -i mon0 -b 08:76:FF:XX:XX:XX 
--pin=62XXXX60 -vv

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

[+] Waiting for beacon from 08:76:FF:XX:XX:XX
[+] Switching mon0 to channel 1
[+] Associated with 08:76:FF:XX:XX:XX (ESSID: Thomsonxx6AAx)
[+] Trying pin 62XXXX60 
[+] Key cracked in 5 seconds
[+] WPS PIN: '62XXXX60' 
[+] WPA PSK: (CORRECT KEY) 
[+] AP SSID: 'Thomsonxx6AAx'
[+] Nothing done, nothing to save.

I have pcaps from outputs shown here, and some others that show this router 5 
min lock after 5 tryes (these others are not related to the original issue I am 
reporting). Craig I emailed you with another mail accnt. of mine about the wps 
lock system on this router. May I send you the pcaps via email? (about 500 kb)

thanks in advance 

Original issue reported on code.google.com by Stnd....@gmail.com on 7 Jan 2012 at 12:59

[GoogleCodeExporter]

Yes please, pcaps would be very helpful.

Original comment by cheff...@tacnetsol.com on 7 Jan 2012 at 1:36

[GoogleCodeExporter]

I just sent the pcap pack to you with my other email account

Original comment by Stnd....@gmail.com on 7 Jan 2012 at 2:04

[GoogleCodeExporter]

Got them, thanks! It looks like with r69 the AP is NACKing Reaver's M4 message, 
which should only happen if the first half of the pin is incorrect. But since 
you've manually specified the correct pin, this is very odd...I will see if I 
can reproduce this issue and look at what might have changed in the code to 
cause this to happen.

Original comment by cheff...@tacnetsol.com on 7 Jan 2012 at 2:33

[GoogleCodeExporter]

also forgot to mention, if you input one of those pcap to walsh it will not see 
it as a WPS enabled device, nor with the -i parameter

Original comment by Stnd....@gmail.com on 7 Jan 2012 at 2:37

[GoogleCodeExporter]

Taking a closer look at the NACK messages from the r69 pcap, the AP definitely 
thinks this is the wrong pin (device password auth failure error code is set). 
Can you do me a favor and run r67 and post (or email) the output from Reaver? 
There were no code changes between r67 and r69 except that the verbose 
debugging flag was enabled which will give much more info about what's going on 
inside Reaver.

Original comment by cheff...@tacnetsol.com on 7 Jan 2012 at 2:39

[GoogleCodeExporter]

Yes, that's a known bug in walsh that I'm working on. :)

Original comment by cheff...@tacnetsol.com on 7 Jan 2012 at 2:40

[GoogleCodeExporter]

i had not noticed the bug report for walsh, sorry.
unfortunately i cannot dump it today, because althought i have acess to the AP 
it is not at my house. Despite this, where i live and am right now i cath a 
very reasonable sign on a exact same AP model, problem is i will not be able to 
test the correct pin because all my attempts to crack it failed, and i dont 
have phisical acess to it. Would me tryng a wrong pin, with an Ap of same 
model, but with a wrong pin still be useful? otherwise i will dump it from the 
AP i have acess to when i go there, wich is going to be in 1-2 days 

Original comment by Stnd....@gmail.com on 7 Jan 2012 at 2:57

[GoogleCodeExporter]

Stnd.cpp i have the same wifi card that you have but i always get timeouts can 
you please tell me the router that you tried the attack

Original comment by fabiogfe...@gmail.com on 7 Jan 2012 at 11:22

[GoogleCodeExporter]

Stnd, yes, just try explicitly specifying a pin number (any pin) and see what 
output you get. Basically I want to make sure that Reaver is sending the pin 
that it's supposed to be sending.

Original comment by cheff...@tacnetsol.com on 7 Jan 2012 at 12:46

[GoogleCodeExporter]

I've reproduced the bug on my end using r76; same result, M4 message gets 
rejected. Work in progress...

Original comment by cheff...@tacnetsol.com on 7 Jan 2012 at 4:35

• Changed state: Started

[GoogleCodeExporter]

Another related note on a problem found due to this issue.  When it gets to 
90.90% having not found the pin it just starts repeating the same pin over and 
over.  This is once it hits the last of the 4 digit combinations.  It should 
instead error out saying the first 4 couldn't be found or it should start over.

Original comment by TheShort...@gmail.com on 7 Jan 2012 at 6:09

[GoogleCodeExporter]

In my understanding when reaver goes 90% it has found the first 4 pins.

Original comment by patricks...@gmail.com on 7 Jan 2012 at 6:16

[GoogleCodeExporter]

I'm talking about when reaver hits 90.90%, without skipping any percentage, 
which is when it hits the very last 4 digit pin in the list to try.  Once it 
gets there I guess it doesn't know what to do, so just keeps retrying that last 
4 digit pin.

Original comment by TheShort...@gmail.com on 7 Jan 2012 at 8:10

[GoogleCodeExporter]

Same issue here as in the original post, identical hardware setup. r66 works - 
r67 and later fail.

Original comment by fixbox2...@gmail.com on 7 Jan 2012 at 10:10

[GoogleCodeExporter]

fabiogfe...@gmail.com:
if you get allways timeouts, probably the ap does not accept a wps pin by 
design. or it could also be you are too far, but less likely. I would consider 
the first.

Craig, you have reproduced the bug, ao i guess you no longer need me to paste 
the output of this issue with r67, but if you need, just let me know. if i can 
collaborate in any other way i would also be pleased.

thanks  

Original comment by Stnd....@gmail.com on 8 Jan 2012 at 4:13

[GoogleCodeExporter]

Thanks fixbox, r67 is indeed the revision that caused this issue. Bug is now 
fixed and checked in as of r77.

Original comment by cheff...@tacnetsol.com on 8 Jan 2012 at 6:21

• Changed state: Fixed

[GoogleCodeExporter]

Thank you. r78 is working.

Original comment by fixbox2...@gmail.com on 8 Jan 2012 at 9:51

[GoogleCodeExporter]

try reaver -i mon0 -b AP_MAC -vv -p 9998 and now it should start from there.. 
you lose a few keys in the process but at least it bypasses the loop... i do 
not know if this will recover a key i am currently testing this! at least i 
aint stuck at 90.9% anymore

Original comment by phyra...@gmail.com on 24 Feb 2013 at 6:33