The WiFi Dodecauthenticator

Posted on by glitch0ne

Versiunea în Română: https://glitch0ne.com/2021/01/09/ro-the-wifi-dodecautenticator/

Disclaimer: The things I’m about to tell you about should only be tried on personal devices or with the explicit consent of any targets. I’m not responsible for the malicious use of the information presented below. Thank you, and godspeed!

A few years ago I had the pleasure of seeing firsthand what the WiFi Cactus from Mike Spicer [@d4rkm4tter] looked like and what its capabilities were. Then, through some of my research (a.k.a. randomly browsing the interwebz) I found out that people sometimes use cheap WiFi chips to build deauthentication devices that kick people off of their WiFi network. So, inspired by the WiFi Cactus mantra of “do the thing but on all WiFi channels” I thought, what if I had a bunch of chips that stayed on specific channels instead of just jumping channels every once in a while? Of course, then you’re also missing traffic while you’re out sniffing for packets, so what if I separated the functionality, one chip to do the sniffing, and one to do the kicking. And thus, the idea of the WiFi Dodecauthenticator of Death was born.

1. The off the shelf hardware

The main part of this whole endeavor is usually a ESP chip. I used an ESP8266 (the ESP-07 version), because it was cheap enough to get in bulk but also because it has an IPEX connector which means I can upgrade from the weak ceramic antennas that these things usually have. For the prototype I used a couple of IPEX to RP-SMA extenders and a couple of 2dbi antennas I had laying around so that I would get decent reception and transmission ranges. Other than this, I had to use a USB to TTL converter for programming and a bunch of 1k resistors and headers to make sure that I can start the chips up and program them. Additionally, considering that I had to power a total of 22 ESP chips together with auxiliary LEDs, I needed a power supply beefy enough to sustain the full amp load of all of the chips while supplying 3.3v. I decided on using a 5v, 4A power supply hooked up to the Pololu D36V28F3 step-down regulator, which can reliably supply up to 4.5A at 3.3v. Even though my chips would probably not hit that full amp load continuously, I considered that 22 chips running at a theoretical maximum of about 200mA per board would put me at about 4.4 amps of peak load. With that said, the average draw of one of these chips is around 80mA, so I can say that the power supply side of this was reliably over-engineered.

2. The custom hardware

In order to have all eleven channels scanned and attacked at the same time, I needed to design and build a custom PCB that would hold two chips, and I needed to find a way to connect and power eleven boards. Normally, I would go for plain ‘ol stacked, squared PCBs but for some reason, I thought about the fact that I could mount them up in a dodecahedron shape. A regular dodecahedron is a 12-sided shape that some of you may know as a D12 die. All of the shapes are exactly the same, being pentagonal in nature, and because I would technically only need eleven sides for my eleven channels, I could use the bottom as a stand, so that everything is in view. Therefore, I designed a pentagonal PCB, with 2.2mm holes in each of its five corners that would fit M2 machine screws. Each PCB needed to fit the resistors that the chips needed to start up together with any other auxiliary items like LEDs and headers that I would short with jumpers so that I can select channels externally and not with custom code for each PCB.

In order to power up and use a bare-bones ESP8266, I needed to add a few resistors that connected either the ground (pull-down) or the 3.3v line (pull-up) to some of the pins. To be more precise, I had:

  • One 1k pull-down resistor to GPIO_15.
  • One 1k pull-up resistor to the CH_PD pin.
  • One 1k pull-up resistor to the RESET pin.
  • One 1k pull-up resistor to the GPIO_0 pin.
Image courtesy of Pieter P: https://tttapa.github.io/ESP8266/Chap01%20-%20ESP8266.html

In order to program the ESP8266, I needed to put the board in programming mode which is normally done with a smaller value pull-down resistor on GPIO_0. However, I just shorted GPIO_0 to GND with a jumper, and fortunately the magic blue smoke didn’t escape the chips. If you’re doing this yourself, just use a resistor that has a smaller ohm value than the pull-up you have on GPIO_0, to be safe.

After setting up the needed parts I also wanted to find a way to “communicate” to the board without altering the code. I accomplished that by using run-of-the-mill headers that I would short to ground to input data to the board, and a couple of LEDs to output data from the board. In the end, these were the parts that I needed to fit on the PCBs:

  • Two ESP8266 boards.
  • Eight resistors (four per ESP), in order to get the ESPs to start up.
  • Two 6 pin headers (one per ESP), for programming and serial debugging.
  • One 2×2 pin header to connect RX to TX for both boards, by connecting the pins with jumpers. I need this so that the chips can communicate with each other.
  • One 2×2 pin header to connect power from one half of the board to the other, in case I needed to debug one side while the other was powered off, which ended up happening multiple times.
  • Two 2×5 pin headers for selecting the channel and whether an ESP is main or secondary.
  • Ten more resistors (five per ESP), to properly read the values from the channel selection headers.
  • Four LEDs (two per ESP) because lights. Also for debugging.
  • Two JST-XH two pin connectors, for power delivery to and from the boards.
  • Two reset buttons (one per ESP).

