DEV Community: Donato Maglie

Title: Building an ESP32 Multi-Tool - Part 3: Packet Sniffing, Deauth Detection, and Web Portal

Donato Maglie — Fri, 18 Sep 2026 22:18:04 +0000

In the previous articles of this series, I covered how I turned an ESP32-S3 into a BadUSB and built the FreeRTOS and LVGL architecture to run everything. Now it's time to actually use the radio. The ESP32 is famous for its Wi-Fi capabilities, and leaving it as just an offline hardware tool felt like a waste.

For network analysis, having a portable device that can monitor 802.11 traffic is a game changer. The ESP-IDF APIs are pretty flexible. Instead of just connecting to a router like a normal IoT device, we can set up a SoftAP or put the silicon into promiscuous mode to sniff raw frames right out of the air.

This post breaks down how I built the network modules for my multi-tool. I'll walk through the local Web Portal I use to upload payloads wirelessly to the LittleFS filesystem, the network scanner, and the packet sniffer that saves .pcap files directly to memory. I also added a "Deauth Radar" to catch Wi-Fi deauthentication attacks in real-time.

Handling all these network events without crashing the limited RAM of the microcontroller required some specific architectural choices, which I'll share below.

1. The Bridge: SoftAP and Web Portal

In part one, I showed the BadUSB executing DuckyScript payloads. The problem was that updating those scripts meant plugging the device into a PC over serial every single time. I needed a wireless way to transfer files.

I configured the ESP32 to run in WIFI_MODE_AP to broadcast its own network. I used the esp_http_server component from ESP-IDF to serve a retro-themed HTML interface. The server has a few endpoints, like /upload for normal files and /upload_payload which routes DuckyScript files straight into a specific LittleFS folder.

Handling uploads on an embedded device is tricky. If you try to buffer a 2MB file in RAM on an ESP32, you're going to get an Out-Of-Memory crash immediately.

To fix this, the upload handler works as a stream. First, it checks esp_littlefs_info to make sure there's actually enough flash storage left. If there is, it reads the HTTP request in small chunks using httpd_req_recv and flushes each chunk directly to the flash memory with fwrite.

Here is the streaming logic I wrote in tool_rete.c:

// Safety check: verify available storage on LittleFS
size_t total = 0, used = 0;
esp_littlefs_info("storage", &total, &used);
size_t free_space = total - used;

if (req->content_len > free_space) {
    httpd_resp_send_err(req, HTTPD_500_INTERNAL_SERVER_ERROR, "Insufficient disk space!");
    return ESP_FAIL;
}

FILE *fd = fopen(filepath, "w");
char buffer[512];
int remaining = req->content_len;

// Stream processing: read from socket and write directly to flash
while (remaining > 0) {
    int to_read = (remaining < sizeof(buffer)) ? remaining : sizeof(buffer);
    int read_bytes = httpd_req_recv(req, buffer, to_read);

    if (read_bytes <= 0) {
        if (read_bytes == HTTPD_SOCK_ERR_TIMEOUT) continue; // Non-blocking retry
        fclose(fd);
        remove(filepath); // Clean up partial file on error
        return ESP_FAIL;
    }

    fwrite(buffer, 1, read_bytes, fd);
    remaining -= read_bytes;
}

fclose(fd);
httpd_resp_sendstr(req, "File successfully saved to LittleFS!\n");
return ESP_OK;

This keeps the memory footprint completely flat during the transfer, so the rest of the OS keeps running smoothly.

2. Network Discovery: The Wi-Fi Scanner

Before playing around with network diagnostics, the tool needs to know what APs are around. I built a simple network discovery module that turns the ESP32 into a Wi-Fi scanner.

It uses esp_wifi_scan_start() and esp_wifi_scan_get_ap_records(). When you trigger the scan from the UI, it drops into Station mode (WIFI_MODE_STA) and scans the 2.4GHz channels.

One issue I ran into was that doing a blocking Wi-Fi scan on the main thread freezes the LVGL interface entirely. ESP-IDF supports async scans, but I found it cleaner to just run a synchronous scan inside a separate, low-priority FreeRTOS task. This way, the UI stays responsive, and when the scan is done, I lock the LVGL mutex and update the screen.

