A tool for analyzing x86-64 binaries.

Related tags

Miscellaneous reopt
Overview

reopt

Reopt is a general purpose decompilation and recompilation tool for repurposing application logic. It does this by analyzing machine code to recover a more flexible program representation -- specifically the LLVM assembly language. Once in this format, one can then apply optimization tools to optimize the LLVM, recompile the application into optimized or security hardened object code, and use Reopt to merge the recompiled code back into the original executable.

Reopt supports Linux x86_64 programs. We are working towards a full 1.0 release, but the current pre-release version supports the end-to-end recompilation toolchain.

Getting Reopt

Although Reopt can build on other POSIX systems such as OSX, we recommend building Reopt to run on Linux. Reopt currently only supports Elf binaries which are the default binary format for Linux. It does not support OSX Macho binaries, and so it is easier to find applications to try Reopt on when running Linux.

Gitpod

For most people, the easiest way to try out Reopt is to try it out on Gitpod. This requires an account on Gitpod, but gives you access to a VSCode IDE connected to a Linux container with Reopt pre-installed.

Github Releases

If you have Linux installed, you can download one of our recent releases from the Releases page. We build releases as static binaries on Centos 7, so they should work on a variety of distributions.

Docker

If you have Docker installed, you can install and run the Reopt pre-release Docker image by running:

docker pull galoisbinaryanalysis/reopt
docker run --rm -it galoisbinaryanalysis/reopt

Building from source

Building Reopt requires that one has installed the GHC Haskell compiler and supporting tooling. We currently build on GHC 8.10.4. An easy way to get GHC is to install ghcup, and run ghcup install ghc-8.10.4. We also maintain a Docker image that has GHC and other dependencies preinstalled for building Reopt.

Once GHC is installed, the following steps may be useful for building Reopt:

git clone https://github.com/GaloisInc/reopt.git

cd reopt
# Fix submodule URLs (can skip if you have a Github account)
sed -i 's/[email protected]:/https:\/\/github.com\//' .gitmodules
git submodule update --init
# Build Reopt
cabal install exe:reopt
# Build Reopt Explore
cabal install exe:reopt-explore

Reopt and Reopt Explore will be installed at $HOME/.cabal/bin/reopt $HOME/.cabal/bin/reopt-explore.

Reopt's verification condition generator (reopt-vcg) is included in the aforementioned Github release and Docker image, however the source is currently maintained in a separate repository with it's own build instructions and requirements.

Using Reopt

Once reopt is installed on a Linux system and included in your path, you can try running it on system utilities such as ls. To do an end-to-end recompilation, you can run reopt with the command.

$ reopt -o ls.exe $(which ls)

This execution will use the version of ls in your system path and produce an executable ls.exe in the current directory. When running reopt will print out messages as it discovers functions within the application and attempts to convert each discovered function into LLVM.

Inspecting intermediate state

During recompilation, Reopt has to do a complex series of analysis steps to lift the machine code into LLVM. Each of these analysis steps is incomplete and may fail either due to Reopt not recognizing features in the binary or an error in our prerelease version of Reopt. As such, do not be alarmed when Reopt fails to translate functions.

If you'd like to inspect Reopt's intermediate state, there are several command line flags to export intermediate results. We describe the main flags for exporting intermediate state below. Additional options can be viewed by running reopt --help.

  • Disassembly. reopt --disassemble <binary> provides a raw disassembler output view of the code in the binary. This is similiar to objdump's disassembly output.

  • Control flow graph construction. reopt --cfg <binary> displays the low level control flow graphs that Reopt has constructed for each discovered function within the binary. This is a low-level IR that maintains machine code's explicit stack and register references, but lifts the machine code instructions into a more architectural neutral register transfer language.

  • Function Recovery reopt --export-fns <path> <binary> writes the functions that Reopt has generated after performing stack and function argument analysis. This is a higher-level IR in which explicit references to the stack have been replaced with allocations, and functions take arguments.

  • LLVM Generation reopt --export-llvm <path> <binary> generates LLVM from the binary. This is essentially a version of function recovery rendered in LLVM's format. Providing the --annotations <ann_file> flag during LLVM generation will cause reopt to additionally emit JSON in <ann_file> describing verification conditions which (if valid) demonstrate functional equivalence between the generated LLVM and machine code. Running reopt-vcg <ann_file> will simulate the executation of the LLVM and machine code, block-by-block, leveraging an SMT solver (cvc4) to verify as many of the conditions as possible.

  • Object Files reopt --export-object <path> <binary> generates an object file from the LLVM generated in the previous state. This is essentially the same as generating the LLVM, and then running the LLVM compiler toolchain with the selected options.

