Long time ago I ordered several ESP8266 modules (ESP-201) for my yet-to-be-made home automation system. Not long before that time I had Wi-Fi security related project on "big" PCs. Which inevitably brought me to well known Kali system. So, idea to use tiny ESP8266s for wireless penetration tests come to my mind immediately after I had them on my table. But quick look through early version of Espressif SDK doesn't reveal any "hacker friendly" functions. So, I focused on other applications.

Some time ago I, as a faithful Hackaday RSS feed subscriber, read article about packet injection on ESP8266. This article finally gave me last part of the puzzle and plan for the weekend.

HARDWARE

My hardware setup consists of ESP module, mini DC-DC converter (D-SUN), pin headers, jumper, 9V battery plug and four 4k7 resistors.

Plug for 9V battery can be salvaged from old, discharged battery. Connections between plug and DC converter, and between converter and pin headers are from thick solid iron wire. This makes construction solid and easy to handle. Resistors are connected as required by my ESP module: CHIP, RST -> PullUp; io15 -> PullDown. io0 connected to small 3 pins male header at the side of the assembly. If you put the jumper and pull io0 to ground, you can flash module via TTL level serial cable.

Without jumper, module boots into the "battle" mode. It still outputs some diagnostic messages over serial port, even if there is nothing connected to receive them. As a bonus, small blinking LED connected to serial lines on surface of ESP module shows that something is going on and software is still running :-)

SOFTWARE

I use Arduino IDE (1.6.7), because it can work with all boards I have in my inventory. Also it is multi-platform, I can easily start project on Windows and finish on Linux. I am definitely missing code completion and editor tools from my "working horse" - MS VS, but for the small scale projects it doesn't matter much.

I started with code from original article, but first adopted it for Arduino project, and finally replaced nearly everything, looking with one eye onto the MDK3 source code. My code have couple of strange things, some fixes I made looking at test results, without deep understanding and reading standards. First - I do not have time for complete analysis, and second, let's face the truth, I can't see many usages for this code except to show it to my friends.

Below is the screenshot from wired Kali system which I use for monitoring. You can see how ping to my phone connected over Wi-Fi was terminated after ~10 seconds after I attached battery to assembly. Also you can see Deauthentication packets in Wireshark dump.

Work of software is rather simple. It receives & parses Beacons, Data and QoS frames on given channel. Software keeps lists of discovered Access Points and Clients. If Software doesn't encounter any new AP or Client for 200ms, it starts "deauth" procedure, disconnecting all clients discovered on this channel from corresponding APs. Then software goes to new channel.

Different devices behave differently in response to this attack. One of my phones goes permanently offline, and another manages to reconnect quickly, while software checking other channels. There are several options I can suggest for people who would like to have more stable effect:

There is a catch with Espressif SDK versions and "wifi_send_pkt_freedom" function. As it is mentioned here, "....wifi_send_pkt_freedom can't send management packets and encrypted packets, beacon is one kind of the management packets. We add this limitation because it may effect other devices......"

BUT, this fix is applied by Espressif only in latest versions of SDK. In the SDK version 1.3.0 "freedom" function was already present, but without limitations. You only may need to insert following lines into "user_interface.h":

typedef void (*freedom_outside_cb_t)(uint8 status);
int wifi_register_send_pkt_freedom_cb(freedom_outside_cb_t cb);
void wifi_unregister_send_pkt_freedom_cb(void);
int wifi_send_pkt_freedom(uint8 *buf, int len, bool sys_seq);
Also, it may be good to know that promiscuous, monitor mode capture function "wifi_set_promiscuous_rx_cb" gives access only to first 112 bytes of packet data. This makes impossible more fancy stuff like handshake capture, wireless tap etc. (At least, until somebody hack SDK binaries.)

Source code on the GitHub.

Second Floor

And yet, performance of prototype described above is not enough. The last argument for me was failed demonstration to my son, when his Android smartphone managed to re-connect so quickly that he can browse without actually noticing anything.

But I do not want to give up so easily :-)

After consideration I come up with another idea, not mentioned in details of the first device. We can use two ESP8266 modules. First module will continuously scan for APs and Clients. It will report new Clients to second module via serial port. Second module will send Deauthenticate packets at maximum speed, adding new Clients as they come.

HARDWARE

Both modules installed on two longer female pin headers. Both connected to the same power supply. Both have 2-pin headers to allow boot to flashing mode with jumper. Additionally Tx pin of one module's serial port connected to Rx of another. (Grounds are already connected.) It means port works in simplex mode. Which module is "first" and which is "second" - doesn't matter, software is the same on both. (see below)

The negative side of expansion - reduced battery life. Duty become too heavy even for my "HEAVY DUTY" battery. I didn't measure working time precisely, but I think it is something around 1 hour. So I have to use laboratory power supply for debugging.

SOFTWARE

Of course I am too lazy to make two separate programs. So I made one for both modules, with initial synchronization. After startup both modules send continuous 0xFF sequences for about 3 seconds. But only one of them (candidate for Jammer) receives such sequence. Because of only one wire between serial ports. Information simply can't go other direction.

Finally module without confirmed input become Scanner, module which received at least 10 sequential 0xFFs become Jammer. As a bonus, Jammer have Tx pin free and it can be used to output debug information.

Scanner receives Beacons and Data packets, parsing them, keeps lists of already detected entities. If it sees new Client, it sends to fellow module minimum needed information - channel, MACs and last found packet sequence number. If, for roughly 200 milliseconds there are no new Clients detected, Scanner jumps to next channel. Also it resets Clients counter, to allow same Clients be detected and forwarded again to Jammer. It helps keep packet sequence number on Jammer current and provides more reliability.

Protocol between modules is as simple as it can be. For every Client Scanner sends 15 bytes, starting with channel number. Such packet structure helps with initial synchronization. Jammer module can wait until all 0xFFs from Scanner will run out, they can't be misinterpreted as channels because channel is a number between 1 and 14.

Jammer check serial port for new data, updates its internal table with Clients. After that Jammer sends Deauthentication to all Clients on the current channel and switching to next one.

As a result of using two ESPs, disconnection become much more efficient. Prototype disconnects from the Net two smartphones, laptop and wi-fi enabled printer in two adjacent rooms of my apartment.

MODDING

From the very beginning I don't like much these curved pig tails. In my mind antenna is associated with something straight :-) And now I have two of them very close. I am only have to wonder what kind of interference they cause to each other. And another issue is mechanical stability, construction too easily fall.

And this is how new mod come: "No-Wi-Fi-Coctail-Party-Edition".

I think you can guess where I took these nice tubes for antennas :-) Now Antennas are in one line, causing (as I hope) not so much problems to each other.

And battery have a small magnet attached to the back side. This allows to put assembly on any vertical metallic surface with one move.

Source code on GitHub.

For sure construction needs some final touches to be used safely (at least for the owner) in the wild. All sticking out contacts should be isolated or removed. I am even thinking about slim 3D printed box. I didn't do yet it because maybe I will find some use for available ESP8266 inputs/outputs.