m4b / bingrep Goto Github PK

View Code? Open in Web Editor NEW

1.7K 37.0 66.0 1.03 MB

like ~~grep~~ UBER, but for binaries

License: MIT License

Rust 100.00%

grep binary objdump elf portable-executable mach-o

bingrep's Introduction

bingrep

Greps through binaries from various OSs and architectures, and colors them. Current backends:

ELF 32/64, arm, x86, openrisc - all others will parse and color, but relocations won't show properly
Mach 32/64, arm, x86
Unix and BSD archive printer
PE (debug only)

NOTE: Building requires rustc version 1.20 or greater. If you're using a distro's rust compiler, consider using https://rustup.rs to install your rustc compiler and associated binaries.

Install

bingrep is available through cargo, via cargo install bingrep, or you can build, and install the resulting binary wherever you like.

Build

Tested with stable rustc 1.38.0.

cargo build --release

Now copy the resulting binary in <path_to_bingrep>/target/release/bingrep wherever you like.

Run

Example:

bingrep /bin/ls

To dump internal debug representation of the parsed binary:

bingrep -d /bin/ls

To demangle symbols, use -D or --demangle:

bingrep -D /bin/ls

Meta Analysis (Experimental)

You can print a hextable (WIP) via --hex or an overview of file offset ranges via --ranges.

Searching

Search functionality is being added.

You can try it out using bingrep --search "string" or bingrep -s "string". Currently only works for ELF targets.

Please chime in on #13 for how this functionality will:

Be presented,
What API will be exposed
What usecases are most important (e.g., how do you like to search binaries)
How it will be implemented

FAQ

Why is this repo called bingrep, it's nothing like grep at all

That's a good question; I was using this as a personal development tool for some time, and I was conferring with someone from the internet about some binary stuff, when I decided I should just upload this to a proper repo instead of sending pictures. So I quickly created a repo, I felt like I had been greppin' through binaries, so that was the name I uploaded. Even worse, I named it bg as the produced executable at the time of the upload, and this of course immediately conflicted with the unix command bg. There's an issue for a better name, you can chime in too!

Why do you/should I use this instead of X ?

For some of my projects or workflows I need to very quickly see the load address, offset, or size of a symbol/program header/section header/export/import. I got tired of using objdump/nm/X because really, I just needed to colorize addresses, sizes etc., so I can quickly identify them and move on. So I wrote this, very quickly, and named it a bad name (sorry!). Then I went totally overboard and started coloring everything, everywhere. You love it, don't worry. Also you're free to use anything you want, whatever makes you happy and productive!

Is there anything to work on?

Yes, there are several open issues. I think I'd actually like to port the symbol map functionality (which enables printing every binary that exports a symbol) from https://github.com/m4b/rdr, as well as implement a "reverse symbol map", which finds every binary that calls/imports a symbol.

If you also like hacking on binary stuff, the backend this uses, https://github.com/m4b/goblin, is responsible for the actual loading, parsing, etc., and there are several open issues on that repo as well if you feel like contributing.

bingrep's People

Contributors

Stargazers

Watchers

bingrep's Issues

refactor closure colorizers into proper reusable functions

Functions were literally copy pasted out of ELF colorizer because I'm super lazy and I was too busy to refactor and type out properly.

This way PE backend can use them, and will enforce consistent colorizing scheme, e.g., addresses red, size green, strings yellow, libs blue, headers some color i forgot, etc.

bingrep is reported as a lib

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.

remove memrange

We should remove memrange coming in via metagoblin, since it pulls in rustc-serialize which has a vulnerability apparently; I haven't look at good alternatives, but posting this issue here so don't forget. it should be a fairly easy task, I think i used it originally only for a few functions

Outdated Cargo.lock file?

bingrep is currently failing to build for Homebrew with Rust 1.49 on Apple Silicon: Homebrew/homebrew-core#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: Homebrew/homebrew-core#68301

Potential bug with ELF binaries

