Dumping NAND via UART: Extracting Secrets from Embedded Devices

Router connected to Attify Badge

Overview

This blog documents my journey in hardware hacking, where I successfully accessed a router’s UART debug port, dumped NAND flash memory, and extracted credentials used for the WebUI. By leveraging tools like the Attify Badge, USB-to-TTL adapters, and software utilities like Minicom and Picocom, I was able to interact with the router’s bootloader and retrieve sensitive data.

Finding the UART Port

The first step was identifying the UART (Universal Asynchronous Receiver-Transmitter) debug port on the router’s PCB. Most embedded devices include a UART interface for debugging purposes. Using a multimeter and examining PCB traces, I identified TX, RX, GND, and VCC pins.

How to identify the Pins

Open the device and look for 4 pins marked as GND, RX, TX, and VCC.

In some cases these markings will be written, and in some cases these markings won't be there.

UART pins in devices

If the UART pin markings are not visible, you can use a multimeter to identify the GND, TX, and RX pins. Follow these steps:

Finding GND (ground):

• Set the multimeter to continuity mode.
• Place the black probe on any of the round pins.
• Touch the red probe to the metal casing of the antenna or another known ground point.
• If you hear a beep, it indicates continuity—mark this pin as GND.
• Repeat this process for all pins, ignoring the square pad (which is usually VCC).

Identifying TX and RX:

• Set the multimeter to voltage (V) mode.
• Place the black probe on the GND pin.
• Touch the red probe to each remaining pin one by one.
• If a pin shows a stable voltage (e.g., 3.3V or 5V) during boot, it is the TX (Transmit) pin.
• If another pin shows fluctuating voltage during boot-up, it is the RX (receive) pin.

UART pin in router, identify the ports and solder cables for connection

Tools Used for UART Access

Attify Badge: A hardware tool designed for hardware security assessments, allowing easy interaction with embedded systems via UART, SPI, and I2C.

Attify Badge v3.1

USB-to-TTL Adapter: An alternative method to connect to UART ports using a simple FTDI or CP2102-based adapter.

USB-to-TTL Device

Once the pins are identified (GND, RX, TX) in your device, now take your USB-to-TTL or Atiifiy Bridge and connect GND to GND, RX to TX, and TX to RX.

Connection from Device1 to Device 2

Minicom/Picocom: Terminal emulators used to interact with the UART serial interface.

Finding the Baud Rate for UART Communication
Before connecting to the router via UART, it’s crucial to determine the correct baud rate (the speed at which data is transmitted). If the wrong baud rate is used, the output will be unreadable. There are several ways to find the correct baud rate:

1. Checking Manufacturer Documentation
Some routers have publicly available datasheets or manuals specifying the default baud rate, commonly 115200, 57600, or 9600. But no luck; I have not found any related documents.

2. Using a Logic Analyzer
A logic analyser can capture UART signals and determine the baud rate by analysing the timing between pulses. Don't have one.

3. Brute-Force with baudrate.py
A simple script from the Attify Badge toolkit or manually cycling through common baud rates using a script like:

#!/bin/bash
for baud in 9600 14400 19200 38400 57600 115200 230400 460800; do
    echo "Trying baud rate: $baud"
    picocom -b $baud /dev/ttyUSB0
done

When I use the bud rate 115200, I get the proper readable data while the router is being booted.

Command to connect using Picocom:

picocom -b 115200 /dev/ttyUSB0

Command to connect using minicom:

minicom -b 115200 -D /dev/ttyUSB0

Minicom Screen

If your baudrate is wrong, you will get the data in unreadable format.

Once the router started booting with proper baudrate, there was an issue. I thought I'd get direct shell access in all routers as shown in videos, or I'd need to enter the credentials to enter the shell. No, that wasn't the case; once the route was booted, it was getting stuck at this point.

Router Booting process

No idea what it is and went on the booting process for a day and indetified that it is using the UBoot, and there was a warning coming showing that press any key to exit the booting process.

Interuo the boot to enter UBoot

When you hit any key, I get into UBoot (not Shell). I had gone through the online reading regarding the UBoot based on version.

The problem here is that I had limited access to commands; to list all commands, type help, so I got a list of all commands.

UBoot help

based on commandsdid printenv

env variables inside the UBoot

Dumping NAND Flash
Inside the U-boot environment, I used the available NAND commands to extract memory contents.

Based on the commands in Avilabe, I want to be able to get the firmware. I tried for days and had no hope. When I do nand info, it gives me the data, and I understand what it says.

Device 0: nand0, sector size 128 KiB
Page size 2048 b
OOB size 64 b
Erase size 131072 b

I tried to dump the entire block; the router was getting restarted.

SO Started to dump sections of NAND memory:

nand dump 0x00000000 0x020000  # First 128KB
nand dump 0x00200000 0x020000  # Next segment
nand dump 0x00400000 0x020000
nand dump 0x00600000 0x020000

When I entered these commands, for the first two I got some random data, and in the second one 25% of the data was random, and the rest was FF.

nand dump of the sector 1, where it has data

nand dump of sector 2, which has less data and rest isall empty

FF was there in the rest of the sectros.

Here random value means it has data; if you are getting FF, then the sectro is empty.

SO finaly I got data from 2 sectors and copied the data to my host machine and saved it into a text file using binascii. I wrote the simple code to convert it into plain text.

Data extracted from the nan dump, which contains the config details like Username and Passwords

What I have found in those sectors is that in the first sector the data was related to ARM instructions, and in the second sector there were credentials stores.

BootImageNum=0x00000000
DownloadState=0x00000003
LastBooting=0x00000000
O7State=0x00000000
Image1Status=0xffffffff
Image0Status=0xffffffff
USERNAME=user
USERPASSWD=Web@0763
IsOmciUpgrading=0x00000000

These credentials turned out to be the actual WebUI login, confirming that they were stored insecurely in the router’s firmware.

Conclusion

In this blog, I detailed my journey of extracting credentials from a router by identifying a UART interface, connecting via tools like the Attify Badge and USB-to-TTL converters, and dumping NAND memory using U-Boot commands. Through this process, I successfully retrieved and converted firmware data, ultimately uncovering valid credentials for the web UI.

This might not be the ultimate method, but it represents the best I could achieve in my first attempt. There’s always more to explore, and I’m eager to dive deeper into firmware analysis, memory dumping, and embedded security. The journey doesn’t end here—there’s much more to understand, and I look forward to refining my approach with every new challenge.