After the scan finishes, I grab the array of wifi_ap_record_t structures. I pull the BSSID, SSID, channel, and RSSI, and use that data to build a scrollable list of buttons on the screen.

// Configure the scan parameters
wifi_scan_config_t scan_config = {
    .ssid = NULL,
    .bssid = NULL,
    .channel = 0,
    .show_hidden = true
};

// Start a blocking scan in the background task
esp_wifi_scan_start(&scan_config, true);

// Retrieve the number of discovered Access Points
uint16_t ap_count = 0;
esp_wifi_scan_get_ap_num(&ap_count);

// Allocate memory and fetch the records
wifi_ap_record_t *ap_records = malloc(sizeof(wifi_ap_record_t) * ap_count);
esp_wifi_scan_get_ap_records(&ap_count, ap_records);

// Iterate through records to extract intelligence
for (int i = 0; i < ap_count; i++) {
    printf("SSID: %s, BSSID: %02x:%02x:%02x:%02x:%02x:%02x, CH: %d, RSSI: %d\n",
           ap_records[i].ssid,
           ap_records[i].bssid[0], ap_records[i].bssid[1], ap_records[i].bssid[2],
           ap_records[i].bssid[3], ap_records[i].bssid[4], ap_records[i].bssid[5],
           ap_records[i].primary,
           ap_records[i].rssi);

    // The extracted data is then used to populate the LVGL scrollable list
}

free(ap_records);

This gives me the exact channels and MAC addresses I need to configure the sniffer and radar later.

3. Entering the Matrix: Promiscuous Mode and the PCAP Sniffer

Scanning is fine, but I wanted actual packet sniffing. Normally the Wi-Fi chip ignores frames that aren't meant for it. If you enable promiscuous mode, the hardware forwards every 802.11 frame it hears on the current channel to your code.

Setting it up is easy enough:

esp_wifi_set_promiscuous(true);
esp_wifi_set_promiscuous_rx_cb(&wifi_promiscuous_cb);

The real problem is the I/O bottleneck. The wifi_promiscuous_cb callback is an interrupt that fires thousands of times a second on a busy network. Writing to LittleFS is slow and blocking. If you call fwrite inside that Wi-Fi callback, you will instantly trigger a Watchdog Timeout and crash the board.

I solved this by setting up a basic Producer-Consumer pipeline with a FreeRTOS Queue.

The Wi-Fi callback acts as the producer. It grabs the payload, adds a timestamp using esp_timer_get_time(), and pushes the struct into a queue using xQueueSendFromISR. If the queue is full because traffic is too heavy, it just drops the packet to keep the radio alive.

Then I have a separate, lower-priority task (sniffer_write_task) acting as the consumer. It waits on xQueueReceive. When a packet pops out, it handles the slow fwrite to the flash memory without blocking the Wi-Fi interrupts.

To make this data useful, I had to save it as a valid .pcap file so I could open it in Wireshark later. When the sniffer starts, it writes a standard PCAP global header with the magic number 0xa1b2c3d4. Then, for each packet, it writes a packet header containing the length and microsecond timestamp, followed by the raw 802.11 frame.

// The Consumer Task
static void sniffer_write_task(void *arg) {
    sniffer_packet_t pkt;
    while (1) {
        // Wait for a packet from the Wi-Fi callback queue
        if (xQueueReceive(sniffer_queue, &pkt, portMAX_DELAY) == pdTRUE) {
            if (pcap_file && sniffer_running) {
                pcap_packet_header_t hdr;
                hdr.ts_sec = pkt.ts_sec;
                hdr.ts_usec = pkt.ts_usec;
                hdr.incl_len = pkt.length;
                hdr.orig_len = pkt.length;

                // Write the PCAP packet header
                fwrite(&hdr, sizeof(pcap_packet_header_t), 1, pcap_file);
                // Write the raw 802.11 frame payload
                fwrite(pkt.payload, 1, pkt.length, pcap_file);
                fflush(pcap_file);
            }
        }
    }
}

This decoupling lets the ESP32 survive traffic spikes and gives me clean files I can actually analyze on my PC.

4. The Deauth Radar: Real-Time Attack Detection

Saving packets for later is cool, but I also wanted a real-time warning if a deauthentication attack was happening around me.

