Unmasking the Snitch Puck: IoT surveillance tech in the school bathroom

Unmasking the Snitch Puck: IoT Surveillance Tech in the School Bathroom

Speakers: Reynaldo (Rey), nyx

Conference: DEF CON 33 (August 2025)

YouTube: https://www.youtube.com/watch?v=WCnojaEpF2I

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Reynaldo%20nyx%20-%20Unmasking%20the%20Snitch%20Puck.pdf

Overview

Two researchers — one a recent high school graduate, one an experienced hardware hacker — conducted a comprehensive teardown and security audit of the Halo 3C, an IoT surveillance device manufactured by IP Video Corporation (acquired by Motorola Solutions in 2023) and marketed to schools, primarily for detecting vaping in bathrooms. The research spans hardware teardown, firmware extraction, application security analysis, and cloud infrastructure examination, uncovering an authentication bypass, unsigned firmware with root execution, command injection, and a persistent cloud backdoor. The findings raise significant privacy questions about a device explicitly marketed as "safe for private areas like restrooms" while containing two microphones and an always-on cloud connection. The vendor disclosed, acknowledged the issues, and patched several vulnerabilities before the talk. The researchers released the device filesystem and firmware encryption/decryption scripts.

Background

▶ Watch: Discovery: identifying the 'Snitch Puck' vendor - IP Video Corporation (1:00)

The Halo 3C exists at the intersection of two trends: the commoditization of IoT sensor platforms and the expansion of institutional surveillance into nominally private spaces. Marketed primarily to schools at approximately $1,200 per unit, the device is presented as a safety tool that detects vaping, gunshots, aggression, and spoken keywords ("help," "911," "emergency") without recording audio — a claim that the researchers found technically accurate under normal operation but trivially reversible given the security vulnerabilities discovered.

Rey first encountered the device as a 15-year-old high school student, scanning his school's unsegmented Wi-Fi during lunch and finding a device with an unfamiliar OUI registered to IP Video Corporation, a small New York startup. Two years later, a unit appeared on eBay. With a mini-grant from the Portland Hacking Foundation, the researchers purchased it for approximately $600 and began what became a full hardware-to-cloud security audit.

Beyond schools, the Halo 3C and its competitors are deployed in retail stores, banks, hotels, hospital rooms, assisted living facilities, and public housing projects. One vendor case study describes the device being used as an "expert witness" in court proceedings for no-smoking policy enforcement in public housing — a use case with significant implications for tenant privacy and due process.

Key Findings

▶ Watch: Hardware teardown: what's actually inside the device (5:00)

• Brute-forceable web login: Rate limiting implemented entirely via a client-side cookie. Omitting the cookie bypasses rate limiting; the researchers achieved approximately 3,000 password attempts per minute against the device's web interface. With a wordlist, a one-million-entry list could be exhausted in under six hours.
• Unsigned firmware with embedded decryption key: Firmware updates are AES-encrypted, but the decryption key and IV are stored in the update file header itself. There is no signature validation. Custom firmware can be packed and uploaded by anyone with web access.
• Root code execution via firmware update: The update extraction script executes any file named extra found in the unpacked update as root — an intended hook for migration scripts. This provides arbitrary root shell access to any authenticated user who can upload a firmware update.
• Command injection (pre-patch): The timezone-setting function passed user-supplied parameters directly to shell commands without sanitization. Patched with a clean_arg() function before the talk.
• Cloud backdoor: The device opens a TLS WebSocket connection to iotmanager.com ten seconds after boot. Incoming messages are forwarded to the local web API as the cloud user, which Express middleware grants admin privileges unconditionally for any request originating from localhost. This provides the vendor (Motorola Solutions) with persistent remote admin-equivalent access to every deployed device.
• Full unauthenticated attack chain: Brute-force login → firmware upload with extra payload → root shell. The chain is roughly 10 lines of Bash.

Approximately 20 Halo 3C units were found with public IPv4 exposure via Shodan at the time of the research.

Technical Deep Dive

▶ Watch: Firmware analysis: obfuscated and poorly written surveillance code (8:59)

Hardware Teardown

