For our Capstone project, we built a multi-protocol IoT honeypot designed to help students understand modern home-lab security and how easily common IoT protocols can be explored or abused when controls are weak. The goal was to create a realistic-looking device that could safely log attacker-style interactions and turn them into something instructors and students could learn from in a controlled environment.

Hardware & Architecture

A key design constraint shaped the entire build: the Seeed Studio XIAO ESP32-C6 can’t run 2.4 GHz Wi-Fi and Zigbee (802.15.4) at the same time. To solve this, we split the honeypot into two identical ESP32-C6 boards.

• Bottom board: Dedicated Zigbee coordinator with intentionally weak security to encourage join attempts. It converts Zigbee events into small JSON objects and sends them to the top board over UART.
• Top board: Acts like a multi-protocol gateway. It connects to Wi-Fi, exposes an HTTP dashboard, interacts with an MQTT broker, advertises a believable BLE GATT profile, and logs events from all four protocol surfaces (HTTP, MQTT, BLE, Zigbee).

Designing the Enclosure

To make the honeypot practical and portable, I designed a custom case in FreeCAD around the boards’ dimensions and mounting needs. The enclosure was 3D printed in HYPER-PLA on my Ender 3. To simplify maintenance, I included magnet-based snap-fit closure using 10 mm × 3 mm magnets instead of screws. I also integrated a lid mount for a small 5 V solar panel, then finished the chassis with a yellow paint job and honeycomb theme to visually reinforce the “honeypot” identity during demos.

How it works

The top board is where the honeypot feels like a real device to an attacker. On boot, the firmware starts serial, connects to Wi-Fi, configures time using NTP, initializes the HTTP server, MQTT client, BLE stack, and then brings up the Serial1 UART link to the Zigbee board. It also generates a short unique ID based on the board’s MAC address so multiple nodes can be deployed without manual topic configuration. It then continuously services HTTP requests, processes MQTT traffic, and reads Zigbee JSON messages from the UART link.

Because the microcontroller has limited memory, the system avoids long-term storage and instead uses separate ring buffers for each protocol. Each buffer stores the most recent 50 events, overwriting older entries as new ones arrive. Every entry includes a timestamp, event type, and protocol-specific details such as HTTP path, MQTT topic/payload, BLE address, or Zigbee

The MQTT component is designed to look believable to scanners and testers. The top board connects to a broker on the core VLAN, builds a client name and topic prefix from its MAC-derived ID, publishes an “online” status message, and subscribes to an input topic pattern. When messages arrive, a callback logs the event and echoes the content back to an output topic.

For BLE, the device uses the NimBLE stack to present as a plausible smart device named “Honey-LightBLE.” The advertised services include familiar standards like Device Information and Battery Service alongside a fake configuration-style service. Read/write callbacks record which characteristic UUID was accessed, the client’s BLE address when available, and both hex and ASCII representations of any data written. If a client writes to a state-like characteristic, the honeypot sends a notification back to simulate a real device response.

Rather than trying to merge all radios onto one chip at once, Zigbee events are forwarded from the bottom board using a clean, simple UART protocol. The top board reads Serial1 until it sees a newline, then attempts to parse the line as JSON. If the object contains an “evt” field, it is logged into the Zigbee ring buffer; if parsing fails, the firmware logs an error event instead.

The bottom ESP32-C6 is dedicated to Zigbee. Its setup initializes debugging serial, the UART link, LED state, and sends early “boot/hello” style events for quick verification from the top board’s dashboard. Zigbee logic runs inside a separate task (esp_zb_task), keeping the coordinator responsibilities isolated from the multi-protocol gateway functions.

Setting Up the Lab

To keep the project realistic but safe, I built a dedicated testing environment on my home network using VLAN segmentation on my UniFi gateway. The lab was designed so our team could run recon and protocol testing against the honeypot without putting my everyday devices or core services at risk. The structure also reflects how an enterprise would isolate IoT systems to reduce lateral movement and limit blast radius if a device becomes compromised.

