wrong PSK about reaver-wps

[GoogleCodeExporter]

Hmmm, that is odd. What access point are you testing against? Since you know 
the pin, you can try using wpa_supplicant to become a registrar and see if that 
works.

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

[GoogleCodeExporter]

Found this in the wpa_supplication source code:

"By default, the AP that is started in not configured state will generate a 
random PSK and move to configured state when the first registration protocol 
run is completed successfully."

I'm guessing that's what is happening here. There is an option that can be set 
that supposedly will tell the AP to not generate a random PSK; I'm adding that 
option into Reaver's WPS packets now.

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

• Changed state: Started

[GoogleCodeExporter]

Just made a code check in that should disable this feature. See if that fixes 
things.

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

[GoogleCodeExporter]

Any word on if this fixed your problem?

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

[GoogleCodeExporter]

I'm sorry, I was away for NYE.

Just checked out the svn source, and the issues is not fixed.
I'm still not sure tho if it's the issue with the reaver or my AP 
since I tested it only on my cheap Tenda wifi router. 
I'll soon have some free time, and will look into it with more care.

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

[GoogleCodeExporter]

No worries, just got back myself. 

Something to try would be to use wpa_supplicant and see if it gives you the 
same results (I think in verbose mode it should give you enough info to 
determine this).

It could be that the AP always generates a new PSK regardless, it wouldn't 
surprise me. If this is the case, one thing you can do though is once you have 
the WPS pin, you can reconfigure the AP with any PSK of your choosing using 
wpa_supplicant. Certainly not ideal as it will DoS other wireless users, but it 
may still be useful.

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

[GoogleCodeExporter]

Nickolic, have you been able to re-test this?

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

[GoogleCodeExporter]

Same problem over here on ath5k: One of my APs each time returns a different 
WPA key (using R55).
[+] WPS PIN: '19380247'
[+] WPA PSK: 'ddf522a4f84e27683958df41c082b69a0c43e370a6f610a1f4dd744463c65b73'

[+] WPS PIN: '19380247'
[+] WPA PSK: 'de5934e6149bbb2b5c117f2f836001e1a1928037081ec40c837ad5a1a1af44fe'

(Haven't tried reconfiguring the AP using wpa_supplicant yet)

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

[GoogleCodeExporter]

What make/model is the AP? This sounds like an AP-specific thing. 
wpa_supplicant should work for reconfiguration though.

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

[GoogleCodeExporter]

What make/model is the AP? This sounds like an AP-specific thing. 
wpa_supplicant should work for reconfiguration though.

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

[GoogleCodeExporter]

I too am having this issue,

entire sting bellow:

# reaver -i wlan0 -vv --pin=53363480 -b c0:3f:0e:bb:23:8e

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

[+] Waiting for beacon from C0:3F:0E:BB:23:8E
[+] Switching wlan0 to channel 11
[+] Associated with C0:3F:0E:BB:23:8E (ESSID: Orange)
[+] Trying pin 53363480
[+] Key cracked in 4 seconds
[+] WPS PIN: '53363480'
[+] WPA PSK: 'VM1AsogutopuYnoke7kAJ'
[+] AP SSID: 'NTGR_T'
[+] Nothing done, nothing to save.

Used Components/Software

Reaver v1.3
Using Backtrack 5 R1
Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
Netgear Router WGR614v10

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

[GoogleCodeExporter]

The AP Model that has this issue: Sweeex LW150 

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

[GoogleCodeExporter]

Unfortunately, AFAIK there isn't anything Reaver can do to stop this behavior, 
short of the code change that has already been made. If the AP is ignoring the 
"do not generate new key" option, I can't control that (as much as I'd like 
to... :).

One option (which might not be a valid option depending on your situation) is 
to change the WPA key to something of your choosing; this can be done using 
wpa_supplicant/wpa_cli. You need to know the AP's WPS pin, but of course you 
already have that. Obviously this will DoS any legitimate clients on the 
wireless network though.

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

[GoogleCodeExporter]

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

• Changed state: WontFix

[GoogleCodeExporter]

Would be really nice to have a wpa_supplicant example documented within the 
tool. I, for one, am struggling to understand how this works.

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

[GoogleCodeExporter]

i'm not sure what changed, but it successfully recovers the passphrase on
my ap now

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

[GoogleCodeExporter]

Well, if I read this thread correctly you were using 1.1 at start and you 
probably got the 1.3 version now. I was using 1.3 from the very begining soI 
think it's a different usecase for me

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

[GoogleCodeExporter]