Function arguments

One common reason Reopt fails is because it cannot figure out the arguments that a function can take. We have four mechanisms for obtaining function arguments: (1) User provided hints; (2) a small builtin database; (3) debug information; and (4) a demand analysis that looks at what registers are used to infer arguments. These mechanisms are listed in priority order, although we note that the builtin database is currently the only mechanism for supporting functions that take a variable number of arguments like printf.

If you'd like to provide hints to Reopt, the recommended way is write a C header file with the arguments, such as:

// decls.h


typedef long ssize_t;
typedef unsigned long size_t;

ssize_t read(int fd, void* buf, size_t count);
ssize_t write(int fd, const void* buf, size_t count);

You can then use this file to tell Reopt about the expected types for read and write via the --header flag, e.g.,

reopt -o ls.exe --header decls.h $(which ls)

Using OCCAM for additional optimizations

reopt can leverage the OCCAM whole-program partial evaluator for LLVM bitcode to further optimize binaries (assuming a user has already installed and made available both OCCAM and its accompanying interface slash).

This feature can be enabled by passing the --occam-config=FILE option to reopt, where FILE is the reopt/OCCAM manifest. The manifest should essentially a valid OCCAM manifest file (i.e., a file with JSON entries) with the following (optional) additional field:

  • slash_options: a list of command line option flags for OCCAM's slash tool,

and excluding the following fields (reopt will populate these appropriately):

  • binary
  • name

The main field should specify the desired name of the bitcode file that will be generated for OCCAM to process, and the OCCAM optimized result will share the name with an added .occam suffix.

N.B., when passing flags to customize OCCAM/slash behavior, be aware that reopt passes the -c and -emit-llvm flags via the ldflags manifest entry so OCCAM skips recompiling and acts only as an LLVM to LLVM translator.

Using Reopt Explore

With reopt-explore installed we can gather statistics regarding reopt's ability to recover functions in an individual or collection of binaries.

To examine a single binary, simply call reopt-explore with the a path to the binary:

$ reopt-explore $(which ls)
...
/usr/bin/ls
  Initialization:
    Code segment: 112,004 bytes
    Initial entry points: 234
    Warnings: 0
  Discovery:
    Bytes discovered: 59,502 (53%)
    Succeeded: 216 (92%)
    Failed: 18 (8%)
      Unhandled instruction: 1 (0%)
      Unidentified control flow: 17 (7%)
  Argument Analysis:
    Succeeded: 123 (57%)
    Failed: 93 (43%)
    Header Warnings: 0
    DWARF Warnings: 0
    Code Warnings: 112
  Invariant Inference:
    Succeeded: 92 (75%)
    Failed: 31 (25%)
      Indirect call target: 1 (1%)
      Unresolved call target arguments: 30 (24%)
  Recovery:
    Succeeded: 81 (88%)
    Failed: 11 (12%)
      Unsupported function value: 8 (9%)
      Unimplemented LLVM backend feature: 3 (3%)
  LLVM generation status: Succeeded.

To recursively search a directory for binaries and examine each, call reopt-explore with the path to the directory to search:

$ reopt-explore /usr/bin
...
reopt analyzed 394 binaries:
Generated LLVM bitcode for 394 out of 394 binaries.
Initialization:
  Code segment: 42,933,178 bytes
  Initial entry points: 79776
  Warnings: 0
