PIN Found but Incorrect. about reaver-wps

[GoogleCodeExporter]

You don't have to press the WPS button for this attack. Otherwise it would be 
worthless.

Original comment by [email protected] on 30 Dec 2011 at 9:57

[GoogleCodeExporter]

Ok, thanks...

So i'm right to assume that 'accepted' PIN by the program is directly related 
to starting the WPS PIN registration on the AP? OK, as long as this is not a 
bug with directly affects actual PIN cracking...

Original comment by [email protected] on 30 Dec 2011 at 10:19

[GoogleCodeExporter]

You don't have to press the WPS button, but the resulting pin should be the 
correct pin listed as the AP's pin in the administrative interface. 

What is the pin of your AP? Are the first four digits correct? Did Reaver print 
out your WPA key?

Original comment by [email protected] on 30 Dec 2011 at 12:30

[GoogleCodeExporter]

Reaver printed: 

[+] Trying pin 42616139
[+] Key cracked in 2155 seconds
[+] WPS PIN: '42616139'

And nothing else, immediately after the WPS button was pressed

The button i'm talking about is the 'refresh' icon in the screenshot I've 
attached, there you can see the passphrase and pin number.

However, I am using a Cisco Linksys WUSB100v2 usb adapter which supports WPS, 
perhaps the key is somehow the device WPS Pin? 

I am using wpa_gui supported by wpa_supplicant to initiate WPS connections on 
my computer.

Thanks.

Original comment by [email protected] on 30 Dec 2011 at 3:03

Attachments:

