Binsider – A TUI for analyzing Linux binaries

[gjvc]

see also: https://github.com/haampie/libtree for ldd(1) output as a tree for transitive dependencies

[q3k]

I don't really get why this is a TUI. Any time I actually hack on this sort of stuff, I'd rather have the outputs (eg. symbols, ELF sections/segments, strings, ...) directly on stdout so I can then further filter stuff or otherwise process it. Especially strings!

The only part of this tool that seems to merit a TUI is the hex view...

[IggleSniggle]

Sometimes you really want to make a TUI videogame but can't think of a good roguelike design so you just start hacking away at what you're curious about.

I can see this tool being a fun introduction to many things you would normally want to keep as separate tools you can glue together, and was probably also just a chance for them to exercise the TUI library they also created.

[mtndew4brkfst]

The creator is a maintainer of a major Rust library for writing TUI applications, so it's almost certainly a just-because rather than something that is intuitively or practically better as a TUI.

[Vegenoid]

One of the biggest benefits of a (good) TUI (or GUI) is that it guides someone who doesn't already know exactly what they want to do towards the most relevant information and the most common actions. Once you already know these things, it is usually faster and more powerful to work with code instead. With this TUI, someone who doesn't know very much about the internals of a binary gets that information presented them in a way that helps them learn the parts of the file, and their relations and relevance.

It is also easier for many people to remember how to navigate a GUI/TUI to achieve a task than to use the CLI, likely because it makes use of the parts of our brain for navigating space. This often makes them easier to use for tasks that you only do occasionally (at least until you learn how to take good notes, manage snippets, and work with your shell history).

So why a TUI instead of a GUI? Probably mostly for aesthetic and comfort reasons than for utility reasons - but I prefer staying in the terminal if possible, as I have a lot of control over its appearance and behavior, and TUIs generally have much better keyboard support than GUIs.

[fuhsnn]

"llvm-readelf --elf-output-style=JSON | jq" is handy.

[MSFT_Edging]

Sometimes you find yourself looking for a piece of info over and over again, and you'll lose something in stdout you think you'll remember as you do further analysis.

Ie for this, switching between readelf and objdump options, a handful of operations are already getting you 1000 lines into scrollback. I imagine having one terminal with this up and pre-parsed could be useful on the side while doing other analysis.

[Retr0id]

I always forget the precise flags for readelf/objdump etc., and in practice I do something like `readelf -a | less` and scroll until I find the info I was looking for. Scrolling around in `less` is pretty cumbersome for large outputs, and I wouldn't mind a TUI for it.

(I also forget the difference between a segment and a section, but I know what I'm looking for when I see it, heh)

[TimeBearingDown]

A reminder of why it’s good to analyze your project’s binaries. Test data, famously, but also firmware blobs, etc.

[hacb]

I cringed when I saw that

[johnisgood]

Yeah, an explanation would be nice, or perhaps a demonstration of whatever he has in mind that involves xz. That would make for a good demo.