In src/format_elf.rs:286, the condition expression shflags & flag == flag seems wrong:

                    let mut flags = String::new();
                    for flag in &section_header::SHF_FLAGS {
                        let flag = *flag;
/* HERE */              if shflags & flag == flag {
                            flags += &section_header::shf_to_str(flag).to_string().split_off(4);
                            flags += " ";
                        }
                    }
                    Cell::new(&flags).style_spec("lbW")

The condition always evaluates to true. This change was introduced by commit #34c38277abe8305a9070d9a05e9d8ddfe354521d.

@m4b, could you please double-check this code to fix it.

error[E0523]: found two different crates with name `std` that are not distinguished by differing `-C metadata`. This will result in symbol conflicts between the two.

Trying to build with cargo build --release I get:

   Compiling clap v2.24.2
   Compiling scroll_derive v0.4.0
error[E0523]: found two different crates with name `std` that are not distinguished by differing `-C metadata`. This will result in symbol conflicts between the two.
 --> /home/sander/.cargo/registry/src/github.com-1ecc6299db9ec823/scroll_derive-0.4.0/src/lib.rs:3:1
  |
3 | extern crate proc_macro;
  | ^^^^^^^^^^^^^^^^^^^^^^^^

error: Could not compile `scroll_derive`.
Build failed, waiting for other jobs to finish...
error: build failed
sander@Stream-13:~/git/bingrep$

Version of rustc:

sander@Stream-13:~$ rustc --version
rustc 1.16.0

This is on Ubuntu 17.04

Full log of CLI:

sander@Stream-13:~/git$ rm -rf bingrep/
sander@Stream-13:~/git$ rm -rf /home/sander/.cargo/

sander@Stream-13:~/git$ git clone https://github.com/m4b/bingrep.git
Cloning into 'bingrep'...
remote: Counting objects: 91, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 91 (delta 6), reused 15 (delta 5), pack-reused 73
Unpacking objects: 100% (91/91), done.
sander@Stream-13:~/git$ cd bingrep/

sander@Stream-13:~/git/bingrep$ cargo build --release
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading colored v1.5.1
 Downloading goblin v0.0.10
 Downloading structopt v0.0.3
 Downloading structopt-derive v0.0.3
 Downloading lazy_static v0.2.8
 Downloading plain v0.0.2
 Downloading scroll v0.5.0
 Downloading scroll_derive v0.4.0
 Downloading quote v0.3.15
 Downloading syn v0.11.11
 Downloading synom v0.11.3
 Downloading unicode-xid v0.0.4
 Downloading clap v2.24.2
 Downloading vec_map v0.8.0
 Downloading unicode-width v0.1.4
 Downloading strsim v0.6.0
 Downloading bitflags v0.8.2
 Downloading atty v0.2.2
 Downloading ansi_term v0.9.0
 Downloading unicode-segmentation v1.2.0
 Downloading term_size v0.3.0
 Downloading libc v0.2.23
   Compiling scroll v0.5.0
   Compiling unicode-xid v0.0.4
   Compiling unicode-segmentation v1.2.0
   Compiling ansi_term v0.9.0
   Compiling strsim v0.6.0
   Compiling unicode-width v0.1.4
   Compiling quote v0.3.15
   Compiling synom v0.11.3
   Compiling libc v0.2.23
   Compiling plain v0.0.2
   Compiling lazy_static v0.2.8
   Compiling colored v1.5.1
   Compiling atty v0.2.2
   Compiling syn v0.11.11
   Compiling bitflags v0.8.2
   Compiling vec_map v0.8.0
   Compiling term_size v0.3.0
   Compiling clap v2.24.2
   Compiling scroll_derive v0.4.0
error[E0523]: found two different crates with name `std` that are not distinguished by differing `-C metadata`. This will result in symbol conflicts between the two.
 --> /home/sander/.cargo/registry/src/github.com-1ecc6299db9ec823/scroll_derive-0.4.0/src/lib.rs:3:1
  |