• [Screenshot - 30122011 - 17:00:59.png](https://storage.googleapis.com/google-code-attachments/reaver-wps/issue-16/comment-4/Screenshot - 30122011 - 17:00:59.png)

[GoogleCodeExporter]

WPS has different modes of operation. You are confusing the registrar 
capability, which is what Reaver exploits, with the push button functionality. 

Do not push the WPS button. Do not use a WPS-capable wireless adapter. Do not 
use wpa_supplicant. Just run reaver against the AP.

Original comment by [email protected] on 30 Dec 2011 at 3:07

[GoogleCodeExporter]

of course I understand that nothing needs to be done on the AP being attacked 
to retrieve the PIN/Passphrase!

I'm just bringing this to your attention, I assume the AP sent a packet that 
the program wasn't expecting or something and that caused the program to think 
it had the right PIN, obviously without it returning the Passphrase and the PIN 
number being way off that its some kind of issue with the packet that the 
program recieved from the AP.

Usually WPS PINs attempt to associate the client with the AP and then validate 
returning the Passphrase, may be the association took place differently than 
the program expected it causing it to return a positive boolean.

Original comment by [email protected] on 30 Dec 2011 at 3:25

[GoogleCodeExporter]

Thanks for this program, i'm excited about it and i'm going to test it on my 
cisco APs at the office next year,

cheers, have a good new years.

Original comment by [email protected] on 30 Dec 2011 at 3:26

[GoogleCodeExporter]

I'm experiencing this on one particular router, which is a D-Link according to 
the MAC vendor prefix.

Reaver cracks the pin after the first attempt. The pin being different every 
try of course.

[+] Waiting for beacon from **:**:**:**:**:**
[+] Switching mon0 to channel 1
[+] Associated with **:**:**:**:**:** (ESSID: Pretty Fly for a Wi-Fi)
[+] Trying pin 76609923
[+] Key cracked in 6 seconds
[+] WPS PIN: '76609923'

Original comment by [email protected] on 30 Dec 2011 at 5:46

[GoogleCodeExporter]

rtstaniforth, can you provide a pcap of the WPS exchange?

Original comment by [email protected] on 30 Dec 2011 at 6:22

[GoogleCodeExporter]

Sorry, I've only just seen your last comment. That router has stopped 
broadcasting for some reason. I'll get you a capture as soon as I see it come 
back.

Original comment by [email protected] on 30 Dec 2011 at 8:16

[GoogleCodeExporter]

Here it is.

Original comment by [email protected] on 30 Dec 2011 at 10:25

Attachments:

• false-positive.pcap

[GoogleCodeExporter]

Are you sure this is a full capture of the exchange? All I see is the M1 
message (beginning of the WPS exchange) and nothing else after that.

Original comment by [email protected] on 31 Dec 2011 at 2:03

[GoogleCodeExporter]

Yes, that's it all. If you want, I can capture with tcpdump instead. I captured 
that one with Wireshark.

Original comment by [email protected] on 31 Dec 2011 at 9:56

[GoogleCodeExporter]

Here is the capture using tcpdump instead. Also the output from Reaver again.

[+] Waiting for beacon from 84:C9:B2:73:B4:13
[+] Switching mon0 to channel 1
[+] Associated with 84:C9:B2:73:B4:13 (ESSID: Pretty Fly for a Wi-Fi)
[+] Trying pin 45519253
[+] Key cracked in 1 seconds
[+] WPS PIN: '45519253'

Original comment by [email protected] on 31 Dec 2011 at 10:27

Attachments:

• tcpdump-capture.pcap

[GoogleCodeExporter]

Not sure off the top of my head what might be causing this. I'm going to be out 
of town for the holiday weekend, I'll take a closer look at the pcap when I get 
back. Thanks!

Original comment by [email protected] on 31 Dec 2011 at 1:30

[GoogleCodeExporter]

No problem, thanks for all the work you've done.

Original comment by [email protected] on 31 Dec 2011 at 1:36

[GoogleCodeExporter]

I see a couple of EAP packets in the output you provided, but not enough for a 
full WPS exchange. Can you run tcpdump with '-w outfile.pcap' to get a full 
pcap? The text output doesn't provide enough information about the contents of 
the EAP packets to really see what is being exchanged between Reaver and the AP.

Original comment by [email protected] on 2 Jan 2012 at 3:10

• Changed state: Accepted

[GoogleCodeExporter]

Here you go. Also got a few time-outs this time.


[+] Switching mon0 to channel 1
[+] Waiting for beacon from 84:C9:B2:73:B4:13
[+] Switching mon0 to channel 1
[+] Associated with 84:C9:B2:73:B4:13 (ESSID: Pretty Fly for a Wi-Fi)
[+] Trying pin 22012418
[!] WARNING: Receive timeout occurred
[+] Trying pin 22012418
[!] WARNING: Receive timeout occurred
[+] Trying pin 22012418
[+] Key cracked in 16 seconds
[+] WPS PIN: '22012418'

Original comment by [email protected] on 2 Jan 2012 at 3:40

Attachments:

• output.pcap

[GoogleCodeExporter]

Hi

I have the same thing as above, only one AP
pentagram

After a few seconds the PIN found (different each time), but can not find the 
WPA

[+] Waiting for beacon from C8:3A:35:18:XX:XX
[+] Switching mon0 to channel 6
[+] Associated with C8:3A:35:18:XX:XX (ESSID: PENTAGRAM)
[+] Trying pin 79366168
[+] Key cracked in 2 seconds
[+] WPS PIN: '79366168'

[+] Waiting for beacon from C8:3A:35:18:XX:XX
[+] Switching mon0 to channel 6
[+] Associated with C8:3A:35:18:XX:XX (ESSID: PENTAGRAM)
[+] Trying pin 40391847
[+] Key cracked in 0 seconds
[+] WPS PIN: '40391847'

[+] Waiting for beacon from C8:3A:35:18:XX:XX
[+] Switching mon0 to channel 6
[+] Associated with C8:3A:35:18:XX:XX (ESSID: PENTAGRAM)
[+] Trying pin 68229825
[+] Key cracked in 6 seconds
[+] WPS PIN: '68229825'

Original comment by [email protected] on 2 Jan 2012 at 7:00

Attachments:

• pentagram-01.cap
• pentagram-02.cap
• pentagram-03.cap

[GoogleCodeExporter]

May have found the source of the bug. Try the latest SVN code and let me know 
what happens.

Original comment by [email protected] on 3 Jan 2012 at 7:09

[GoogleCodeExporter]

the latest SVN update does not configure, i'm missing a Sqlite package? what 
was the name of the package?

Original comment by [email protected] on 3 Jan 2012 at 7:35

[GoogleCodeExporter]

Yes, the sqlite dev package is required as of version 1.3. On Ubuntu/Debian the 
package is called libsqlite3-dev.

Original comment by [email protected] on 3 Jan 2012 at 7:41

[GoogleCodeExporter]

thanks configure succeeded, one other question: (if your prepared to answer)

the last 4 digits are always locked in a particular sequence like 5810 - 5819, 
dependent it seems on the type of WPA used, but after working for about 5 hours 
it hasn't changed that, it randomizes the first 4 digits... 

the last 4 digits remain wrong, and i know my PIN so, I can see that its never 
going to get it... is this my particular AP and its method?

Original comment by [email protected] on 3 Jan 2012 at 7:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Raanan, that is expected behavior. As soon as the first 4 digits are cracked, 
Reaver will start working on the last 4 digits (the very last digit is a 
checksum of the first 7 digits, which is why it always changes).

So I take it that since the pins are changing I assume that the changes fixed 
your issue?

Original comment by [email protected] on 3 Jan 2012 at 8:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Still seeing the wrong pin being returned instantly with R52, hope this helps:

[+] Waiting for beacon from 14:D6:4D:XX:XX:XX
[+] Switching mon0 to channel 1
[+] Associated with 14:D6:4D:XX:XX:XX (ESSID: TALKTALK-4FXXX)
[+] Trying pin 68974497
[+] Key cracked in 2 seconds
[+] WPS PIN: '68974497'
[+] Nothing done, nothing to save.

Here's the pcap: http://pastie.org/private/j3azkrttnniqofvfmak7a

Original comment by [email protected] on 3 Jan 2012 at 10:26

[GoogleCodeExporter]

Hello, I and many people I know are having the exact same problem that is 
described in Comment 27 when targeting a specific wireless router model. 
Association works, then whatever PIN is entered returns a positive result but 
weaver fails to get the wpa key. Also, even when the PIN provided with the -p 
command is known to be the correct one, weaver stops without even giving the 
WPA key, just like in comment 27.
Do you guys know what could be causing this? Cheers !

Original comment by [email protected] on 3 Jan 2012 at 11:29

[GoogleCodeExporter]

(on a side note: weaver works perfectly with other router models while running 
the same configuration)

Original comment by [email protected] on 3 Jan 2012 at 11:31

[GoogleCodeExporter]

I suspect there might be a bug in the exchange loop that is causing it to 
return a false positive result, but it is not obvious why this might happen, 
nor do I know why it would only affect one model router. What is the router 
model? It would be much easier to debug if I had one. :)

