firmware

It’s not often you look to extract an embedded device’s firmware over the network. Luckily, it’s possible with SSH! We’ll go over a few techniques for dumping raw block device bytes out onto the network to facilitate quick extraction of device firmware for static analysis on a separate host computer.

The device I’m currently working with has over five hundred shared libraries, all spread out across random folders within the filesystem. Bleh!

This is a common issue I’ve run into when working with embedded systems. You want to import an arbitrary binary into Ghidra, but first you have to spend 10 minutes tracking down where all of it’s shared libraries are located! A major pain.

But have no fear, a one-liner is here! (every Linux graybeard’s favorite saying)

In general, most software security operates on the basis of sources and sinks - vulnerable data, input, influence, etc. comes from a known source, and eventually reaches a vulnerable sink. When thinking of a single binary, this concept can be fairly straightforward:

If a binary takes input via argv that eventually ends up in a system() call and leads to command execution, argv() is the source, and system() is the sink.

But what about when thinking of an entire embedded system, rather than just a single binary?

This is where the concept of border binaries come into play!

In the beginning of December, I published a new tool I wrote for analyzing ELF files! This tool is aimed at helping reverse engineers and tinkerers understand embedded filesystems quickly and easily, through ergonomic methods of displaying in-depth device and binary metadata.

Here’s your five second tip of the day: Need to install CaringCaribou on a system you don’t have root on? (For example: a CTF VM)