Embedded Linux

Embedded Linux is what runs on the majority of network-connected devices bigger than a microcontroller: routers, IP cameras, NAS boxes, set-top boxes, industrial gateways. It is recognisably Linux, with the parts nobody needs on a device removed and a few embedded-specific pieces added.

What is different from a desktop

• BusyBox instead of coreutils. One multi-call binary provides sh, ls, cat, ps, wget, telnetd and a few hundred other applets, in roughly one megabyte. Every applet is a symlink to the same executable, and each is a reduced version of the real tool with fewer options.
• A read-only root. The rootfs is usually SquashFS, compressed and immutable. Writable state lives on a small overlay (JFFS2, UBIFS, or a tmpfs) mounted over /etc, /var or /overlay. This is why a factory reset works by erasing one partition.
• Flash, not disks. Storage is raw NAND or NOR flash exposed as MTD devices (/dev/mtd0, /dev/mtdblock0), partitioned by a table the bootloader passes in on the kernel command line, not by anything on the media itself.
• A minimal init. Often BusyBox init reading /etc/inittab, or procd on OpenWrt. Systemd is rare.
• No package manager, no users. Everything runs as root because there is nobody else. Privilege escalation is frequently not required: you start there.
• A serial console. The kernel command line names it (console=ttyS0,115200), and the physical pads are usually still on the board.

Where the interesting things live

Once a rootfs is unpacked, the same handful of paths pay off almost every time:

/etc/passwd  /etc/shadow      # hashes, often crackable, often shared across a model line
/etc/init.d/  /etc/rc.d/      # what starts at boot, and with what arguments
/etc/config/                  # OpenWrt-style configuration
/www/  /usr/www/  /var/www/   # the web UI, its CGI binaries, its authentication
/etc/*.pem  /etc/*.key        # TLS material, frequently a single key across the fleet
/lib/  /usr/lib/              # versions of libc, openssl, and any vendor library
/usr/sbin/  /usr/bin/         # the vendor's own binaries, the actual reverse-engineering targets

Init scripts are the most underrated of these. They tell you which services exist, which ports they bind, what debug flags they take, and frequently contain the exact hardcoded credentials a running service will accept.

How you get in

• The bootloader. Interrupt u-boot, append init=/bin/sh to bootargs, and the kernel runs your shell as PID 1. No authentication involved.
• The serial console. Some devices simply give you a root prompt; others ask for a password whose hash is in /etc/shadow in the firmware you already have.
• The network services. Telnet still exists on this class of device, and the web UI's CGI binaries are usually C programs parsing attacker-controlled strings.

Build systems

Most vendor images are produced by Buildroot (a compact build system emitting a single rootfs image) or Yocto/OpenEmbedded (a larger, layered system). OpenWrt is a full distribution in its own right with a package manager, and it shows: an OpenWrt-derived image is far more complete and consistent than a typical Buildroot one, and easier to work with in every direction.

Pitfalls

• BusyBox applets are not their GNU equivalents. Options differ, and a command that works in your shell may not on the target.
• The root filesystem being read-only means your changes vanish on reboot unless you write them to the overlay or to flash.
• /proc/mtd and the kernel command line, not the on-disk layout, are the authority on where partitions actually are.
• Cross-architecture reality: the target is usually MIPS or ARM. Binaries you drop on it must be statically linked for the right architecture, or brought in with the right loader.

What it pairs with

u-boot is the way in, busybox is the userland, squashfs-concept and rootfs cover the filesystem, and binwalk is what gets you all of it from a flash dump.

Further reading

• Wiki: u-boot
• Wiki: busybox
• Wiki: rootfs
• Wiki: squashfs-concept
• Wiki: binwalk
• Wiki: uart