What I’ve actually
built and broken.

Facial recognition terminals are showing up everywhere, office lobbies, school entrances, gym check-ins, apartment buildings, warehouses. They’re sold as modern access control: employees or students scan their face instead of swiping a badge. The pitch is efficiency and security. The reality is that most of the people responsible for buying and installing these devices have no idea what’s actually running inside them, and neither do the students, employees, or visitors handing over their biometric data. I pulled one of these terminals onto an isolated lab network to find out. The device was marketed under one brand name, but inside it was a generic Chinese OEM platform sold under dozens of different names at every price point. What I found was a device that had no meaningful security at any layer.

Service enumeration with nmap to map every open port, then manual assessment of each one: the web management interface, an open telnet service, a backend service referenced in JavaScript source, and an RTSP video endpoint. Client-side JavaScript source review revealed credentials and stream paths that the device had no business exposing. Each finding fed the next, standard methodology for building a complete compromise chain.

The web interface accepted factory default credentials with no lockout and no rate limiting, but that barely mattered, because a publicly documented authentication bypass (CVE-2021-33044) returned the full admin dashboard with zero credentials whatsoever. The login page shipped a hardcoded encryption key in plaintext JavaScript, visible to any browser without authentication. The algorithm was Triple DES, cryptographically broken and deprecated by NIST since the 1990s. The device also exposed a fully unauthenticated RTSP video stream: any device on the same network could open it silently, with no credentials, no log entry, and no indication to anyone that the feed was being accessed. This is a facial recognition terminal. It was actively scanning and recording faces. Anyone on the network could watch that in real time. Telnet was open on port 23, transmitting everything in cleartext. An undocumented service on port 5000 was listening with unknown purpose. The full compromise chain, from discovery to live biometric video feed, required zero credentials. These findings apply to any network this class of device is placed on: a school, a medical office, a corporate lobby, an apartment complex.

A modern smart refrigerator sits on your home network and talks to the manufacturer cloud all day long. Most owners never think about what it is sending, who can read it, or whether that connection is actually secure. I put my own Hisense Wi-Fi refrigerator, which runs on the ConnectLife platform, through a complete assessment on an isolated network to answer one question: is the data leaving this appliance really protected?

I built a passive capture tool (fridge_recon.py) and ran a five phase penetration test methodology I documented in house. It began with passive traffic recon to fingerprint the device and map every server it reached, then moved to an active man in the middle stage using ARP and DNS redirection with a custom relay, sitting between the fridge and the cloud to inspect traffic the appliance believed was private. Everything was done on hardware and a network I own.

The refrigerator did not properly validate the security certificate of the server it connected to (CWE-295, improper certificate validation). In plain terms, it could not tell the difference between the real manufacturer cloud and my relay pretending to be it. That allowed me to decode the appliance proprietary telemetry protocol and read the live data it was sending, including the commands that control it such as temperature settings. A weakness like this means anyone positioned on the network path could potentially read or tamper with that traffic. Specific tokens, identifiers, and payloads are kept private.

Wardriving produces enormous, messy datasets, thousands of 802.11 and BLE observations with randomized MACs, missing vendor data, and no easy way to make sense of them after the drive.

Built a cross-platform analysis tool (Electron desktop app plus a mobile PWA) that ingests capture data, performs OUI vendor lookups, separates BLE and Zigbee observations, handles MAC randomization, and supports WiGLE CSV import. Session save/load lets you revisit and compare drives over time.

A reusable platform that converts a night of capture into something you can actually analyze, vendor breakdowns, device categories, and signal patterns, instead of a wall of hex. Published open-source.

BLE devices broadcast constantly and pair with little user friction. How much can you learn passively, and how do real-world devices hold up against known pairing attacks?

Decoded raw BLE advertisement packets down to the manufacturer-data level to identify devices and vendors. Then tested a published BLE pairing CVE against my own hardware using an academic research toolkit, strictly on devices I own, to understand the attack surface firsthand.

Confirmed how much device and vendor information leaks from passive advertisement monitoring alone, and reproduced the pairing-vulnerability behavior against one of my own devices while another resisted it. A practical, hands-on understanding of where BLE security actually breaks down versus where it holds.

Automated license-plate-reader and surveillance devices broadcast identifiable wireless signatures. Could a portable rig passively detect and log them in the field?

Built a multi-radio platform combining WiFi and BLE monitoring with a reflashed Zigbee dongle running Sniffle. Wrote a custom bridge script targeting a specific manufacturer ID to flag known surveillance hardware in the captured stream, correlating across radios.

A working detection rig that passively identifies specific surveillance devices by their wireless fingerprints, entirely passive, no transmission, all on equipment I built and own.

A growing fleet of IP cameras and IoT devices, several of which (see project 01) phone home to third parties. They needed to function without being trusted.

Designed a segmented UniFi network with isolated VLANs for IoT and cameras, firewall rules preventing those segments from reaching the internet or the trusted LAN, and a self-hosted Frigate NVR pulling RTSPS streams locally so footage never depends on a vendor cloud. Added a separate NAS as an archival target over SMB.

Cameras work fully, live view, recording, detection, while being firewalled off from the internet and the rest of the network. Footage stays local. If a camera is compromised or phones home, it reaches nothing of value.

A PTZ camera shipped with closed vendor firmware of unknown provenance, exactly the kind of black box that phones home (see project 01). Could it be reflashed with open firmware that the owner controls?

Identified the flash chip and read the bootloader over UART to understand the boot process, the highest-value first step before touching anything. Used a CH341A SPI programmer to interface with the flash directly, working toward replacing the stock image with OpenIPC, an open-source camera firmware.

Established the hardware access path, UART boot log captured, SPI flash interface confirmed, for moving the camera off opaque vendor firmware onto auditable open-source firmware the owner fully controls.