survey: binary search string results + api + usecases

# Prolegomena

Hullo!

So I've begun adding search functionality, and I already find it very useful. In particular, this is a usecase I find myself having:

1. I want to search a binary for a string; this string could be a symbol I'm looking for, or an actual string in the binary, or it could be an import, or it could be referenced by a relocation.
2. I want the search results to display these matches in a semantically meaningful manner

There are a number of issues at hand here. It's in the beginning stages, so I'd like to ask for everyone (anyone's) input about:

1. what their common usecase for "grepping" a binary is
2. _how_ they'd like to see this information displayed
3. _how_ they'd like to present the search to the program
4. _what_ they'd expect to be output

Again, there's a lot going on here, so I'll open up with a particular example which addresses the uses I usually have, but I'd really like to know what other people want!

## Grepping for a static string

I'm debugging/analyzing a binary. I want to see if "hello world" is somewhere in the binary. So I run:

```
bingrep merp -s "hello"
```

I want to know a few things:

1. at what _offset_(s) the string occurred in the binary, if any
2. how this offset would be normalized into the virtual address space of the section/program header/whatever
3. where, semantically, could we interpret this offset and/or vm address w.r.t. what we know about the binaries sections/segments/etc?

It might look something like this:

```
Matches for "hello":
0x724
├──PT_LOAD(2) ∈ 0x724
├──.rodata(16) ∈ 0x724
Idx Name Type Flags Offset Addr Size Link Entsize Align
16 .rodata SHT_PROGBITS ALLOC 0x720 0x720 0x12 0x0 0x4
0x1707
├──.strtab(28) ∈ 0x9f
Idx Name Type Flags Offset Addr Size Link Entsize Align
28 .strtab SHT_STRTAB 0x1668 0x0 0x20a 0x0 0x1
```

Which is trying to say that hello was found at offset 0x724 in the binary; it is normalized to 0x724 in the PT_LOAD program header (for elf); to the .rodata section in the section headers, and here is that section header.

Similarly, it was also found in a strtab section header, which normalized is to the offset of `0x9f` starting from `0x1668`

## Grepping for a symbol

Similarly, suppose we're looking simply for whether `puts` is called by our binary, and if so, what are the details of the symbol, and if possible, where is it called.

Perhaps using the same api, we search for:

```
bingrep binary -s puts
```

and this returns to us a couple of hits, which are semantically quite different:

```
Dyn Syms(8):
Addr Bind Type Symbol Size Section Other
0 GLOBAL FUNC puts 0x0 0x0
Plt Relocations:
201018 X86_64_JUMP_SLOT puts
```

## Goal

What i'd like in both of these cases, if possible, is a unified api for querying the contents of a binary for a search string, and _very importantly_:

1. an efficient, terse, but understable _presentation_ of this information

I don't want it to be busy; I want with similar color coding techniques to highlight the information I need; and I want the output to be semantically relevant, e.g., the search string is used against symbol names in the symbol table, etc.

Ideally, this is presented finally to the user as some kind of tabular structure, or a summary of a group of tabular structures, each tailored to the semantic content the string matched against, perhaps in different categories, like:

```
raw string:
- [ offset, vmaddr, phdr ]
- [ offset, vmaddr, shdr ]

symbol:
- dynamic entry
- symtab entry
- debugging entry
- locations
```

etc., for any various number of different kinds of matches, and categories.

## Implementation Details

I'm not a big text search aficionado, so if anyone wants to help with the actual search string api, e.g., regexes, case insensitive, etc., as well as efficiency concerns, that would be great - i'm all ears - or in the case of PRs, very grateful!

## Conclusion

If you have a usecase, or an idea of how to present this information usefully, I'm interested in your feedback.

The master branch right now contains a very, very prototypical implementation invoked via:

```
bingrep -s "your string"
```

it is case sensitive, but also accidentally works with prefixes.

It currently dumps the regular print, then scans the binary, and pushes all matches, then normalizes the string against the program and section headers. I've started experimented with other "semantic" output, and there's definitely a lot of potential, hence this issue :)

Output is like:

```
Matches for "hello":
0x724
├──PT_LOAD(2) ∈ 0x724
├──.rodata(16) ∈ 0x724
0x1707
├──.strtab(28) ∈ 0x9f
```

Start with the existing `bingrep -s "your string"` prototype on the master branch and review its current search and normalization output. The issue needs maintainer and user agreement on supported search cases, semantic result categories, presentation, and API before completion can be defined.

Written by the indexing model from the issue text.