brute force broken by inversion of p1 and p2 indexes while using option -p about reaver-wps-fork-t6x

[kcdtv]

I guess that the p1 and p2 indexes are generated in this function
void advance_pin_count() { if(get_key_status() == KEY1_WIP) { set_p1_index(get_p1_index() + 1); } else if(get_key_status() == KEY2_WIP) { set_p2_index(get_p2_index() + 1); } }

The function starts line 287 in /reaver-wps-fork-t6x-master/src/cracker.c
The question now is to understand why (and how) does the option -p "break" it...

[KokoSoft]

When the user passes the parameter -p it means that he is sure of the first part/the whole of the PIN code. Thekey_status = KEY2_WIP is then set. Function parse_static_pin in argsparser.c file, line 297.

When the NACK message is received, function do_wps_exchange() (exchange.c) returns KEY_REJECTED. It happens when the last message sent is M3 or M5 (lines 233). It does not take into account the key_status variable!
The result of the function is validated in cracker.c file, line 197.
When it equals KEY_REJECTED an advance_pin_count() (cracker.c:287) function is called. The index p1 or p2 is increased depending on the key_status variable.
The given line numbers refer to the state of the files In commit 6e60ee2. This bug is already fixed.

[kcdtv]

hi!
Thanks for the details you gave

When the user passes the parameter -p it means that he is sure of the first part/the whole of the PIN

Nope.
It is not like that, when the user uses the -p it does not mean / assume that he has a cue about the PIN first or second half
-p, --pin=<wps pin> Use the specified 4 or 8 digit WPS pin
It is just to indicate a PIN to be sent first, that is how the option works and what it was designed for since day one of reaver.
the issue isn't solve
As you can see in this stdout, index -p 2 rises instead of index -p 1
kcdtv@kalimuxo:~/Documentos/reaver-wps-fork-t6x-6e60ee25e86ec798de2e23971b029d555e9dc398/src$ sudo reaver -i wlan0mon -b 9C:97:26:A1:27:C7 -p 12345670 -c 6 -vv

Reaver v1.5.2 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner [email protected]
mod by t6_x [email protected] & DataHead & Soxrok2212 & Wiire & AAnarchYY

[+] Switching wlan0mon to channel 6
[+] Waiting for beacon from 9C:97:26:A1:27:C7
[+] Associated with 9C:97:26:A1:27:C7 (ESSID: Jazztel_A127C7)
[+] Starting Cracking Session. Pin count: 10000, Max pin attempts: 11000
[+] Trying pin 12345670.
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] p2_index set to 1
[+] Pin count advanced: 10001. Max pin attempts: 11000

[kcdtv]

I update this issue after testing reaver 1.3 and reaver 1.4
As KoboSoft said the original work of Craig HEFFNER was implemented this way:
Reaver tries continuously the same PIN (the one that we indicate)
Nevertheless the actual situation is not OK.
We have 2 options:
1) We leave the option -p as it is
2) We change it

1. If we leave the option -p as it is we definitely have to do something about this continuous loop with a non legitimate PIN: It can wake u the AP rate limit
   A way to do it is to automatically associate the use of the option -p with the argument -g 1 (one PIN tried)
   The help should be modified to advert that the PIN entered will be the only one tested when users use option -p
2. I would rather change the "concept" of the option and solve this precise issue (reaver rise p2 index instead of p1)
   If we just want to try one PIN that we introduce and stop after we just have to use the argument g -1
   If we want to try a PIN first and continue brute force we just use the option -p with the PIN we want.
   This approach is more flexible and gives more freedom to the user

[rofl0r]

so it is only broken with -p ? i.e. it works when doing a linear search/bruteforce attack, even when resuming the session with a .wpc file ? i'd somehow guess that p2_index is always changed even when a non-successful crack attempt was made, as explained in #111

[kcdtv]

so it is only broken with -p ?

Yes it should

i.e. it works when doing a linear search/bruteforce attack, even when resuming the session with a .wpc file ?

That's exactly what i was doing in WPSPIN to avoid the problem and choose the PIN(s) to be sent first: the script create a custom wpc file on the fly and use it to launch the session.
I think that this -p option is not correctly made.
As it is designed to be used with a single PIN it should stop immediately after fully trying the PIN,
The use of -p should automatically induces the use of -g 1 (one attempt and this automated parameter should overwrite any eventual -g option defined in the command line by user) to avoid this stupid loop.
(And it should over ride any eventual -g option introduced by user manually)
Than it should record the results normally and increase -p1.
The problem is even different now with latest release: I can't even reproduce the error and fully try a PIN with option -p.
It report automatically a [!] WARNING: Fake NACK detected, waiting 0 seconds before re-checking all the time after M4 when there is no problem without -p flag.
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK (reason: 0x0012)
[+] Sending WSC NACK
[!] WARNING: Fake NACK detected, waiting 0 seconds before re-checking

[rofl0r]