I had the exact same issue. Reaver would return a random string of 64 hex 
digits each time it matched the pin. The target AP is a new TP-Link TL-WR1043ND 
I had just set up for testing. I had never established a wireless connection to 
the AP before my initial testing. Once I made a connection to the device with 
my iPad it started returning the configured PSK rather than the random strings.

Original comment by [email protected] on 20 Jan 2012 at 2:58

[GoogleCodeExporter]

Hmm interesting, i'll check that out. Btw, when you refer to establishing a 
connection, do you mean by PSK or by PIN input ?

Original comment by [email protected] on 20 Jan 2012 at 6:33

[GoogleCodeExporter]

PSK

Original comment by [email protected] on 20 Jan 2012 at 11:44

[GoogleCodeExporter]

Correction - I found that establishing the wireless connection was not the 
trigger that caused the AP to stop returning random 64 hex character keys when 
reaver matched the PIN. After resetting my router back to factory defaults (and 
the random key problem came back) I found that changing the encryption field in 
my wireless security settings from "Automatic(Recommended)" to "AES" is the 
trigger. After this change reaver will consistently return my configured PSK. 
In fact I haven't been able to find any AP configuration screen changes that 
will cause the AP to return the random keys again. I had to reset the device to 
factory defaults and set it up with the "Easy Setup Assistant" program (not the 
browser interface) in order to get the random keys back. Unfortunately this 
behavior is probably unique to the WR1043ND AP.

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

[GoogleCodeExporter]

I'm having the same issue, reaver detects the correct PIN but it retrieves a 
different PSK every time, also displays an incorrect AP SSID along with it 
(wrong SSID doesn't change, it's always the same but not the correct one).

Original comment by [email protected] on 23 Jan 2012 at 12:40

[GoogleCodeExporter]

I noticed the incorrect SSID as well, it was "Network-nnn" where "nnn" is the 
bssid of my AP. I'd be interested in hearing if any change to the AP encryption 
field will change this behavior on your AP. In my case any change to the 
encryption field (to TKIP, or AES, or changing it back) stopped the random PSK 
behavior.

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

[GoogleCodeExporter]

SSID is exactly as you explain. Tomorrow I'll test changing the encryption in 
the AP but it's definitely not the same model.

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

[GoogleCodeExporter]

I got the same problem with PSK key and SSID on ath9k

Original comment by [email protected] on 11 Feb 2012 at 9:35

[GoogleCodeExporter]

Issue confirmed on a AP WNR1000v2-VC, generates a new PSK which Dos other 
connected clients... Thus defeating the purpose of the exploit. So I guess its 
a good thing, seems to be more a Netgear AP issue. 

Original comment by [email protected] on 14 Feb 2012 at 8:52

[GoogleCodeExporter]

I tested it against my cheap Tenda router, same problem here:
    [+] Pin cracked in 11041 seconds
    [+] WPS PIN: '16275362'
    [+] WPA PSK: 'bbc20c6e1c91d3dbf1e2780bb261ab693761eb8a72b4ec8654b093f8c3ed1a68'
    [+] AP SSID: 'Tenda'

Seems cheap routers help.

I'm running BT5 R1, Reaver 1.4.

Original comment by [email protected] on 24 Jun 2012 at 3:20

[GoogleCodeExporter]

Greetings from Bulgaria. I'm having the same issue, reaver detects the correct 
PIN but it retrieves a different PSK every time. Each time is 64bit hex 
password and i found some information about on:
http://code.google.com/p/reaver-wps/issues/detail?id=343
http://code.google.com/p/reaver-wps/issues/detail?id=25
http://code.google.com/p/wifite/
https://github.com/derv82/wifite
http://code.google.com/p/reaver-wps/issues/detail?id=282
https://code.google.com/p/reaver-wps/issues/detail?id=203
http://code.google.com/p/reaver-wps/issues/detail?id=282
I hove this will be helpful for some one.

Original comment by [email protected] on 16 Aug 2012 at 7:11

[GoogleCodeExporter]

I'm too having the same issue, reaver detects the correct PIN but it retrieves 
a different PSK every time, also displays an incorrect AP SSID along with it. 
this change affects clients with old psk?

Original comment by [email protected] on 11 Oct 2012 at 3:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

hello friends, I found the code of wifi wpa, with reaver but can't connect, and 
I have the wps code and every time the code change I get another one but can't 
connect help please.

Original comment by [email protected] on 14 Mar 2014 at 2:33

[GoogleCodeExporter]

same here...

Original comment by [email protected] on 22 Apr 2014 at 10:44