Closed GoogleCodeExporter closed 8 years ago
[deleted comment]
Ok, strange issue has cropped up.
I'm at 10.65%, I have started getting "Receive timeout occurred" messages.
After many failed tries with the error, it may continue onto the next number
but then the next number will fail. Repeat infintitum.
To add, it is only halfway to my routers wps key (First 4), so I cannot test
the current issue.
Is there any possibility to add a switch to define a start key so it can start
from that number? eg. 50000000
It will cut down the testing time significantly, atleast in the initial phases.
Original comment by kahakki...@gmail.com
on 17 Jan 2012 at 8:45
[deleted comment]
Ok, I think I have worked out what is going on.
My modem is a Technicolor TG582n. When it goes into WPS lock, it will not send
out a M6 packet even if the first 4 pins are correct. It will return a NACK
packet instead.
When I was testing today, I found that when it got to the first 4 digits of my
pin, WPS was locked and would only return a WSC NACK instead of M5 and M6. When
I left it for a minute for WPS to unlock, I ran reaver (starting a few numbers
behind my wps key) and boom, it returned a M5 and M6 Packet.
I should note that while testing, I disabled the lock check (--ignore-locks)
which significantly took down the time needed to run the tests. Something
interesting (Well, I thought was interesting), once the first 4 numbers are
known, WPS will not lock no matter how many attempts you make.
Do you still want the output from when it is locked and a pcap file from the
same test? If so, and I know I am going to sound like a noob here, how do I
generate a pcap file? I am guessing I would use wireshark or something similar?
Original comment by kahakki...@gmail.com
on 17 Jan 2012 at 2:21
Ah, that's evil! :) Most APs just reject the WPS session at the beginning.
If you don't specify the --ignore-locks option, does reaver detect that WPS has
locked and wait until it is unlocked before continuing? Assuming the AP is
properly reporting that it has locked WPS, this should prevent Reaver from
attempting pins while WPS is locked and therefore mitigate the AP's behavior of
always NACKing M4 packets while locked.
I have also seen other devices that don't lock as long as you get the first
half of the pin correct. This is nice once you've broken the first half of the
pin, but the first half is 90% of the attack. :P
I think this explains the behavior you were seeing, pcaps aren't necessary.
Removing the --ignore-locks option when running reaver should fix the issue,
unless the AP is not properly reporting that it has locked WPS. If it is not
properly reporting a locked state, I'd suggest a little trial and error to see
how many failed attempts cause it to lock, and how long the lock period is. You
can then adjust the timing options on Reaver to ensure that you aren't trying
pins while the AP is locked (also if this is the case, you should post the
timing options to issue 78 so others know about it too!).
Original comment by cheff...@tacnetsol.com
on 17 Jan 2012 at 2:39
Thanks, I was thinking about doing some testing along those lines. I havn't
tried it that much yet without the ignore locks option so I will give that a go.
Thanks for all the help :)
Original comment by kahakki...@gmail.com
on 17 Jan 2012 at 2:59
I'll try but after restoring session (1 day after) and seeing the reaver trying
the same pin, I believe there is a problem when reaching 9999 part 1 keys..
Original comment by tiago.ju...@gmail.com
on 18 Jan 2012 at 7:46
[deleted comment]
[deleted comment]
Hi, newbie here
running reaver with autodetect best options, ~65 sec/pin
running reaver with --vv & -L switch's, takes it down to 4 sec per pin, but
freezes at 90.9% attempting same pin. If I ctrl+C out, and give -P option with
the Pin it stuck at, it goes to 99.9% and freezes there, attempting last pin
99985677.
I made regular backups of the /usr/local/etc/reaver folder, resuming from
earlier stage pins are attempted again, alll goes through fine but freezes
again at 90.9%
Original comment by System...@gmail.com
on 5 Jul 2012 at 2:05
Yeah I have the same issue here and I am guessing this is something has to do
with the Router...
I have got some routers that I can crack easily using the same command and same
system on the same computer but there are some others that just keep getting
this error at 90,90% or more... or some from the beginning starts to repeat the
exact same pins like 012345678 over and over again...so I gave up on those
after a month trying all things but still didn't work with Reaver 1.4 maybe a
downgrade to 1.3 ?
Original comment by peter.hu...@gmail.com
on 9 Aug 2012 at 2:46
[deleted comment]
Try to remove the -L option because the Thomson TG 585 used by Maroc Telecom
Locks for 60 seconds every 3 tries of PIN.
I succesfully cracked this type of router using Reaver 1.4 but I used these
options reaver -i mon0 -b MAC -vv -d 4 -T 5 it's very slow, Its took 5 days
to crack it but its efficient.
Original comment by inpti...@gmail.com
on 24 Aug 2013 at 3:15
salut est ce que vous pouvez m'aide? jai un problem sur reaver jelancé rever
le rtoure impose apres 3 essai un verouillage de 60s et apres 6 jours il a
arrivé a 90.90% et il reseyye le meme pin et il reste sur 90,90% toujours
!!!!!!!! ls commande que je fait c'est
airmon-ng start wlan0
airodump-ng mon0
apt-get update
apt-get install reaver
reaver -i mon0 -b 00:11:22:33:4D -vv
Original comment by adam.lah...@gmail.com
on 24 Dec 2013 at 8:46
Pour #64: T'es sûr que ta langue maternelle c'est le Français?
Enfin bref: le coup du 90.90% ca me le fait aussi sur certaines BBox, c'est pas
à cause de Reaver, c'est à cause du routeur qui "se bloque" après plusieurs
essais, et dis "NACK" dans tout les cas à l'étape M1/M2, même si c'est "le
bon" début. Typiquement, un routeur "bien implémenté" devrait bloquer les
requêtes au lieu de répondre NACK.
Reaver avance jusqu'à ce que les essais possibles pour M1/M2 soient épuisés,
et du coup à 90.90% il teste indéfiniment la dernière combinaison possible.
Original comment by hadwa...@gmail.com
on 24 Dec 2013 at 11:48
m
try to get the wps pin by using wps generator in slaxwifi and ur reaver will
start at 90.91
Original comment by markdoom...@gmail.com
on 2 Feb 2014 at 6:05
I am currently stuck on 90.90% running latest version of reaver 1.4. I have
tried this on backtrack 5 r3 and also Kali linux 1.0.7 the latest version of
everything still gets to the same pin number 99985677 and keeps sending same
one over and over. The AP is in the next room i am getting 30/30 100% injection
from aireplay-ng -9 mon0, ap is not locked with wash -i mon0, its getting about
a pin every 4 seconds fine but still stuck on 90.90% has anyone found the cure
to this?
Original comment by berezini...@gmail.com
on 11 Jul 2014 at 9:17
I should have added in my last post that i have tried to put in --pin=99985678
just to see if it will give me output for the next pin, instead it continued to
try 99985677 ignoring the --pin= switch all together.
i use reaver -i mon0 -b xx:xx:xx:xx:xx:xx -a --channel=2 -vv --dh-small
later added --pin=99985678 which did not yield any difference.
Original comment by berezini...@gmail.com
on 11 Jul 2014 at 9:21
haha i think reaver is really confused... i have deleted the save file in
/usr/local/etc/reaver xxxxxxxxxx.wpc on the target ap and forced changed pin to
--pin=99975678 to see if it will get over its hick-up and not a change, it
started repeating pin# 99975678 repeatedly.. now as far as % goes it printed
90.95% done, then next time 91.00% done.. ALL while repeating the same
99975678, 99975678 pin repeatedly... how is that possible? doesn't make any
sense.
Original comment by berezini...@gmail.com
on 11 Jul 2014 at 9:30
Hello ,
Is there anyone who found the pin of the TG585 router to check if it is a
default one .
Thanks a lot
Original comment by Wafaa.Ta...@gmail.com
on 29 Sep 2014 at 10:53
Original issue reported on code.google.com by
ismailce...@gmail.com
on 12 Jan 2012 at 11:37