namura's notes

Rfirmware

4 min read

Target: Linksys WRT1900ACS v2 Firmware Difficulty: Medium (Requires Linux Kernel Module interaction) Objective: Analyze a router firmware image, mount the filesystem, and extract sensitive configuration data.

1. Executive Summary

We are tasked with analyzing a firmware image for the Linksys WRT1900ACS v2 router. Using Binwalk, we identify the filesystem structure as JFFS2 (Journaling Flash File System version 2). To explore the contents, we cannot simply “unzip” it; we must emulate a flash storage device (mtdblock) in Linux, write the image to this emulated device, and mount it. Post-exploitation involves searching through configuration files (.ini) to find version numbers and default credentials.

Key TTPs (MITRE ATT&CK):

  • T1592 (Gather Victim Host Information): Firmware reverse engineering.
  • T1083 (File and Directory Discovery): Analyzing file system hierarchies.
  • T1552 (Unsecured Credentials): Extracting hardcoded passwords from config files.

2. Operational Setup & Prerequisites

Before analyzing, we need to prepare the environment. Many modern tools struggle with older Python dependencies required by jefferson (the JFFS2 extractor used by binwalk).

A. Tool Installation

  1. Clone the Firmware:
git clone https://github.com/Sq00ky/Dumping-Router-Firmware-Image/ /opt/Dumping-Router-Firmware
  1. Install Jefferson (JFFS2 Support): Note: Using a Python Virtual Environment (venv) is highly recommended to avoid dependency conflicts.
sudo pip install cstruct
git clone https://github.com/sviehb/jefferson
cd jefferson
python3 setup.py install
  1. Unpack the Firmware:
cd /opt/Dumping-Router-Firmware
7z x FW_WRT1900ACSV2_2.0.3.201002_prod.zip
  1. Verify Integrity:
sha256sum FW_WRT1900ACSV2_2.0.3.201002_prod.img
# Expected: dbbc9e8673149e79b7fd39482ea95db78bdb585c3fa3613e4f84ca0abcea68a4

3. Firmware Analysis: Binwalk

We use Binwalk to analyze the binary structure of the firmware image.

binwalk FW_WRT1900ACSV2_2.0.3.201002_prod.img

Output Analysis:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header (Linksys WRT1900ACS Router)
64            0x40            Linux kernel ARM boot executable zImage
4214256       0x404DF0        Flattened device tree
6291456       0x600000        JFFS2 filesystem, little endian
  • Critical Finding: The actual filesystem starts at offset 6291456 (0x600000) and is of type JFFS2. This is where the files we want (shadow files, configs) live.

Extraction

We can try binwalk -e, but for this exercise, we manually mount the specific JFFS2 block to ensure we can browse it natively.

First, extract the raw partition:

binwalk -e FW_WRT1900ACSV2_2.0.3.201002_prod.img

This creates a directory _*.extracted. Inside, we find 600000.jffs2. This is our target.

4. Flash Memory Emulation (Mounting JFFS2)

Standard mount commands cannot mount JFFS2 files directly because JFFS2 is designed for raw flash chips, not block devices (like hard drives). We must simulate a flash chip in RAM.

Step 1: Create the Block Device

We create a special device node in /dev that represents our fake flash storage.

# Cleanup previous attempts
rm -rf /dev/mtdblock0
 
# Create block device (Major 31, Minor 0 is standard for MTD)
mknod /dev/mtdblock0 b 31 0

Step 2: Load Kernel Modules

We need to load the modules that allow Linux to understand Memory Technology Devices (MTD).

modprobe jffs2      # Filesystem support
modprobe mtdram     # Emulates flash in RAM
modprobe mtdblock   # Allows access to MTD as a block device

Step 3: Write the Image to Memory

We copy our extracted JFFS2 file into the emulated flash device.

# "Burning" the firmware to our fake chip
dd if=_FW_WRT1900ACSV2_2.0.3.201002_prod.img.extracted/600000.jffs2 of=/dev/mtdblock0

Step 4: Mount

Now that the data is on the “chip” (/dev/mtdblock0), we can mount it like a normal drive.

mkdir /mnt/jffs2_file
mount -t jffs2 /dev/mtdblock0 /mnt/jffs2_file

5. Forensics & Flag Hunting

With the filesystem mounted at /mnt/jffs2_file, we can browse it as if we were logged into the router.

A. Searching for Secrets

We use grep to hunt for keywords related to the CTF questions.

1. Media Server Configuration

find /mnt/jffs2_file -name "mediaserver.ini"
# OR
grep -iRl "media" /mnt/jffs2_file 2>/dev/null
  • Target: mediaserver.ini
  • Finding: Checking the content usually reveals the Media Server Version (e.g., version=...).

2. SSH Configuration/Credentials

grep -iRl "ssh" /mnt/jffs2_file 2>/dev/null
  • Target: dropbear (common SSH server for embedded devices) or specific config files.
  • Finding: Often reveals the default SSH password or port.

3. Operating System Version

cat /mnt/jffs2_file/etc/openwrt_version
# OR
cat /mnt/jffs2_file/etc/banner
  • Finding: The exact firmware/OS version (e.g., OpenWRT version).

4. Shadow File (Password Hashes)

cat /mnt/jffs2_file/etc/shadow
  • Analysis: This contains the password hashes for the root user. While cracking might take time, having the hash confirms we have full access.

6. Key Takeaways

  1. JFFS2 is Unique: Unlike EXT4 or NTFS, JFFS2 requires mtdblock and mtdram to mount because it expects the physical behavior of flash memory (erase blocks).
  2. Binwalk is Essential: It is the primary tool for identifying where the filesystem lives inside the binary blob.
  3. Grep is King: Once mounted, standard Linux enumeration (find, grep, cat) is all you need to extract the secrets.

Graph View

Backlinks