estemeza1 / reaver-wps

Automatically exported from code.google.com/p/reaver-wps
0 stars 0 forks source link

Stuck 99.99%,repeats one key #88

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. checks keys until 99.99%
2. repeats one key
3. repeat from one

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

Expect the wpa pass. Cycling one key over and over

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

Version 1.3,no svn updates,Backtrack 5 R1 x86

Please provide any additional information below.

The setup and hardware end worked fine,was successful against my old Linksys. 
Against my Dlink it gets stuck at 99.99% trying one key over and over.
This is my second attempt. 
The first attempt was Bactrack 5 x86 with an Atheros card.
The second attempt is The same but with a Realtek card.
Both attempts produce the exact same output,99.99% one key repeating.
Different repeating keys for each,42237501 and 42232377,both close but not 
right.
Association is fine,I don't have mac filtering enabled.
I know the router is configured and working correct because I just posted this.

Original issue reported on code.google.com by emailr...@gmail.com on 5 Jan 2012 at 3:14

GoogleCodeExporter commented 8 years ago
It happen to me to, i think the program was jumping over the right pin number 
but did not recognizing it, so it is only one pin combination left to test. 
Probably you can try to delete the 3 digit pins in the stored file in the hope 
the first four pins where the right ones. so it takes another 1000 try's.

Original comment by patricks...@gmail.com on 5 Jan 2012 at 3:44

GoogleCodeExporter commented 8 years ago
So the first four pins are correct, but the last four are not? What happens if 
you specify the correct pin explicitly using the --pin option? If the--pin 
option also fails, can you provide a pcap of the traffic? 

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 4:01

GoogleCodeExporter commented 8 years ago
Okay,I'm guessing the first four pins are correct.
It is actually my girlfriends router,she thinks this whole thing is a joke the 
internet is having at my expense,so there's no way I can --pin the password.
Here is a cap.
My mac is 00-18-E7-62-3F-1F,the router is 14:D6:4D:30:A4:E2.
I also threw in a succesful association with aireplay while reaver was running.

Original comment by emailr...@gmail.com on 5 Jan 2012 at 5:47

Attachments:

GoogleCodeExporter commented 8 years ago
Well it doesn't look like you have any association issues, and the first half 
of the pin definitely appears to be correct. Unfortunately, it's impossible to 
tell what the issue may be without knowing which request should have been the 
right pin, but I'm guessing it's a bug in Reaver that is causing it to skip the 
right pin.

So there are two options:

1) Run the attack against the second half of the pin again and capture the 
entire thing with wireshark. You can do this by editing the session file as 
mentioned above, or specify the first four digits of the pin using '--pin=4223' 
(if using the --pin option, do not restore from the previous session when 
prompted). Use the display filter of 'eap || eapol' and only save the displayed 
packets in order to keep the file size low.

2) When your g/f isn't looking, go peek at the bottom of the AP; the pin is 
usually printed on a label along with the MAC address. You can then specify the 
right pin with the --pin option.

#2 is obviously preferred, as it will be the easiest way to diagnose the 
problem; going through the pcap from #1 will be painful and tedious. :P

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 6:11

GoogleCodeExporter commented 8 years ago
What are the first 3 lines of a "/etc/reaver/macadress.wpc" indicating ?

Original comment by patricks...@gmail.com on 5 Jan 2012 at 6:25

GoogleCodeExporter commented 8 years ago
The first line is an index into the array of 4 digit numbers (the first half of 
the pin); the second is an index into the array of 3 digit numbers (the second 
half of the pin, minus the checksum which is dynamically generated); the third 
is the status of the attack:

0 - Still trying to break the first half of the pin
1 - First half broken, working on the second half
2 - Entire pin broken

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 6:33

GoogleCodeExporter commented 8 years ago
Thank's, So it is possible to generate a *.wpc file. Then put the corresponding 
mac adress.wpc ,,and before the first attempt of reaver, reaver will take this 
produced file.

Original comment by patricks...@gmail.com on 5 Jan 2012 at 6:51

GoogleCodeExporter commented 8 years ago
Yes, but you must make sure that the 4 and 3 digit pins are all contained in 
the session file as well. You don't have to name it <mac>.wpc either, you can 
call the file whatever you'd like and load it explicitly using --session=<file>.

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 6:53