I created three main network segments. The core VLAN (10.0.0.x) hosts my critical services, including my main Ubuntu server (“wifu-server”) running Docker containers like my web server and Home Assistant, as well as a separate DNS cache server. The IoT VLAN (10.0.11.x) is used exclusively for testing and contains the honeypot plus several real IoT devices such as a Litter-Robot 4, an Ecobee thermostat, and a wired Philips Hue bridge and bulbs. The main VLAN is reserved for personal devices (laptops, phones, TVs, etc.) and is intentionally out of scope to keep experimental traffic away from my daily-use equipment.

From there, I added routing and firewall rules to expose only what we needed for testing. A key part of the lab design was enabling controlled team access to an attacker workstation without opening default high-noise ports to the internet. To achieve this, I configured port forwarding from my public IP to a dedicated attacker machine: a Minisforum UN150P running Kali on the IoT VLAN. External requests are mapped to RDP on port 6767 and SSH on port 6768, allowing remote access while avoiding standard ports like 3389 and 22. This approach keeps access practical for teammates while reducing basic opportunistic scanning risk.

On the services side, I installed an MQTT broker on my home server and configured it for anonymous access so the honeypot and test devices could publish/subscribe without needing per-device credentials. This setup was intentional for education: it increases realism for “weak default” demonstrations and makes it easier to reproduce attacks and logging outcomes during testing.

To make the Kali box usable for the whole team, I installed a full desktop environment along with xrdp and OpenSSH so teammates could connect either through remote desktop or terminal. I also created separate user accounts for Jesse and Cynthia, which avoided password sharing and made activity more traceable during collaboration.

Recon and MQTT

Cynthia led our recon and MQTT testing, validating that the honeypot was discoverable and behaved like a believable IoT target inside the segmented home lab. She used Nmap to identify MQTT-related exposure and confirm the messaging surface.

After discovery, she used curl to pull useful HTTP-visible details, including the connected broker, ClientID, and base topic structure; exactly the kind of information that makes MQTT hijacking and message injection easier.

For MQTT exploitation and validation, Cynthia used Mosquitto tooling to simulate message injection/broker-style interaction and confirm our logger captured the traffic as expected. She also incorporated RALMQTT as part of her MQTT pentesting toolkit, which we referenced alongside our broader MQTT testing sources.

[See image gallery at erikmakesthings.ddns.net]

To round out the risk story, she performed a SlowITe-style MQTT denial-of-service demonstration, showing how TCP-based IoT messaging can be disrupted through connection exhaustion even with minimal bandwidth.

---

BLE Testing

I led the BLE testing to confirm the honeypot presents a believable Bluetooth target and reliably logs both passive probing and active interaction. I started by scanning for nearby devices using Bettercap’s ble.recon module, which gave me a quick snapshot of the BLE environment and helped me confirm Honey-LightBLE was advertising as expected based on name, RSSI, and vendor details.

After identifying the device, I connected and queried its GATT profile. The honeypot exposed standard services like Generic Access, Device Information, and Battery, plus a custom Nordic UART-style service. While exploring the GATT table, I confirmed that even simple reads generated visible events in my dashboard, which showed the system could capture low-noise reconnaissance.

[See image gallery at erikmakesthings.ddns.net]

To test active input, I used bluetoothctl to connect and write a short payload to a writable UART RX-style characteristic. The dashboard logged and decoded the write, validating the full chain from discovery, connection, GATT enumeration, write action, and finally event capture. This confirmed the honeypot can reliably record both read-style recon and write-based injection behavior.

[See image gallery at erikmakesthings.ddns.net]

Zigbee Testing

Jesse led our Zigbee testing to validate that the Zigbee side of the honeypot functioned correctly and to establish what normal baseline traffic should look like in a small smart-home style environment. He noted that meaningful “attack-style” testing was harder to demonstrate in a clean way because Zigbee’s behavior is highly local and device-driven, so most of the effort focused on observation and recon rather than flashy exploitation.

