Identifying Chips on an Unfamiliar Board
Every hardware assessment starts with the same question: what am I looking at. Identifying the major chips tells you where the processing, storage, and radios are, and that map guides everything that follows. Spend the first hour here and the rest of the work becomes targeted instead of blind.
Every Assessment Starts Here
A board you have never seen is a pile of black rectangles until you name them. Naming the major parts is what converts it into a set of known interfaces with public datasheets, and those datasheets are where the attack surface is written down.
The goal of this phase is a labeled map: which chip is the processor, where the firmware lives, what radios are present, and which buses connect them. Everything after this step is faster because of it.
Find the Big Three
Three chips define most of the attack surface; decorative parts, power regulators, and passives can wait. Find these first:
| Component | How to spot it | Why it matters |
|---|---|---|
| Processor / SoC | Largest package, most pins, usually near a crystal | Runs the firmware and defines the architecture |
| Storage (SPI NOR / eMMC / NAND) | 8-pin SOIC on four wires, or a many-pin BGA | Holds firmware and secrets; sets the extraction method |
| Radio | Shielded can with an antenna trace; FCC ID on the label | Wireless attack surface; the FCC filing reveals internals |
Read the Markings
Use a loupe or a USB microscope and raking light to read the top of each major package. The first line is usually the part number, and the lines below are date and lot codes. Even a partial number plus a manufacturer logo is often enough to identify the part.
# markings read off the three largest packages
U1: MT7628AN (large QFP, many pins) -> SoC?
U2: W25Q128JV (8-pin SOIC) -> SPI flash?
U3: shielded can, "RTL8192" -> Wi-Fi radio?MT7628AN -> MediaTek MIPS SoC, common in routers W25Q128JV -> Winbond 16 MB SPI NOR flash RTL8192 -> Realtek 802.11n Wi-Fi
Three markings turned an anonymous board into a MediaTek router-class SoC with 16 MB of SPI flash and a Realtek Wi-Fi radio. That is most of the architecture, established in a few minutes with a loupe.
Search the Part Number
Each number leads to a datasheet, and the datasheet leads everywhere else. A quick search confirms the manufacturer, the package, and the role, and it surfaces the reference manual you will use to find debug and boot pins later.
# a part-number search resolves role, package, and docs
W25Q128JV -> 16 MB (128 Mbit) SPI NOR, SOIC-8, 3.3V, standard 25-series command set-> SPI flash, readable with a SOIC-8 clip and flashrom -> likely holds the bootloader, kernel, and root filesystem
Confirming the flash is a standard 25-series SPI part tells you immediately that a clip and flashrom can read it, and that it most likely holds the entire firmware. The identification step has already pointed at the next move.
Infer Role from Layout and Storage Type
Traces and neighboring components tell a story even when a marking is unreadable: a chip with a nearby crystal is a processor or a radio, a small eight-pin part on four wires is almost certainly SPI flash, and two lines with pull-up resistors are an I2C bus. The function follows from the connections, which are visible on the board even when the silkscreen and the markings are not helpful.
Storage is the highest-value part after the processor, so pin it down precisely: a small SPI NOR (8 pins, 25-series number) versus larger eMMC or NAND (more pins, a controller). The distinction decides your extraction method, an 8-pin SPI part means a clip and a programmer, a BGA eMMC means test points or a reball, so identifying the storage type early tells you which tools to bring to the bench.
Spot the Radio and Mine the FCC Filing
A shielded can with an antenna trace is a radio, and the module often carries its own marking or an FCC ID printed on the shield or a label, an ID that is a public record naming the module and its capabilities.
# an FCC ID printed on a module label resolves the exact part
FCC ID: 2AB12-ESP32 -> fccid.io lookup-> Espressif ESP32 module: Wi-Fi + Bluetooth LE, Xtensa dual-core -> internal photos and test reports are public on the FCC database
An FCC ID is a gift to reconnaissance, because the public filing requires internal photos and test reports that often reveal the module’s chipset and antenna layout without you opening anything. For any device with a radio, that filing is a goldmine that needs no hardware at all: the photos frequently show the board clearly enough to read the major chips, and the report lists the test frequencies, telling you what the device transmits.
# find a device's FCC filing from the ID printed on its label # fccid.io/<GRANTEE>/<PRODUCT> -> internal photos, test report, block diagram echo "FCC ID 2AB12-XYZ -> internal photos show MT7621 SoC + W25Q128 flash"
Pulling the internal photos and the test report from the public FCC database can hand you most of the board map and the wireless capabilities for free. It is one of the highest-yield, lowest-effort steps in component identification, routinely overlooked by people who reach for the soldering iron before the public filing that already documents the device.
When the Markings Are Gone
BGA packages hide their tops, and some vendors sand or laser off part numbers to slow you down. Even then, the package size, the pin or ball count, the power and ground layout, and the surrounding parts narrow the field to a family, and a sanded chip with the power and clock fingerprint of a known SoC family is identified by elimination.
When the eye is not enough, the work moves to imaging. A microscope at higher magnification often recovers a number that looked blank, because laser etching leaves a shallow contrast that good lighting and angle bring out; for BGAs, an X-ray reveals the ball pattern and die size, both of which narrow the candidates. These tools sound exotic but are increasingly accessible, and for the main processor of a device under assessment, knowing exactly what it is repays the time spent imaging it.
Map the Buses and Build the Board Map
With the chips named, trace the buses that connect them: the processor-to-flash SPI lines, the I2C sensors, the UART console, and the link to the radio, with a continuity meter confirming which pads carry which signal. That bus map tells you where to clip a logic analyzer and reveals trust relationships, a key that travels from the processor to a secure element over an exposed I2C bus is a finding before you have powered anything on.
Pull it together into a labeled diagram, each major chip with its role, its part number, and the buses between them. This map is the deliverable of the recon phase and the reference for everything that follows: it tells you which datasheets to pull, which buses to clip onto, and which interfaces to attack first, and it is what makes a report credible by showing the client exactly what their product is made of. The hour spent here is repaid many times over in the focus it brings to the rest of the work.
The Defender’s View
The same map is useful in reverse: knowing exactly what is on your board, and what each part exposes, is the starting point for deciding what needs locking down before the device ships and what an attacker will reach for first. A product team that can produce its own accurate board map, with the exposed interfaces and sensitive data flows marked, is already ahead of most, because the attacker is going to build that map anyway and building it first is how you decide what to close.
Where This Fits
Component identification and board mapping are the opening phase of any hardware penetration test or product security assessment. If you want a structured teardown of your product that turns the board into an actionable map, that is the kind of work we do at Berkner Tech.
