MCU vs SoC
Microcontroller or system-on-chip? The distinction decides where firmware lives, how you dump it, and which attacks are even on the table.
MCU versus SoC is the first classification you make when you open a device, because it decides everything downstream: where the firmware is stored, how you get a copy, and what an attack even looks like. A microcontroller (MCU) is a small, self-contained computer, CPU, RAM, and flash on one die, running bare-metal or a real-time OS. A system-on-chip (SoC) is a much larger part, an applications processor with memory controllers and peripherals, that boots a full operating system (usually Linux or Android) from external storage.
What it is
The two classes differ across the board:
| Trait | MCU | SoC |
|---|---|---|
| Examples | STM32, ATmega, PIC | i.MX, Broadcom BCM, Allwinner |
| CPU | One core, MHz range | Multi-core, GHz range |
| Flash | Internal, small (KB-MB) | External, large (MB-GB) |
| OS | Bare-metal / RTOS | Linux / Android |
| RAM | On-die, small | External DRAM |
| Debug | SWD / JTAG | JTAG + a UART Linux console |
| Firmware dump | Read internal flash over SWD | Read the external SPI/NAND flash |
Why it matters
The class dictates your entire approach. An MCU usually keeps its firmware in internal flash, so a dump means talking to the debug port and hoping read-out protection is off. A Linux SoC boots from an external flash chip you can often read directly, or even pull the whole filesystem off, and then you attack it like any Linux box: extract the rootfs, hunt binaries, read configs. Same goal, completely different route, and knowing which you face stops you wasting an afternoon attacking the wrong surface.
How you assess each
- Identify the main chip and pull its datasheet block diagram; the memory map tells you internal-vs-external at a glance.
- For an MCU, target
SWD/JTAGand read the read-out protection level first (RDPon STM32); if protection is off, dump internal flash withopenocd. - For a SoC, find the external boot flash (SPI-NOR or NAND) and the
U-Boot/UART console; a live console often gives you a shell or a way to halt and dump. - Match the tooling.
openocdand ajtag-swd-probefor MCUs;flashromplus ach341a/soic8-clipandbinwalkfor SoC boot flash.
Pitfalls
- The line is blurry. The ESP32 runs bare-metal like an MCU but boots from external flash like a SoC; classify by behaviour, not by reputation.
- Read-out protection changes everything on MCUs. If
RDPis set, the easy SWD dump is closed and you are into voltage-glitching or other invasive paths, a completely different effort tier. - SoCs hide service MCUs. A Linux router still has small MCUs (power, radio, EC) on board; do not assume one chip is the whole story.
- External flash is not always readable in place. Encrypted or authenticated boot on a SoC can make a raw flash dump useless, just as secure boot does on an MCU.