When Hardware Hacking Gets a Robot Arm: The Case for Automated PCB Probing

There’s a project on GitHub called autoprober that has been making the rounds on Hacker News, and the headline writes itself: someone built an AI-driven hardware hacking arm out of duct tape, an old webcam, and a repurposed CNC machine. It sounds like a weekend experiment. It is, in a way. But the underlying technique it demonstrates is something hardware security researchers have been circling around for years, and the fact that it’s now buildable from spare parts at home says something worth examining.

What the machine actually does

The core task autoprober automates is finding and interacting with debug interfaces on printed circuit boards, specifically UART and JTAG ports. These are the serial communication interfaces that firmware developers use during development and that never quite get disabled before products ship. Finding them on an unfamiliar board is traditionally a manual process: you study the PCB layout, identify likely test points, attach a multimeter or logic analyzer, and start probing pads one by one until you find something that looks like serial traffic.

Autoprober replaces the human hands in that loop. The CNC machine provides an X/Y positioning system that can move a probe tip to any coordinate on a board with sub-millimeter repeatability. The webcam feeds a top-down image of the board to a computer vision pipeline that identifies candidate probe points, test pads, and component layouts. The AI layer, built on top of a vision model, interprets what it sees and decides where the probe should go next. When the probe touches a pad, the system reads the electrical signal and determines whether it looks like UART idle state (typically high), I2C clock lines, or JTAG chain signals.

The result is a machine that can scan an unknown board, identify likely debug interface candidates, probe them in sequence, and report back with findings, without a human holding tweezers and squinting at silk screen labels.

Why this is harder than it sounds

Automatic identification of debug ports has a few genuinely tricky sub-problems. The first is the computer vision piece. PCBs do not come with standardized test pad layouts. A UART TX pin might be an exposed via, a labeled header, a solder bridge, or a tiny pad near the SoC with no marking at all. The model has to generalize across board styles, component densities, and manufacturing quality. Early approaches to this used simple edge detection and contour finding to locate circular pads, but that produces too many false positives on complex boards.

Modern approaches, including what autoprober uses, lean on convolutional neural networks or vision-language models that have been trained or fine-tuned on PCB imagery. The JTAGulator project by Joe Grand, released back in 2013, solved the electrical side of this problem elegantly by brute-forcing pin combinations to identify JTAG chains. What it could not do was tell you which physical pads on a board to connect to in the first place. That gap is exactly what vision-guided probing fills.

The second hard problem is signal classification. Once the probe is touching a pad, you need to determine what protocol is running on it. A pad sitting at 3.3V with no activity could be a power rail, a GPIO held high, or a UART line waiting for input. You need to see actual traffic to distinguish them, which means either waiting for the device to boot, or sending stimulus. UART in particular is identifiable by its framing: a start bit, eight data bits, and a stop bit at a fixed baud rate. Tools like baudrate detection heuristics can identify the baud rate from captured traffic by looking at the shortest pulse width, since the shortest pulse must be one bit period.

JTAG is more annoying. The JTAG Test Access Port uses four mandatory signals (TCK, TMS, TDI, TDO) and the boundary scan architecture is defined in IEEE 1149.1, but identifying which physical pin is which still requires trying combinations. JTAGulator handles this by iterating through pin combinations and sending the IDCODE instruction sequence, then checking whether TDO produces a valid 32-bit device ID. Integrating that kind of active probing with a physical positioning system is where autoprober is doing interesting work.

The CNC as a precision instrument

Using a CNC machine as the physical positioning layer is clever because CNCs are everywhere and cheap. A basic 3018-style CNC router, the kind sold for under 200 dollars on most electronics import sites, has enough X/Y precision for PCB work. The positioning resolution on those machines is typically around 0.1mm per step in hardware, though real-world accuracy depends on the lead screw quality and whether you’ve tuned the stepper driver current properly.

The probe itself needs to make reliable electrical contact without damaging the pad. Spring-loaded pogo pins are the standard solution here. They’re used in bed-of-nails test fixtures in production PCB testing for exactly this reason: consistent contact force, repeatable, and they handle minor height variation in the board surface. Mounting one to a CNC spindle mount and wiring it back to a logic analyzer or oscilloscope gives you a repeatable probing station.

The duct tape part of the build description is presumably the board fixture, and that choice actually matters. The board has to stay still relative to the camera and the probe. If the board shifts between the vision step (where the coordinates are identified) and the probing step (where the machine moves to those coordinates), your coordinate mapping breaks and you start probing the wrong pads. A proper fixture would use alignment pins or a vacuum table, but duct tape works fine for experimentation as long as you calibrate after fixing the board.

Coordinate calibration is the unsexy critical path