During this phase, the Zigbee network was confirmed to be working and able to pair with Zigbee end devices, which helped verify the core functionality of the setup.

Jesse also documented a limitation we ran into: issues with the Zigbee logger prevented us from showing the depth of logs we originally intended. Even so, we were still able to capture and confirm devices attempting to connect to the system, which supported the overall purpose of the Zigbee-facing honeypot design.

Download the code to try for yourself.

A garden is a grand teacher. It teaches patience and careful watchfulness; it teaches industry and thrift; above all, it teaches entire trust.

–Gertrude Jekyll

When I first took up gardening a few years ago, I figured it couldn’t be that hard. Just throw some seeds in the dirt, sprinkle a little water, and boom salad. Easy, right?

It turns out that growing plants successfully requires more than casual optimism and a watering can. It takes patience, consistency, and most importantly precision. Too much water? Dead plants. Too little? Also dead plants. As someone who works odd hours as a mainframe operator, I quickly learned that remembering to water my plants at the right time every day wasn’t exactly my strong suit. So I did what any tinkering nerd would do, I spend hours building something so I wouldn’t need to spend seconds doing something and automated it.

Water PI v1

The first version of my automated watering system was basic but surprisingly effective. I repurposed an old Raspberry Pi 2 B to control a 5V relay via the GPIO pins, which toggled a small fish tank pump at set times of the day. The pump sat at the bottom of a 5-gallon bucket and pushed water through a 3/8″ tube. I had pinched the end of the tube shut and drilled holes along its length to create a DIY sprinkler. All of this was controlled by a Python program I wrote and setup as a service so it always ran. I could also SSH and send a command to get it to run for an extra cycle if it was a rather dry day.

It wasn’t elegant, but it worked. My plants got watered, and I didn’t have to think about it. That is, until a summer storm rolled in and decided to conduct a field test, in destruction. Water Pi v1, with its exposed wires and hot-glued components, was utterly torn apart. The setup had served its purpose, but it was no match for wind, rain, and poor weatherproofing.

Grow Lights

Over the winter, I expanded the system indoors to start seedlings early. I picked up some budget-friendly grow lights from the local Home Depot and spliced in a Sonoff Zigbee relay to automate them through my Home Assistant setup. Now, the grow lights are part of my daily automation routines, turning on and off precisely when the seedlings need them, no more guessing or timers.

Water PI v2

This year, I’m rebuilding the system from the ground up to be more scalable, energy-efficient, and portable. Enter Water Pi v2 the next-generation watering node powered by a Raspberry Pi Pico 2W and a Waveshare power board, all mounted inside a 3D-printed (possibly weather-resistant) enclosure that I’m designing in FreeCAD.

One of the main improvements is the addition of a motorized stirring mechanism. In my previous setup, stagnant water in the tank sometimes led to algae growth, which eventually caused blockage issues. This new version includes a dedicated motor to stir the tank periodically, helping keep the water clean and flowing consistently.

The watering function itself is now handled by a larger pump, again controlled via a relay module. The Pico 2W listens on a dedicated TCP port and receives instructions from a Python-based server program running on my home server. This server sends commands like pump:2000 or stir:1500 to toggle the corresponding relay for a specified duration (in milliseconds).

To make the system more user-friendly and easier to diagnose, I’ve added a small I2C LCD to the node. It displays real-time status updates, such as the current system state and any received commands. Eventually, I plan to have the screen cycle through useful device information like IP address, battery level, and more — helpful for debugging and at-a-glance monitoring.

Power-wise, the system is designed to be solar-powered. I’m using a solar charging controller and a LiPo battery to allow the node to run independently. The pump, due to its higher power draw, is still powered by an external wall source. I also plan to design a custom bracket to mount the solar panels directly on top of the node’s housing for an all-in-one footprint.