Original comment by [email protected] on 4 Jan 2012 at 1:56

[GoogleCodeExporter]

Related to comments 28, 29 and 30: The AP Jean is talking about is the Livebox 
2. The router inside uses drivers Sagem FAST3XXX_6814AE I believe. So I'd guess 
the router is one of the Sagem F@st 3xxx line.

Despite my other problems (which occur against various AP models, so it's 
iwlagn driver issue), I don't have that bug when trying to crack a Livebox 2. 
I've never ever seen Reaver return a PIN code; currently it just never finds 
the right one even if I provide it through --pin. Am saying this in case it is 
of any use to know that the bug described above is not occurring for all PCs 
running Reaver against a Livebox.

Original comment by [email protected] on 4 Jan 2012 at 2:31

[GoogleCodeExporter]

b195, are you using release version 1.3, or the latest SVN code? 1.3 had a bug 
in the --pin option.\

I'll see if I can get a hold of one of the Livebox's to test.

Original comment by [email protected] on 4 Jan 2012 at 2:48

[GoogleCodeExporter]

The AP I'm having issues with is the D-Link DSL 2680 (or 2780 I'm not sure off 
hand) and I've tried with 1.3 and the latest SVN code.

Original comment by [email protected] on 4 Jan 2012 at 3:12

[GoogleCodeExporter]