The problem is even different now with latest release: I can't even reproduce the error and fully try a PIN with option -p.

can you find out which is the last commit that works ?
for example, does it work with this version c94ce48 which is the last version before you merged my 2 christmas PRs ?
(you can go there and test it by doing git checkout c94ce484c4, and then make clean and rebuild it)

[kcdtv]

Sorry, crazy week-end
it might have happened before... at sometime between this thread and now. I have a crazy monday (uos it is already monday)but will have plenty of time on tuesday...I'll try to locate the faulting update
It is before the latest commit: Wen i saied "with latest revision" I didn't meant that it was coming from the latest request (it shouldn't, you just added a flag for compiling and got read of an option of wash)
I'll tell you more on tuesday

[kcdtv]

I canot locate exactly when started the problem. It is before the version used in kali repositroies so it is at the early stage of this branch,
If you check this stdout from reaver 1.4 the bug is not there.

kcdtv@kalimuX0:~$ sudo reaver -i wlan1mon -b DC:53:7C:08:AC:19 -vvv -p 01234567 -g 1

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

[+] Waiting for beacon from DC:53:7C:08:AC:19
[+] Switching wlan1mon to channel 1
[+] Associated with DC:53:7C:08:AC:19 (ESSID: ONO81D2)
[+] Trying pin 01234565
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] Quitting after 1 crack attempts
[-] Failed to recover WPA key

The PIN is not god reaver understand it and tel me failed toi recover the WPA key as i used -g 1 (stop after one try)
With reaver 1.5. i have the issue mentioned bedore

:64:7e:76:c5:f7:56:df:92:b9:b9:a3:f4:88:30:c7:77:b7:75:62:b5:8b:ce:7d:af:53:31:53:3b:c3:da:14:12:44:08:6a:13:bd:db:28:62:89:6c:af:b3:b9:0f:0d:68:d9:fd:e4:fb:4e:bb:44:1c:8e:fe:ed:92:95:33:f6:1f:17:6c:b4:c5:34:cc:b2:86🆎4c:f0:2b:7d:d8:92:dd:d6:31:e5:9a:28:98:76:4c
[P] AuthKey: 68:04:8c:e8:99:cb:81:28:fb:f2:59:f2:1e:38:67:da:6a:73:79:83:0d:01:af:21:c4:3e:f9:23:64:7b:2b:39
[+] Sending M2 message
[P] E-Hash1: 3d:72:2a:f7:5b:3e:b1:58:5b:d6:0e:ee:de:4a:62:1b:f1:34:d6:47:0a:d7:2c:30:49:3c:72:a0:86:5d:1d:8b
[P] E-Hash2: 05:2c:95:24:3e:e8:5c:7b:63:1a:8a:e0:07:ad:d9:1c:1c:dd:74:72:26:4a:a8:ec:ff:bf:da:bf:6e:33:38:44
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK (reason: 0x0012)
[+] Sending WSC NACK
[!] WARNING: Fake NACK detected, waiting 0 seconds before re-checking
[+] Trying pin 01234565.
[+] Sending EAPOL START request
[+] Received identity request

A fake NACK (it is not fake) is "detected" and reaver doesn't acknowledge the PIN as illegitimate.
I'l try to find the faulty release...

[kcdtv]

with this commit there is not the error of the fake NACK but we have the problem with -g option that is broken (doesn't stop after one PIN with -g 1)

commit 68515bd
Author: t6x [email protected]
Date: Tue May 5 01:16:34 2015 -0300
improved code

I wil hae to try from here to locate the -p fake nack issue and to try to locate the -g issue.
see you around with some news

[kcdtv]

this commit doesn't have the option -g broken, doesn't have the fake NACK but has the bad counting (p2 increase isntead of 1)

commit f26803e
Author: t6x [email protected]
Date: Thu Jun 4 14:49:59 2015 -0300

Zyxel default pin generator by kib0rg

[kcdtv]

At the end i tried the first commit made by t6_x and the bug is also there:

[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] p2_index set to 1
[+] Pin count advanced: 10001. Max pin attempts: 1
[+] Trying pin 12345670.

we can see also that option -g was broken since day one.
Notice that the commit

commit 957d7de
Author: KokoSoft [email protected]
Date: Fri Apr 15 19:30:09 2016 +0200

Fixed option -g

Does the job but the option -g 1 won't work if we use -p due to the fake "fake NACK" issue

[binarymaster]

From /src/exchange.c:

There are four states that can signify a pin failure:

- Got NACK instead of an M5 message, when cracking second half	(fake NACK)

There should be an additional check on line 244 and 252:
https://github.com/t6x/reaver-wps-fork-t6x/blame/1f9906b03894f4089e7062c504043d0cfdeed404/src/exchange.c#L244

If we're testing one-shot pin, then the first half of it can be wrong. Even if get_key_status() == KEY2_WIP.

[rofl0r]

i think this should be fixed by release 1.6b.