Hacking a $27 Smartwatch with Claude Code: Embedded AI Workflows

The Hack, Plainly Stated

Mike Kasberg bought a $27 smartwatch—the kind sold under a dozen generic brand names on AliExpress. It pairs with a phone, displays notifications, and tracks steps. Nothing special. But he didn't want to wear it. He wanted to mount it on a wall and turn it into a persistent display for home automation data: room temperatures, garage door status, the works.

The watch runs a proprietary RTOS with no public SDK, no documented protocol, and no obvious attack surface beyond Bluetooth Low Energy. The companion app on Android speaks a custom BLE protocol to push notifications and sync data. Reverse-engineering that protocol by hand—capturing packets, guessing at field boundaries, writing a parser—is a weekend-killing grind.

Kasberg instead pointed Claude Code at the problem. He fed it Android app decompilation output, BLE packet captures, and a rough goal: "Figure out how to push arbitrary text to the watch screen." Claude Code traced through obfuscated smali code, identified the notification-push codepath, mapped the packet structure, and generated a working Python script that sends custom notifications over BLE—no phone required.

The result: a $27 wall-mounted display that pulls data from Home Assistant and shows it on a watch that was never designed to do any of this.

Why This Matters for Engineers and FDEs

This isn't a story about a smartwatch. It's a story about collapsing the cost of reverse-engineering embedded systems—a task that Forward Deployed Engineers face constantly when integrating customer hardware that ships with zero documentation.

The Old Way vs. The Claude Code Way

For FDEs embedded at customer sites, this is a force multiplier. When a manufacturer drops a piece of industrial equipment on your desk and says "make it talk to our cloud," you're now armed with a tool that can chew through decompiled firmware and packet captures while you focus on architecture and stakeholder alignment. The Palantir embed model was built for exactly this kind of scenario—and tooling like Claude Code makes the "figure out the black box" phase dramatically faster.

The Meta-Skill: Prompting for Protocol Reverse-Engineering

The watch hack succeeded because Kasberg didn't just throw a binary at Claude and say "reverse this." He staged the problem:

1. Context dump: Decompiled app source, BLE capture files, watch model info
2. Targeted prompt: "Find the method that constructs the notification packet"
3. Iterative refinement: "The checksum field is wrong—what other algorithms might they use?"
4. Code generation: "Write a Python script using bleak that sends 'Hello World'"

This is the same pattern FDEs use when collaborating with product and engineering after a sale closes. You're not expected to know every protocol. You're expected to know how to decompose an unknown system into testable hypotheses—and now you have an AI that can test those hypotheses at machine speed.

The Embedded AI Workflow: How to Try It Today

You don't need a smartwatch. Any BLE or serial device with an unknown protocol is fair game. Here's the repeatable workflow:

Step-by-Step

1. Capture the traffic. For BLE, use an nRF52 dongle with Wireshark or Android's built-in HCI snoop log (Developer Options → Enable Bluetooth HCI snoop log). For USB, Wireshark with USBPcap. For serial, a logic analyzer with protocol decode.

2. Decompile the companion app. APKTool for Android apps, then feed the smali or decompiled Java to Claude Code. You don't need to understand the decompiled code yourself—Claude handles that. The key is giving it enough context: "Here's the entire decompiled source of the app that talks to this device. Find where it constructs packets sent over BLE characteristic X."

3. Structure your prompts like a code review, not a question. Bad: "How does this watch work?" Good: "In this decompiled Android app, trace the execution path from NotificationService.onNotificationPosted() to the BLE write. Identify every byte field in the outgoing packet and its purpose."

4. Generate, test, fail, refine. The first generated script will almost certainly fail—wrong checksum, wrong encoding, wrong characteristic UUID. Feed the error back to Claude Code: "Script fails with GATT error. Here's the raw packet the real app sends vs what our script sends. What's different?" This tight feedback loop is where the speedup lives. Compare this to Autolith's approach of closing the loop with a live runtime—same principle, different domain.

5. Document as you go. The Claude Code conversation is your documentation. When you hand off the integration to a customer's engineering team, the full reasoning chain is preserved. This matters enormously for FDEs who need to build trust with non-technical stakeholders—showing your work is showing competence.

