PIN Found but Incorrect.

[GoogleCodeExporter]

>What steps will reproduce the problem?

1. Initialize Reaver normally.
2. Press the 'WPS' Button (hard or soft) on the AP

>What is the expected output? What do you see instead?

Expected nothing.
Program Returns:

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

Cracked PIN is not the AP PIN number, the PIN that was being tested when the AP 
WPS button was pressed, would make sense, as the AP allows a different type of 
PIN check when pressing its WPS button, either on the device itself or the 
admin webpage, the admin webpage of the AP tested lists its own PIN, which is 
different from the cracked PIN in this case.

>What version of the product are you using? On what operating system?

--Reaver1.0
--Ubuntu11.10
--WAG120N AP

>Please provide any additional information below.

I'm not sure exactly how this program works, though I can assume the engine for 
cracking uses the NACK to determine failure, if there is no NACK at the end of 
the handshake does the program assume success and stop with a PIN it thinks is 
correct?

Original issue reported on code.google.com by Raanan.A...@gmail.com on 30 Dec 2011 at 7:38

[GoogleCodeExporter]

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

Original comment by rtstanif...@gmail.com 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 Raanan.A...@gmail.com 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 cheff...@tacnetsol.com 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 Raanan.A...@gmail.com 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 cheff...@tacnetsol.com 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 Raanan.A...@gmail.com 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 Raanan.A...@gmail.com 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 rtstanif...@gmail.com on 30 Dec 2011 at 5:46

[GoogleCodeExporter]

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

Original comment by cheff...@tacnetsol.com 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 rtstanif...@gmail.com on 30 Dec 2011 at 8:16

[GoogleCodeExporter]

Here it is.

Original comment by rtstanif...@gmail.com 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 cheff...@tacnetsol.com 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 rtstanif...@gmail.com 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 rtstanif...@gmail.com 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 cheff...@tacnetsol.com on 31 Dec 2011 at 1:30

[GoogleCodeExporter]

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

Original comment by rtstanif...@gmail.com 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 cheff...@tacnetsol.com 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 rtstanif...@gmail.com 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 aaanorma...@gmail.com 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 cheff...@tacnetsol.com 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 Raanan.A...@gmail.com 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 cheff...@tacnetsol.com 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 Raanan.A...@gmail.com 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 cheff...@tacnetsol.com 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 bdee...@gmail.com 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 jeanbar...@gmail.com 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 jeanbar...@gmail.com 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 cheff...@tacnetsol.com 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 b1957...@nwldx.com 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 cheff...@tacnetsol.com 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 bdee...@gmail.com on 4 Jan 2012 at 3:12

[GoogleCodeExporter]

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

Original comment by cheff...@tacnetsol.com 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 bdee...@gmail.com 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 bdee...@gmail.com 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 cheff...@tacnetsol.com 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 b1957...@nwldx.com 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 cheff...@tacnetsol.com 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 bdee...@gmail.com 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 cheff...@tacnetsol.com 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 b1957...@nwldx.com 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 bdee...@gmail.com 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 cheff...@tacnetsol.com on 5 Jan 2012 at 1:20