dougives/wispScript and hardware kit to automatically deauth 802.11 clients en masse. Captures packets for later nefariousness.
Script to automatically deauth 802.11 clients en masse. Captures packets for later nefariousness. Great conversation starter in your local coffee shop.
This script was designed to run on a Raspberry Pi 3 or above. It will also run on similar hardware with the same or greater capabilities, of course.
A fair amount of additional kit is required to operate the script effectively. You will also require:
For maximum effectiveness, you should also have:
I personally use ConnectBot with Hacker's Keyboard on my cell phone for controlling kits like this over SSH. It draws the least attention and fits in your pocket.
I suggest that the device be configured to automatically connect to a VPN that you host, to avoid any routing/NAT issues. Setting up OpenVPN on a cloud host is the easiest way to achieve this. Be sure to use OpenVPN's client-to-client server configuration directive, or have forwarding configured otherwise.
You will require some other method besides wifi for connecting the device to the internet, obviously. Cellular access is the simplest candidate. Unless you desire to pull packet captures from the device remotely, very little bandwidth (<100Kib/s) is required. You can get away with using a cheap "unlimited" data plan that restricts your speed after some amount of data is used.
I have had MTU issues when running OpenVPN over cellular. The easiest remedy is to set your MTU to 1200 with ip link set dev tunX mtu 1200, where tunX is your tun device. You may have to use a different MTU depending on your network.
Depending on your specific configuration, the connected USB devices may draw more power than the Raspberry Pi can provide through its usual means. Using a USB powered hub like the one mentioned above will let you power the radios through another USB port on the battery. Some cheap USB hubs will "back-power" the hub on the Raspberry Pi. This is suitable as long as you're using a good quality battery, and even useful.
Another solution is to provide additional power to the USB hub using a splitter like this. It works, but I don't recommended it. It is one more thing that could accidentally become disconnected, and is just unruly to organize otherwise.
If you are providing remote control through a tethered cell phone, you should ensure the battery has a full charge when starting the kit, if possible. Some cheap devices may not draw enough current to keep up with the power consumed by a constant data connection.
The combination of multiple radios, the Raspberry Pi, and cellular modem will get very toasty. The Panda PAU06's run especially hot. If you don't mind the heat, you will end up with melted radios or worse. Do a test run with your chosen bag/enclosure at room temperature beforehand, to ensure it provides suitable heat dissipation. If you must use the kit in a hot environment, like inside a vehicle on a warm day, take some extra steps to prevent overheating. In the case of a vehicle, setting the climate controls for A/C and remote starting the vehicle intermittently will suffice.
Some cheap cell phones are prone to overheating due to the combination of the additional gear and the need to regularly transmit data. They may shut off under these conditions, preventing remote control. Placing the phone in a separate compartment from the rest of the kit will help, but you are better off using a different device.
If you intend to operate the kit covertly, keep in mind that the heat may draw attention in unexpected ways. If it is left on the dashboard of a vehicle during a snowy day, it will melt the snow and ice. There will be a nice round clear space on the windshield, centering the kit in view, where everything else is otherwise covered in snow!
Wisp install instructions are detailed in rpi-install.md. The steps should be similar for non-raspian systems. Wisp depends on aireplay-ng from aircrack-ng to transmit deauth frames. Notably, you will need to build Python-3.7.1 for the device, which is also described in the rpi-install.md file.
Wisp depends on another small C program called dream. The source is included as dream.c. Dream depends on libpcap.
Compile dream for your device with the command gcc -O3 dream.c -lpcap.
Dream is a tool for monitoring 802.11 traffic with a line-greppable output. It also saves captured traffic into files with the standard pcap format. Wisp calls dream for each monitoring radio and parses the output for client traffic. Here are its arguments:
--a: Only report traffic from associated clients. (All packets are still logged to disk if --d is enabled.)--d (file): Dump packets to the specified file.-[b][c][d][f][s][t]: Specifies which fields to output per line, specifically:
b: BSSc: Channel number.d: Name of the device which received the packet.f: Frequency.s: Station (STA).t: Pcap timestamp.These fields are always printed in the same order, regardless of the order specified. (That is, -bcst is equivalent to -sctb.)
Wisp reads a json formatted file named wisp.json for configuration. Here is a description of the keys:
monitors: Contains a list of devices to be configured as monitors. Each device contains subkeys describing their specific configuration:
channel: The channel for the device to monitor.injector: The device to be configured to inject deauth frames.timing: Lists several timing parameters, all given in milliseconds:
delay: The delay between deauth packets sent, per client.jitter: Modulates the delay time by a random amount, in the range given.stale: Amount of time a client is not seen before being removed from the delay list. Has little practical effect unless it is close to the delay timespan.