And you are having the same false positive pin issues bdeesal?

Original comment by [email protected] on 4 Jan 2012 at 3:26

[GoogleCodeExporter]

Yep, it returns the incorrect pin within a couple of seconds without the PSK 
each time Reaver is run.

I've include the output and pcap in comment 27, let me know if you want me to 
try anything else... 

Original comment by [email protected] on 4 Jan 2012 at 4:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

A little update, I'm running the latest SVN with the same AP and am getting 
another issue now, it's not instantly returning the incorrect pin.

I now get:

[+] Waiting for beacon from 14:D6:XX:XX:XX:XX
[+] Switching mon0 to channel 1
[!] WARNING: Failed to associate with 14:D6:XX:XX:XX:XX (ESSID: TALKTALK-4FFXXX)

Pastebin of the pcap: http://pastie.org/private/45hvnb4rmo6mehrr0qcifw

This looks of interest.

19:12:54.138371 1.0 Mb/s [bit 15] DeAuthentication (00:c0:xx:xx:xx:xx (oui 
Unknown)): Deauthenticated because sending station is leaving (or has left) 
IBSS or ESS

I have strong signal or -25 or so.

Using Backtrack 5R1 and a AWUs036 (Realtek RTL8187L).

Original comment by [email protected] on 5 Jan 2012 at 12:29

[GoogleCodeExporter]

There is a bug in Reaver that I'm working where certian APs (I've only found 
one myself so far) don't like the association packets that Reaver sends. 

Can you associate with aireplay-ng? I added an option (--no-associate) in r61 
that tells Reaver to not send association packets, allowing you to use an 
external application like aireplay-ng to do the association for your MAC. See 
if you can associate with aireplay-ng and run the attack then.

Original comment by [email protected] on 5 Jan 2012 at 12:43

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@Comment 32:
I was using Reaver 1.3 r48. But then I tested with both r56 and r58 and 
association problem is back full force. >_<

I noticed that using r58, each time Reaver processes to the next PIN code, 
airodump-ng displays a "Decloak: XX:XX:XX:XX:XX:XX" where XX thing is the AP 
MAC address.
I had to connect to the Livebox 2 AP as a legit client to get around the 
association problem, hoping to test Reaver's issues with PIN codes. Got a lot 
of timeouts though and the right PIN code 12345670 gets processed as any other 
wrong PIN code. It's kind of the opposite bug of the issue we're posting in, 
come to think of it, so I should just shut up :p

Finally if you intend to get a hold of a Livebox, be aware that they're not all 
using a Sagem F@st 3202 router. Some, probably a minority nowadays, use a 
Thomson one.

Quote from here: http://fr.wikipedia.org/wiki/Livebox
"La Livebox résidentielle est de couleur blanche, et fabriquée par Sagem et 
Thomson, modèles existants : Sagem F@st 3202 et Inventel DV4210-WA"

What a mess it seems debugging this, good luck :)


EDIT @Comment 41: Oh good, I'll test with r61 and --no-associate, as Fakeauth 
attack does work. Maybe that'll propel me right onto Issue 16 :)

Original comment by [email protected] on 5 Jan 2012 at 12:54

[GoogleCodeExporter]

Yeah, unfortunately (or sometimes fortunately) a lot of vendors just rebrand 
other routers, but it's hard to know which one without actually buying the 
device. :P

So you had no association problems with r48, but you do with r56/r58?

