When using pager like less or more, bingrep works. However sometimes when it quits, it will panic. Here is a result when using bingrep with rustc with pager more.

Observations:

1. This seems to happen for some binaries, e.g., there is no such a panic for /bin/ls on my machine.
2. Other pager, e.g., view (from nvim) works fine when used like bingrep /path/to/target | view - however will hang forever when using wrongly, e.g., bingrep /path/to/target | view.

~ > RUST_BACKTRACE=1 bingrep ~/.cargo/bin/rustc  | more
thread 'main' panicked at 'Cannot print table to standard output : Broken pipe (os error 32)', /home/hongxu/.cargo/registry/src/github.com-1ecc6299db9ec823/prettytable-rs-0.6.7/src/lib.rs:188:12
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
             at /checkout/src/libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: prettytable::TableSlice::print_tty
   8: bingrep::format_elf::Elf::print::{{closure}}
   9: bingrep::format_elf::Elf::print
  10: bingrep::run
  11: bingrep::main
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:101
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/rt.rs:58
  14: __libc_start_main
  15: _start
~ > file ~/.cargo/bin/rustc
/home/hongxu/.cargo/bin/rustc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.9, not stripped
~ > /home/hongxu/.cargo/bin/rustc --version                                                                                                                                                               
rustc 1.24.0-nightly (2d4df9584 2017-12-10)

rustc 1.30.0-nightly (73c78734b 2018-08-05)
binary: rustc
commit-hash: 73c78734bae8f2947a4bfdeabebeeb84ccf0b0e1
commit-date: 2018-08-05
host: x86_64-unknown-linux-gnu
release: 1.30.0-nightly
LLVM version: 7.0

repo is at 41a73a85920aa0c37846c6d7e5c391c292de1731

cargo build
RUST_BACKTRACE=1 ./target/debug/bingrep target/debug/bingrep

crashes:

[...]
                                                                     0x0                                0x0
            781870    GLOBAL     FUNC        _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..LowerHex$u20$for$u20$i8$GT$3fmt17h4c27396496188f2dE
                                                                     0x91       .text(16)               0x0
            781910    GLOBAL     FUNC        _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..UpperHex$u20$for$u20$i8$GT$3fmt17h62566deaeb3faf4cE
                                                                     0x91       .text(16)               0x0
            7819b0    GLOBAL     FUNC        _ZN4core3fmt3num53_$LT$impl$u20$core..fmt..LowerHex$u20$for$u20$i16$GT$3fmt17hf381e43bda4c6951E
                                                                     0x92       .text(16)               0x0
            781a50    GLOBAL     FUNC        _ZN4core3fmt3num53_$LT$impl$u20$core..fmt..UpperHex$u20$for$u20$i16$GT$3fmt17h93eac570e2e7c86eE
                                                                     0x92       .text(16)               0x0
            785bc0    GLOBAL     FUNC        _ZN4core3fmt9Formatter12pad_integral17h0a1e2b34e19c7ddcE
                                                                     0x3d7      .text(16)               0x0
            782cc0    GLOBAL     FUNC        _ZN49_$LT$i8$u20$as$u20$core..slice..SliceContains$GT$14slice_contains17h417b7695ed3578c1E
                                                                     0x12       .text(16)               0x0
             853b0    GLOBAL     OBJECT      _ZN4core3str15UTF8_CHAR_WIDTH17h727782c8fa92515fE
                                                                     0x100      .rodata(5)              0x0
            785290    GLOBAL     FUNC        _ZN4core3num21_$LT$impl$u20$u64$GT$25checked_next_power_of_two17h9ebcca98f19e8d85E
                                                                     0x29       .text(16)               0x0
            787d30    GLOBAL     FUNC        _ZN82_$LT$core..fmt..builders..PadAdapter$LT$$u27$a$GT$$u20$as$u20$core..fmt..Write$GT$9write_str17h2ae040e1ef527b3cE
                                                                     0x24e      .text(16)               0x0
            7884f0    GLOBAL     FUNC        _ZN4core3fmt8builders8DebugSet5entry17h69411f4b5bb034afE
                                                                     0xe        .text(16)               0x0
            7897e0    GLOBAL     FUNC        _ZN62_$LT$core..num..bignum..Big32x40$u20$as$u20$core..cmp..Ord$GT$3cmp17hfee4d6134a187f3dE
                                                                     0x55       .text(16)               0x0
                 0    GLOBAL     FUNC        __register_atfork
                                                                     0x0                                0x0
                 0    GLOBAL     FUNC        __cxa_atexit
                                                                     0x0                                0x0
                 0    GLOBAL     FUNC        __xstat64
                                                                     0x0                                0x0
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: BadOffset(131072)', libcore/result.rs:983:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:475
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:782
  10: bingrep::format_elf::Elf::print::{{closure}}
             at /home/matthias/.cargo/registry/src/github.com-1ecc6299db9ec823/goblin-0.0.14/src/strtab.rs:99
             at src/format_elf.rs:284
  11: bingrep::format_elf::Elf::print
             at src/format_elf.rs:300
  12: bingrep::run
             at src/main.rs:103
  13: bingrep::main
             at src/main.rs:166
  14: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  15: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  16: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  17: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  18: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  19: main
  20: __libc_start_main
  21: _start