The firmware for the Pico is written in C to give me finer hardware control and to sharpen my embedded systems skills. On the other hand, the server is written in Python, which should make it easier to get it integrate in to a nice and neat front end, or so I hope. Currently, the UI is a terminal-based menu, but I plan to expand it into a web interface. Long term, I’d like the server to manage a database to support multiple nodes, allowing for more scalable deployment and organization.

I’m just a simple man trying to make my way in the universe

– Jango Fett

I am a huge Star Wars nerd, like my father before me, and ever since I bought my Ender 3, I’ve been printing various Star Wars models and costume parts. After many failed and semi-successful projects, I finally set out to make my father the helmet of one of his favorite, and most iconic, characters from a galaxy far, far away: RC-1207 Sev from the Republic Commando series.

A Long Time Ago…

For some backstory, my father is without a doubt one of the biggest Star Wars fans in the galaxy. Some of my earliest memories with him involve watching The Empire Strikes Back on VHS, playing the ’90s X-Wing vs. TIE Fighter games, and building starfighters out of LEGO. As I grew up, he took us to every new movie, bought pretty much every Expanded Universe book, and played countless Star Wars tabletop and video games with us. For the longest time, he dreamed of building a Sev cosplay. I remember when he got in trouble with Mom for buying a helmet off eBay. He never finished the cosplay, life with five kids will do that, so my goal was to make him the helmet he always deserved.

The Journey Begins…

To get this project started, I relied on my mostly stock Ender 3 printer. After a year of learning slicing programs, post-processing, and printer quirks, I felt ready to take on something bigger. Here are a few of the smaller projects I tackled to prep for this build:

And of course a test fit was in order.

Finding the Model…

First thing to do is to find the right model. If you’re good with 3D modeling or CAD, you can make your own. Otherwise, you can purchase models from amazing creators like aguilarworkshop.com, or search for free ones on sites like Thingiverse. I found the Republic Commando helmet model on Thingiverse, so huge shoutout to creators who share their hard work freely.

Printing and Assembly…

Then next step was to slice and print all of the pieces, sand them a little, and then put them all together. Since this print is in PLA I used just some simple Gorilla super glue to put them all together. Depending on the plastic you are using you will have different options to fuse everything, like Acetone when printing in ABS. Typically, what I found works best is to place a few drops in the face of the parts that would touch, and then either hand press or clamp the parts together for about five minutes. Then to further increase the the bond between the PLA parts, I would apply a few drops on both sides of the spot where the parts are connected and then spread it out with a brush. After repeating the exterior application a few times I would usually have a pretty strong bond!

Filling and Finishing…

Then all you have to do is do a bit of sanding with some rough grit to get it ready for the next step. Before we move on though let me just point out that this project involved a lot of sanding. Just assume that in between every step I have sanded the helmet going from a rough to a more fine grit each time. If you are going to do this project at home, I would highly recommend some sort of handheld power sander. I did this by and and it was terrible and very time consuming! Also don’t forget to work in a well ventilated area with a respirator and safety glasses. Don’t want to get anymore micro plastics than you already have!

Once you get everything sanded it’s time to start filling in the cracks so the surface will be smooth to the touch! From what I read and watched online most people either used watered down wood filler for it’s ability to fill gaps and sand easily, or Bondo for it’s ability to add getter structural support to the prints. So I opted to do both, because why not! I used Bondo I got from Mendards and applied it to the sides of the helmet where I had most of the larger parts of the helmet attached to each other. Then used the watered down wood glue for for the smaller gaps and seams where things didn’t line up perfectly. After letting it dry, I did some more sanding. Finally, I coated the entire helmet with one layer of water downed wood filler and sanded until it was smooth.

Painting and Detail Work…

With the bulk of the work behind me all I had left was to put down a few layers of primer while filling any extra seems with wood filler. Then I laid down the white base that the clones are known for. After the two or three base coats I when in with a brush to paint the accents with black acrylic paint. For the visor I used a plastic face visor off of Amazon, and cut it down to fit. After using a heat gun to shape the visor to the helmet I secured it in place using some hot glue. For the mouth grill I bought some wire mesh from a hobby store and cut it to fit before securing it with super glue.