For this "Deauth Radar", I kept the ESP32 in promiscuous mode but applied a hardware filter: WIFI_PROMIS_FILTER_MASK_MGMT. This tells the Wi-Fi silicon to ignore data frames and only pass management frames to my callback, which saves a massive amount of CPU cycles.

Inside the callback, I look at the first byte of the MAC header. If it's 0xC0 (Deauth) or 0xA0 (Disassoc), I pull the source, destination, and BSSID MAC addresses to figure out who is attacking who.

Since attacks can happen anywhere, I made a small FreeRTOS task that hops the Wi-Fi channel every 250 milliseconds to sweep the whole spectrum.

I also had to be careful with RAM. Tracking every deauth packet would eat the heap immediately. Instead, I keep a small array of structs in RAM tracking up to 10 APs and 20 targets each.

I also had to account for false positives, because regular deauth frames happen naturally when devices roam or disconnect. My logic only flags a device as "Under Attack" if it gets hit with a fast burst of more than 20 deauth frames.

// Inside the promiscuous callback
if (len >= 24) { 
    uint8_t fc = pkt->payload[0];
    // Check for Deauth (0xC0) or Disassoc (0xA0)
    if (fc == 0xC0 || fc == 0xA0) {

        uint8_t *addr1 = pkt->payload + 4;  // Destination
        uint8_t *addr2 = pkt->payload + 10; // Source
        uint8_t *addr3 = pkt->payload + 16; // BSSID

        // Determine the victim based on the packet direction
        uint8_t *victim = (memcmp(addr2, addr3, 6) == 0) ? addr1 : addr2;

        // Log the target in RAM to track the packet count
        radar_add_to_log(addr3, victim, current_radar_channel);
    }
}

Once that threshold is hit, it sets a flag. The LVGL UI timer picks up the flag, throws a warning popup on the screen, and writes the attack details to a text file for later.

Wrapping up

By using the ESP-IDF Wi-Fi APIs and managing memory with FreeRTOS queues and streams, I managed to turn a standard ESP32 into a pretty decent network analysis tool. It now has a web portal for payloads, a Wi-Fi scanner, a PCAP sniffer, and a real-time deauth radar.

Next time, I'll switch gears from security to the UI and show how I built a Game Boy-style interface and put some playable retro games on this thing.

Exploiting "Trust-by-Default": How I transformed an ESP32-S3 into a BadUSB

Donato Maglie — Tue, 08 Sep 2026 18:25:34 +0000

The first tool I decided to arm my Swiss army knife with was a BadUSB emulator. First and foremost, this extremely powerful tool (provided you have physical access to the target machine) relies on an inherent vulnerability of the USB protocol (born in 1996), originally designed to make connecting peripherals as simple and invisible as possible.

Practically, when we plug a USB device into a computer, a rigorous process called Enumeration begins. This is divided into several phases: the device is physically connected, its communication speed is identified, and immediately after, the device sends its Descriptors. These descriptors are a set of vital information that defines how the host machine will communicate with the device; subsequently, the device is reset, an address is assigned to it, the interfaces are loaded, and finally, the drivers.

(If you want to delve deeper into the enumeration phase, I recommend this article by TotalPhase).

Having defined this, it's easy to guess that if we alter the descriptors via software, we can disguise an ordinary flash drive (or in our case, an M5Stick) making it appear as a keyboard or a mouse.

And this is where the "Trust-by-Default" vulnerability comes into play: all operating systems blindly trust an HID (Human Interface Device) like a keyboard, as it is an essential input tool. Generic drivers are already pre-installed in the kernel (zero incompatibilities or warning popups) and, moreover, antiviruses have no say in the matter, since they are not designed to scan hardware inputs sent via electrical impulses.

The architectural choice: Dynamic Parser vs Hardcoding

Initially, for "simplicity", I thought about hardcoding the payloads directly in the C source code. But thinking about it carefully, the use cases in pentesting are infinite: the end-user must have the ability to modify scripts on the fly, without having to recompile or flash the ESP32 firmware every time.

For this reason, I decided to implement a dynamic Parser for DuckyScript. This allows the user to upload their own plain text scripts (.txt) onto the device's LittleFS memory and have the microcontroller interpret them on the fly.