After putting together the parts in Fritzing, my PCB designer software of choice, I had to design a couple of 3D printable parts to hold everything together. More precisely, I needed corners and a base. Each corner had to have the proper 2.2mm hole for the screws as well as enough spacing to hold three boards when all was mounted, without the boards colliding. As for the base, I just had to take the PCB outline and extrude it. It was a bit more work than that to get everything to fit together, look nice and fit a barrel connector for power delivery, but eventually I had a thing going.

3. The software

After designing the hardware side of the project, I needed to trick these rocks into thinking. One of the reasons for which I wanted to use the ESP8266 chips was that those were the only ones I knew of that were programmable with the Arduino IDE, which I was familiar with. Additionally, because this particular use-case (deauthentication attacks) was not anything new, there were already plenty of open-source code snippets that I could use and adapt for my particular use case. In my case, I used code from a fella named RandDruid after I read his article on this very attack about two years ago, which you can find here: A weekend on the dark side

The code I initially grabbed from GitHub was however lacking certain functionalities that I wanted in my project. Namely, I wanted to separate the “sniffing” from the “attacking” and I also wanted the chip to stay on one channel instead of skipping channels every once in a while. Therefore, I modified the promiscuous callback function that was called each time the ESP chip detected a packet. Adding a send_data() function which sent the information needed for deauthentication (that was normally on the same chip) over to the other chip via Serial communication was really the biggest modification to the original code. I tried a bunch of workarounds but eventually I had to simply send each element of the structure on its own in order to be sure that the information got transmitted properly. On the receiving side, I only had to read the information in the same order as it was sent and assemble it back together in the proper format and we were off to the races.

After receiving the information and saving it into an array, came the time for the fun stuff to happen. I had to kick people off of their WiFi networks. Now, a few years ago the fellas over at Espressif who make the chips that are powering the ESP8266 and who also build the SDK I used for programming them, decided that the chips should not be allowed to send malformed and management packets, starting with the 1.4 version. Naturally, this broke people’s hearts and they stormed the city gates to claim what was rightfully theirs. That or they just decided to just use the old SDK. My memory’s a bit fuzzy regarding that subject. Of course, the people maintaining the main Arduino IDE board repository kept up with the changes and put them into the IDE, which meant that unbeknownst to me, there was no way that my attacks would ever work. The ESP would just refuse to send those packets.

Luckily, I had some hardware laying around that I use for another project and which was capable of detecting deauthentication attacks, so I could debug that. By using good ‘ol debug prints to Serial I also learned that my code was entering the function that was meant to do the deauthenticating and at least tried to send the packets. Lastly, I knew of DStike’s deauthentication boards, which are being sold to this very day, so it’s obvious that somebody made this particular attack work. Luckily, the people maintaining the DStike repository also provided a link to an Arduino IDE board repository which had an SDK capable of sending deauthentication packets. You can find the repository link here: https://github.com/SpacehuhnTech/esp8266_deauther/wiki/Installation#compiling-using-arduino-ide

4. Tying it all together

In order to program the chips, I first needed to load the .ino sketch into the Arduino IDE, select the “Generic ESP8266” board from the “Deauther ESP8266 Boards” list, and then check if the following settings were, well, set:

  • Builtin Led: 2
  • Upload Speed: 115200
  • CPU Frequency: 80 MHz
  • Crystal Frequency: 26 MHz
  • Flash Size: 1MB (FS:64KB OTA:~470KB)
  • Flash Mode: DOUT (compatible)
  • Debug port: Disabled
  • Debug level: None
  • IwIP Variant: v2 Lower Memory
  • VTables: Flash
  • Exceptions: Legacy (new can return nullptr)
  • Erase Flash: “Only Sketch”
  • SSL Support: All SSL ciphers (most compatible)

Now, I’m not completely sure that I needed all of these, or even if these are completely correct. But, they came as default in the IDE and they worked for my ESP8266 board, so maybe they’ll work for you, too.

For the actual programming part I used a CP2102 USB 2.0 to TTL Module Serial Converter connected to the RX, TX, GND and VCC pins that I exposed in a header on the PCBs for easy programming and debugging. Do note that you have to connect the TX pin of the serial converter to the RX pin of the chip and viceversa, the RX of the converter to the TX of the chip. Also, make sure that you are connecting the VCC pin to the 3v line of the converter, as the 5v line will fry the chip.

Of course, now came the first of the issues stemming from my lack of experience with this chip. I had initially planned to use GPIO_2 to set whether or not the board was a main or secondary board. The problem with that was that the ESP8266 needs GPIO_2 to always be high at boot. That eliminated the possibility of me using it for data input. To fix this, I removed one of the planned LEDs that was connected to GPIO_4 and switched it for a 1×2 pin header as it had the same 0.1″ spacing. I therefore lost one set of LEDs, but gained the ability to set the main flag of my code.