The camera sees the board in image coordinates, pixels. The CNC moves in machine coordinates, millimeters from an origin. Bridging those two coordinate systems requires a calibration step where you identify at least three known points in both systems and compute a transformation matrix. In practice this is a homography: a 3x3 matrix that maps image coordinates to machine coordinates accounting for camera angle, lens distortion, and any rotation between the camera frame and the machine axes.

OpenCV makes this straightforward with cv2.findHomography(). You give it corresponding point pairs and it solves for the transformation. For hardware probing the calibration targets can be corner pads of known components, fiducial marks if the board has them, or physical reference points you add yourself. The accuracy of your final probe placement is only as good as your calibration, which means this step deserves more attention than it usually gets in hobbyist builds.

import cv2
import numpy as np

# image_pts: pixel coordinates of known points
# machine_pts: corresponding CNC coordinates in mm
image_pts = np.array([[120, 85], [892, 91], [887, 634], [115, 628]], dtype=np.float32)
machine_pts = np.array([[5.0, 5.0], [85.0, 5.0], [85.0, 60.0], [5.0, 60.0]], dtype=np.float32)

H, mask = cv2.findHomography(image_pts, machine_pts)

def image_to_machine(px, py):
    pt = np.array([[[px, py]]], dtype=np.float32)
    result = cv2.perspectiveTransform(pt, H)
    return result[0][0]

With a well-calibrated homography, pixel coordinates from the vision pipeline map directly to CNC G-code coordinates you can send over serial to the controller.

Prior art and why this build matters now

This is not the first attempt at automated hardware probing. The GreatFET platform and associated tooling from Great Scott Gadgets provides a programmable hardware interface for exactly this kind of work, but it requires the human to handle physical contact. Academic work like JTAG Finder from WOOT 2013 and subsequent papers on automated debug interface discovery focused on the electrical and protocol side without tackling the physical automation.

What’s different now is the cost and accessibility of both the computer vision components and the positioning hardware. Running a capable vision model locally, or calling a hosted one cheaply, was not practical at hobbyist scale even five years ago. CNC machines that are accurate enough for this work are now available for less than the cost of a decent oscilloscope. The combination of cheap, precise physical actuation and accessible vision inference is what makes a build like autoprober possible in a garage rather than a research lab.

There’s also something worth noting about the DIY security research community’s relationship to automation. Projects like ChipWhisperer democratized side-channel analysis. The Glasgow Interface Explorer made flexible hardware protocol interfacing accessible without a full lab setup. Autoprober fits in that lineage: a tool that takes a technique previously requiring either expensive equipment or significant manual labor and makes it repeatable, scriptable, and reproducible.

What this means for device security

The implication that gets less discussion than the cool robot arm aspect is what automated probing means for the security posture of consumer electronics. UART debug interfaces left enabled on shipping hardware are remarkably common. Academic surveys of IoT device firmware have found exposed debug interfaces on a significant fraction of devices across categories from home routers to smart appliances. The usual defense is obscurity: the interfaces are physically small, unlabeled, and require someone to manually locate and probe them.

A machine that can scan a board, identify candidate pads, and systematically attempt UART connections in under an hour changes the economics of that obscurity. It does not make the attack easier for someone who already knows hardware security; it makes it accessible to people who do not. That matters when you’re thinking about who can find vulnerabilities in your product.

The countermeasure side is also worth considering. Authenticated debug interfaces, JTAG password locks (available on many modern SoCs via the JTAG Authentication specification extensions), and ROM-level disable of debug infrastructure before shipping are all real mitigations. The problem is that they require deliberate effort during product development, and that effort often loses to schedule pressure.

Builds like autoprober make the case concretely that “nobody will find it” is not a security argument. The arm does not care about schedule pressure.

Building one yourself

If this is the kind of project you want to replicate or extend, the rough shopping list is: a 3018 CNC router or equivalent, a spring-loaded pogo pin probe tip, a USB webcam with a wide enough field of view to capture a full PCB, a Bus Pirate or similar for the signal reading side, and a machine running Python with OpenCV and whatever vision model you want to use for pad detection.

The software pipeline has three stages: vision (detect and classify pads from camera feed), calibration (map image coordinates to machine coordinates), and probing (move to each candidate, read signal, classify protocol). Each stage is independently testable. Starting with a known board where you already know the UART location lets you validate the full pipeline before you trust it on unknown hardware.

The interesting extensions from here involve adding active stimulus capability (sending UART break signals, driving JTAG TAP state machines), building a dataset of PCB pad images to fine-tune the vision model, and handling multi-layer boards where the interesting pads might be vias that go to an inner layer. The physical automation is solved; the intelligence layer still has a lot of room to grow.