Hi,

I see below error. Didnt find any solution useful on google to resolve this..

ajith@ashetty:~/Desktop/bingrep-master$ cargo build --release --verbose Updating registry https://github.com/rust-lang/crates.io-index Updating git repository https://github.com/m4b/goblin failed to parse registry's information for: colored

Caused by: the given version requirement is invalid

I'd like to package this tool in Homebrew. However, like many other package managers, a tag release is required. As such, the source code for each versions can be downloaded through some url.

I noticed there are version bumps in Cargo.toml, so all you need to do is to create git tag (or even better creating Github Release).

Thanks.

Running bingrep on bingrep, says that it is a lib:

is_lib: true

While unrelated to this issue, I would also like to note that Soname prints Some("lib") when it is a lib. Maybe it would be better to match on that value and present the name of the lib directly.

Thanks for this awesome tool!

I ran into a panic when trying bingrep against /bin/ls and the problem was that it was trying to represent the .bss section as a range in the binary, but as you know that section takes no space in the binary.

HI ! I found a memory allocation of 18446744073709551610 bytes failed in the current master e232665 POC : poc.zip

$ ./bingrep out/default/crashes/poc 
ELF EXEC EM_UNKNOWN-little-endian @ 0x8049080:

e_phoff: 0x80 e_shoff: 0xc e_flags: 0x10000 e_ehsize: 0 e_phentsize: 3 e_phnum: 0 e_shentsize: 36992 e_shnum: 2 e_shstrndx: 0

ProgramHeaders(0):
  

SectionHeaders(2):
memory allocation of 18446744073709551610 bytes failed[1]    552937 abort      ./bingrep out/default/crashes/poc

bingrep is currently failing to build for Homebrew with Rust 1.49 on Apple Silicon: https://github.com/Homebrew/homebrew-core/pull/68089

It appears this is due to a stale lock file, causing cargo install --locked to pull in dependencies that do not work for bingrep on Apple Silicon. Is it possible for the Cargo.lock file to be updated? If this could be done with a new release, that would be especially helpful.

Related: https://github.com/Homebrew/homebrew-core/issues/68301

I just recently discovered bingrep and think it's quite cool. But, in my haste, I decided to try and bingrep ~/.cargo/bin/rg and found it spit out 35000 lines of very nice colorful output. So then tried bingrep ~/.cargo/bin/rg | less and...aww, no color.

But bingrep -h tells me about the --color option and, yay, color...but also a lot of ^O characters everywhere.

So, I'm just wondering: is there a way to page bingrep output and make it look like the non-paged output?

Disclaimer: IANAL. I'm trying my best to be correct but I may be wrong.

FWICS this package depends on metagoblin and theban_interval_tree, both of which in turn depend on memrange. Since memrange is GPL-3, it effectively requires any derivative work to be licensed GPL-3 as well. theban_interval_tree seems to try to do that. However, both metagoblin and bingrep specify only the MIT license.