Tools You'll Need

• Claude Code (Anthropic's agentic coding tool) or a comparable LLM with large context and code generation capability
• BLE capture: nRF Connect, Wireshark, or Android HCI snoop log
• Decompilation: APKTool, jadx, or Ghidra for firmware
• Script runtime: Python with bleak (async BLE) or pyserial
• Test harness: The actual device (buy two—you'll brick one)

A Balanced Take: Where This Shines and Where It Fails

What's Genuinely New

The watch hack isn't impressive because AI wrote some Python. It's impressive because AI handled the cognitive bottleneck of reverse-engineering: pattern-matching across decompiled code and raw packet dumps to infer protocol structure. That's a task that previously required an engineer who was fluent in both the target platform's assembly and the protocol domain. Now it requires someone who can stage a problem and iterate on feedback.

This shifts the bottleneck from protocol knowledge to systems integration judgment. Claude Code can tell you the packet format. It can't tell you whether polling that characteristic at 100Hz will drain the watch battery in 4 hours, or whether the customer's factory floor has enough BLE range. That's still engineering judgment—and it's exactly the kind of judgment FDEs are paid for.

Where It Falls Down

Proprietary encryption. If the protocol uses a non-standard cipher or key exchange that's implemented in native code (not the decompiled Java layer), Claude Code will hit a wall. It can't extract keys from a black-box hardware secure element.

Real-time constraints. The watch hack is a one-way push. If you're reverse-engineering a protocol that requires precise timing or state-machine synchronization, AI-generated scripts tend to be too naive about edge cases. You'll need to add the robustness yourself.

Hallucinated APIs. Claude Code will confidently invent BLE library methods that don't exist. When it does, the fix is straightforward—point it at the actual bleak docs—but you have to catch it. This is the same dynamic covered in our piece on why local LLMs feel dumber: model capability matters, but so does your ability to detect when the output is plausible nonsense.

The $27 watch is a toy, not a product. This is a proof-of-concept. Nobody's shipping a wall display built on an AliExpress watch. The real value is the workflow, not the artifact. For production embedded work, you still need proper hardware with documented SDKs—but the ability to rapidly prototype against undocumented hardware is what gets you from "can we integrate this?" to "here's a working demo" in an afternoon instead of a week.

FAQ

Q: Do I need a $27 smartwatch to try this? No. Any BLE device with an Android/iOS companion app is a candidate. Fitness trackers, smart locks, LED light strips, tire pressure monitors—if it has an app, you can decompile it and feed it to Claude Code.

Q: Is this legal? Reverse-engineering for interoperability is generally protected under fair use and DMCA exceptions in the US, but the legal landscape varies by jurisdiction and by any EULA you may have clicked through. If you're doing this as an FDE at a customer site, get legal sign-off before decompiling third-party software.

Q: How does this compare to just reading the BLE specification? The BLE spec tells you how GATT works. It doesn't tell you that byte 4 of the notification characteristic is a bitfield where bit 3 enables vibration. That's proprietary and only exists in the companion app's source code—which is why decompilation + AI analysis is the shortcut.

Q: Can I use a local LLM instead of Claude Code? You can try, but the large context window and code-generation quality of frontier models make a significant difference for this use case. Decompiled smali is verbose and messy—you need a model that can hold tens of thousands of tokens of it in context without losing the plot. Local models have improved, but as we've covered, sampling settings often explain the gap more than raw parameter count.

Q: What's the FDE-specific takeaway here? Forward Deployed Engineers live at the boundary between "the thing the customer bought" and "the thing the customer actually needs it to do." That gap is often bridged by reverse-engineering, protocol translation, and rapid prototyping. Claude Code and similar tools don't eliminate the need for an FDE—they eliminate the need for the FDE to spend 14 hours staring at hex dumps. The judgment about what to build and how to make it reliable remains firmly in human territory. If you're targeting FDE roles, expect interviewers to probe your systems-thinking and stakeholder skills as much as your coding—our FDE interview guide covers what that looks like in practice.

Source: Mike Kasberg's original write-up details the full technical journey.