For those unfamiliar with it, DuckyScript is a macro language created by Hak5 that abstracts interaction with the victim machine. It's simple and easily readable.
To better explain what I mean by "abstract": if I were to write a payload directly in low-level C or Bash, I would have to carefully calculate every single delay between one command and the next to give the PC time to open windows, and I would have to manually map the hexadecimal codes (HID Keycodes) of every single key to "press". DuckyScript, combined with my parser, automates all of this.

Originally, to use Rubber Ducky scripts, they had to be transformed from simple text files into binary files; this conversion was performed by a PC tool called Ducky Encoder, which converted them into inject.bin. This tool was used because many older devices lacked the computational power to analyze text during runtime, a problem that the ESP32-S3 has now overcome.

So I decided to integrate a native parser into my code: this way, a user can simply upload a file from their phone (via the dedicated internal HTML page) or from a computer and execute it immediately, without having to use an external tool for the conversion. Practically, this is done using standard C functions to separate the actual command from the argument at runtime:

char *cmd = strtok(line, " ");
char *arg = strtok(NULL, "");

if (strcmp(cmd, "DELAY") == 0 && arg) {
    int delay_ms = atoi(arg); 
    if (delay_ms > 0) { 
        vTaskDelay(pdMS_TO_TICKS(delay_ms)); 
    }
}

RAM Security: O(1) Space Complexity

But we all know that C doesn't joke around when it comes to memory allocation, so I tried to make the script reading phase as secure as possible. The underlying problem is that if a user decided to use a very long script (for example, uploading an entire binary file encoded in text), the M5Stick S3 would risk running out of the memory designated for the SRAM, resulting in a Kernel Panic followed by a crash and a device reboot.

To bypass this hardware limit, I thought of allocating a buffer that reads the uploaded file in small, controlled blocks with the help of the fgets() function, which is memory-safe by nature. This mathematically prevents a Buffer Overflow from occurring: even if the user uploads a malicious or malformed file with a single line 10,000 characters long, fgets will still only read the first 255 characters per cycle, safeguarding the microcontroller's stack.

If we look at the reading process from a space-complexity perspective, you can see that the way I decided to implement this mechanic has a space complexity of O(1); whereas the classic implementation would have had a complexity of O(N), as it would have loaded the entire file into RAM simultaneously.

// RAM consumption locked at only 256 bytes
char line[256];

// The file is strictly read and processed line by line
while (fgets(line, sizeof(line), f)) {
    trim_trailing(line); 
    if (strlen(line) == 0) continue;

    // ... start parsing for this specific line ...
}

Beyond abstraction: USB Protocol and Polling Rate

Despite all the numerous advantages that come from using the ESP32-S3, one "limit" remains: not being able to use libraries that allow a high level of abstraction, such as Arduino's Keyboard.h. This is a problem because, in the USB standard, a keyboard must regularly build and send 8-byte raw packets (divided into modifier mask, protocol byte, and key array) known as HID Reports.

Sending these reports falls under the polling operation, which is a mechanism by which the Host (the PC) cyclically queries the USB device to check if there have been any state changes. Specifically, I handle these cyclic requests with tud_hid_ready(), which checks if the USB Endpoint is free and if the PC has confirmed the reception of the previous packet. Through the while (!tud_hid_ready()) vTaskDelay(...) block, I prevent the ESP32 from overwriting its own buffer before the packets have actually traveled across the cable. Without this blocking check, the keystrokes would be "dropped" (lost), and a DuckyScript command like STRING powershell would be read by the victim PC as an incomprehensible pwsel.

State-Based Logic and the Auto-Repeat Trap

Added to this strict temporal "dance" of polling is one last huge engineering pitfall related to the nature of 8-byte reports. The most common cognitive error people run into is thinking that USB sends "print commands" (e.g., "type the letter R"). In reality, the USB architecture imposes a State-Based logic: the keyboard only communicates its electromechanical state to the PC at that precise moment.

When we send a report with a specific key, we are not telling it to print it, but we are communicating: "Right now, the user is physically pressing this key".

The operating system's driver receives this state. If the microcontroller were to immediately move to the next command without doing anything else, the PC would think the user's finger was glued to the key, triggering the operating system's Auto-Repeat (which would endlessly open dozens of windows or print RRRRRRRR...). To solve this problem, my firmware is forced to close the cycle by always sending a subsequent "zeroed" HID Report (passing the NULL array to TinyUSB). This tricks the PC, communicating that the key's physical contacts have finally been released (Key Release), allowing us to safely move on to the next letter.

