How to quarantine and reverse suspicious firmware updates on smart locks using only a spare rpi and free tools

I once had a smart lock begin acting strangely after an "automatic" firmware update: intermittent reboots, slower response, and a few unrelated access logs that didn't make sense. I didn't panic — I grabbed a spare Raspberry Pi, isolated the device, and treated the update as potential malware. Over a long evening of testing and reversing, I developed a repeatable workflow that lets you quarantine suspicious firmware updates from a smart lock and reverse-engineer them using only a spare RPi and free tools. Here’s the step-by-step method I use when I suspect something is wrong.

Why quarantine firmware updates?

Firmware updates can fix bugs, add features — or introduce backdoors. Smart locks are especially sensitive because they gate physical access. The goal of quarantine is simple: stop the update from being applied to the lock, capture the update payload and associated metadata safely, and analyze it offline to determine whether it’s legitimate or malicious. You don’t need expensive lab gear to do this — a Raspberry Pi, a bit of networking know-how, and open-source tools are enough for a credible first-line investigation.

What you’ll need

I keep a modest toolkit on my bench that’s sufficient for these investigations. It’s intentionally cheap and portable.

Spare Raspberry Pi (Pi 3/4 recommended) with Raspbian/Ubuntu

MicroSD card and power supply

USB-Ethernet adapter (if using Pi without built-in ethernet)

Wi-Fi adapter that supports AP mode (or use Pi’s built-in Wi-Fi)

Cable to connect the lock (if it has a serial port) — optional

Free tools: tcpdump, Wireshark, binwalk, radare2, Ghidra (free), binutils, openssl, hostapd, dnsmasq, tshark, socat, python3

I also rely on esptool.py when the lock uses ESP32/ESP8266 chips and nrfjprog or Nordic tools for nRF devices when the vendor-provided debug access is available.

Step 1 — Isolate the lock (create a quarantine network)

First, stop the lock from contacting its cloud. The safest approach is to create a dedicated wireless network the lock will connect to instead of the normal internet-connected network. On the RPi I set up hostapd (Wi-Fi AP) and dnsmasq (DHCP/DNS) so the lock thinks it’s on its usual network but all traffic passes through the Pi.

Key points:

Use hostapd to mirror the SSID the lock expects (SSID/PSK cloning can be optional — some locks bind by MAC address). Be mindful of legal issues if spoofing third-party SSIDs; prefer using a quarantine SSID you control.

Disable IPv4 forwarding and don’t enable NAT to the internet. The Pi must act as a sink so updates don’t reach the vendor servers.

Log everything with tcpdump: tcpdump -i wlan0 -w lock_quarantine.pcap

Step 2 — Capture the update

Once the lock connects, watch DNS and HTTP/HTTPS traffic. Most updates are delivered over HTTPS or proprietary protocols — capturing them often requires a MiTM approach.

Options I use depending on protocol:

If updates use unencrypted HTTP or plain TCP/UDP, tcpdump/Wireshark will capture the payload directly.

If updates use HTTPS, try to force the lock into an unencrypted channel by manipulating DNS or the host file served by dnsmasq. For instance, point the update domain to a local server and serve a benign or instrumented response.

If you can’t downgrade TLS, capture raw TLS sessions and save pcap. You may later extract the firmware blob from the TLS stream or perform TLS interception if you have the lock’s root CA (rare but possible for devices using custom certs).

If the lock fetches updates via a vendor API, emulate the API endpoint locally. I commonly write a small Flask server to mimic the endpoint and serve the update file.

Tip: Many smart locks request metadata (JSON) that points to a firmware URL. Intercepting and recording that JSON is often enough to get the firmware URL and SHA256 hash.

Step 3 — Save and verify the artifact

Once you have the firmware file — whether pulled from the pcap, downloaded from your local emulated server, or extracted from a container — save a copy and record its hashes for traceability.

Command	What it does
sha256sum firmware.bin	Produce a SHA-256 fingerprint for tracking
file firmware.bin	Identify file type (raw flash, zip, tar, ELF, etc.)
binwalk -e firmware.bin	Automatically extract embedded files and common filesystems

Binwalk is my go-to for unpacking firmware. It can find squashfs, JFFS2, compressed images, and kernels. If binwalk extracts a root filesystem, you can immediately start inspecting configuration files, binaries, and vendor scripts.

Step 4 — Quick triage: look for red flags

Before deep reversing, I perform a fast triage to see if the firmware contains obvious malicious signs:

Suspicious domains/IPs: grep -R "http" or examine /etc/hosts, /etc/config

Backdoor services: search for dropbear, telnetd, busybox telnetd startup scripts

Integrity checks: vendor signatures, PGP blocks, or custom verification routines

If you find credentials, open remote access, or references to unknown third-party servers, treat the firmware as high-risk.

Step 5 — Reverse engineer the suspect binary

For binaries and firmware components I want to understand, I use radare2 and Ghidra. Ghidra is heavier but provides a GUI-friendly decompilation — perfect for inspecting suspicious code paths. radare2 is great for scripted extraction and quick function inspection.

Common workflow:

Identify architecture: use file or readelf to see if it's ARM, MIPS, x86, or RISC-V.

Load the binary into Ghidra or radare2 and find network-related syscalls or libraries (e.g., socket, connect, send, recv).

Search for string constants that look like commands, C2 endpoints, or encoded payload stubs.

Simulate or run in QEMU when safe: for Linux-based firmware, QEMU user-static or full-system can boot extracted rootfs in a contained environment for dynamic analysis.

Step 6 — Check signatures and update mechanism

Legitimate vendors often sign firmware. I always look for signature blocks (PEM, DER, or appended signatures) and attempt verification using openssl or vendor public keys if available.

Examples:

openssl dgst -sha256 -verify public.pem -signature firmware.sig firmware.bin

Compare embedded hash with metadata captured during the update request.

If a firmware image is unsigned and the lock accepts it, the device has a major integrity flaw. If it’s signed but the signature is bogus, that’s a red flag of possible supply-chain compromise or malicious update servers.

Step 7 — Emulate the update process safely

To understand what an update does without bricking a live lock, emulate the update flow. For Linux-based locks, copy extracted rootfs into a VM (QEMU) and run the vendor’s update script. For MCU-based devices (ESP32, nRF), you can mount the extracted partitions with QEMU or use emulation frameworks.

Emulation lets you log file operations, network behavior, and processes spawned during the update. It’s not perfect, but it reveals a lot about side effects the update causes.

Operational checklist I follow every time

Isolate the device from the real network (quarantine SSID).

Capture all traffic while preventing outbound internet access.

Extract firmware blob and preserve checksums and metadata.

Run binwalk and extract filesystems.

Quickly triage for credentials, C2 indicators, or backdoors.

Verify signatures and integrity checks.

Reverse binaries that look suspicious with Ghidra/radare2.

Emulate update in QEMU when possible before applying to hardware.

Document everything and, if confirmed malicious, report to the vendor and your local CERT.

Throughout the process I keep a forensic mindset: make copies, don’t modify the original image, and keep logs. If you find high-severity indicators (remote admin shells, hard-coded credentials, or contact with unknown servers), escalate to the vendor and consider replacing the hardware. For less-clear cases, the analysis often uncovers whether the update is sloppy engineering or a targeted compromise.

This approach has saved me and others from applying problematic updates more than once. It’s not a perfect substitute for a full lab or professional firmware analysis, but using an inexpensive Raspberry Pi and a pile of free tools gives you a practical, timely way to protect physical access devices like smart locks. If you want, I can share a ready-to-flash Raspberry Pi image and a sample hostapd/dnsmasq configuration I use for quarantine networks.