The Halo 3C's physical form factor — a flat disc approximately the size of a smoke detector — conceals a sophisticated sensor stack. The compute substrate is a Raspberry Pi Compute Module 4 (Broadcom 2711 SoC), which is significant for several reasons: it runs full Raspbian Linux, it has readily available tooling for firmware extraction, and it supports USB boot mode, which proved critical for bypassing the attempted secure boot chain.

The device uses two double-sided PCBs in a sandwich configuration, connected by a through-hole mezzanine connector.

Bottom board (floor-facing, sensor-heavy):

• SHT40 temperature/humidity sensor (thermally isolated in its own cutout)
• Omron pressure sensor
• SCD41 CO2 sensor ($15 BOM cost; uses direct photoacoustic CO2 measurement, not the cheaper eCO2 proxy used by sensors like the SGP30)
• MICS gas sensor (VOCs, ammonia, nitrogen dioxide)
• A second VOC sensor with air quality index estimation
• Vishay light level sensor
• Passive infrared (PIR) motion detector

Top board (ceiling-facing):

• Two PoE connectors (in/out for daisy-chaining: one Halo can power itself and another)
• Ring of RGB LEDs for alerts and emergency lighting
• MEMS accelerometer for tamper detection (detects removal, impact, or vibration)
• Ethernet switch IC for daisy-chaining

Between boards:

• Two MEMS microphones connected to a Waveshare audio codec

Underside of enclosure:

• Speaker for local alerts
• SPS30 particle sensor (fan + laser light scattering for particulate detection, the primary vape-detection mechanism)

The microphones are the focus of the privacy analysis. The vendor's marketing states the device "ensures privacy without audio recording" and is "safely used in private areas like restrooms." The claim, in its narrow sense, is technically accurate: under normal firmware, audio is not saved or transmitted. Instead, the audio pipeline feeds a local inference engine that detects noise levels, aggression (via acoustic signatures), specific wakewords, and gunshot signatures. However, with the root access path described below, an attacker with network access to the device can trivially redirect the audio pipeline to recording or streaming.

Secure Boot and Firmware Extraction

The Pi CM4's Broadcom 2711 supports a multi-stage secure boot chain: Boot ROM → signed bootloader in SPI flash → customer public key in the SoC's OTP fuses → signed kernel image → encrypted filesystem with a device-specific private key stored in OTP.

The Halo 3C intends to use this chain but does not enforce it: the carrier board exposes a USB connector in mass storage gadget mode, allowing eMMC extraction via standard Raspberry Pi tooling (rpiboot + the mass storage script). This produced a full dump of the device filesystem.

The OS is Raspbian 10 (Debian Buster). The main application runtime is Node.js, with an Express web server handling the local dashboard and API. Sensor drivers are compiled ELF binaries or Python bytecode that communicate with the main server via JSON WebSocket or TCP socket over I2C.

Firmware Update Analysis

Firmware updates are downloaded from the vendor's website as encrypted binary blobs (high entropy, AES-encrypted). Reverse-engineering the extraction script revealed the format: a header containing the AES key and IV in plaintext, followed by an encrypted tar.gz archive. The unpack script:

1. Reads the key and IV from the file header.
2. Decrypts the payload.
3. Extracts the tar archive to the filesystem root.
4. If a file named extra exists in the archive, executes it as root.

The extra mechanism is documented in the codebase as a hook for database migrations, log rotation, and other maintenance tasks during upgrades. It is exactly the arbitrary root execution mechanism it appears to be. A reverse shell payload embedded as extra in a crafted firmware archive, uploaded via the web API, produces a root shell in seconds.

No cryptographic signature is verified on the firmware archive. The key in the header is not a public key — it is the symmetric AES key used for that specific update, stored in the file it protects.

Authentication Bypass

The web interface login tracks failed attempts via a cookie: on each failed login, the server increments a counter, stores it in a response cookie, and returns it. On the next request, the client is expected to present this cookie. If the cookie is omitted, the server does not increment the counter — the rate limiting has no server-side state.

At the Pi's CPU capability, the researchers measured approximately 3,000 authentication attempts per minute. The password policy (8+ characters, requiring uppercase, lowercase, digit, and special character) reduces but does not eliminate the feasibility of wordlist attacks. The 20 Shodan-exposed units represent a population of directly exploitable targets requiring no network access beyond the internet.

