Wiki / Concepts

Root Filesystem (rootfs)

The filesystem mounted at / on a Linux device. Carve it out of the firmware and you have the whole userland on disk: binaries, configs, and secrets.

rootfs squashfs linux binwalk unsquashfs credentials
Where the wins live in a rootfs
/ (rootfs)
/etc
passwd, shadow
*.conf, keys
/usr/sbin
httpd, dropbear
/www
cgi-bin
The first places to look after extraction: account files and configs in /etc, service and CGI binaries in /usr/sbin and the web root. Grep them for credentials, then reverse the custom daemons.

The root filesystem (rootfs) is the top-level filesystem mounted at / on a Linux-based device, containing its binaries, libraries, configuration, startup scripts, and, very often, hardcoded secrets.

What it is

On a Linux device the rootfs is the userland: /bin and /usr for programs and libraries, /etc for configuration and accounts, /www or /var for the web interface, and the init scripts that wire it all together at boot. Embedded devices ship it packed into flash as a filesystem image, most commonly a read-only compressed squashfs, sometimes cramfs, jffs2, or ubifs. Carving that image out of the firmware and unpacking it gives you the device's entire userland as ordinary files on your disk.

Why it matters

Once you have the rootfs extracted, you effectively hold the whole device offline. Configuration files, startup scripts, web roots, TLS certificates, SSH host keys, and credentials are all just sitting there to read, with no authentication and no network round-trip. It is where nearly every quick firmware win comes from, and it is also the map to the binaries worth reverse engineering.

How it works

The bootloader launches the kernel, and the kernel mounts the rootfs at / (which filesystem and which partition are named on the kernel command line, for example root=/dev/mtdblock2). The init system then runs the startup scripts under /etc/init.d or the inittab, bringing up the daemons that make the device do its job. Because the image is usually read-only squashfs, the running system overlays a small writable area (tmpfs or a separate jffs2 partition) for state that must persist.

How to inspect it

Extract, then hunt.

binwalk -e firmware.bin                         # carve the rootfs out of the image
cd _firmware.bin.extracted/squashfs-root/       # enter the extracted tree
grep -rniE 'password|passwd|secret|token' etc/  # sweep configs for credentials
cat etc/shadow etc/passwd                        # account hashes and shells
find . -name '*.pem' -o -name '*_key' -o -name '*.crt'   # TLS and SSH key material

Read /etc/shadow for crackable hashes, look for dropbear or OpenSSH host keys, TLS server keys and certificates, and any plaintext credentials in *.conf files. Then move to the binaries: CGI programs under the web root and custom daemons in /usr/sbin and /usr/bin are prime reverse-engineering targets, since they are usually where the vendor's own (buggy) code lives.

Pitfalls

  • There can be more than one rootfs (a factory image plus an upgrade image, or an overlay). Make sure you are analysing the one that actually boots.
  • squashfs is read-only, so runtime state you care about (provisioned keys, logs) may live in a separate writable partition, not in the image you carved.
  • binwalk -e occasionally extracts a partial or wrong tree. If files look truncated, re-extract the filesystem with unsquashfs directly.
  • Symlinks in the extracted tree may point outside it; do not follow them blindly with tools that resolve paths against your host /.

Further reading

Related tools

SPICH341A programmer