Improve the commit #2db7ca59, solution to treat the ISPs that had vulnerable
routers in the past opted to "fix" them by simply ending WPS transaction
sending an WSC_NACK with reason code 0x000F after receive M2.
With -L option continue attack ignoring the stop.
There is a very rare error with using the -p option.
It only happens when re-attack the AP already cracked,
specifying only the first half of PIN cracked and
answer yes for Restore previous session.
Taking advantage of the bug fix, functions jump_p1_queue() and
jump_p2_queue() were used to insert the specified PIN into current index.
there are 3 cases which trigger a reprint in both json and regular
mode:
- AP lock status changes
- AP PBC status changes
- AP deactivates or activates WPS completely
(WPS fields in probe response are either present or lacking)
in case of PBC status change, the field "WPS version" is temporarily
used to print "PBC" instead of the version number.
the old behaviour, which was changed recently, was to just not print
anything anymore when the internal cache of 512 APs was full.
b7c1d0e0ca changed that to print everything
after the list was full.
a better way is to just clean the list when this happens and start
over, to prevent excessive spam in the output.
this makes it possible to e.g. realize when the WPS button was pushed,
in such a case additional fields appear in a probe response, or when
the AP went to locked state. we only do this on probe response packets.
additionally, if we exhausted the maximum number of bssid's cached
(currently 512), default to print anything not in the list.
the previous behaviour was to silently ignore any APs after the list
was full.
also add some missing stuff like UTF8 and '--output-file' not being mentioned
on 'Wash Usage' and 'Reaver Usage'.
Signed-off-by: Andreas Nilsen <adde88@gmail.com>
Original author: Gabriel Rodrigues Couto <gabrielrcouto@gmail.com>
Patch created by: Andreas Nilsen <adde88@gmail.com>
Signed-off-by: Andreas Nilsen <adde88@gmail.com>
The return value of pcap_activate() is:
0, if activation succeeded, with no warnings;
a non-zero positive number, if activation succeded with a
warning - the number is a PCAP_WARNING_ indication of the
warning;
a negative number, if activation failed - the number is a
PCAP_ERROR_ indication of the error.
We should not treat non-zero positive numbers as errors. (Printing a
warning might be useful.)
We should treat non-zero negative numbers as errors, and translate it to
an error message using libpcap's own pcap_statustostr(), rather than
attempting to duplicate its mapping ourselves, as new error codes may
appear in the future, and using pcap_statustostr() future-proofs us
against that. In addition, if the error is PCAP_ERROR, we should report
the return value of pcap_geterr(handle), as that will provide additional
information about that "generic" error.
bug was introduced in 488f2e7186.
the second call to the new function was always meant to use 1 as parameter,
but i typo'ed. thanks to @1yura for the patch.
addressing #303
as it is experimental, it is not yet being advertised in the
usage output.
the switch runs pixiewps with the -u uptime switch.
it is not actually a switch for pixiewps itself, but for
pixie-wrapper, which can use the timestamp for faster attacks
on hardcoded reset-dates in routers (in case the first regular
pixiewps pass fails).
is_target() had a confusing check for NULL_MAC: if the bssid
was set to it, it would return true.
the purpose of that is that wash by default isn't targetting a
specific bssid, so a target check needs to always succeed under
these circumstances. however it also allows to specify a specific
bssid, thus the is_target check.
the other site calling the function was from reaver code, which
always has the bssid set.
therefore i factored the null mac check out to the single site
it's needed, in wpsmon.c, which immediately makes the meaning
of both the check and the function much clearer.
reordering the code so we can safely exit after a pixie attack,
while having the wpc file updated. this prevents reaver from
retry-ing the pixiewps-found pin when the submission fails.
this allows the user to take a break and try it some minutes later
with -p manually, so he can circumvent time-based lock counters.
a couple routers started turning WPS off after a pixie attack.
research showed this happens only with reaver, not oneshot, so it's
either a defensive mechanism against reaver itself, or simply against
non-compliant WPS implementations.
as @feitoi pointed out, the best way to deal with that is to send
WSC NACK.
however, we can just as well continue the session if pixiewps succeeded
in a certain timeframe, and inject the found pin into the running
WPS transaction.
the new logic now works as follows:
pixiewps is started in a thread, which processes its output. if the
pin was cracked successfully during the normal transaction timeout
interval (-t parameter), reaver will try to inject the found pin.
if pixiewps fails, NACK is sent and the program terminated.
if we hit the timeout while pixiewps runs, we send NACK, but let
the pixiewps program running in the background until it terminates,
so the full output becomes visible, and finally terminate the program.
the thread is necessary because reading from the pixiewps process handle
is a blocking operation, and even if we'd detect a timeout, we still
couldn't get the main thread to interrupt its current read operation to
send the NACK immediately (and we can't do it from a SIGALRM signal
handler, because sending the NACK involves a lot of memory allocations
and other non-async-safe operations).
fixes#291
encountered an AP that turned off WPS completely after a couple
NACK-interrupted attempts.
reaver then went into an endless loop trying to figure out whether
it is locked.
feitoi
rofl0r
Andreas Nilsen
Gabriel Rodrigues Couto
Guy Harris
Christian Bremvåg