Original comment by [email protected] on 5 Jan 2012 at 12:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I managed to associate using aireplay:

# aireplay-ng -1 0 -a 14:D6:XX:XX:XX:XX -h 00:c0:XX:XX:XX:XX mon0
19:57:02  Waiting for beacon frame (BSSID: 14:D6:XX:XX:XX:XX) on channel 1

19:57:02  Sending Authentication Request (Open System) [ACK]
19:57:02  Authentication successful
19:57:02  Sending Association Request [ACK]
19:57:02  Association successful :-) (AID: 1)

Now when I run Reaver with --no-associate I get:

[+] Waiting for beacon from 14:D6:XX:XX:XX:XX
[+] Associated with 14:D6:4D:4F:F6:F7 (ESSID: TALKTALK-4FXXXX)

... I'm not seeing anything else yet and tcpdump isn't showing me anything bar 
the beacons. I'll leave it going for a while longer and see if anything happens.

Oh and I also tried BT4, no difference (worth a try!).

Original comment by [email protected] on 5 Jan 2012 at 1:04

[GoogleCodeExporter]

bdeesal, can you indulge me and also add the --ignore-locks option when running 
Reaver and see if anything starts happening then?

Original comment by [email protected] on 5 Jan 2012 at 1:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@Comment 44:

Yes. But I'll be re-testing r48 because that seems odd and I don't trust that 
ol' scurvy iwlagn, he's not being a reliable pal with Reaver. I'll confirm or 
infirm this when I'll be back from testing r61 and getting LB 2 beacons in a 
pcap.

PS: I believe Livebox 2 is 100% Sagem, that's why I keep putting the "2" all 
around the place :p You can't be wrong if you get that one.

Original comment by [email protected] on 5 Jan 2012 at 1:10

[GoogleCodeExporter]

Sorry, I forgot to tag -vv onto the end, what is actually happening is (tried 
with --ignore-locks as well): 

[+] Trying pin 12345670
[!] WARNING: Receive timeout occurred
[!] WARNING: Receive timeout occurred

Nothing of interesting in tcpdump.

Original comment by [email protected] on 5 Jan 2012 at 1:12

[GoogleCodeExporter]

@b1957: Yeah, it's looking like most of the issues now are either AP-specific 
bugs or driver issues. Hopefully Reaver will be getting integrated into the 
aircrack-ng suite soon, and therefore using their injection libraries and the 
driver issues at least will go away. :P

@bdeesal: Odd...you should at least seeing some eap/eapol packets going out, 
although --no-associate was just added earlier tonight and is not thoroughly 
tested, so could be a bug there.

Original comment by [email protected] on 5 Jan 2012 at 1:20

[GoogleCodeExporter]

Great, I was almost considering buying some USB wifi card known to be 
compatible with Reaver, just so I can sort out what's due to iwlagn and what's 
due to the LB2. If aircrack-ng does it for me, my wallet will be grateful =)

So r48 does have association failures, a lot of it. r61 works with 
--no-associate and Fakeauth, except I only get timeouts and out of order 
packets. The PIN is never tested, I think it stops at M3 whereas with previous 
versions, when association worked through being a legit AP client, the PIN 
failed at M4 (even the correct one) and a "Failure" packet was logged right 
after.

This is a Wireshark pcap summary but I also have the fully detailed one if you 
need it. (Contains M1/M2/M3 packets, out of order stuff and is stripped of 
beacons)

Original comment by [email protected] on 5 Jan 2012 at 4:13

Attachments:

• Fail-summary.txt

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

^By the way, RXQ is 100, PWR is about -60 at worst and I'm literally swamped in 
beacons.

I used command:
reaver -i mon0 -b XX:XX:XX:XX:XX:XX -c 6 -vv -A

And Fakeauth, where YY mac address is the real one and not a fake:
aireplay-ng mon0 --fakeauth 600 -e Livebox-XXXX -a XX:XX:XX:XX:XX:XX -h 
YY:YY:YY:YY:YY:YY

