Everything about the new options from wash
Reaver 1.3 introduced for the first time in the "wps-reaver project" a WPS scanner called (by the time) walsh. There was no scanner dedicated to wps cracking and it got popular quickly among the community as it is simple and fast. After some improvements, Craig Heffner changed the name to "wash" when he published the first revision of reaver 1.4. With wash in 1.6.x we kept the focus on simplicity and introduced some new features that we will present here:
There was a known bug in wash with some very common wifi chips such as the well known RT3070 (and basically with all Ralink USB chips). Also the internal chips made by Atheros that use the ath9k driver (and that's a bunch of them!) had issues too.
Wash was unable to display the correct RSSI value. Thanks to the work of Notaz, wash now displays the correct signal level with all the (supported) WiFi chips.
While we do a WiFi scan focused on WPS it might be convenient to see APs without WPS enabled too. If you use the -a, --all option, all the Acess Point (with or without WPS) that are detected will show up in the shell.
If there is no value in the columns "WPS" and "lck" it means that WPS is not enabled on that router.
The probe response is a key element to analyze a target as it contains crucial information such as the exact model, the serial number, the wifi chip model, etc... assuming WPS is enabled.
You can see here a sample with the kind of data that can be found in the extended WPS information from a probe response:
With the -j tag this information will be displayed in json format (one equally formed line for every router) in order to simplify the automatic parsing and scripting with wash.
In the next picture you can see the -j option in action:
Notice that wash is logically a bit slower when you use the -j option as a probe response from the Access Point is needed.
You can now modify "on the fly" wash's stdout with pipe compatibility. Let's take an example: Some users asked to introduce an eSSID filter and others asked to introduce a bSSID filter. It is now possible to do both things with a basic grep command.
And so much more... You could for example filter by model using the extended information from the new -j option or use a custom script to generate a default PIN with some algorithm and (why not?) colorize the stdout.
Just close your eyes and let your imagination fly... The power is in your hands!
As a conclusion. a special "Hoody Ho!" to @rofl0r who implemented these new features.