After this, came another issue that to this day I don’t know the cause of. When I first did the preliminary testing with some “beta” code, I was getting really weird behaviours in the Serial communications between the boards. It seemed that the data was being corrupted on the way to the secondary board, and the behaviour was utterly random. Sometimes everything worked flawlessly, sometimes nothing worked. Eventually, I figured out that the issue stemmed from the fact that the TX pin of the USB converter used for programming was connected to the RX pin of the secondary board, and that somehow messed with the serial data being transmitted by the main board. I don’t know why that was the case as I wasn’t transmitting anything from the USB converter, but alas, disconnecting that pin while testing “fixed” the issue for me. If you have any idea why I was getting that behavior, hit me up, I wanna know.

When everything was said and done, I needed to test the code that I had made. Of course, kicking people off of their own WiFi networks is borderline illegal, and mainly very annoying, so I wanted to make sure that I had no way of affecting networks and devices I did not own. So, I used the “whitelist” functionality that was already present in the code and essentially turned it on its head by adding my own MAC addresses to it and only deauthenticating what was on that list, instead of deauthenticating what wasn’t on it. Like I mentioned in the previous section, when I first plugged the code in and ran it, no attacks were going off from the board, which I detected (or rather, didn’t) by using Wireshark and Kismet. Kismet alerts of any deauthentication attacks if you have it running and if you sniff WiFi traffic and then analyze it with Wireshark, it’s pretty easy to see if someone’s performing a deauthentication attack. After I figured out the issue and switched to the DStike SDK and boards, I powered on my prototype board, et voila, Kismet lit up like a Christmas tree. It was working.

Of course, that was just one prototype board. I had to solder 11 more of them, and assemble everything by using the 3D printed corners I designed and a whole bunch of M2 machine screws and spacers, while also adding some decorative laser cut plexiglas pieces that held the 22 3dbi antennas connected to the ESP boards.

The final problem I encountered when putting everything together and firing up some of the PCBs was a very high voltage drop that was happening at the end of my chain. The pentagonal PCBs were designed to be daisy-chainable so that power moved from one board to the other, while also keeping the PCBs electrically in parallel, so if one burned out, the rest of the boards would still technically work. However, I was not aware at the time that the traces and connecting wires I had used were not suitable for the job, causing me to drop from 3.3v to about 2.9v at the end of the seventh board when everything was daisy-chained together. This meant that the chips (which were rated for a minimum input voltage of 3.0v) could not run properly. Fortunately, I had a piece of proto-board laying around that I quickly made a 12 port power distribution board from, bypassing the traces and allowing me to have about 3.24v supplied to all of the boards. Thus, I had learned that long, skinny wires and traces will cause your voltage to drop significantly.

When everything was put together I plugged in the power supply and all eleven boards lit up like a Christmas ornament, with green LEDs flashing randomly through the panel antennas of each board. It was beautifully scary, because the thing essentially looks like a nuclear device prop.

5. Conclusions

In the end, this project took way longer than I would like to admit. And while it may not be in a finished state, it works. And if I load the combat-ready code on it, it will kick people off of WiFi until the cows come home. But right now, it is essentially harmless, and most likely will stay that way until I need to demo it for whatever reason. What I want you to take away from this is the fact that the issue I’m exploiting with this has been around since forever, and only just got patched a couple of years ago with the arrival of WPA3. However, few consumer-grade devices that I know of use WPA3 and even fewer support Management Frame Protection (802.11w), so a lot of devices out in the real world are still vulnerable to this. And while this specific attack may not be that powerful or destructive in and of itself, it paves the way for other, more powerful attacks like brute-forcing one’s WPA passkey. In essence, you can think of my device as a pretty (or menacing) little work of art that demonstrates that hacking can also look good. And that you should upgrade your devices.

Dodecauthenticator image preview
The WiFi Dodecauthenticator of Death in all its glory.

6. Future plans

In the future, if I’ll ever lose enough neurons to want to build one of these things again, I want to make the following changes:

  • Make it easier to debug by adding test pads all over the PCBs.
  • Use I2C for communication between the ESP8266 boards.
  • Use the proper GPIO pins off of the ESP8266 boards.
  • Use a ground plane for the PCBs.
  • Use dip switches or encoding switches for channel selection.
  • Use a switch or button instead of jumper for programming.
  • Use SMD resistors and LEDs.
  • Use black solder mask.
  • Use thicker gauge wires and traces for power delivery.
  • Use one power supply or step-down converter per board, and supply 12v DC to all of them to mitigate voltage drop.
  • Get higher gain antennas and make it spiky.

Trivia

  • There’s 20 corners (or vertices) in a regular dodecahedron.
  • The angle between each pentagon face is called the dihedral angle. Its value is 116.57 degrees.
  • Each interior pentagon corner has a value of 108 degrees.
  • Some numbers:
    • 22 ESP8266 boards
    • 242 Resistors
    • 352 Soldered pads
    • 484 Soldered headers
    • 110 M2 machine screws
    • 55 M2 10mm spacers
    • at least 17 work hours spent soldering, assembling and programming this bloody thing. And that’s after I wrote the final “beta” version of the code that’s on all the boards.
  • If I never solder another thing in my life, it’d be to soon… But I loved every minute of it.

References

Leave a comment