GoogleCodeExporter commented 8 years ago
Okay,it worked.
I seem to have left out a little info.
It got stuck on day 2 at 99%,day 1 it got stuck at 40%.
Day 3 was succesful in about 5 minutes.
So apparently for some reason or another I got locked out.
Sorry I didn't get a cap for you,or have any useful information other than : i 
pinned the 4223 and I added the -L switch.
And yes I could have snuck a peek on the router,but it's all about integrity.
I wanted to stand on the shoulders,brains and hard work of others to accomplish 
the goal=).
Thanks for the hard work,information and reaver.

Original comment by emailr...@gmail.com on 6 Jan 2012 at 11:06

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I have the exact same issue right now.

Original comment by micropix...@gmail.com on 7 Jan 2012 at 1:01

GoogleCodeExporter commented 8 years ago
Did you try looking on the bottom of the router?

Original comment by emailr...@gmail.com on 7 Jan 2012 at 2:15

GoogleCodeExporter commented 8 years ago
The same issue for me

Original comment by tiger2...@abv.bg on 7 Jan 2012 at 9:26

GoogleCodeExporter commented 8 years ago
I'm also having this issue with the latest revision on the svn (r76). However, 
I don't have the problem with the released 1.3 version.

Basically, even if i feed in the correct PIN on r76, it will not recognize that 
it's correct and keep guessing other pin numbers, and it will eventually get up 
to 99% without ever finding the key.

With 1.3, it works fine and cracks the wpa key.

This issue has been verified with 2 separate routers.

I'm using an Alfa awus036h wireless card in Backtrack 5 r1 (vmware workstation 
8.0.1 build-528992).

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

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
btw.. I forgot to mention that the 1.3 that works correctly is the Reaver 
1.3-bt0 that I got through apt-get install reaver in backtrack 5 r1.

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

GoogleCodeExporter commented 8 years ago
dgprather, it looks like the original issue here was that Reaver was getting 
locked out, and it eventually did get the right pin. The bug you mention has 
already been reported in issue 100.

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

GoogleCodeExporter commented 8 years ago
Also experiencing the same. It found firs part of key - 1234, and then comes 
thru all 3 digits array and cant find another part of key from them. When i 
start wireshark while cracking, it repeat EAP/EAPOL packets with fail (==2) 
status. 
I expect to found the EAP/EAPOL packet with success (==3) status, while 
cracking with 'pin=1234' option, is it true? 
And when i found this packet (which seems to ignored by reaver), where could i 
find the right part of key? In which field of this packet? In data? Or i need 
to catch some packet before this EAP with 'success' status? Or i need to see 
all time on both windows - with reaver and wireshark to catch moment, when 
wireshark sees right packet? 

Original comment by Gosh...@gmail.com on 8 Mar 2012 at 5:08