Correct PIN is 12345670.

Though I'm thinking this belongs in another issue. For clarity, do you wish 
that I create a new one or is it tied to issue 16 in some twisted way that only 
makes sense for programmers? :)

Original comment by [email protected] on 5 Jan 2012 at 4:38

[GoogleCodeExporter]

I think the current issue is definitely different from the original. But before 
creating a new issue I really would like to get it working to verify that the 
correct pin does in fact work. 

Can you provide an actual pcap? You can sanitize it and/or email it to me 
directly if that's a concern. It would really help to be able to look at the 
raw traffic.

BTW, that's an interesting pin. Is that the one that the AP had set by default? 
I've heard reports of multiple devices having that pin hard coded, so Reaver 
now checks 12345670 first. ;)

Original comment by [email protected] on 5 Jan 2012 at 5:04

[GoogleCodeExporter]

Hi!

Sorry for the delay. I just tried getting a pcap with Reaver r76 (or 75, forgot 
which), unfortunately it just doesn't run anymore. He talks about bad 
fragmentation or something and doesn't even get to send a packet, the program 
returns right away.

Walsh doesn't work even with a pcap from the Livebox 2 containing beacons and 
data (no active client, just me associated through Fakeauth).

I think it would not be a good idea that I continue to give you feedback with 
my current card and driver, sounds like it could only make you lose time. I 
should either find a proper USB wifi card or wait until Reaver uses aircrack to 
provide driver compatibility. Any idea about when this will be implemented?

And yes 12345670 is the default PIN for my AP, which seems to be the most 
widespread in France by far. I heard 12345670 is also the default for "Bbox 2" 
from Belgacom. I wonder how long it will take before ISPs catch up :)

Original comment by [email protected] on 6 Jan 2012 at 10:16

[GoogleCodeExporter]

Yay, I finally reach this bug.

Using Reaver r78 I am now able to have this very bug. I have pcap files of both 
a wrong PIN and a right PIN being tested, but considering comments 18 and 19 do 
provide pcaps, I don't know if you need any more. (Plus I don't know how to 
sanitize a pcap with all that hexadecimal mess inside)


Wrong PIN:
# reaver -vv -A -b XX:XX:XX:XX:XX:XX -i mon0 -p 00010009 

Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<[email protected]>

[+] Waiting for beacon from XX:XX:XX:XX:XX:XX
[+] Switching mon0 to channel 6
[+] Associated with XX:XX:XX:XX:XX:XX (ESSID: Livebox-XXXX)
[+] Trying pin 00010009
[+] Sending EAPOL START request
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[!] WARNING: Receive timeout occurred
[+] Trying pin 00010009
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending M2 message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Sending M2D message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[+] Key cracked in 17 seconds
[+] WPS PIN: '00010009'
[+] Nothing done, nothing to save.




Right PIN:
# reaver -vv -A -b XX:XX:XX:XX:XX:XX -i mon0

Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<[email protected]>

[+] Waiting for beacon from XX:XX:XX:XX:XX:XX
[+] Switching mon0 to channel 6
[+] Associated with XX:XX:XX:XX:XX:XX (ESSID: Livebox-XXXX)
[+] Trying pin 12345670
[+] Sending EAPOL START request
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[!] WARNING: Receive timeout occurred
[+] Trying pin 12345670
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending identity response
[+] Sending M2 message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Sending M2D message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[+] Key cracked in 16 seconds
[+] WPS PIN: '12345670'
[+] Nothing done, nothing to save.

Original comment by [email protected] on 9 Jan 2012 at 12:24

[GoogleCodeExporter]

Issue 112 has been merged into this issue.

Original comment by [email protected] on 9 Jan 2012 at 2:28

[GoogleCodeExporter]

