Closed GoogleCodeExporter closed 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
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
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:
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
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
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
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
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
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
[deleted comment]
I have the exact same issue right now.
Original comment by micropix...@gmail.com
on 7 Jan 2012 at 1:01
Did you try looking on the bottom of the router?
Original comment by emailr...@gmail.com
on 7 Jan 2012 at 2:15
The same issue for me
Original comment by tiger2...@abv.bg
on 7 Jan 2012 at 9:26
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
[deleted comment]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
emailr...@gmail.com
on 5 Jan 2012 at 3:14