Discovery:
  Bytes discovered: 23,025,164 (54%)
  Succeeded: 64,494 (81%)
  Failed: 15,500 (19%)
    Unhandled instruction: 425 (1%)
    Unidentified control flow: 15,075 (19%)
Argument Analysis:
  Succeeded: 40,429 (63%)
  Failed: 24,065 (37%)
  Header Warnings: 0
  DWARF Warnings: 0
  Code Warnings: 38,681
Invariant Inference:
  Succeeded: 30,221 (75%)
  Failed: 10,208 (25%)
    Symbolic call stack height: 1 (0%)
    Unresolved stack read: 13 (0%)
    Indirect call target: 526 (1%)
    Call target not function entry point: 41 (0%)
    Unresolved call target arguments: 9,614 (24%)
    Could not resolve varargs args: 13 (0%)
Recovery:
  Succeeded: 21,952 (73%)
  Failed: 8,269 (27%)
    Unsupported function value: 2,425 (8%)
    Unimplemented feature: 6 (0%)
    Unimplemented LLVM backend feature: 4,762 (16%)
    Stack offset escape: 83 (0%)
    Stack read overlapping offset: 1 (0%)
    Unresolved return value: 8 (0%)
    Missing variable value: 984 (3%)

Improving recovery with debug information

reopt and reopt-explore will try to determine if any debug information is available for dynamic dependencies by quiering gdb (if it is installed).

Users can also manually specify dependency and debug directories to search in manually for both reopt and reopt-explore via the folowing flags:

--lib-dir=PATH              Additional location to search for dynamic
                            dependencies.
--debug-dir=PATH            Additional location to search for dynamic
                            dependencies' debug info.