After looking over the pcaps, this issue appears to manifest itself when there 
are connectivity issues between Reaver and the AP (many have fairly low signal 
levels). Probably Reaver is getting into an unexpected state when the 
transactions don't complete properly and is incorrectly interpreting this as a 
success. Working on it now.

Original comment by [email protected] on 9 Jan 2012 at 2:36

• Changed state: Started

[GoogleCodeExporter]

OK, I haven't been able to reproduce this bug myself, but I think I've located 
the logic bug that was causing the issue. Can anyone verify that this issue is 
fixed as of r80?

Original comment by [email protected] on 9 Jan 2012 at 3:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Unfortunately I get the same result. Although when I got the signal up a bit it 
looks like a few tries are going through. Only on the first run did it return 
12345670 immediately. Later it ran a few cycles - although also had lots of 
retries (50db).

Original comment by [email protected] on 9 Jan 2012 at 5:07

Attachments:

• r80.pcap

[GoogleCodeExporter]

There is only one place in the code during the cracking process where the 
status is marked as complete; I've added additional sanity checking to this 
section of code which will hopefully prevent these false positives (r82).

Original comment by [email protected] on 9 Jan 2012 at 5:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi again.

Bug fixed for me. Although the right pin still doesn't work, at least there's 
no false positive anymore AND Walsh works good.

Regarding connectivity issues, airodump says I have -60 PWR and 100 RXQ. I do 
get timeouts and out of order packets using Reaver, I just don't know why 
considering airodump's numbers.

In case this is of any relevance, I'll throw the new output from Reaver r82 and 
some compile time warnings:

Warnings:
iwlib.c: In function 'iw_enum_devices':
iwlib.c:254: warning: ignoring return value of 'fgets', declared with attribute 
warn_unused_result
iwlib.c:255: warning: ignoring return value of 'fgets', declared with attribute 
warn_unused_result
iwlib.c: In function 'iw_get_kernel_we_version':
iwlib.c:337: warning: ignoring return value of 'fgets', declared with attribute 
warn_unused_result
iwlib.c:353: warning: ignoring return value of 'fgets', declared with attribute 
warn_unused_result


Reaver output is attached below and it's the same whether the PIN used is the 
right one or not.

Original comment by [email protected] on 9 Jan 2012 at 6:00

[GoogleCodeExporter]

Attachment here (oh boy do I suck using Google Code)

Original comment by [email protected] on 9 Jan 2012 at 6:05

Attachments:

• Reaver_output.txt

[GoogleCodeExporter]

Just a little update from me, I was initially getting the false pin returned 
instantly with no PSK, and after a particular revision it turned into timeouts. 

I've tried r82 (still using Backtrack 5R1 and a AWUS036 (Realtek RTL8187L).

It won't associate so I'm using aireplay-ng mon0 --fakeauth 600 -e 
TALKTALK-XXXX -a XX:XX:XX:XX:XX:XX -h YY:YY:YY:YY:YY:YY, then reaver -i mon0 -b 
bssid -vv -A.

[+] Waiting for beacon from 14:D6:XXX:XX:XX:XX
[+] Switching mon0 to channel 2
[+] Switching mon0 to channel 1
[+] Associated with 14:D6:XXX:XX:XX:X (ESSID: TALKTALK-4FXXXX)
[+] Trying pin 12345670
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request

My capture from Wireshark doesn't show much of interest either just:

17:25:20.085645 EAPOL start (1) v1, len 0
17:25:20.086788 558682821us tsft 1.0 Mb/s 2412 MHz 11b -24dB signal antenna 1 
[bit 14] Acknowledgment RA:00:XX:XX:XX:XX:XX (oui Unknown) 
17:25:20.086805 1.0 Mb/s [bit 15] EAPOL start (1) v1, len 0
17:25:25.101291 EAPOL start (1) v1, len 0
17:25:25.102080 1.0 Mb/s [bit 15] EAPOL start (1) v1, len 0
17:25:30.118981 EAPOL start (1) v1, len 0
17:25:30.120098 568716924us tsft 1.0 Mb/s 2412 MHz 11b -24dB signal antenna 1 
[bit 14] Acknowledgment RA:00:XX:XX:XX:XX:XX (oui Unknown) 
17:25:30.120617 1.0 Mb/s [bit 15] EAPOL start (1) v1, len 0

