Offensive Security Researcher & Quantum Cryptography Analyst

Wash: How to Discover WPS-Enabled Routers Before You Test Them

Abdul Wahab Junaid
wash: A tool for discovering WPS-enabled routers to exploit

Before you ever point Reaver or Bully at a target, you need to know two things: is WPS even enabled on this access point, and is it currently locked out from previous attempts? That’s exactly what Wash does, and it’s honestly a tool people skip past too quickly on their way to the “exciting” attack tools — even though skipping it is how you waste hours attacking a router that was never vulnerable to begin with.

Wash ships as part of the Reaver project, and I treat it as the mandatory first step of any WPS-focused assessment. This article covers what it does, how it reads WPS information elements from beacon frames, installation, full command syntax, and how I use it before every WPS test.

What Is Wash?

Wash is a WPS scanning utility bundled with the Reaver suite. It passively listens to 802.11 beacon and probe response frames and parses the WPS Information Element (IE) that WPS-capable access points broadcast. From that IE, Wash can tell you:

This lets you triage a whole list of nearby access points in seconds and immediately know which ones are even worth pointing Reaver or Bully at.

How It Works Internally

Every WPS-enabled AP includes a vendor-specific Information Element in its 802.11 beacon and probe response frames, defined by the Wi-Fi Alliance’s WPS specification. This IE contains structured TLV (type-length-value) fields describing WPS state, version, device name, and manufacturer.

Wash simply puts your adapter into monitor mode listening mode (it doesn’t need to inject anything — it’s fully passive) and parses these TLV fields out of every beacon it sees, presenting them in a clean table. Because it’s passive, running Wash carries essentially zero risk of disrupting a network — it’s pure reconnaissance.

Installation

Wash comes bundled with Reaver on Kali Linux:

sudo apt update
sudo apt install reaver -y

Confirm it’s available:

wash --help

Expected output:

Wash 1.6.6 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner

If it’s not bundled with your Reaver package, build from source:

git clone https://github.com/t6x/reaver-wps-fork-t6x.git
cd reaver-wps-fork-t6x/wash
./configure
make
sudo make install

Prerequisites

Your adapter must be in monitor mode:

sudo airmon-ng check kill
sudo airmon-ng start wlan0

Basic Usage and Syntax

sudo wash -i wlan0mon

Typical output:

Wash v1.6.6 WiFi Protected Setup Scan Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner

BSSID              Ch  dBm  WPS  Lck  Vendor    ESSID
-----------------------------------------------------------------------------
AA:BB:CC:DD:EE:FF   6  -42  1.0  No   Ralink    LabRouter
11:22:33:44:55:66  11  -61  2.0  Yes  Broadcom  NeighborNet
77:88:99:AA:BB:CC   1  -75  N/A  N/A  --        OldOfficeAP

Reading this table:

Scanning on a Specific Channel

To reduce scan time and focus on a known channel:

sudo wash -i wlan0mon -c 6

Writing Results to a File

sudo wash -i wlan0mon -o wash_results.txt

Scanning From an Existing Capture File

If you already have a .cap file from airodump-ng, Wash can parse WPS data from it directly instead of live-scanning:

wash -f capture-01.cap

This is particularly useful when you’ve already done a broad passive capture with Kismet or airodump-ng and don’t want to key up the radio again.

Real-World Use Cases (Authorized Testing Only)

1. Triage Before a WPS Assessment On every wireless engagement I run, Wash is the very first command after monitor mode is up. It tells me in seconds which in-scope APs even have WPS enabled, saving hours of pointless Reaver runs against networks that were never exposed to begin with.

2. Verifying Remediation After recommending a client disable WPS, I re-run Wash during a follow-up assessment to confirm the setting actually took effect and isn’t still broadcasting the WPS IE.

3. Lockout State Monitoring During an active Reaver/Bully test, I periodically re-run Wash in a separate terminal to check whether the target AP has entered a lockout state, so I know when to pause the attack rather than keep hammering a locked router pointlessly.

Workflow and Tool Integration

Performance Optimization

Troubleshooting

Common Mistakes

Best Practices

Practical Lab Example

  1. Enable WPS on your own test router.
  2. Put your adapter into monitor mode.
  3. Run sudo wash -i wlan0mon and confirm your router appears with WPS: 1.0 or 2.0 and Lck: No.
  4. Disable WPS on the router and re-run Wash — confirm it now shows N/A or disappears from WPS-capable listings.
  5. Optionally, capture a .cap file with airodump-ng first, then run wash -f yourcapture.cap to confirm offline parsing works identically.

FAQ

Does Wash attack or attempt to crack anything? No. Wash is purely passive reconnaissance — it only reads beacon/probe information, it never sends attack traffic.

Is running Wash risky or detectable? Since it’s fully passive, it carries essentially no risk of disruption and is very difficult to detect, unlike active tools like Reaver.

Can Wash tell me the actual WPS PIN? No — it only reports whether WPS is enabled and its lockout state, not any credential material.

Why does an AP show WPS enabled but Reaver still fails? This usually means the AP has entered a lockout state, or the vendor’s WPS implementation has quirks that Reaver doesn’t handle well — check Wash’s Lck column and consider trying Bully instead.

Summary

Wash is a small, unglamorous tool that saves enormous amounts of time in any authorized WPS assessment. By passively reading the WPS Information Element out of beacon frames, it tells you exactly which access points are even worth testing and whether they’re currently locked — turning what could be hours of blind Reaver attempts into a focused, evidence-based test plan.

References

Exit mobile version