Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EXHAUSTIVE] Stuck at 99.99% and keeps repeating the same key, it seems this issue has been around for a long time but no clear solution. #262

Open
r00tdvd opened this issue Aug 26, 2018 · 10 comments

Comments

@r00tdvd
Copy link

r00tdvd commented Aug 26, 2018

Hi,

I am still learning about all the details having said that I've been able in the past to get the pin for a PSK enabled routers.

This time I am encountering this issue with reaver stuck at 99.99% and keeps on repeating the same key after its done so many keys. I was reading the following link and someone suggesting I should modify the code to bypass this problem but I am not sure why the latest version still have this as a problem when it goes way back?

https://code.google.com/archive/p/reaver-wps/issues/195

From the link above, I sort of understand what the problem is but I would like to know what is the right way to fix this issue and if there is a simple solution since its been a long while.

I am using Reaver v1.6.5 in latest Kali.

Here is my reaver command line for a Broadcom router with PSK enabled:-
reaver -i wlan1mon -b xx:xx:xx:xx:xx:xx:xx -c -k -v -S -N

When I rean reaver initially it always displays the msg: Found packet with bad FCS, skipping, then it starts
and after 15 hours or so it got stuck at 00003432 the first 4 pins are:0000

Now if I try reaver to start with a specific pin it just keeps on repeating in an endless loop.

Thanks.

@rofl0r
Copy link
Collaborator

rofl0r commented Aug 26, 2018

relevant comments from that bugreport:

Comment 26
Posted on Sep 5, 2012 by Happy Dog

Good evening I can tell you the reason for this issue and how to solve. I came across the solution in these last 3 days spare time. it took me some "mumble mumble" and a little bit of coding.

You get 99.99% and stuck because reaver has attempted all the pins that knows. So what if the right pin is not in the knowledge of reaver?