Conclusion

Developing a low-level BadUSB emulator using esp_tinyusb is an immensely more educational challenge compared to using "pre-built" libraries. It forces you to study the anatomy of USB packets, understand how operating systems handle polling, and deal with the physical limits of a microcontroller's memory.

Now our digital "Swiss Army Knife" has its first real weapon, capable of uploading and launching payloads on the fly in total safety.

But a multi-tool isn't just a keyboard. What if we used the ESP32's antenna to intercept the invisible data floating in the air? In the next article, I'll show you how I configured the network interface in promiscuous mode to turn the ESP32 into a Wi-Fi Sniffer, capable of capturing raw packets and saving them directly to the file system in .pcap format, ready to be analyzed on Wireshark.

From Arduino to ESP-IDF: The architecture behind my digital "Swiss Army Knife"

Donato Maglie — Mon, 31 Aug 2026 20:52:11 +0000

1. Why build another multi-tool?

How many of you have often found yourselves wanting to buy a Flipper Zero? I thought about it many times, but there were always problems holding me back: stock is often limited, the price tag is quite high, and above all, you miss out on the thrill of building such a powerful tool literally from scratch.

From these observations, my project was born: designing and developing a low-level "Swiss Army Knife".

It all started a few months ago. I was thinking about buying an M5Stick S3 after watching some videos online where people spoke very highly of it, especially for one major detail: unlike the Flipper, it has Wi-Fi and Bluetooth modules already built-in.

Digging deeper, I quickly realized the advantages of the ESP32-S3 over the classic Arduino. The key features that convinced me were:

Dual-core processor: It opens the door to serious features, like managing firmware tasks separately.
More RAM: It allows integrating very complex external libraries (like heavy graphical interfaces) without killing performance.
Native USB HID: It allows emulating peripherals like keyboards or mice natively and quickly.

So, the hardware was decided. But why build a multi-tool?

The main reason is to explore and understand the technical background of as many tools as possible. Lately, I feel there is a tendency to overlook the ingenuity of the mechanisms operating right in front of our eyes. We prefer having a ready-made tool, usable perhaps without even knowing the basics of computer science. I wanted to go in the opposite direction and understand exactly how these things work at the code level.

2. Fluid Graphics and Multitasking: How not to blow up an ESP32

A major problem when rendering a graphical interface on a microcontroller is that the CPU has to calculate and send every single pixel. Since this is a time-consuming operation, the entire device gets blocked until the whole interface is completely redrawn. In a multi-tool, if the ESP32 is stuck drawing buttons, it cannot sniff packets or execute attacks.

To solve this problem and make the device truly responsive, I decided to use DMA (Direct Memory Access). DMA is a dedicated hardware component that allows peripherals (in this case the SPI display) to read data directly from RAM without involving the CPU, generating a single interrupt only when the transfer is complete.

I initialized the SPI bus asking ESP-IDF to automatically assign a DMA channel:

spi_bus_initialize(SPI2_HOST, &buscfg, SPI_DMA_CH_AUTO);

The RAM problem and Chunk Rendering

However, implementing DMA without the right precautions wouldn't have been enough. The device's screen resolution is 135x240 at 16 bits, which requires a total of 64.8 KB to be rendered. This leads to two major problems:

Wasting so many resources just for the interface is not sustainable for a microcontroller.
It is virtually impossible to find 64.8 KB of contiguous memory inside the RAM once the system is running.

To bypass this issue, I decided to divide the screen into horizontal "slices" of 20 lines each (about 5.4 KB total). Using the advanced ESP-IDF APIs, I allocated this buffer in a memory area compatible with DMA:

lv_color_t *buf1 = heap_caps_malloc(LCD_H_RES * 20 * sizeof(lv_color_t), MALLOC_CAP_DMA);

This way, we optimize RAM usage while still maintaining super fluid rendering.

At this point, a question arises: how does LVGL (the library I use to manage the interface) know when the DMA has finished sending the bits for those 20 lines? Simply, with a Hardware Interrupt system that defines this flow:

LVGL fills the buffer and calls the driver.
The driver passes the buffer to the DMA controller.
When the transmission process ends, the interrupt is triggered.
The interrupt immediately calls a callback (notify_lvgl_flush_ready) which orders LVGL to calculate the next slice of the interface.