If this should be somewhere else, please let me know... 

Original comment by [email protected] on 9 Jan 2012 at 6:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hello cheff ! If you had to take a wild guess, what could be the cause of this? 
(by this, I mean the right PIN not working)? Because this is not an isolated 
error. It happens with everybody on the same router model. Have you ever 
encountered anything like this before? b1957, do you think you could provide a 
cap showing this behaviour? Cheers

Original comment by [email protected] on 9 Jan 2012 at 6:14

[GoogleCodeExporter]

bdeesal, this looks like a separate issue. But just a couple quick questions:

1) Were you able to associate to this same AP before?
2) What kind of signal strength do you have with the target AP?
3) Are you spoofing your MAC address?

Original comment by [email protected] on 9 Jan 2012 at 6:18

[GoogleCodeExporter]

@jean: Based on bdeesal's output above, Reaver can't test the pin because it 
can't establish a full WPS session with the target AP. I most commonly see the 
AP's signal strength is low or there is a lot of interference. There is also a 
known bug where reaver doesn't play nice with MAC spoofing, so if you are 
spoofing your MAC address you'll see these types of issues as well; in either 
case, they I don't think they're related to the original issue here.

Original comment by [email protected] on 9 Jan 2012 at 6:22

[GoogleCodeExporter]

Cheff, do you want me to start a new issue- or is there another issue that 
looks similar? The only reason I put it here was because my issue seemed to 
change as you updated reaver.

To answer your questions:

1) I was initially, but I think the release about 4 days ago broke this, see 
comments 27 and 38 from me, output included in them
2) Very strong, -35 or so
3) No

Original comment by [email protected] on 9 Jan 2012 at 6:41

[GoogleCodeExporter]

Oh... and to add, I forgot to shut the Reaver session down and came back to 
this, unfortunately I had close Wireshark, but might help:

[+] Sending EAPOL START request
[+] Sending identity response
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Sending WSC ACK
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Got packet type 21 (0x15), but haven't broken the first half of 
the pin yet!
[+] Sending identity response
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Got packet type 19 (0x13), but haven't broken the first half of 
the pin yet!
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Sending M6 message
[!] WARNING: Receive timeout occurred
[+] Trying pin 22925671
[+] Sending EAPOL START request
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Sending identity response
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Sending WSC ACK
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Got packet type 21 (0x15), but haven't broken the first half of 
the pin yet!
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Got packet type 19 (0x13), but haven't broken the first half of 
the pin yet!

Let me know if you want me to try anything else, tempted to leave it going 
overnight.

Original comment by [email protected] on 9 Jan 2012 at 6:42

[GoogleCodeExporter]

bdessal, there have been a lot of changes in the past few days, so it may be 
something not related to this issue. It definitely looks like a different 
problem though, please open a new issue for it (I'll also need a pcap to 
further debug the problem). Thanks!

Original comment by [email protected] on 9 Jan 2012 at 6:48

[GoogleCodeExporter]

@Comment 74:

I can't sanitize a pcap properly but I can provide a TCPdump similar to what's 
seen in comment 70. Not sure if it would still be any useful to you Craig?

If there's a way to dump more info in clear text so I can edit it, I'm okay as 
well, just let me know :)

Original comment by [email protected] on 10 Jan 2012 at 10:53

[GoogleCodeExporter]

OK, it looks like the false positive bug has been fixed. A new issue (issue 
117) has been opened to investigate the repeated timeout messages.

Original comment by [email protected] on 10 Jan 2012 at 6:27

• Changed state: Fixed