3 | extern crate proc_macro;
  | ^^^^^^^^^^^^^^^^^^^^^^^^

error: Could not compile `scroll_derive`.
Build failed, waiting for other jobs to finish...
error: build failed
sander@Stream-13:~/git/bingrep$

pager issue

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:

This seems to happen for some binaries, e.g., there is no such a panic for /bin/ls on my machine.
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)

inconsistent results from ldd for library dependencies

I compiled the following source code on Linux with gcc.

// test.c
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
int main(void) {
    fd_set rfds;
    struct timeval tv;
    int retval;
    /* Watch stdin (fd 0) to see when it has input. */
    FD_ZERO(&rfds);
    FD_SET(0, &rfds);
    /* Wait up to five seconds. */
    tv.tv_sec = 5;
    tv.tv_usec = 0;
    retval = select(1, &rfds, NULL, NULL, &tv);
    /* Don’t rely on the value of tv now! */
    if (retval == -1)
        perror("select()");
    else if (retval)
        printf("Data is available now.\n");
        /* FD_ISSET(0, &rfds) will be true. */
    else
        printf("No data within five seconds.\n");
    return 0;
}

gcc test.c -fsanitize=address

ldd a.out gives

        linux-vdso.so.1 =>  (0x00007ffec89a5000)
        libasan.so.2 => /usr/lib/x86_64-linux-gnu/libasan.so.2 (0x00007fde56b6a000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fde567a0000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fde56583000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fde5637f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fde56076000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fde55e5f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fde57ad7000)

But bingrep tells only

...
Libraries(2):
    libasan.so.2
       libc.so.6
...

While I can understand libraries like linux-vdso.so.1 can be omitted, I think libpthread.so.0 should at least (only sure about libm.so.6 and others) exist in the dependence list.

mach: better load command info

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

How to correctly page bingrep output with color?

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?

Disassemble support

For example capstone could be used.

add search string

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.

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:

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.
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:

what their common usecase for "grepping" a binary is
how they'd like to see this information displayed
how they'd like to present the search to the program
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:

at what offset(s) the string occurred in the binary, if any
how this offset would be normalized into the virtual address space of the section/program header/whatever
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:

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

Crashes on rustc 1.67

bingrep segfaults on everything:

cargo run --release target/release/bingrep
    Finished release [optimized] target(s) in 0.02s
     Running `target/release/bingrep target/release/bingrep`
ELF DYN X86_64-little-endian @ 0x34bb0:

e_phoff: 0x40 e_shoff: 0x720d00 e_flags: 0x0 e_ehsize: 64 e_phentsize: 56 e_phnum: 14 e_shentsize: 64 e_shnum: 42 e_shstrndx: 41

ProgramHeaders(14):
Segmentation fault (core dumped)

It happens whether built from 8596f7f or if v0.10.2 is cargo installed. It crashes on itself, ls, and cat.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.10
Release:        22.10
Codename:       kinetic
$ rustc --version
rustc 1.69.0-nightly (c8e6a9e8b 2023-01-23)
$ cargo --version
cargo 1.69.0-nightly (985d561f0 2023-01-20)

Here is the debug debugging output:

$ RUST_BACKTRACE=1 cargo run -- target/debug/bingrep
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/bingrep target/debug/bingrep`
ELF DYN X86_64-little-endian @ 0x7b520:

e_phoff: 0x40 e_shoff: 0x3236158 e_flags: 0x0 e_ehsize: 64 e_phentsize: 56 e_phnum: 14 e_shentsize: 64 e_shnum: 44 e_shstrndx: 43

ProgramHeaders(14):
thread 'main' panicked at 'attempt to add with overflow', /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/iter/traits/accum.rs:149:1
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/panicking.rs:64:14
   2: core::panicking::panic
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/panicking.rs:114:5
   3: <usize as core::iter::traits::accum::Sum>::sum::{{closure}}
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/iter/traits/accum.rs:53:28
   4: core::iter::adapters::map::map_fold::{{closure}}
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/iter/adapters/map.rs:84:21
   5: core::iter::traits::iterator::Iterator::fold
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/iter/traits/iterator.rs:2438:21
   6: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/iter/adapters/map.rs:124:9
   7: <usize as core::iter::traits::accum::Sum>::sum
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/iter/traits/accum.rs:50:17
   8: core::iter::traits::iterator::Iterator::sum
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/iter/traits/iterator.rs:3408:9
   9: prettytable::row::Row::column_count
             at /home/home/.cargo/registry/src/github.com-1ecc6299db9ec823/prettytable-rs-0.9.0/src/row.rs:36:9
  10: prettytable::TableSlice::get_column_num
             at /home/home/.cargo/registry/src/github.com-1ecc6299db9ec823/prettytable-rs-0.9.0/src/lib.rs:75:21
  11: prettytable::TableSlice::get_all_column_width
             at /home/home/.cargo/registry/src/github.com-1ecc6299db9ec823/prettytable-rs-0.9.0/src/lib.rs:117:22
  12: prettytable::TableSlice::__print
             at /home/home/.cargo/registry/src/github.com-1ecc6299db9ec823/prettytable-rs-0.9.0/src/lib.rs:142:25
  13: prettytable::TableSlice::print_term
             at /home/home/.cargo/registry/src/github.com-1ecc6299db9ec823/prettytable-rs-0.9.0/src/lib.rs:174:9
  14: prettytable::Table::print_term
             at /home/home/.cargo/registry/src/github.com-1ecc6299db9ec823/prettytable-rs-0.9.0/src/lib.rs:362:9
  15: bingrep::format::print_table_to_stdout
             at ./src/format.rs:305:32
  16: bingrep::format::flush
             at ./src/format.rs:291:5
  17: bingrep::format_elf::Elf::print
             at ./src/format_elf.rs:512:9
  18: bingrep::parse_elf_file
             at ./src/main.rs:104:9
  19: bingrep::run
             at ./src/main.rs:205:29
  20: bingrep::main
             at ./src/main.rs:216:11
  21: core::ops::function::FnOnce::call_once
             at /rustc/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Here is the release debugging output:

$ gdb target/release/bingrep
GNU gdb (Ubuntu 12.1-3ubuntu2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from target/release/bingrep...
(gdb) r target/release/bingrep
Starting program: /home/home/CLionProjects/bingrep/target/release/bingrep target/release/bingrep

This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.ubuntu.com
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
ELF DYN X86_64-little-endian @ 0x34bb0:

e_phoff: 0x40 e_shoff: 0x720d00 e_flags: 0x0 e_ehsize: 64 e_phentsize: 56 e_phnum: 14 e_shentsize: 64 e_shnum: 42 e_shstrndx: 41

ProgramHeaders(14):

Program received signal SIGSEGV, Segmentation fault.
0x0000555555707670 in prettytable::TableSlice::get_all_column_width ()
(gdb) bt
#0  0x0000555555707670 in prettytable::TableSlice::get_all_column_width ()
#1  0x00005555555b59c1 in prettytable::Table::print_term ()
#2  0x00005555555d157b in bingrep::format::print_table_to_stdout ()
#3  0x00005555555bfda5 in bingrep::format_elf::Elf::print ()
#4  0x00005555555b1b77 in bingrep::parse_elf_file ()
#5  0x00005555555b3db7 in bingrep::main ()
#6  0x00005555555d57d3 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#7  0x00005555555b5139 in _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17hcc4805e891370521E.llvm.6285060230740621483 ()
#8  0x000055555572cabc in core::ops::function::impls::{impl#2}::call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> () at library/core/src/ops/function.rs:287
#9  std::panicking::try::do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> ()
    at library/std/src/panicking.rs:483
#10 std::panicking::try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> ()
    at library/std/src/panicking.rs:447
#11 std::panic::catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> ()
    at library/std/src/panic.rs:140
#12 std::rt::lang_start_internal::{closure#2} () at library/std/src/rt.rs:148
#13 std::panicking::try::do_call<std::rt::lang_start_internal::{closure_env#2}, isize> () at library/std/src/panicking.rs:483
#14 std::panicking::try<isize, std::rt::lang_start_internal::{closure_env#2}> () at library/std/src/panicking.rs:447
#15 std::panic::catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> () at library/std/src/panic.rs:140
#16 std::rt::lang_start_internal () at library/std/src/rt.rs:148
#17 0x00005555555b4a25 in main ()

crashes running on itself

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 41a73a8

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

Doesn't work on /bin/busybox

bingrep errors out on /bin/busybox with the following message:

$ cargo run --release /bin/busybox
    Finished release [optimized] target(s) in 0.02s
     Running `target/release/bingrep /bin/busybox`
Malformed entity: Section 63 size (4195032) + addr (1008) is out of bounds. Overflowed: false

Environment

Built at c3516e7.

readelf /bin/busybox works fine.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal

$ dpkg -S /bin/busybox
busybox-static: /bin/busybox

$ dpkg -s busybox-static
[...]
Version: 1:1.30.1-4ubuntu6.3
[...]

$ sha256sum /bin/busybox
6278d294297c0eb6224e4674da95a180d6c1805f17e640d0977f68553033bddb  /bin/busybox

Mach-O universal binary are always reported not a 64bit binary file

Mach-O universal binary are always reported is_64: false

[ 12/22 15:31:29 ] inndy @ Inndys-MBPR ~/repo/bingrep/target/release (master)
$ file /usr/lib/libc++.dylib
/usr/lib/libc++.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386]
/usr/lib/libc++.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/usr/lib/libc++.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
[ 12/22 15:32:20 ] inndy @ Inndys-MBPR ~/repo/bingrep/target/release (master)
$ ./bingrep /usr/lib/libc++.dylib | tail

Libraries(2):
/usr/lib/libc++abi.dylib
/usr/lib/libSystem.B.dylib

Name: /usr/lib/libc++.1.dylib
is_64: false
is_lib: true
little_endian: true
entry: 0

Copyright notice missing

Neat and useful project! But its licensing information is unclear, is this meant to be GPL? MIT? Apache?

It's up to you; it's your project. But if you want others to use or contribute this should be addressed.

Create git tag for releases

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.

Doesn't work on COFF object files

It gives Unknown magic: 0x68664. It works fine on PE executable files.

Bingrep also doesn't support ELF objects with many sections

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

(This is a follow up on m4b/faerie#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>

osx symbols are not demangled

E.g.:

__ZN4core5slice89_$LT$impl$u20$core..iter..traits..IntoIterator$u20$for$u20$$RF$$u27$a$u20$$u5b$T$u5d$$GT$9into_iter17h450e234d27262170E

core::slice::<impl core::iter::traits::IntoIterator for &'a [T]>::into_iter::h450e234d27262170

make program header printing more pretty

There's lots of room for improvement:

1 we could do some cool unicode block char tree printing for each phdr
2. color code the types better
3. remove the extra field names
4. add a header with the field names to remove redundant information
5. do better alignment with field columns
6. add second indented line (like objdump) with the flags and alignment, since its less important

PE/PE+ colorized backend

Should be easy; can copy paste some of the closure color functions until they're refactored into nicer functions.

As for exact display, can discuss, see what works best

Support demangling of rust symbols

_ZN4core3ptr13drop_in_place17h86fdc7b11166c663E is not nice to read. Could bingrep demangle it?

executable name sucks

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:

binocular
binlens
~~od (ObjDump)~~
ng (biNGrep)
ig (bInGrep)
bd (BinDump)
bing (BINGrep)
bgrep

Or also any other name :P

Linking memrange (via metagoblin) causes GPL license violation

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.

Publish on crates.io

In order for "cargo install bingrep" to work

memory allocation of 18446744073709551610 bytes failed[1]

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

Error on running command

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