Boot and Loot: Dumping Firmware via U-Boot
- Victor Hanna
- May 6
- 3 min read
Updated: May 7
Harvest Firmware Before Linux Even Wakes Up
What is U-Boot?
U-Boot (short for Universal Bootloader) is an open-source bootloader commonly used in embedded Linux systems. It's responsible for initializing hardware and booting the OS. U-Boot often includes powerful commands for memory inspection, file transfer, and flashing firmware—making it a goldmine for hackers when exposed.
If you hit U-Boot early enough, you can dump the entire firmware before the OS even knows you're there.
Why Hackers Love U-Boot Access
Pre-kernel control: No userspace, no login prompts, no defenses.
Direct memory access: Read flash memory, RAM, and bootloader code.
No exploits needed: Just serial access and timing.
Tools You’ll Need
A USB-to-serial adapter (e.g., CH340, FTDI CP2102)
Terminal emulator: minicom, screen, or picocom
A target device with exposed UART pins
Patience and a steady hand during boot
Step 1: Connect to UART
Locate TX, RX, GND pins on the target board.
Connect:
TX → RX
RX → TX
GND → GND
FTDI connection to target
Open terminal:
Use a terminal like minicom
Try common baud rates: 115200, 57600, 38400, etc.
Step 2: Interrupt Boot and Enter U-Boot
As the device powers on:
Watch the terminal closely.
Capitalise on your moment went it arises. There will be a clear indication for your chance to pounce, simply follow the prompt where it directs you
Step 3: Identify Flash Memory Location
Once you have been afforded a u-boot prompt we can commence recon and determine the memory location of the much sort after loot.
Using printenv, which will help you determine the bootcmd parameter, which ultimately points to the bootm command which takes the memory address of the image as its first argument, allowing it to find and load the operating system.
Step 4: Deteriming the size of the flash device
Thankfully for us being eagled eye afforded a valuable piece of information during the boot process and just prior to the u-boot escape sequence, namely the flash chip used to store the firmware image.
NOTE: You can also infer the sizing of the flash chip within the product id, W25Q128BV (128Mbit = 16MB)
This can also be verified by the datasheet:
Step 5: Loading and Dumping the firmware from RAM
What we know:
Chip: W25Q128BV
Flash size: 16MB = 0x01000000
Firmware start (from bootcmd): 0xBC050000
We want to dump the firmware starting at 0xBC050000 to the end of the flash, which ends at:
Flash end = 0xBC000000 + 0x01000000 = 0xBD000000
So the dump size is:
0xBD000000 - 0xBC050000 = 0x00FB0000 (15.6875 MB)
Copy the firmware to RAM (at a safe buffer like 0x81000000):
At this stage we have a few options (if available via the bootloader)
cp.b 0xBC050000 0x81000000 0x00FB0000
or alternatively
cp2ram 0xBC050000 0x81000000 0x00FB0000
We can now use minicom's logging feature to capture output over UART and redirect to a file on our host device
Start the Logging Feature:
CTRL + A, L and choose a output filename e.g. firmware_dump_over_uboot.log
On the target, run the md.b command:
md.b 0xbc050000 0x1000000
(Waiting patiently for the dump to end)
On the host, we now cleanup and rebuild the binary:
Analyze Firmware using binwalk
Dump Exposes SQUASHFS filesystem
Final Thought
Embedded devices guard secrets behind soldered shields and locked-down bootloaders, the humble UART—paired with the raw power of U-Boot—becomes your covert channel.
Mastering firmware dumping over serial isn’t just a hack; it’s a critical skill that bridges hardware and software, giving you insight into how the device truly operates.
Whether you're a pentester mapping out attack surfaces, a reverse engineer uncovering vulnerabilities, or a digital archaeologist chasing zero-days buried in silicon—this method gives you access where there was none. It’s slow, it’s gritty, but it’s the kind of edge that turns curiosity into control.
Comments