GoogleCodeExporter commented 8 years ago
Had the same stuck-at-99.99% problem. Was using reaver version 1.4 (downloaded 
and compiled from http://code.google.com/p/reaver-wps/downloads/list) on Ubuntu 
10.4 -- kernel version 2.6.32-36-generic, using an Atheros A928x card, ath9k 
driver for the crack. The first 4 digits had been correctly cracked -- the last 
3 (plus the check digit) were the problem. For some reason, reaver was passing 
over the correct PIN during the last stretch, reaching 99.99% and basically 
trying the last PIN over and over again.

Overcame this using the tip posted in Comment 14 by dgprat...@gmail.com, Jan 7, 
2012:-

"I'm also having this issue with the latest revision on the svn (r76). However, 
I don't have the problem with the released 1.3 version."

Removed reaver version 1.4 by doing a "sudo make distclean" in the 
reaver-1.4/src/ directory. Then downloaded, untarred and installed reaver 
version 1.3 from the code.google page. 

Ran "reaver -i mon0 -b 08:8x:xx:43:xx:xx -vv -p 8302" -- where 8302 was the 
4-digit prefix correctly cracked by reaver-wps version 1.4.

And the complete PIN was cracked within minutes!! Many thanks to dgprat.. and, 
of course, the reaver-wps programming team!

Hope this helps some of those who have this 99.99% infinite-loop problem on 
version 1.4. 

1. Note down the first 4 digits of the PIN reaver's stuck at 99.99% with 
2. Downgrade to version 1.3, after doing a "distclean" of the installed version 
1.4
3. Run reaver with the -p option, with the 4 digits noted above. 

Certainly worked for me! 

Original comment by profdrea...@gmail.com on 15 Mar 2012 at 5:31

GoogleCodeExporter commented 8 years ago
happened to me, I think it happens when using --dh-small to speed up the 
cracking

Original comment by saveme...@gmail.com on 21 May 2012 at 11:56

GoogleCodeExporter commented 8 years ago
Hi all, 
Can you please give me a command code for downgrade?
I know its first delete with the distclean but as I am not a pro user of linux 
I dont know the command line!
Thanks!

Original comment by peter.hu...@gmail.com on 4 Jul 2012 at 9:53

GoogleCodeExporter commented 8 years ago
And no I did not use --dh ... I am on iMac with virtual box Backtrack 5r2 and 
Alfa AWUS036H
TIA

Original comment by peter.hu...@gmail.com on 4 Jul 2012 at 9:55

GoogleCodeExporter commented 8 years ago
Same issue, repeatable 100% of the time - Backtrack 5 R2 - Reaver 1.4 - a 
couple older APs - 2 different wireless nics - internal broadcom and usb alfa 
awus036h - all combinations of hardware stop at 99% and repeat the last pin

reaver -i mon0 --mac=xx -b xx -vv -f -c x --no-nacks

adding the --no-nacks is the only way I've been able to even move forward to 
this point , without --no-nacks it hangs on the first pin 

Original comment by brock1...@gmail.com on 19 Sep 2012 at 4:15

GoogleCodeExporter commented 8 years ago
hey man.. can you please help me how to Downgrade reaver 1.4? Distclean doesn't 
seems to be working.. im using BT5 R3..
Thanks!

Original comment by johnnn.g...@gmail.com on 10 Nov 2012 at 5:27

GoogleCodeExporter commented 8 years ago
Hi people,

I'm fairly new to using reaver but like many others I'm getting stuck at 99.99% 
with the pin stuck repeating on 12349982, I've tried using the --pin=1234 but 
to no avail and it still sticks at 99.99%, I'm using a RTL8187L chipset with 
reaver 1.4. Any suggestions or remedies will be appreciated.

Original comment by jason.i....@gmail.com on 19 Mar 2013 at 9:24

GoogleCodeExporter commented 8 years ago
This seems like a counter measure in place in many routers, whereby they keep 
responding to pin attempts, but always with a failure as an alternative to rate 
limiting. I know this isn't the best solution, but try setting the delay (-d) 
to 10-15 seconds. It seems most APs don't think that is a feasible attack rate, 
when really it is. At least for me, I don't see much a difference between 
waiting few hours or day. It would be nice to make it a 2-3 hour process, but 
just waiting until tomorrow is still feasible.

Original comment by Google.A...@email.com on 20 Apr 2013 at 3:50

GoogleCodeExporter commented 8 years ago
Thanks for the reply, I've actually found a temporary fix by downloading and 
installing Reaver 1.3 which seems to work so much better. When I ran 1.3 I was 
able to crack the WPA in just over 3 hours. But thanks again for your input.

Original comment by jason.i....@gmail.com on 20 Apr 2013 at 3:56

GoogleCodeExporter commented 8 years ago
Jason could you elaborate I am in need of assistance what method did you use to 
crack it with? I am using reaver 1.3 and 1.4 and am having no success please 
help and let me know if you need my email address any and all information or 
help is appreciated.

Original comment by dustinj...@gmail.com on 21 Nov 2013 at 10:52

GoogleCodeExporter commented 8 years ago
dustinj, I found that downgrading Reaver to 1.3 works so much better, don't get 
me wrong I've had success in the past with 1.4 but 1.3 seems to work better. 
Hope this helps buddy.

Original comment by jason.i....@gmail.com on 17 Jan 2014 at 9:34

GoogleCodeExporter commented 8 years ago

HERE IS THE SOLUTION-

The 90.90 % loop occurs when reaver is unable to find even the first half of 
the pin and it has no pin left to try.

Similarly 90.90% loop is when reaver has the first 4 digits but doesn't find 
the last 3 digits(4th is the check sum) and it has no pin left to try.

The reasons for these loop are as follows-
1. timeout errors.
2. frequent resuming and pause.
3. using parameters -S -N -L etc
4. lockdowns.
5. router showing false positive.
6 other simiar cases where a correct pin is rejected.

The solution is- Start reaver again with keeping these things in mind-
1. DONT USE THE ABOVE POINTS 1,2 AND 3

Thank you.
Sushobhit333@gmail.com
www.facebook.com/technology.lancers

Original comment by Sushobhi...@gmail.com on 3 Aug 2014 at 6:06

GoogleCodeExporter commented 8 years ago
one thing more, it has nothing to do with 1.3 or 1.4

Original comment by Sushobhi...@gmail.com on 3 Aug 2014 at 6:06