Introducing elf-analyzer

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.

The tool can be found on my GitHub: https://github.com/ttepatti/elf-analyzer

What does it do?

This tool assists in analyzing the metadata around ELF files.

  • Their strings,

  • their shared libraries,

  • their place in a filesystem image,

  • etc.!

But that’s not telling the whole story:

The main goal of this tool is to reduce the mental fatigue on those analyzing such firmware images! It aims to display in-depth binary and device metadata in a way that allows users to compare and contrast binaries, explore a device’s filesystem, and make inferences about data quicker and easier.

Why is it useful? An example scenario!

Traditionally when performing analysis of an embedded device filesystem, there’s a LOT of context that you have to keep in your head. For example, if your goal is to answer the question “what binaries draw to this device’s screen?”, you may need the following information:

  • What framework(s) are used to draw graphics to the screen?

  • What shared libraries on the system are imported to allow calls to those frameworks?

  • What binaries on the system import those shared libraries?

To perform this kind of analysis by hand, the steps would likely involve:

  • Grepping through all of the binaries on the device’s filesystem for known strings

  • Dumping a list of shared libraries or symbols with readelf

  • Correlating which binaries all share the same shared libraries, possibly grepping for their names

  • Writing down the paths of the relevant binaries, becoming familiar with where various functionality lives on the filesystem

It can be a lot of tedious work even answering a simple question like that!

Usually, somewhere in this mix of readelf, strings, file, etc. you’ll end up getting interrupted. Maybe it’s a loved one asking if you to come to bed, or a coworker asking if you’d like to go to lunch, or maybe even just a friend hitting you up on Discord. But now, the precarious balance of context and information you’ve stored in your head needs to go somewhere!

Perhaps you’ve been taking notes - this would be the optimal solution. You could drop your project at any time and all of your context would be saved, ready to be picked back up next time you start. But I feel that isn’t fully realistic… Usually, at least some amount of context is lost when you are interrupted.

And what’s next? The grueling process of getting back up-to-speed. Re-gaining the lost context, re-exploring your binaries and filesystem, trying to remember “where the heck were those binaries again? What was that graphics library?”

The Alternative: Using elf-analyzer

The goal of elf-analyzer is to make this unique form of cross-file research easier. You can import an embedded device’s filesystem, browse it visually in a “tree” graph layout, and drill down into the details of any ELF or shared library on the system.

  • Curious to get a list of all binaries that have a shared library starting with “libc”?

    • You can find that.

  • Next, do you want to see what folders all of those binaries sit in, to get an idea of where libc-using binaries sit in the filesystem?

    • No worries - it’s already been rendered in the left-side ‘tree’ pane!

  • Curious to view all binaries that have the string “password” in them?

    • Also possible!

While the functionality is somewhat basic for now, my goal is to reduce the amount of “context” you have to hold in your head about any given embedded device, to make it easier to visualize the entire filesystem and layout of the device’s operating system without doing so all in a mental model.

As an example, I’ve included a screenshot below of me browsing through the filesystem of a TP-Link WA901ND WiFi router.

A TP-Link router filesystem opened in elf-analyzer

On the left side of the screen, a tree graph of the device’s filesystem is displayed.

  • Scanned binaries are highlighted in green

  • If binaries are clicked, the page will scroll to the relevant entry on the table on the right

  • Folders are shown in white

  • Non-binary files are still shown, but are greyed out and not clickable

On the right side of the screen is a more detailed table of the scanned binaries.

  • The output of ‘file’ is shown, along with the binary’s path

  • If clicked, the row expands to show additional details

  • The expanded row shows the binary’s SHA256 hash, string count, and a list of the binary’s shared libraries

In addition to this information, you can also drill down into the details of a specific binary, as shown in the screenshot below.

Inspecting the specific details of the “iwlist” binary

This view allows you to:

  • View all captured metadata about the current binary

  • Scroll through the full list of the binary’s strings

  • Export the binary’s strings to a file to save

Planned Features & What’s Next

As you can see, the tool is still somewhat light on in-depth analysis, and is ever-evolving!

I have a whole laundry list of features I’d like to implement:

  • Statistics about shared library usage

    • ie: how many times is each identified shared library used?

  • Relationship graph between binaries and dependencies

    • Helps visualize common import trends and high value targets for RE

  • Scanning for dynamic library calls

    • Due to the use of readelf to detect imported libraries, the tool currently can’t detect libraries that are called at runtime, like with dlopen!

  • Automatic flagging of non-stripped binaries

  • Ability for users to add custom tags to binaries or shared libraries

    • A user could add a tag of ‘KNOWN-VULNERABLE’ to the library ‘libmsglog.so’. Any binary that imports this shared library would automatically have the tag applied, making it easy to visualize potential targets for additional research!

Of course, it likely won’t end there, and this will be an ever-evolving tool and project.

In Conclusion

That’s about it! Thanks for checking out my new tool :)

If you have any feedback from what you’ve seen here, please feel free to reach out! I’d love to hear others’ thoughts and ideas.

Previous
Previous

Firmware Border Binaries and Multi-Binary Taint Analysis

Next
Next

Using CaringCaribou Without Root