Coder Legion - Recent posts tagged esp32

Build a bird-feeder camera that sends photos to your phone (ESP32-CAM, one weekend)

Fri, 30 Oct 2026 11:14:48 +0000

"I want photos of birds at my feeder sent to my phone."

A tiny camera board next to the feeder takes a photo when something moves and sends it to your phone. It's cheap and fun; the photos are decent, not wildlife-magazine sharp.

Cost $15–30 · Time one weekend · Level some experience helps · Power USB (solar is harder)

What to buy

Part	Why this one	Rough cost
ESP32-CAM with its USB programming board (ESP32-CAM-MB)	Camera and WiFi on one small board. The add-on board makes uploading code easy.	$8–15
PIR motion sensor (e.g. AM312)	Detects warm, moving bodies. Small and low-power.	$1–3
5V USB power supply, 2 A	The camera and WiFi together draw a lot; weak supplies cause random resets.	$5
Weatherproof box with a clear window	Keeps rain and condensation off the lens.	$5–10

Prices are rough ranges, not quotes. Check the current price and stock before you order.

What to install

An Arduino sketch that wakes on motion, takes a photo and sends it through a Telegram bot (the UniversalTelegramBot library has ESP32-CAM examples). ntfy can take photo attachments too.

Runner-up: a Raspberry Pi with its camera module. It costs more and uses more power, but takes much better photos and can spot motion in the image itself.

Build it in three steps

Take a photo on your desk. Flash the camera web-server example that comes with the ESP32 Arduino package, and view the picture in a browser.
Send one to your phone. Set up the bot, and send a photo when you wave at the motion sensor.
Move it outside. Mount it 30–60 cm from the perch, facing away from the sun, and adjust from there.

What catches people out

Motion sensors miss small birds. PIR sensors are made to spot people; a small bird a metre away may not trigger one. Mount the sensor close to the perch, or take a photo every few seconds and keep only the ones that changed.
Focus. The stock lens is usually focused further away. For close-ups it can be turned carefully to refocus (it's often held by a dab of glue), or move the camera back.
Random resets. "Brownout detector was triggered" in the log means the power sagged. Use a good 5V supply and a short, thick cable.
Solar is a step up. The camera draws a lot while it's awake. Get it working on USB before you try solar.

This guide first appeared on IotMentor, a free chat mentor for small electronics builds (I make it). If your setup is different (distance, power, budget, experience), you can ask it there and it will plan your version.

Build a water-leak alarm for under the sink (ESP32, one evening)

Fri, 30 Oct 2026 11:14:12 +0000

"How do I get warned before a leak under the sink floods the kitchen?"

Water conducts a little electricity. Two metal contacts a few millimetres apart on the cupboard floor, a small board that checks them, a loud buzzer and a phone alert. The test is dramatic: pour a glass of water and it screams.

Cost $6–12 · Time one evening · Level first build · Power USB or battery

What to buy

Part	Why this one	Rough cost
ESP32-C3 board	Small, cheap, WiFi built in.	$4–7
Leak probe: two wires or two screws, a few mm apart	Or a cheap "rain sensor" board with a comparator, which gives a simple wet/dry signal.	$0–2
Active buzzer	Beeps by itself when powered, so no tone code is needed. It still warns you when your phone is off.	$1
A 100 kΩ resistor	For reading the probe (see step 1).	$0.10
USB power (there's often a socket under the sink) or batteries		—

Prices are rough ranges, not quotes. Check the current price and stock before you order.

What to install

ESPHome or a short Arduino sketch: check the probe, sound the buzzer when it's wet, and send a phone alert through ntfy or Home Assistant. Repeat the alert every few minutes until it's dry; a leak is urgent.

Ready-made option: leak sensors for Zigbee or WiFi cost about $10–20. Build your own to learn, or to get a loud buzzer right at the sink.

Build it in three steps

Test with a glass of water. Connect one probe to ground. Connect the other to an analog pin, and through the 100 kΩ resistor to a second pin that you switch on only while measuring. Print the reading dry, and with the probe in water: wet should read clearly lower.
Add the buzzer and the alert. Drive the buzzer from a pin (through a small transistor if it needs more current than a pin can give). Alert once when it turns wet, then every few minutes.
Place it. Probes flat on the lowest point of the cupboard floor; board and buzzer higher up, where they stay dry.

What catches people out

Probes corrode if they're powered all the time. Constant current through wet metal eats it away. Power the probe only for the moment you measure, which is why the resistor goes to a pin, not straight to 3.3V.
Damp isn't a leak. Set the alert point from your own test, well away from the dry reading.
Battery version: wake every 30–60 seconds, check, sleep. A leak takes minutes to do damage, so that's fast enough.
Low voltage only. USB or batteries; never run mains wiring near the water.

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

Sat, 12 Sep 2026 14:58:38 +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"

Sat, 12 Sep 2026 14:58:13 +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!

ESP32 ate the maker world - and audio projects beat smart home (May 2026 data)

Tue, 26 May 2026 05:46:55 +0000

We pulled the numbers on 662 maker projects from 367 makers over the last three months. A few of the results genuinely surprised us - and most of them contradict what the hardware press keeps repeating.

Three findings worth your attention

1. ESP32 isn't winning. It already won.
ESP32-family chips show up in 59.8% of new projects. Arduino AVR (mostly the Nano) holds 21.5%, almost entirely in non-connected builds — workshop tools, lighting, art. The "Arduino + Wi-Fi shield" pattern? Effectively zero. Dead.

2. Raspberry Pi Pico flopped on the workbench.
Just 0.6% — 4 projects out of 662. Despite years of marketing push from Adafruit, Pimoroni and friends, makers aren't reaching for it when they actually sit down to build.

3. The #1 project category is audio, not smart home.
Audio and music projects (guitar tuners, visualizers, synths, effects) hit 10.3% of all originals - beating every "IoT" or "smart home" subcategory. The tech press narrative doesn't match what people are actually soldering.

Bonus signal: offline AI is quietly happening

Six independent makers shipped offline AI inference nodes in two months. No coordination, no hype cycle - just people putting models on their own hardware. Worth watching.

Kit economics

Median project BOM: $139. There's a sharp drop-off above $200 - a real ceiling for hobby builds, useful to know if you're designing a kit or product around this audience.

This is the short version. The full post has the methodology, all the data tables, the kit-cost distribution, and a downloadable dataset if you want to run your own cuts.

Read the full breakdown: State of Maker Projects, May 2026

What's your default MCU in 2026? Drop it in the comments - curious whether the ESP32 dominance holds in this audience too.