Issues
  • `git submodule update --init` gives

    `git submodule update --init` gives "fatal: Could not read from remote repository."

    Hi!

    Reopt looks like a really interesting project, and I'd love to get the chance to start using it and develop a further understanding of it's inner architecture and design.

    I recently tried to build reopt on one of my new laptops, and then noticed an issue that is not obvious for already configured development laptops.

    The way that the submodules (of dependencies) are currently setup in reopt requires you to use a Git SSH key, otherwise, you run into an error when running git submodule update --init.

    In particular, for all the submodules (e.g. llvm-pretty-bc-parser, macaw, etc), running git submodule update --init gives the error "fatal: Could not read from remote repository. Please make sure you have correct access rights"

    This is because all submodules are accessed using [email protected]:GaloisInc/foo.git instead of e.g. https://github.com/GaloisInc/foo.git.

    While a very small issue, it does make it more difficult to get started with the project as a new user. Thus, I wanted to let you know, as this issue is not likely to turn up in the development environment of existing developers.

    Cheers, Robin

    opened by mewmew 10
  • improved record constraint reasoning

    improved record constraint reasoning

    This adds some functionality and basic tests so constraints regarding record types can be sensibly combined.

    E.g., x <: {0 : τ1} and x <: {64 : τ2} can now essentially be unified into the constraint x <: {0 : τ1, 64 : τ2}.

    opened by pnwamk 6
  • Support transformations on intermediate LLVM code (.ll)

    Support transformations on intermediate LLVM code (.ll)

    Is there a possibility to make custom changes to the generated .ll code and continue with the producing final binary? Specifically, I'm interested in applying AFL instrumentation. I tried to compile/link produced .ll with clang and got linker errors. I looked at the source code and it seems like the original binary is used to merge .ll into the final binary (.ll alone cannot be used to produce the final binary). Could you please clarify how does this work or maybe point me to some documentation?

    opened by vfoltsgt 3
  • feat: reopt stats reporting/exporting

    feat: reopt stats reporting/exporting

    Adds the following recovery statistics flags to reopt:

         --print-stats               Print discovery/recovery statistics.
    
         --export-stats=PATH         Path at which to write discovery/recovery
                                     statistics.
    

    E.g., reopt --print-stats fib_test.1234 will run reopt through discovery/recovery and then emit a summary (i.e., starting with "reopt discovered ...") after completing:

    $ reopt --print-stats fib_test.1234
    ...
    reopt discovered 1086 functions:
      recovery succeeded: 287 (26.43%)
         recovery failed: 799 (73.57%)
        skipped PLT stub: 0 (0.00%)
    800 errors occured.
    

    whereas using the --export-stats=PATH flag will output the recovery statistics info a CSV file named PATH with a header in the first line and data entries on the remaining lines, e.g.:

    binary,fn name,address,recovery result
    fib_test.1234,,0x400270,FnFailedRecovery
    fib_test.1234,,0x400276,FnFailedRecovery
    fib_test.1234,_IO_default_seekpos,0x40dff0,FnFailedRecovery
    fib_test.1234,_IO_default_setbuf,0x40ded0,FnFailedRecovery
    fib_test.1234,_IO_default_showmanyc,0x40ed10,FnRecovered
    fib_test.1234,_IO_default_stat,0x40ece0,FnRecovered
    fib_test.1234,_IO_default_sync,0x40e350,FnRecovered
    ...
    

    The statistics are derived from the events passed to recoverX86Elf's logger (i.e., the first parameter), as can be seen in the recoverLogEvent function.

    opened by pnwamk 3
  • Error while building reopt

    Error while building reopt

    Build errors:

    In order, the following will be built (use -v for more details):
    parameterized-utils-1.0.8
    macaw-base-0.3.4
    macaw-x86-0.0.1
    reopt-0.1.0
    Preprocessing library parameterized-utils-1.0.8...
    [12 of 27] Compiling Data.Parameterized.NatRepr ( src/Data/Parameterized/NatRepr.hs, /home/sdasgup3/Github/reopt/dist-newstyle/build/parameterized-utils-1.0.8/build/Data/Parameterized/NatRepr.o )
    
    src/Data/Parameterized/NatRepr.hs:138:1: error:
        Failed to load interface for ‘GHC.TypeNats’
        Perhaps you meant
          GHC.TypeLits (from base-4.9.1.0)
          GHC.Types (from ghc-prim-0.5.0.0)
        Use -v to see a list of the files searched for.
    
    

    Tools versions are:

    $ ghc --version 
    The Glorious Glasgow Haskell Compilation System, version 8.0.2
    
    $ cabal --version 
    cabal-install version 1.24.0.1
    compiled using version 1.24.1.0 of the Cabal library
    
    opened by sdasgup3 3
  • reopt_test

    reopt_test

    I'm currently running into build failures with posix-waitpid on OSX. Is there any objection to making reopt_test optional? Specifically, changing "executable reopt_test" to "test-suite reopt_test"?

    opened by joehendrix 3
  • Bug: comparisons between pointers and the number zero

    Bug: comparisons between pointers and the number zero

    Example in date block block_0_402be0:

      %t1 = icmp eq i64 %t0, 0
    

    Example the other way around in column block block_0_402760:

    %t0 = icmp eq { i8, i8 }* %arg0, 0
    
    opened by Ptival 2
  • reopt: log block size

    reopt: log block size

    This adds block size to the CFGError datatype so that IDE frontends can decide to highlight the whole block.

    I'm a little spooked by the two unlabeled Int fields, if this datatype becomes any more populated it probably ought to have named fields.

    opened by Ptival 2
  • feat: dynamic dependency debug info search

    feat: dynamic dependency debug info search

    Now reopt and reopt-explore will attempt to find function types in the debug information of dynamic dependencies when analyzing a binary. If the dependency has previously been analyzed, the gleaned information will be cached in a REOPTHOME directory (getXdgDirectory XdgData ".reopt" by default or whatever path is specified by the REOPTHOMEenv var).

    reopt

    new reopt flags:

         --home                      Show location of the reopt home directory.
                                     Customizable via the REOPTHOME environment
                                     variable.
         --lib-dir=PATH              Additional location to search for dynamic
                                     dependencies.
         --debug-dir=PATH            Additional location to search for dynamic
                                     dependencies' debug info.
    

    N.B., in addition to any specified --lib-dir directories, reopt will check the following default unix locations for libraries:

    unixLibDirs = [ "/usr/local/lib"
                  , "/usr/local/lib64"
                  , "/usr/lib"
                  , "/usr/lib64"
                  , "/lib"
                  , "/lib64"]
    

    And in addition to any specified --debug-dir, reopt will query gdb to see where it looks for debug directories by executing the following:

    gdb --batch --eval-command="show debug-file-directory"
    

    reopt-explore

    reopt-explore also now has the flags to add directories to the paths searched for libs and debug libs, i.e.:

         --lib-dir=PATH              Additional location to search for dynamic
                                     dependencies.
         --debug-dir=PATH            Additional location to search for dynamic
                                     dependencies' debug info.
    

    and has a flag which switches the "exploration mode" to just looking for debug info (e.g., if there is a desire to pre-compute it on a machine before running reopt):

      -d --debug-info              Explore and export debug information for
                                   functions only.
    
    opened by pnwamk 2
  • RepMovs and RepStos data constructors not in scope

    RepMovs and RepStos data constructors not in scope

    Platform info:

    [email protected]:~/reopt$ ghc --version
    The Glorious Glasgow Haskell Compilation System, version 8.4.3
    [email protected]:~/reopt$ cabal --version
    cabal-install version 1.24.0.2
    compiled using version 1.24.2.0 of the Cabal library 
    [email protected]:~/reopt$ uname -a
    Linux ubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
    [email protected]:~/reopt$ cat /etc/lsb-release 
    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=18.04
    DISTRIB_CODENAME=bionic
    DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"
    

    Error:

    [ 7 of 18] Compiling Reopt.CFG.LLVM.X86 ( src/Reopt/CFG/LLVM/X86.hs, /home/pag/reopt/dist-newstyle/build/reopt-0.1.0/build/Reopt/CFG/LLVM/X86.o )
    
    src/Reopt/CFG/LLVM/X86.hs:224:5: error:
        Not in scope: data constructor ‘RepMovs’
        |
    224 |     RepMovs bytesPerCopy destExpr srcExpr cntExpr dirExpr -> do
        |     ^^^^^^^
    
    src/Reopt/CFG/LLVM/X86.hs:245:5: error:
        Not in scope: data constructor ‘RepStos’
        |
    245 |     RepStos bytesPerCopy destExpr srcExpr cntExpr dirExpr -> do
        |     ^^^^^^^
    
    opened by pgoodman 2
  • git submodule out of date - macaw-base and flexdis - top level commit missing?

    git submodule out of date - macaw-base and flexdis - top level commit missing?

    git submodules grabs macaw-base-0.0.1, but the cabal file requires macaw-base-0.0.2 I checked out master for all the submodules, more of the code builds, but LoadOptions in Data.Macaw.Memory.LoadCommon has changed field names, it's no longer loadStyle, but now loadStyleOverride.

    I suspect there's a commit missing from the top level repo.

    opened by shapr 2
  • Bump terser from 5.7.0 to 5.14.2 in /vscode-plugin

    Bump terser from 5.7.0 to 5.14.2 in /vscode-plugin

    Bumps terser from 5.7.0 to 5.14.2.

    Changelog

    Sourced from terser's changelog.

    v5.14.2

    • Security fix for RegExps that should not be evaluated (regexp DDOS)
    • Source maps improvements (#1211)
    • Performance improvements in long property access evaluation (#1213)

    v5.14.1

    • keep_numbers option added to TypeScript defs (#1208)
    • Fixed parsing of nested template strings (#1204)

    v5.14.0

    • Switched to @​jridgewell/source-map for sourcemap generation (#1190, #1181)
    • Fixed source maps with non-terminated segments (#1106)
    • Enabled typescript types to be imported from the package (#1194)
    • Extra DOM props have been added (#1191)
    • Delete the AST while generating code, as a means to save RAM

    v5.13.1

    • Removed self-assignments (varname=varname) (closes #1081)
    • Separated inlining code (for inlining things into references, or removing IIFEs)
    • Allow multiple identifiers with the same name in var destructuring (eg var { a, a } = x) (#1176)

    v5.13.0

    • All calls to eval() were removed (#1171, #1184)
    • source-map was updated to 0.8.0-beta.0 (#1164)
    • NavigatorUAData was added to domprops to avoid property mangling (#1166)

    v5.12.1

    • Fixed an issue with function definitions inside blocks (#1155)
    • Fixed parens of new in some situations (closes #1159)

    v5.12.0

    • TERSER_DEBUG_DIR environment variable
    • @​copyright comments are now preserved with the comments="some" option (#1153)

    v5.11.0

    • Unicode code point escapes (\u{abcde}) are not emitted inside RegExp literals anymore (#1147)
    • acorn is now a regular dependency

    v5.10.0

    • Massive optimization to max_line_len (#1109)
    • Basic support for import assertions
    • Marked ES2022 Object.hasOwn as a pure function
    • Fix delete optional?.property
    • New CI/CD pipeline with github actions (#1057)

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 0
  • Bug: types need to be quoted in CSV

    Bug: types need to be quoted in CSV

    We now generate types that contain commas, e.g. { i64, i64 }.

    In the absence of quoting, these confuse the CSV output into thinking there are more columns.

    opened by Ptival 0
  • Bug: not respecting function return type

    Bug: not respecting function return type

    e.g. in x86_64.ubuntu20.dnsmasq.clang.O0.nopie.nostrip/x86_64.ubuntu20.dnsmasq.clang.O0.nopie.nostrip.elf:

    The function is defined as:

    define i64 @cache_get_name({ <52 x i8>, i32, { }* }* %arg0) {
    

    Yet, in the final block we infer a pointer type for the return value:

    block_0_403d83:
      ; r22
      %t29 = phi { }* [ %t11, %block_0_403d3d ], [ %t25, %block_0_403d61 ], [ %t28, %block_0_403d72 ]
      ret { }* %t29
    

    These are incompatible.

    opened by Ptival 0
  • Bug: not reconciling pointer types with external function types nicely

    Bug: not reconciling pointer types with external function types nicely

    Example in x86_64.ubuntu20.anope.clang.O0.nopie.nostrip.elf:

    error: '@reopt__ZN9__gnu_cxx14__alloc_traitsISaINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEES6_E9constructIS6_EEvRS7_PS6_RKT__0_0x407630'
    defined with type 'void (i64, i64, i64)*' but expected 'void ({}*, i64, i64)*'
    

    The error seems to arise of the conflict between the declared type of this symbol:

    declare void
    @reopt__ZN9__gnu_cxx14__alloc_traitsISaINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEES6_E9constructIS6_EEvRS7_PS6_RKT__0_0x407630
    (i64, i64, i64)
    

    While we have inferred a pointer type for the value that will end up in first argument position.

    opened by Ptival 0
  • Bump minimist from 1.2.5 to 1.2.6 in /vscode-plugin

    Bump minimist from 1.2.5 to 1.2.6 in /vscode-plugin

    Bumps minimist from 1.2.5 to 1.2.6.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 0
Releases(release-2021-09-20)
Owner
Galois, Inc.
Galois, Inc.
A port of the Linux x86 IOLI crackme challenges to x86-64

This is a port of the original Linux x86 IOLI crackme binaries to x86-64. The original set of IOLI crackmes can be found here: https://github.com/Maij

Julian Daeumer 4 Mar 19, 2022
Powerful automated tool for reverse engineering Unity IL2CPP binaries

Powerful automated tool for reverse engineering Unity IL2CPP binaries

Katy 1.9k Aug 5, 2022
OS X command line tool to inject Frameworks and dylibs on mach-o binaries (iOS & Mac Apps).

macho-inject OS X command line tool to inject Frameworks and dylibs on mach-o binaries. It does the injection of the framework and the codesigning. It

Jon Gabilondo 5 Jul 29, 2022
A tool for detecting manual/direct syscalls in x86 and x64 processes using Nirvana Hooks.

manual-syscall-detect A tool for detecting manual/direct syscalls in x86 and x64 processes using Nirvana Hooks. Description A full write-up of this to

Conor Richard 66 Jul 24, 2022
Universal binaries for Linux.

FatELF The latest information about FatELF can be found at https://icculus.org/fatelf/ What is this? FatELF is a simple file format that allows you to

Ryan C. Gordon 32 May 22, 2022
Project is to port original Zmodem for Unix to CP/M and provide binaries and source code for platform specific modification as needed. Based on 1986 C source code by Chuck Forsberg

Zmodem-CP-M This repository is intended to foster a RetroBrewComputers community effort to port the original Zmodem source code for Unix to CP/M so ev

null 10 Apr 7, 2022
Project is to port original Zmodem for Unix to CP/M and provide binaries and source code for platform specific modification as needed. Based on 1986 C source code by Chuck Forsberg

Zmodem4CPM This repository is intended to foster a RetroBrewComputers community effort to port the original Zmodem source code for Unix to CP/M so eve

null 10 Apr 7, 2022
「👾」Some binaries for you to crack

「 ?? 」Crackme Hello visitor! I'll leave some binaries made by me for you to try to crack. I'm not experienced in this area but I'm taking the opportun

null 2 Apr 22, 2022
StochFuzz - Sound and Cost-effective Fuzzing of Stripped Binaries by Incremental and Stochastic Rewriting

StochFuzz: A New Solution for Binary-only Fuzzing StochFuzz is a (probabilistically) sound and cost-effective fuzzing technique for stripped binaries.

Zhuo Zhang 161 Aug 9, 2022
Invoke functions with a spoofed return address. For 32-bit Windows binaries

Invoke functions with a spoofed return address. For 32-bit Windows binaries. Supports __fastcall, __thiscall, __stdcall and __cdecl calling conventions. Written in C++17.

Daniel Krupiński 61 Aug 12, 2022
Automatically de-obfuscate ollvm and generate binaries

AntiOllvm Automatically deobfuscate binaries and generate new binaries. Chinese Help 中文帮助点击 帮助 Decriptor Software obfuscation protection is very commo

sanfengAndroid 69 Aug 13, 2022
Imphash-like calculation on Golang binaries

gimphash gimphash is a proposed method to calculate an imphash equivalent for Go binaries. It's name stands for Go-import-hash. Golang binaries contai

Nextron Systems GmbH 31 Jul 16, 2022
a small C library for x86 CPU detection and feature extraction

libcpuid libcpuid provides CPU identification for the x86 (and x86_64). For details about the programming API, you might want to take a look at the pr

Veselin Georgiev 333 Aug 11, 2022
x86 emulator on Raspberry Pi Pico

picox86 x86 emulator on Raspberry Pi Pico https://user-images.githubusercontent.com/10139098/110543817-13299080-812b-11eb-9c88-674cdae919fc.mp4 PCB fr

null 34 Apr 7, 2022
SerenityOS - Graphical Unix-like operating system for x86 computers. 🐞

SerenityOS is a love letter to '90s user interfaces with a custom Unix-like core. It flatters with sincerity by stealing beautiful ideas from various other systems.

SerenityOS 20.7k Aug 11, 2022
Programming language that compiles into a x86 ELF executable.

ocean Programming language that compiles into a x86 ELF executable. The main goal at the moment is to create a C compiler, which can atleast compile i

Richard 166 Jul 27, 2022
rdtsc x86 instruction to detect virtual machines

rdtsc_detector rdtsc x86 instruction to detect virtual machines What is rdtsc? The Time Stamp Counter (TSC) is a 64-bit register present on all x86 pr

null 4 Apr 29, 2022
A D++ Discord Bot template for Visual Studio 2019 (x64 and x86)

D++ Windows Bot Template A D++ Discord Bot template for Visual Studio 2019 (x64 and x86, release and debug). The result of this tutorial. This templat

brainbox.cc 19 Jul 16, 2022