Cloud Backdoor Architecture

Inspecting the startup script (start_main_b) revealed a ten-second delayed initialization of a TLS WebSocket connection to iotmanager.com, the vendor's cloud management platform. Incoming WebSocket messages are parsed and forwarded to the local Express web API. The Express authentication middleware contains a special case:

Requests originating from localhost (i.e., the cloud proxy) are unconditionally treated as admin-authenticated. The vendor (now Motorola Solutions) has a persistent, authenticated, remote-access channel to every deployed Halo 3C. This is inherent to the product design and was not patched.

No evidence of abuse was found on the unit the researchers analyzed — no audio saved, no data exfiltrated — but the technical capability for undetectable remote activation of the microphones exists.

Demo / PoC

▶ Watch: Privacy violation: device used to profile student behavior for advertising (16:59)

The research included three demonstrations:

1. Keyword detection failure: Speech of obscure phrases played near the device was correctly not detected. Demonstrates that the keyword detection is not an indiscriminate keyword logger under normal operation — but also illustrates that the claimed privacy boundary is software-enforced, not hardware-enforced.
2. Reverse shell: A crafted firmware update package containing a netcat reverse shell as the extra file was uploaded via the authenticated API. The device executed it as root and connected back to a listener.
3. Cloud backdoor simulation: The researchers replicated the WebSocket → localhost API proxy chain to demonstrate admin API access without presenting credentials, mirroring what the vendor's cloud infrastructure can do at any time.

Defensive Implications

▶ Watch: Media coverage: 404 Media and Wired investigations following disclosure (18:59)

For schools and institutions: Before deploying IoT surveillance devices marketed for sensitive areas, request a full technical specification of the network communication profile, remote management interfaces, and audio data handling — including confirmation of whether the vendor retains any remote access capability. A device with a cloud backdoor operating in a school bathroom is not consistent with privacy representations to students and parents, regardless of whether that backdoor has been used.

For IoT product security teams: Rate limiting must be implemented server-side, with state stored in the server session or a server-side data store. Cookie-based rate limiting provides no protection against a client that omits the cookie. Firmware update integrity requires cryptographic signing, not just encryption: the key should not be in the file it protects, and the archive should be signed with an asymmetric key whose public component is embedded in the device.

For privacy advocates and legal analysts: The cloud backdoor in a device deployed in school bathrooms raises questions under FERPA, COPPA, state privacy laws, and institutional data governance policies. The device collects acoustic data in spaces where minors have a reasonable expectation of privacy, and the vendor retains technical capacity to activate the microphones remotely.

For hardware security researchers: The RPi CM4 compute module, while a convenient development platform, provides a well-documented extraction path via USB mass storage mode that circumvents attempted secure boot. Products designed for sensitive deployments should use compute platforms with enforced secure boot and no developer-facing extraction modes.

Key Takeaways

• The Halo 3C contains two microphones and a persistent cloud backdoor in a device marketed for school bathrooms. The vendor can access the microphones remotely.
• Rate limiting via cookies is client-controlled and trivially bypassed. ~3,000 guesses/minute against an unauthenticated web interface.
• Firmware updates are encrypted but not signed, and the encryption key is in the file header. An extra file in any update executes as root.
• The full attack chain — brute-force login, custom firmware upload, root shell — is approximately 10 lines of Bash.
• The vendor patched command injection and some authentication issues before the talk. The cloud backdoor, inherent to the product architecture, was not patched and is unlikely to be.
• Ed-tech surveillance devices are a meaningful attack surface: deployed in sensitive physical locations, running consumer-grade compute hardware, often connected to school networks with access to other devices.

About the Speakers

Reynaldo (Rey) is a Portland-based security researcher who began teaching himself information security as a 15-year-old high school student. The Halo 3C research began when he discovered the device on his school's Wi-Fi network and became fascinated with understanding what it actually did. This was his first appearance at DEF CON. He is seeking opportunities in hardware hacking and security research.

nyx is a hacker with a background in electrical and computer engineering who spent time as a software engineer at a large technology company before shifting focus to security research. nyx holds OCP certification and is a regular at local hacker spaces. At the time of the talk, nyx was between roles and seeking consulting or full-time opportunities in hardware and security research.