static bool notify_lvgl_flush_ready(esp_lcd_panel_io_handle_t panel_io, esp_lcd_panel_io_event_data_t *edata, void *user_ctx) {
    lv_disp_drv_t *disp_driver = (lv_disp_drv_t *)user_ctx;
    lv_disp_flush_ready(disp_driver);
    return false;
}

Semaphores for Safety (Thread-Safety)

Since FreeRTOS is a system based on multi-threading, it is important to implement proper task management. A fundamental detail to know is that LVGL is not thread-safe by design. This means that the library has no internal mechanisms to protect itself: if two different tasks try to access or modify the graphical interface at the exact same moment, the system will crash.

To prevent these race-conditions, which can lead to data inconsistency and deadlocks, I implemented a Semaphore (Mutex) system: every time an external task (other than the graphical one) wants to modify a GUI element, it must first "take" the semaphore.

lvgl_mux = xSemaphoreCreateMutex();

If the graphical task is already working, the network task (for example, the WiFi sniffer) waits in queue for a few milliseconds until the Mutex is released. This guarantees that LVGL's memory is read or written by only one thread at a time, making the firmware solid and crash-proof.

3. Data Security and Crash Prevention

Having a responsive interface and fast loading times is not enough: we also must try to make the firmware as robust as possible against hardware failures.

This justifies the choice of the file system: LittleFS. Unlike the classic FAT32 or SPIFFS (which would corrupt the disk leading to the loss of all data in case of sudden shutdown), LittleFS was specifically designed for battery-powered microcontrollers and can maintain its integrity even if the power is suddenly cut off.

esp_vfs_littlefs_conf_t conf = {
    .base_path="/memoria",
    .partition_label="storage",
    .format_if_mount_failed = true, 
    .dont_mount = false,
};
esp_err_t ret = esp_vfs_littlefs_register(&conf);

A great engineering practice is using the .format_if_mount_failed = true parameter, which allows handling the very first boot of the firmware on an empty memory by simply formatting it entirely on its own, without the user having to do anything.

How to read Giant Payloads without running out of RAM

The second major risk for stability is reading files. Many microcontrollers have very limited RAM that fills up in an instant if you try to open a file of several Megabytes all at once.

To prevent the BadUSB tool from going into Out of Memory when executing complex payloads, I decided to implement a "line-by-line" reading. Think of it a bit like an e-reader: it doesn't load the whole book into memory, but only shows the small part of text you are reading, allowing you to scroll through the pages interacting with the interface.

My parser dynamically loads only 256 bytes at a time:

bool esegui_duckyscript(const char *path) {
    FILE *f = fopen(path, "r");
    if (!f) return false;

    char line[256];

    // RAM consumption is capped at 256 bytes, regardless 
    // of the size of the file loaded by the user!
    while (fgets(line, sizeof(line), f)) {
        trim_trailing(line);
        if (strlen(line) == 0) continue;

        char *cmd = strtok(line, " ");
        // parsing and execution of the single command...
    }
    fclose(f);
    return true;
}

Conclusion

This is how I structured my project to guarantee its stability, responsiveness, and scalability, especially considering the large number of tools I am going to implement.

In the next episode, we will get to the heart of the action: I will show you how I used the USB stack to make the computer believe that the ESP32 is a keyboard, in order to execute DuckyScript scripts (BadUSB).

In the meantime, which pentesting tool would you like to see added to the project? Let me know in the comments!

Hello World!

Donato Maglie — Fri, 28 Aug 2026 21:04:00 +0000

Hello everyone! 👋 Happy to be joining the DEV community.

I’m a Computer Engineering student based in Italy. My main focus is Cybersecurity, but I strongly believe you have to know how to build a system before you can secure (or break) it.

Lately, I’ve been jumping between two very different worlds:

Embedded C: writing firmware, managing file systems, and building custom OLED menus for the M5Stick S3.

Frontend: building web apps using Next.js and React.

My workflow is a bit of a hybrid. I like to focus on the system architecture, memory management, and edge cases, while using AI tools to do the heavy lifting of writing the actual code. Then, I review everything strictly to make sure it doesn't break.

I’m here to build in public, share my projects, and learn from this awesome community.

What are you all currently hacking on? See you around!