if you wish to continue depending on memrange, I believe you need to redistribute both packages as GPL-3. I think you can still license the source files specific to those packages under the MIT license but the combined work must be licensed GPL-3.

bingrep 0.6.2 doesn't handle ELF files with many sections.

(This is a follow up on https://github.com/m4b/faerie/issues/76)

To reproduce:

$ cat hugefileplease.py 
for i in range(0x10000):
	print("void func" + str(i) + "(void){}")
print("int main() {}")
$ python3 hugefileplease.py >huge.c
$ clang -c -ffunction-sections -o hostHuge2.o huge.c
$ bingrep hostHuge2.o 
ELF REL X86_64-little-endian @ 0x0:

e_phoff: 0x0 e_shoff: 0x8bd640 e_flags: 0x0 e_ehsize: 64 e_phentsize: 0 e_phnum: 0 e_shentsize: 64 e_shnum: 0 e_shstrndx: 1

ProgramHeaders(0):
  

SectionHeaders(0):
  

Syms(0):
Dyn Syms(0):
Dynamic Relas(0):

Dynamic Rel(0):

Plt Relocations(0):

Shdr Relocations(0):

Dynamic: None


Libraries(0):

Soname: None
Interpreter: None
is_64: true
is_lib: false
little_endian: true
entry: 0

Readelf correctly handles the extra sections:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          9164352 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         0 (65546)
  Section header string table index: 1 <corrupt: out of range>

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       000000000001000a  0000000000000000           0     0     0
  [ 1] .strtab           STRTAB           0000000000000000  007c0140
       00000000000fd4fa  0000000000000000           0     0     1
  [ 2] .text             PROGBITS         0000000000000000  00000040
<snip>

Load commands could use some love when it comes to printing their content.

Should be very straighforward, e.g. this is output currently:

   0 LC_SEGMENT_64
   1 LC_SEGMENT_64
   2 LC_SEGMENT_64
   3 LC_ID_DYLIB
   4 LC_DYLD_INFO_ONLY
   5 LC_SYMTAB
   6 LC_DYSYMTAB
   7 LC_UUID
   8 LC_VERSION_MIN_MACOSX
   9 LC_SOURCE_VERSION
  10 LC_SEGMENT_SPLIT_INFO
  11 LC_LOAD_DYLIB
  12 LC_LOAD_DYLIB
  13 LC_LOAD_DYLIB
  14 LC_LOAD_DYLIB
  15 LC_LOAD_DYLIB
  16 LC_LOAD_DYLIB
  17 LC_LOAD_DYLIB
  18 LC_LOAD_UPWARD_DYLIB
  19 LC_LOAD_UPWARD_DYLIB
  20 LC_LOAD_UPWARD_DYLIB
  21 LC_LOAD_UPWARD_DYLIB
  22 LC_LOAD_UPWARD_DYLIB
  23 LC_LOAD_UPWARD_DYLIB
  24 LC_LOAD_UPWARD_DYLIB
  25 LC_LOAD_UPWARD_DYLIB
  26 LC_SUB_FRAMEWORK
  27 LC_FUNCTION_STARTS
  28 LC_DATA_IN_CODE
  29 LC_DYLIB_CODE_SIGN_DRS
  30 LC_CODE_SIGNATURE

Would be nice to either summarize the important data in the load command (the version, the uuid, etc.) or just fully print the values of each (more noisy).

I'll pretty much merge anything that does this in a reasonable manner

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 <binary> -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

re #1:

I'd like to do:

bingrep "function_name" <some binary>

which will return any matches for the function in the various "sections" of the binary, e.g., in the dynamic symbol table, the strippable symbol table, the string table, etc.

Current Candidate(s)

• bingrep (no rename)
• binocular
• bing

bg cannot be used without path prefix because of bg for job backgrounding in bash/posix.

so we need to choose a better one. i'm thinking two letters (lets jump on the grep shortname bandwagon renaissance we're in the middle of).

Some candidates:

0. binocular
1. binlens
2. ~~od (ObjDump)~~
3. ng (biNGrep)
4. ig (bInGrep)
5. bd (BinDump)
6. bing (BINGrep)
7. bgrep

Or also any other name :P