Reading a QFP Datasheet Like an Attacker
A datasheet is written for designers, but it reads just as well as an attack map. Once you identify the main chip, its datasheet tells you exactly where to probe for debug access, which traces carry the buses, and how to coax the part into a mode that accepts your code. Reading it first is what separates efficient hardware work from hours of blind poking.
A Datasheet Is an Attack Map
Designers read a datasheet to build a board. An attacker reads the same document to find the fastest way in. The pin tables say where debug and bus signals live, the electrical sections say what voltages to expect, and the boot and protection chapters say how to take control. Every one of those is dual-use.
The most efficient hour on a hardware engagement is usually the first one, spent reading rather than probing. By the time a probe touches a pad, you should already know what that pad is, what it carries, and what you expect to see.
Identify the Chip First
Read the markings on the largest package, usually a QFP or BGA near the center of the board, under a loupe or microscope. The top line is the part number, the rest is a date code and lot code. The part number is the key that unlocks everything else.
# the markings you read off the package STM32F407VGT6 # decode: STM32F4 family, 407 line, V=100 pins, G=1MB flash, T=LQFP, 6=industrial temp
-> Search: STM32F407VG datasheet -> Reference manual RM0090 covers the whole F4 family -> 100-pin LQFP, Cortex-M4, documented JTAG/SWD and boot pins
Two documents matter: the datasheet, which has the pinout and electrical limits, and the reference manual, which explains the peripherals and boot behavior. Together they describe the part better than the vendor’s own engineers remember it.
Find the Debug Pins
Jump to the pin description table and look for JTAG and SWD signals. These are the highest-value targets on the board, because debug access usually means full control over memory and execution. The datasheet names the exact physical pins.
# from the STM32F407 pin definitions table
PA13 JTMS / SWDIO (pin 72)
PA14 JTCK / SWCLK (pin 76)
PA15 JTDI (pin 77)
PB3 JTDO / SWO (pin 89)
PB4 NJTRST (pin 90)-> SWD needs only two pins: SWDIO (PA13) and SWCLK (PA14) -> if those reach a header or test points, the core is reachable
SWD is the easy win because it needs only two lines plus ground. If PA13 and PA14 connect to a header, a pad, or even a test point, an attacker with an inexpensive probe can halt the core and read memory. Whether that is possible is one of the first things the datasheet tells you.
Map the Buses
The same pin table shows the SPI, I2C, and UART peripherals. Cross-referencing them against the board tells you which traces to clip a logic analyzer onto and what to expect on each line. A serial console and an external flash chip are both common findings here.
# peripheral pins from the alternate-function table
PA9 USART1_TX (pin 101) <- likely debug console TX
PA10 USART1_RX (pin 102)
PB13 SPI2_SCK (pin 92) <- external flash?
PB14 SPI2_MISO (pin 93)
PB15 SPI2_MOSI (pin 94)-> USART1 TX/RX: probe for a boot log at 115200 -> SPI2 lines: follow to the nearby 8-pin flash chip
Following those SPI lines to a nearby 8-pin chip often leads straight to the firmware, and the UART lines often lead to a boot log or a shell. The datasheet turned a mystery board into a labeled set of targets.
Check the Electrical Limits
Before a probe touches a pad, the absolute-maximum and operating-condition tables tell you what voltage the I/O runs at. Driving a 3.3V adapter into a 1.8V pin is how you turn a recon session into a dead board.
# from the electrical characteristics section
VDD operating range: 1.8 V to 3.6 V
IO logic high (VIH): 0.7 * VDD
Absolute max on any pin: VDD + 0.3 V-> level-shift to the board's VDD before connecting an adapter -> a 3.3V probe on a 1.8V domain can damage the I/O
Reading this section is not optional caution, it is what keeps a careful attacker, and a careful tester, from destroying the very thing they came to study. The voltage you measure on the rail should match what this table predicts.
Find the Boot Configuration
Many processors choose their boot source from strap pins sampled at reset. The datasheet names those pins and the table of what each combination does. Knowing them can let you force the chip into a serial bootloader that accepts code directly, bypassing whatever is in flash.
# STM32F4 boot mode selection (BOOT1=PB2, BOOT0 pin)
BOOT0=0 -> boot from main flash (normal)
BOOT0=1, BOOT1=0 -> boot from system memory (built-in serial bootloader)
BOOT0=1, BOOT1=1 -> boot from embedded SRAM-> pulling BOOT0 high enters the ROM serial bootloader -> that bootloader speaks UART and can read/write flash unless RDP blocks it
Forcing system-memory boot drops the chip into a ROM bootloader that talks over UART. On an unprotected part, that bootloader will read and write flash for you. Whether it is blocked depends on a readout-protection setting, which is the next thing to check.
Read the Protection Bits
The reference manual documents the option bytes and the readout protection levels that decide whether debug and the ROM bootloader can touch flash. This is the single setting that most often separates a five-minute extraction from a hard one.
// STM32 RDP levels, from the option-bytes section // Level 0: no protection, debug and flash read fully open // Level 1: flash read blocked over debug; mass-erase on level drop // Level 2: debug permanently disabled, RDP locked (irreversible)
A production board left at Level 0 is wide open. Level 1 protects the flash contents but still allows a mass-erase. Level 2 is the locked-down choice and also the one that complicates field repair, which is the tradeoff the design team has to weigh.
Cross-Reference to the Physical Board
A pin number on paper becomes useful only when you find it on the board. With the chip’s pin-one marker as a reference and the package pitch from the datasheet, you can count to any pin, then confirm with a continuity test from the pad to a header or test point.
# continuity from a header pad to the chip's SWDIO pin (PA13) # multimeter in continuity mode, one probe on the header, one on pin 72
beep -> header pin 3 connects to PA13 (SWDIO) beep -> header pin 4 connects to PA14 (SWCLK) # the 4-pin header is an exposed SWD port
That continuity test is the moment the datasheet pays off. The unlabeled four-pin header is now a known SWD port, found in two minutes because you knew which chip pins to look for.
The Memory Map Tells You Where to Look
The reference manual’s memory map is a quiet goldmine. It names the flash base, the RAM base, the option-byte address, and the system-memory region where the ROM bootloader lives. Those addresses are exactly what you feed a debugger to read the right regions.
When you later attach over SWD, you are not guessing at addresses. The map already told you that flash starts at 0x08000000, RAM at 0x20000000, and the option bytes sit at a fixed address you can read to learn the protection level directly from the running chip.
Errata and Application Notes Leak Too
The datasheet is not the only public document. Errata sheets describe bugs the vendor knows about, and application notes spell out how features are meant to be used, including security features. Both occasionally reveal weaknesses, like a protection level that an erratum admits can be bypassed under specific conditions.
Reading the app note on a chip’s readout protection, for example, often describes the exact attack the protection is meant to stop, which tells an attacker precisely what to try. Treat every document the vendor publishes as part of the attack surface.
Identifying an Unknown Chip From Its Pinout
Sometimes the markings are lasered off or sanded down to slow you down. The pinout still betrays the part. Measuring which pins are power, ground, and crystal, then matching that fingerprint against candidate datasheets, usually identifies the family even with no markings at all.
# map power/ground/crystal pins by measurement, then match to a datasheet # VDD pins: 1,11,28,50 GND: 8,23,35,47 crystal: 5,6
-> 4 VDD / 4 GND / HSE on pins 5-6, 64-pin LQFP -> matches STM32F103 family pin map (power and clock layout identical)
A power-and-ground fingerprint is surprisingly unique across a 64 or 100 pin package. Matching it to a datasheet recovers the part number that the vendor tried to hide, and from there the whole attack map opens back up.
Turning the Datasheet Into a Test Plan
The reading pays off as a checklist. By the time you pick up a probe, the datasheet has handed you a short list of things to verify on this specific board: is SWD exposed, is the UART live, what is the readout-protection level, can BOOT0 be strapped, and does the external flash carry the firmware in the clear.
That list is the test plan. Each item is a yes-or-no question with a known way to answer it, and each answer is either a finding or a control working as intended. Starting from the datasheet means the hands-on work is confirmation rather than exploration, which is faster and far less likely to miss something the document already pointed at.
Read It Before You Touch the Board
An attacker reads the datasheet as a map of where the value is and how to reach it. A defender should read it exactly the same way, asking which documented capabilities are exposed on the production board and which were deliberately disabled.
The datasheet is public, so assume your adversary has already read it cover to cover. The only question is whether you read it first and closed the doors it points at, or whether you find out which doors were open after someone walks through one.
Where This Fits
Datasheet-driven reconnaissance is the opening move of a hardware penetration test, and it makes every later step faster and safer. If you want a structured hardware assessment that starts where the attacker starts, that is the kind of work we do at Berkner Tech.