Bingrep: Like grep, but for binaries | Hacker News Reader

Bingrep: Like grep, but for binaries

github.com

145 pointsadulau31 comments

>like grep, but for binaries

It doesn't really seem like grep to me. grep takes 2 inputs: a text and a search string. bingrep only takes one input, a binary. Without a search string it's hard to really say this is like grep.

It seems similar to objdump but with somewhat differing information and with coloring.

possibly more like "less" but for binaries?

The sample output on the github page looks a lot like the sort of information you get from "readelf -a ...", but colorized.

Right; it's not at all "like grep". A little like strings, but yeah, more like objdump if it has to be seen "like" anything else at all.

Ok, grep is a misnomer, but can we assume it was named binless and talk about the merits of this tool? It looks super useful.

I can see how it fills a gap. I am not very often examining binaries, so I can be wrong about it but am i wrong in assuming that objdump will simply list the parts it manages to interpret from a file and silently ignores gibberish or unsupported sections?

I have alway wanted an ability to examine a binary files in a way a bit more interpreted than an hex editor, but without missing any "gibberish" part.

I can see that tool as a nice addition to a binary forensics toolbox

In the case that you are interested, I made a tool for editing ELF files by hand (https://github.com/TheThirdOne/elf-edit).

It is hardly complete, but it does highlight section headers (and decode them into human readable format). One of the next features I want to implement is to skip to the section body, but I haven't had much time to work on it recently so it got put on the backburner.

Also, I realized while writing this that the repo doesn't have a readme, so if you want to check it out you'll have to install it. If you are interested, I might be able to make a decent readme tomorrow.

Thanks

Does it do .NOTEs?

.notes aren't standardized so I don't know of a good strategy to highlight and decode them.

IIRC .note.gnu.build-id is just ascii text so it should be pretty easy to understand anyway.

I would think many others are also just text, but I don't know much about .notes in general because I was focusing on standardized, general ELF stuff.

Well, .notes are standard ELF .. the reason I'm asking is because .notes are for vendors, and well .. this seems like a tool-of-interest to vendors, y'know ..

> I can see how it fills a gap

What gap is that? I can't see anything I wouldn't find in existing tools.

If all it offers is a prettifier, I'd rather it were just that.

I can't see the gap too. Objdump, otool or nm with grep is what binary explorer needs. Rather than colorizing, why not filter unneeded things or colorize needed via search highlighting? (My personal preference, ofc.)

From its very short source it seems that it simply pretty-prints headers of MachO and ELF files. No sophisticated logic involved, just hello world in rust. So it cannot be a prettifier, since it doesn't parse any output.

I am not doing binary forensics regularly but I was under the impression that there is no tool that would display all the sections of a binary, with the insurance it would not skip a part it could not interpret? Maybe there are options of objdump I am ignoring there?

Maybe: readelf -a [0]

[0] https://sourceware.org/binutils/docs/binutils/readelf.html

> Ok, grep is a misnomer, but can we assume it was named binless and talk about the merits of this tool?

The name of the tool is part of the tool, and part of using it will be for me to share it with other people & explain, it's called bingrep by it's not like grep (despite what the project readme says). People who are busy may see that as a signal that the project values communication lower than features, or that they made a mistake and either: know they did but choose not to acknowledge/act to fix it; or don't recognize it (how many other mistakes might they have made? Any which affect its operation?)

Like this is the impression a colleague might get when spending 5 seconds listening to me mention it to them when getting a fresh coffee refill from the office kitchen.

tl;dr; name is important, we'd rather discuss it than the actual features on offer, lest somebody else gets confused by it.

tl;dr my comment? You missed it: attitudes towards superficial stuff (like naming/accessibility/documentation) are used as proxies for important stuff (features, support, community) by people who don't have time to evaluate every possible product (busy engineers + management who can sign purchase orders).

If you're into stuff like this, you might like my project Bloaty McBloatface, which can dump size profiles of binaries:

https://github.com/google/bloaty

Is this in /google/ because of copyright reasons?

I don't know why you're getting downvoted, as far as I can tell, much of /google/ on github is 20% projects that google only owns because they were done on company time/machines.

More or less. It's copyright Google because I am a Google employee and it's related to my work. But it's fully open-source (Apache 2) and I'm the only one really developing it or deciding things about it.

I use https://en.wikipedia.org/wiki/Strings_%28Unix%29

I'm confused, grep has bianary options.

grep -U

The only thing the -U does is to not strip carriage returns embedded in the file.

But if you do, for example, grep NSA_KEY suspiciousfile.exe, you're either going to get:

(a) "Binary file suspiciousfile.exe matches" (which is what I get on the particular system I tried it on, and I'd call that semi-useful because I'd like to see some context around it)

or possibly,

(b) a 50,000-character gibberish output to your shell containing somewhere within it the string "NSA_KEY" if you can possibly scroll through it to see where it appeared.

I think strings, or this bingrep, or some other binary-aware strings-like tool is better.

Unless you use -o/--only-matching, that works fine for binaries!

this is just the front end to the (same author's) more interesting library: https://github.com/m4b/goblin

For indexing and searching into binary files, see also: https://github.com/ANSSI-FR/Binacle

I recommend:

- EDB debugger (like OllyDbg, qt based) https://github.com/eteran/edb-debugger

- HT editor (opensource clone of Hiew, curses based) http://hte.sourceforge.net/screenshots.html

Both provide this functionality as well.

While this does support multiple file formats, there already exists a far more robust utility for ELFs, "readelf" in the the GNU binutils: https://sourceware.org/binutils/docs/binutils/readelf.html