The final part of this model is to add the striking livery to the helmet. Since the character has made few appearances since his debut in the 2005 game Republic Command, I had to take some creative liberties to bring the fear inducing bloodied paint scheme to life. After masking the accent lines and parts I used some watered down crimson acrylic paint and my hand to imprint the signature look across the faceplate. Then I used a sponge applicator to apply additional blood splatter and streaks.

Finishing Touches…

With the helmet complete, I decided to add some flair. Using a Raspberry Pi Pico and MicroPython, I wired up LEDs behind the visor to simulate the in-game glow. I also found original voice lines and sound effects from the game and used small speakers inside the helmet to play them. The entire system is powered by a USB power bank and securely tucked away. Final touches included padding, wire routing, and mini exhaust fans for comfort. Once everything was in place, I drove the helmet to my dad and handed it to him in person.

Watching my dad don the finished helmet with glowing lights and Sev’s iconic crimson streaks was worth every failed print, every grain of sandpaper, and every drop of glue. This wasn’t just a cosplay prop. It was a tribute to the man who introduced me to Star Wars, and to the galaxy we still explore together.

This one was for you, Dad. For the Republic!

MicroPython for helmet.

#libs
import time
import board
import random
import digitalio
from audiocore import WaveFile
from audiopwmio import PWMAudioOut as AudioOut

#Speakers
audio = AudioOut(board.GP16)

#dir var
path = "sounds/"

#LEDs
led = digitalio.DigitalInOut(board.GP5)
led.direction = digitalio.Direction.OUTPUT
led1 = digitalio.DigitalInOut(board.GP6)
led1.direction = digitalio.Direction.OUTPUT
led2 = digitalio.DigitalInOut(board.GP7)
led2.direction = digitalio.Direction.OUTPUT
led3 = digitalio.DigitalInOut(board.GP8)
led3.direction = digitalio.Direction.OUTPUT
led4 = digitalio.DigitalInOut(board.GP9)
led4.direction = digitalio.Direction.OUTPUT

#function to open/read .wav file
def play_sound(filename):
    with open(path + filename, "rb") as wave_file:
        wave = WaveFile(wave_file)
        audio.play(wave)
        while audio.playing:
            pass
        
#from input play selected file        
def sfx(n):
    if n == 0:
        play_sound("62_anger.wav")
    elif n == 1:
        play_sound("rad_02.wav")
    elif n == 2:
        play_sound("rad_03.wav")
    elif n == 3:
        play_sound("62_droids.wav")
    elif n == 4:
        play_sound("40_win.wav")
    elif n == 5:
        led4.value = False
        led3.value = False
        time.sleep(1)
        led2.value = False
        led1.value = False
        time.sleep(1)
        led.value = False
        
        time.sleep(2)
        
        led.value = True
        play_sound("chirp.wav")
        play_sound("chirp.wav")
        led1.value = True
        led2.value = True
        play_sound("chirp.wav")
        led3.value = True
        led4.value = True
        play_sound("chirp.wav")
    elif n == 6:
        play_sound("delta.wav")
    elif n == 7:
        play_sound("62_rgr.wav")
        time.sleep(1)
        play_sound("07_lol.wav")
    elif n == 8:
        play_sound("62_bad.wav")
    

#initial boot sequence
play_sound("chirp.wav")
led.value = True
play_sound("chirp.wav")
play_sound("chirp.wav")
led1.value = True
led2.value = True
play_sound("chirp.wav")
led3.value = True
led4.value = True
play_sound("chirp.wav")
play_sound("boot.wav")
play_sound("heal.wav")

time.sleep(30)

#initial sound play
n = random.randint(0,8)
sfx(n)
m = n

#main loop
while True:
    n = random.randint(0,8)
    
    if m == n:
        n = random.randint(0,8)
        sfx(n)
    else:
        sfx(n)
    
    m = n
    
    time.sleep(300)