While the first 7 digit are consecutive numbers last digit is a checksum. so reaver attempt 10^7 pins not 10^8 (and that's good!)

But what if the target AP PIN is one of the 9000 not computed?

Solution: With a exhaustive attempting (small modification of code under /src/) in the range from 01230000 to 01239999 you will find the right pin (first 4 digit are those recognized by reaver). These are 10^4 pins that for 7sec./pin it will take 19hours and 30minutes to look for them all.

conclusion: luckily it took me 5hours (more or less 2500 attempted pin), thats because of how I implemented the exhaustive algorithm and because the pin was 01234567 (yes seriously, you can expect others to be 12345678).

next issue: a this point reaver communicate that this is the right pin but doesn't give WPA PSK. I used the wpa_supplicant & wpa_cli method (issue 203 comment 6) and it works like a charm! now the problem is that after retrieving psk and connected with success, AP has turned off WPS, I don't mean WPS LOCK, I mean there is no more the AP under WASH and if try to associate thru aireplay (I always used it to associate during pin attempts) give this error message:Denied (code 12), wrong ESSID or WPA ?

from now I will shut connection with this AP for 12 hours to see if it turns WPS up again.

hope that all the things I wrote are interesting for someone!

saluti!

Comment 27
Posted on Sep 7, 2012 by Happy Dog

I got some news

shutting connection it's useless about WPS reactivation.

!!! after 48 hours the AP has rebooted by itself reactivating WPS with same old pin. !!!

yesterday I tried to reactivate from telnet but there is no command to accomplish the task (some router has it).

from 'system shell' I found some directories named "wps...." but didn't had time to discover.

a couple of thing about this AP I found in 'system ver': Version: 4.5.3.AGPWI_1.0.3 Platform: P.DG A4001N

that's all folks! saluti!

Comment 30
Posted on Sep 24, 2012 by Quick Bear

Stefano, thank you very much! As described in issue 203 comment 6, wpa_supplicant works perfectly. My Telecom was 01234567 too. It seems all Telecom routers have this pin by default. It would be very useful if there was an option in reaver to ignore calculation and bruteforce last checksum digit.

Comment 41
Posted on Oct 22, 2012 by Happy Dog

I'm proud of you Tystar! You tried harder than anybody else looking for the insight and then you saw the light. So it's time to show that light to all the masses.

Assumptions: -the router accepts WPS transaction so it's not giving you continuously "timeout". -you know the first 4 digits of the pin (for example 0123 or 1234 or whatever)
retrieve these information using original reaver before applying the modification.

download reaver: svn checkout http://reaver-wps.googlecode.com/svn/trunk/ reaver-wps-read-only

open the file /root/reaver-wps-read-only/src/pin.c with a text editor (save a copy you will need it to reinstall original reaver) after #include "pins.h" SUBSTITUTE THE FIRST FUNCTION WITH THIS SAME FUNCTION (modified):

/* EXHAUSTIVE MOD. init / / * in these lines trivial modifications are applied over the original code. * these lines have to be considered for demonstration purpose only. * WPA PSK retrieval is not granted. * http://code.google.com/p/reaver-wps/issues/detail?id=195 */

/* set global vars */ int exhaustive_last_digit = 9; int exhaustive_index = 000;

/* Builds a WPS PIN from the key tables */ char *build_wps_pin() { char *key = NULL, *pin = NULL; int pin_len = PIN_SIZE + 1;

    pin = malloc(pin_len);
    key = malloc(pin_len);
    if(pin && key)
    {
            memset(key, 0, pin_len);
            memset(pin, 0, pin_len);

            /* Generate a 7-digit pin */
            snprintf(key, pin_len, "%s%s", get_p1(get_p1_index()), get_p2(exhaustive_index));

            /* Append last digit */
            snprintf(pin, pin_len, "%s%d", key, exhaustive_last_digit);

            free(key);

    if(exhaustive_last_digit==0)
    {
        if(exhaustive_index==999)
        {
            cprintf(CRITICAL, "[-] Failed to recover WPS pin. \n");
            /* Clean up and get out */
            globule_deinit();
            exit(EXIT_FAILURE);         
        }
        exhaustive_index++;
        exhaustive_last_digit=9;
    }else{
        exhaustive_last_digit--;
    }
    }

    return pin;

}

/* EXHAUSTIVE MOD. end */

-actual reaver have to be uninstalled:

cd /root/reaver-wps-read-only/src ./configure make distclean

-modified reaver have to be installed:

cd /root/reaver-wps-read-only/src ./configure make
make install

call reaver with the option -p 0123 where "0123" are the pin first 4 digits. if you don't specify these 4 digits worst-case will take at least 10 years (3sec/pin * 10^8pin). using the right 4 digits worst-case will take at least 10 hours (3sec/pin * 10^4).

to reinstall original reaver: substitute modified pins.c with the original pins.c that you kept safe somewhere. uninstall and install with same commands as above.

@rofl0r
Copy link
Collaborator

rofl0r commented Aug 26, 2018

to sum up:
apparently there's a bug in reaver when the following conditions hold:

  1. first pin half was detected by getting a M5
  2. the correct pin does not follow the rules (i.e. checksum is ignored)

a guy in that issue ("Grumpy Horse") created a reaver fork and created an option --exhaustive / -X to do a full scan over the second pin half (10K possibilities instead of 1K).
i suspect that person was @t6x and his fork later moved here.

since the code in this repo became quite buggy over time, we decided to start from scratch i.e. reaver 1.4 and only backport known good changes. the -X change was one i did not backport.

what you could do:
click on releases and download the tagged version 1.5.2 (or checkout the master-old branch). first try it without -X to see if the endless loop is fixed, then try with the exhaustive option on to see if you can successfully find the pin, then let us know the outcome.

maybe @kcdtv or @soxrok2212 remember more details.

@rofl0r
Copy link
Collaborator

rofl0r commented Aug 26, 2018

imo the right thing to do (instead of looping endlessly) would be to display a message like "tried all valid candidates, but pin not found. it is possible that the pin does not follow checksum rules, in which case you could try again with -X" and if -X is given from the beginning, try the exhaustive search automatically after all the correct pins were tried (that also means the exhaustive mode has to be re-added).
the hard thing is that

  1. the reaver code is, frankly, pretty much an inconsistent and badly designed and written mess
  2. it's hard to test these codepaths without access to a router exhibiting the issue (the only way to address that coming to my mind rn is setting up a soft-ap with hostapd)
  3. it takes a very long time to test a full bruteforce scenario (and i for my part don't want to sit 10 hours next to the radiation of WIFI router). this could be circumvented by carefully drafting a .wpc file (which in turn requires deeper understanding of the format - maybe @kcdtv could write a wiki article describing it?)
  4. bruteforce is pretty much dead these days

@rofl0r
Copy link
Collaborator

rofl0r commented Aug 27, 2018

did you even read what i said ? 1.5.2 has support for the exhaustive mode that was mentioned.

If I install reaver v1.5.2 will it have the same issue or not?

SEE PREVIOUS REPLY:

click on releases and download the tagged version 1.5.2 (or checkout the master-old branch). first try it without -X to see if the endless loop is fixed, then try with the exhaustive option on to see if you can successfully find the pin, then let us know the outcome.

does this reply suggest i'm 100% sure if it will work ? it says TRY IT OUT and TELL US whether it works

@rofl0r
Copy link
Collaborator

rofl0r commented Sep 2, 2018

the � symbols are due to a non-zero-terminated string and adjacent garbage in the memory that's being printed out. the WPS: Device Password is the PIN that's being sent to the router. in this case 00000009 and unless you get till M7 you don't the router password which is "WPA PSK"

@soxrok2212
Copy link
Collaborator

If there was MAC filtering, you wouldn’t be able to connect at all.

@rofl0r
Copy link
Collaborator

rofl0r commented Sep 2, 2018

When I put in the string as the pass it looked like I connected and * could see the wifi icon on the status bar but there was no internet!

there's no guarantee that every random router has internet connection... it could also be that you're just too far away or that you didn't configure your IP address correctly. fire up wireshark and look for packets containing an ip adress, so you can configure one within the same subnet, if DHCP doesnt work.

Also why every time I tell reaver check -p 00000000

the -p option is actually only meant to used with a single pin. IMO we should change the option so it sets -g 1 implicitly.

@soxrok2212
Copy link
Collaborator

This is not a general support forum. Please check the internet elsewhere. If you still experience issues with Reaver, open a new issue because this is littered with irrelevant discussion.

@r00tdvd
Copy link
Author

r00tdvd commented Sep 4, 2018

sure no problems. Thanks

@rofl0r rofl0r changed the title Stuck at 99.99% and keeps repeating the same key, it seems this issue has been around for a long time but no clear solution. [EXHAUSTIVE] Stuck at 99.99% and keeps repeating the same key, it seems this issue has been around for a long time but no clear solution. Jan 4, 2019
@rofl0r rofl0r reopened this Jan 4, 2019
@rofl0r
Copy link
Collaborator

rofl0r commented Jan 4, 2019

reopening as a reminder because the underlying issue (exhaustive mode) is currently not implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants