radareorg / radeco Goto Github PK

radare2-based decompiler and symbol executor

Rust 99.32% Shell 0.09% C 0.52% Assembly 0.01% Makefile 0.07%

radeco's Introduction

Radeco

A radare2 based binary analysis framework consisting from the Radeco client, in ./radeco/ directory, ./radeco-lib/ - library where whole high-level logic is located, ./arch-rs/ to abstract the architectures intricacies, ./esil-rs/ to parse the radare2 ESIL, and ./rune/ to perform symbolic execution on top of ESIL. Radeco uses its own intermediate representation, which also has a text representation - RadecoIL.

Is this ready yet?

Nope. There is still a ton of work to do before this can be considered ready. That said, parts of the library are already stable enough to write your own analysis passes and use in your projects.

Usage

Build like a regular rust project, using cargo:

cargo build

To include in your rust project, add to Cargo.toml:

[dependencies.radeco-lib]
git = "https://github.com/radare/radeco"

See examples for usage.

Trace Log

To debug, you may want to enable trace output from various parts of radeco. Build with trace_log feature to enable this:

cargo build --features 'trace_log'

Profiling

Requires gperftools . Check the cpuprofiler repository for more details.

To enable profiling, build with profile feature:

cargo build --features 'profiler'

Wrap the code you want to profile with:

use cpuprofiler::PROFILER;

PROFILER.lock().unwrap().start("./my-prof.profile").unwrap();
// Code you want to sample goes here!
PROFILER.lock().unwrap().stop().unwrap();

Radeco-lib project layout

src/
├── analysis/               Analyzers on SSA form Radeco-IR
├── backend/                Analyzers on C-pseudo code
│   ├── ctrl_flow_struct/   Implementation of `No More Gotos`
│   └── lang_c/             Coverter of C-pseudo code from RadecoFunction
├── frontend/               Loaders of RadecoFunction, RadecoProject
├── middle/                 Constructer, writer, parser of Radeco-IR
│   ├── regfile/            Profile of registers
│   └── ssa/                SSA form of Radeco-IR
└── utils/                  Logger, etc

License

Licensed under The BSD 3-Clause License. Please check COPYING file for complete license.

radeco's People

Contributors

Stargazers

Watchers

radeco's Issues

Improve Graphs

The current CFG and SSA graphs that radeco produces are POC and quite unreadable. Since these form the base of the entire decompilation process and are our main sources of debugging, it would be a good idea to invest some time in improving these outputs.

Colorize CFG produced.
Better layout for the SSA Graph to make the blocks look like they are actually a part of the CFG
Better layout of nodes within each Basic Block and colorize the nodes (and edges) based on their types.

This issue is easy but super important. I'm reserving this issue for new contributors to work on as this is a good way to get familiar with the codebase. Ping me (sushant94 on #radare) for help.

SSA instructions

Several issues here:

file names should be ., in dce.dot, ssa.txt, ...
let assignments at address zero ? this produces an ugly graph
numbers bigger than X should be in hexadecimal for redability: call 4294971244[:64]

sh-3.2$ cat a.out.insts
0x00000000: let  = 8
0x100000F30:    tmp_2[:64] = rsp[:64] - 8[:64]
0x100000F30:    rsp[:64] = tmp_2[:64]
0x100000F30:    tmp_3[:64] = load(rsp[:64])
0x100000F31:    rbp[:64] = rsp[:64]
0x00000000: let  = 32
0x100000F34:    tmp_5[:64] = rsp[:64] - 32[:64]
0x100000F34:    rsp[:64] = tmp_5[:64]
0x00000000: let  = 1
0x00000000: let  = 0
0x00000000: let  = 63
0x100000F34:    tmp_9[:64] = 63[:64] & 0[:64]
0x00000000: let  = 2
0x100000F34:    tmp_b[:64] = 2[:64] << tmp_9[:64]
0x100000F34:    tmp_c[:64] = tmp_b[:64] - 1[:64]
0x100000F34:    tmp_d[:64] = tmp_c[:64] & esilcur
0x100000F34:    tmp_e[:64] = esilold & tmp_c[:64]
0x100000F34:    tmp_f[:1] = tmp_e[:64] < tmp_d[:64]
0x100000F34:    cf[:1] = tmp_f[:1]
0x100000F34:    tmp_10[:1] = esilcur == 0[:64]
...
0x100000F5C:    rsp[:64] = tmp_62[:64]
0x100000F5C:    tmp_63[:64] = load(rsp[:64])
0x00000000: let  = 4294971244
0x100000F5C:    call 4294971244[:64]
0x00000000: let  = 20
0x100000F61:    tmp_66[:64] = rbp[:64] - 20[:64]
0x100000F61:    tmp_67[:64] = load(tmp_66[:64])
0x100000F61:    tmp_68[:32] = narrow(tmp_67[:64], 32)

Add LICENSE

I have removed the license commits for two reasons.

it was not discussed, accepted by at least me. Why BSD?
The commit was merged from the web user interface which poluted the commit history with two commits

Fuzzing

Using https://github.com/frewsxcv/afl.rs

Complete output in a single file for `minidec`

Building error: src/structs.rs:200:37: 200:38 error: mismatched types

Compiling radeco-lib v0.1.0 (https://github.com/radare/radeco-lib#3becd4ac)
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29:2: 29:63 warning: the trait core::marker::Sized is not
implemented for the type Self [E0277]
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29 fn verify_block(&self, i: &Self::ActionRef) ->
VResult;

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29:2: 29:63 help: run rustc --explain E0277 to see a detailed
explanation
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29:2: 29:63 note: Self does not have a constant size known at
compile-time
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29:2: 29:63 note: this warning results from recent bug fixes and
clarifications; it will become a HARD ERROR in the next release. See RFC 1214 for details.
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29 fn verify_block(&self, i: &Self::ActionRef) ->
VResult;

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29:2: 29:63 help: run rustc --explain E0277 to see a detailed
explanation
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29:2: 29:63 note: Self cannot be formatted using :?; if it is
defined in your crate, add #[derive(Debug)] or manually implement it
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29:2: 29:63 note: this warning results from recent bug fixes and
clarifications; it will become a HARD ERROR in the next release. See RFC 1214 for details.
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:29 fn verify_block(&self, i: &Self::ActionRef) ->
VResult;

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 help: run rustc --explain E0277 to see a detailed
explanation
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 note: Self does not have a constant size known at
compile-time
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 note: this warning results from recent bug fixes and
clarifications; it will become a HARD ERROR in the next release. See RFC 1214 for details.
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30 fn verify_expr(&self, i: &Self::ValueRef) ->
VResult;

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 note: required by middle::ssa::error::SSAErr
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 warning: the trait core::fmt::Debug is not
implemented for the type Self [E0277]
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30 fn verify_expr(&self, i: &Self::ValueRef) ->
VResult;

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 help: run rustc --explain E0277 to see a detailed
explanation
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 note: Self cannot be formatted using :?; if it is
defined in your crate, add #[derive(Debug)] or manually implement it
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 note: this warning results from recent bug fixes and
clarifications; it will become a HARD ERROR in the next release. See RFC 1214 for details.
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30 fn verify_expr(&self, i: &Self::ValueRef) ->
VResult;

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/xvilka/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/middle/ssa/verifier.rs:30:2: 30:61 note: required by middle::ssa::error::SSAErr
Compiling radeco v0.1.0 (file:///home/xvilka/radare/radeco)
src/args.rs:213:22: 213:50 warning: unnecessary parentheses around for head expression, #[warn(unused_parens)] on by default
src/args.rs:213 for i in (0..(pipe.len() - 1) as u16) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/structs.rs:200:37: 200:38 error: mismatched types:
expected core::option::Option<radeco_lib::frontend::structs::LRegInfo>,
found core::option::Option<r2pipe::structs::LRegInfo>
(expected struct radeco_lib::frontend::structs::LRegInfo,
found struct r2pipe::structs::LRegInfo) [E0308]
src/structs.rs:200 runner.state.reg_info = r;
^
src/structs.rs:200:37: 200:38 help: run rustc --explain E0308 to see a detailed explanation
error: aborting due to previous error
Could not compile radeco.

TODO in visual mode — unsupported arch?

Hello,

I'm trying to use radeco (minidec) on xtensa elf binary (baremetal). After piping IR to minidec, most decompiled functions are empty (even when dead code elimination passes are disabled) and a few only contain CALL statements. Disassembly is visual mode is full of TODOs. Does this mean that this architecture is not supported by radeco or is this a problem with radare2 xtensa backend?

Memory SSA

Reimplementation of some analysis in Rust

Part of the task requires understand, learning and writing Rust, and therefor this opens the door for reimplementing some core features and allow to verify them in another ways. This issue aims to track the development of adhoc technologies that can be redone in Rust in order to benefit from the language capabilities.

Implement r2pipe.rs (to use rust from inside or outside r2)
Implement a3f in rust? (libr/core/p/core_a2f.c) - analysis engine written in rust based on evil
Implement ESIL parser and emulator
Bindings for r2 APIs - valabind --rust

Add support for unimplemented esil instructions

Currently the following still need to be implemented:

unreachable code error

It would be good to have some better feedback from the tool in order to understand the reason of this situation. i guess this is a bug in esil, but we dont know the address of that instruction or which function was trying to analyze, etc. (this happens with osx's /bin/ls) but probably with other binaries

$ target/debug/radeco /bin/ls
thread '<main>' panicked at 'internal error: entered unreachable code', /Users/pancake/.cargo/git/checkouts/radeco-lib-99c1e75dd493d005/master/src/frontend/esilssa.rs:100

`radeco` utility request/specification

From @XVilka on July 4, 2015 19:50

Radeco

The radare decompiler tool, (namedly 'radeco') should be able to run from r2 or from the shell, accepting different inputs and dumping different outputs.

we can make radeco r2pipe friendly and interact with r2 using the pipes. this piece is already done, but not used at all. so i would suggest making the 'radeco' executable that allows to run like this:

$ radeco -h
Usage: radeco [-flags] [...]
-h           show this help
-o [type]    specify output type (ssa, )
-i [type]    specify input type
-r [r2pipe]  specify how to connect to r2
-O           output all intermediate representations to files (.asm .esil .ssa. ...)
Types: (listedn bottom-top)
 - asm   : assembly/hexpairs
 - esil
 - ssa
 - dot
 - ... magic ...
 - C code

The -r flag can be used to tell the r2pipe connection how to talk to r2 using http, pipes, etc. in order to retrieve all the type information, function signatures, function names, symbols, imports, variable names, etc. By default, if no -r is specified it should check the environment variable R2PIPE_IN and R2PIPE_OUT and connect using pipe in that case.

We should be able to run this tool from commandline or inside r2 like this:

$ radeco -i asm -o ssa disasm.txt > disasm-ssa.txt

And from inside the r2 shell:

> #!pipe radeco -o c   # decompile current function

As long as we have a chain of transformations we should define that pipeline in code and be able to serialize that info from memory data structures to something human readable. This will be good for the testsuite and for debugging issues on every internal decompilation step.

Bear in mind that radeco will get info from r2... but it will also export info to r2. this is. radeco is able to identify basic blocks, local variables, loops, etc.

-> we shold focus on having this tool done asap, it will help to understand the whole problem better, and everyone should be able to test it and use it from r2. The tool can be then rewritten as an RCore command, but this is out of the scope of the current problem, because decompilation needs to happen first.

The next step would be to write a PseudoWriter module that takes the graph and prints C-like code, the graph representation must contain all the information needed to generate this output.

Copied from original issue: #13

Entrypoint error

in case no entrypoint is found, we can asume the address to decompile is 0 (useful when analyzing dumped artifacts or shellcodes), but right now the error is not really helpful

$ target/debug/radeco /etc/services
Invalid address (entry0)
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: ParseError(SyntaxError("EOF While parsing value", 1, 1))', ../src/libcore/result.rs:732

Run through rust-clippy.

[CI] Fix Coveralls report

The current coveralls report shown is incorrect as it includes r2's source as a part radeco (hence resulting in low coverage of 7%).

/cc @XVilka @Maijin @radare

Automatic mode for parser

Though the current ESIL parser is good and convenient to use compared to raw esil, there are a few improvements that I'd like to add that would make it easier to use.

Automate setting of old, cur and lastsz in the parser. These are non-intuitive and easy to forget or not do correctly. Of course this feature could be disabled in applications where this is not suitable, but for most cases this would work fine. Also add a warning to warn the user when old, cur and lastsz were not updated correctly as per the ESIL semantics.

Fix coveralls report

The current coverall report is incorrect as it is taking into account the r2 codebase too in calculation of percentage coverage. This needs to be fixed to get an accurate report.

Error handling

Right now esil-rs panics when something goes wrong. We need to implement better error handling and return errors to the users who may decide on how to handle this.

Missing registers in radeco's register profile

[0x00400526]> #!pipe RUST_BACKTRACE=1 ./minidec
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[x] Analyze function calls (aac)
[0x0040053e esil_mem_addeq_n: invalid parameterse)
[x] Emulate code to find computed references (aae)
[x] Analyze consecutive function (aat)
[aav: using from to 0x400000 0x402198
Using vmin 0x400000 and vmax 0x601040
aav: using from to 0x400000 0x402198
Using vmin 0x400000 and vmax 0x601040
[x] Analyze value pointers (aav)
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[*] Constructing ...
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:325
stack backtrace:
   1:     0x555f02d872ef - std::sys::backtrace::tracing::imp::write::h3800f45f421043b8
   2:     0x555f02d8c0db - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h0ef6c8db532f55dc
   3:     0x555f02d8bd63 - std::panicking::default_hook::hf3839060ccbb8764
   4:     0x555f02d7dccd - std::panicking::rust_panic_with_hook::h5dd7da6bb3d06020
   5:     0x555f02d8c321 - std::panicking::begin_panic::h9bf160aee246b9f6
   6:     0x555f02d7ec8a - std::panicking::begin_panic_fmt::haf08a9a70a097ee1
   7:     0x555f02d8c2be - rust_begin_unwind
   8:     0x555f02dc1b6f - core::panicking::panic_fmt::h93df64e7370b5253
   9:     0x555f02dc1e48 - core::panicking::panic::h9d5bd65bbb401959
  10:     0x555f02cd3584 - _<std..option..Option<T>>::unwrap::h6aef091f4b6ff42e
                        at ../src/libcore/macros.rs:21
  11:     0x555f02cd3357 - _<middle..phiplacement..PhiPlacer<'a, T>>::read_register::h4ead5c0b182be7fe
                        at src/middle/phiplacement.rs:447
  12:     0x555f02ce2339 - _<frontend..ssaconstructor..SSAConstruct<'a, T>>::process_in::hd7618884e7f30e12
                        at src/frontend/ssaconstructor.rs:127
  13:     0x555f02ce0dd1 - _<frontend..ssaconstructor..SSAConstruct<'a, T>>::process_op::h4d0dd0078e677458
                        at src/frontend/ssaconstructor.rs:180
  14:     0x555f02cb3b4e - _<frontend..ssaconstructor..SSAConstruct<'a, T>>::run::h1b082c3ed2f8d414
                        at src/frontend/ssaconstructor.rs:482
  15:     0x555f02ca0ae3 - radeco_lib::frontend::containers::RadecoFunction::construct::h5d9b65935b8ad2d2
                        at src/frontend/containers.rs:100
  16:     0x555f02ce94ac - radeco_lib::frontend::containers::ssa_single_fn::he5096a7f47bddb01
                        at src/frontend/containers.rs:123
  17:     0x555f02bf5c4a - _<radeco_lib..frontend..containers..RadecoModule<'a> as std..convert..From<&'a mut T>>::from::_$u7b$$u7b$closure$u7d$$u7d$::hb44788f1fdd653c6
  18:     0x555f02bf5b37 - _<std..panic..AssertUnwindSafe<F> as std..ops..FnOnce<()>>::call_once::h527d3b6640403128
                        at ../src/libstd/panic.rs:284
  19:     0x555f02bf5a8e - std::panicking::try::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h3f5128ea6bbad281
  20:     0x555f02bf63d4 - std::panicking::try::call::h7da9b03a87cc71a2
                        at ../src/libstd/panicking.rs:272
  21:     0x555f02d95d2b - __rust_try
  22:     0x555f02d95cce - __rust_maybe_catch_panic
  23:     0x555f02bf571d - std::panicking::try::_$u7b$$u7b$closure$u7d$$u7d$::hf4d7c48fcd75690f
  24:     0x555f02bf55ef - _<std..thread..LocalKey<T>>::with::hfba6cb75f1a19d58
                        at ../src/libstd/thread/local.rs:211
  25:     0x555f02bf542f - std::panicking::try::h8b85037222c3ea8b
                        at ../src/libstd/panicking.rs:235
  26:     0x555f02bf530e - std::panic::catch_unwind::h6af3f394e3201ad9
                        at ../src/libstd/panic.rs:387
  27:     0x555f02bf5181 - std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::he15378db27dde864
  28:     0x555f02bf6757 - _<F as std..boxed..FnBox<A>>::call_box::h765aff2a4682d6c1
                        at ../src/liballoc/boxed.rs:543
  29:     0x555f02d8a914 - std::sys::thread::Thread::new::thread_start::h9e5bde00f3b3e2e2
  30:     0x7fd32f6c66f9 - start_thread
  31:     0x7fd32f1e6b5c - clone
  32:                0x0 - <unknown>
[+] Analyzing: sub.__gmon_start___248_420 @ 0x400420
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym.frame_dummy @ 0x400500
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym.__libc_csu_init @ 0x400570
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym.__do_global_dtors_aux @ 0x4004e0
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym.register_tm_clones @ 0x4004a0
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: entry0 @ 0x400430
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym._init @ 0x4003c8
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym.deregister_tm_clones @ 0x400460
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym.__libc_csu_fini @ 0x4005e0
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR
[+] Analyzing: sym._fini @ 0x4005e4
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
  [*] Eliminating Common SubExpressions
  [*] Writing out IR

binary (base64'd) https://gist.github.com/a44b88d77df07c1b6486204eaee34f44

minidec: thread main panicked at called Option::unwrap() on a None value

I have seen similar "unwrap on none" issues, but this one seems to happen in a different source location.

[+] Analyzing: fcn.402119dc @ 0x402119dc
  [*] Eliminating Dead Code
  [*] Propagating Constants
  [*] Eliminating More DeadCode
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:325
stack backtrace:
   1:     0x55a94460f641 - std::sys::backtrace::tracing::imp::write::h46e546df6e4e4fe6
   2:     0x55a944614c41 - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h077deeda8b799591
   3:     0x55a94461487c - std::panicking::default_hook::heb8b6fd640571a4f
   4:     0x55a9446057c4 - std::panicking::rust_panic_with_hook::hd7b83626099d3416
   5:     0x55a944614ece - std::panicking::begin_panic::h941ea76fc945d925
   6:     0x55a94460636f - std::panicking::begin_panic_fmt::h30280d4dd3f149f5
   7:     0x55a944614e77 - rust_begin_unwind
   8:     0x55a94461eb5d - core::panicking::panic_fmt::h2d3cc8234dde51b4
   9:     0x55a94461ee03 - core::panicking::panic::heeca72c448510af4
  10:     0x55a9444ddad2 - _<core..option..Option<T>>::unwrap::hf974143bfcbe386e
                        at /builddir/build/BUILD/rustc-1.11.0/src/libcore/macros.rs:21
  11:     0x55a9444dd618 - radeco_lib::middle::ssa::ssastorage::SSAStorage::external::h1f5b13fa02c4fa7d
                        at /opt/radeco-lib/src/middle/ssa/ssastorage.rs:233
  12:     0x55a9444e47c3 - _<radeco_lib..middle..ssa..ssastorage..SSAStorage as radeco_lib..middle..ssa..cfg_traits..CFG>::exit_node::h63e586e9c197f278
                        at /opt/radeco-lib/src/middle/ssa/ssastorage.rs:337
  13:     0x55a94447c708 - radeco_lib::middle::dce::sweep::h725eb14d32f93186
                        at /opt/radeco-lib/src/middle/dce.rs:64
  14:     0x55a94447a32d - radeco_lib::middle::dce::collect::h52dafd5a519e870c
                        at /opt/radeco-lib/src/middle/dce.rs:20
  15:     0x55a944436ef7 - minidec::main::he08289d7edeea7b6
                        at /opt/radeco-lib/minidec/main.rs:46
  16:     0x55a94461445d - std::panicking::try::call::hca715a47aa047c49
  17:     0x55a94461c36b - __rust_try
  18:     0x55a94461c315 - __rust_maybe_catch_panic
  19:     0x55a944613ec9 - std::rt::lang_start::h162055cb2e4b9fe7
  20:     0x55a9444ad6c9 - main
  21:     0x7fac33c60730 - __libc_start_main
  22:     0x55a944436398 - _start
  23:                0x0 - <unknown>

I can share the binary if necessary.

Use + and - instead of = to specify if a stage needs to be dumped

Improve Docs

The current implementation seems pretty stable. It would be a good idea to add more documentation for the same. This bug is essential composed of two tasks:

Add docs
Make travis push updated docs on every push to master. See travis-cargo.

parsing json fails on 'tachikoma'

[12:36:45] <mom> minishwoods tools/radeco ‹master*› » ./target/debug/cfg_ssa ../../dc23/ctf-services/services/defcon_finals_2015/tachikoma/tachikoma 
[12:36:45] <mom> Cannot find function at 0x0002b3f0
[12:36:45] <mom> thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: ParseError(SyntaxError("EOF While parsing value", 1, 1))', ../src/libcore/result.rs:731

http://toonces.cat/tachikoma

`radeco` utility request/specification

Radeco

The radare decompiler tool, (namedly 'radeco') should be able to run from r2 or from the shell, accepting different inputs and dumping different outputs.

$ radeco -h
Usage: radeco [-flags] [...]
-h           show this help
-o [type]    specify output type (ssa, )
-i [type]    specify input type
-r [r2pipe]  specify how to connect to r2
-O           output all intermediate representations to files (.asm .esil .ssa. ...)
Types: (listedn bottom-top)
 - asm   : assembly/hexpairs
 - esil
 - ssa
 - dot
 - ... magic ...
 - C code

We should be able to run this tool from commandline or inside r2 like this:

$ radeco -i asm -o ssa disasm.txt > disasm-ssa.txt

And from inside the r2 shell:

> #!pipe radeco -o c   # decompile current function

Bear in mind that radeco will get info from r2... but it will also export info to r2. this is. radeco is able to identify basic blocks, local variables, loops, etc.

The next step would be to write a PseudoWriter module that takes the graph and prints C-like code, the graph representation must contain all the information needed to generate this output.

Add `png` stage to generate PNG images from dot graphs

Reference strings in the output

define-fun sym.main(unknown) -> unknown {
    bb_0x4004FC.0000():
        %1: $Unknown64 = rsp - #x8
        %2: $Unknown0 = Store(mem, %1, rbp)
        call 0x4003e0(r15=r15, r14=r14, r13=r13, r12=r12, rbp=%1, rbx=rbx, r11=r11, r10=r10, r9=r9, r8=r8, rax=rax, rcx=rcx, rdx=rdx, rsi=rsi, rdi=#x4005c4, rip=rip, cs=cs, cf=cf, pf=pf, af=af, zf=zf, sf=sf, tf=tf, if=if, df=df, of=of, rsp=%1, ss=ss, fs_base=fs_base, gs_base=gs_base, ds=ds, es=es, fs=fs, gs=gs)
        %4: $Unknown64 = Load(%2, [email protected])
        %5: $Unknown64  = [email protected] + #x8
        %6: $Unknown64  = %5 + #x8
        rbp = %4
        rax = #x0
        rsp = %6
        mem = %2
}

From

push rbp
mov rbp, rsp
mov edi, str.Hello_World
call sym.imp.puts
mov eax, 0
pop rap
ret

Looks like the string is not referenced in the output

Enable OSX Travis

Travis supports OSX. I think we should have OSX tests for esil-rs

Enable Doc, Travis CI and Appveyor on radeco

Configure Appveyor @XVilka
Add radeco to r2pm
Enable Appveyor on github @radare
Add the .travis.yml file
Enable the Travis project on github + travis website @radare
Add the "build passing" logos on the README
Add makefile or/and build instructions for humans(tm)
Automate the rust doc generation @sushant94
Coverall.io #18

Build Failing!

I am getting the same errors as Travis-CI is when compiling. See https://travis-ci.org/radare/radeco-lib/jobs/80833855#L1329.

Python bindings

The same way r2 has. May be even allow access to some 'internal' information via r2pipe (make it radeco pipe too?).

Diaphora support based on RadecoIR

Related to radareorg/radare2#2742

Probably, using higher level IR for diffing makes more sense?

Build fails

This is using rustc 1.10.0 and cargo 0.11.0.

[username@username-pc ~]$ r2pm -i radeco

(omitted beginning)
Compiling radeco v0.1.0 (file:///home/username/.config/radare2/r2pm/git/radeco)
     Running `rustc src/main.rs --crate-name radeco --crate-type bin -C codegen-units=4 -g --cfg feature=\"default\" --out-dir /home/username/.config/radare2/r2pm/git/radeco/target/debug --emit=dep-info,link -L dependency=/home/username/.config/radare2/r2pm/git/radeco/target/debug -L dependency=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps --extern radeco_lib=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/libradeco_lib-1972cdcc2aa244d7.rlib --extern r2pipe=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/libr2pipe-7486d38511f6d9ac.rlib --extern docopt=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/libdocopt-c2a0ac91deaa6c56.rlib --extern rustc_serialize=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/librustc_serialize-3561541d79c18212.rlib --extern log=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/liblog-bf16bb9a4912b11d.rlib`
src/structs.rs:6:25: 6:33 error: unresolved import `radeco_lib::utils::Analysis`. There is no `Analysis` in `radeco_lib::utils` [E0432]
src/structs.rs:6 use radeco_lib::utils::{Analysis, Pipeline, Pipeout, Runner};
                                         ^~~~~~~~
src/structs.rs:6:25: 6:33 help: run `rustc --explain E0432` to see a detailed explanation
src/structs.rs:6:35: 6:43 error: unresolved import `radeco_lib::utils::Pipeline`. There is no `Pipeline` in `radeco_lib::utils` [E0432]
src/structs.rs:6 use radeco_lib::utils::{Analysis, Pipeline, Pipeout, Runner};
                                                   ^~~~~~~~
src/structs.rs:6:35: 6:43 help: run `rustc --explain E0432` to see a detailed explanation
src/structs.rs:6:45: 6:52 error: unresolved import `radeco_lib::utils::Pipeout`. There is no `Pipeout` in `radeco_lib::utils` [E0432]
src/structs.rs:6 use radeco_lib::utils::{Analysis, Pipeline, Pipeout, Runner};
                                                             ^~~~~~~
src/structs.rs:6:45: 6:52 help: run `rustc --explain E0432` to see a detailed explanation
src/structs.rs:6:54: 6:60 error: unresolved import `radeco_lib::utils::Runner`. There is no `Runner` in `radeco_lib::utils` [E0432]
src/structs.rs:6 use radeco_lib::utils::{Analysis, Pipeline, Pipeout, Runner};
                                                                      ^~~~~~
src/structs.rs:6:54: 6:60 help: run `rustc --explain E0432` to see a detailed explanation
src/args.rs:67:20: 67:45 error: type name `radeco_lib::utils::Runner` is undefined or not in scope [E0412]
src/args.rs:67     runner: Option<radeco_lib::utils::Runner>,
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~
src/args.rs:67:20: 67:45 help: run `rustc --explain E0412` to see a detailed explanation
src/args.rs:67:20: 67:45 help: no candidates by the name of `Runner` found in your project; maybe you misspelled the name or forgot to import an external crate?
src/structs.rs:102:31: 102:43 error: no method named `get_bin_info` found for type `r2pipe::R2` in the current scope
src/structs.rs:102             let bin_info = r2.get_bin_info().unwrap();
                                                 ^~~~~~~~~~~~
src/structs.rs:198:24: 198:36 error: no method named `get_reg_info` found for type `r2pipe::R2` in the current scope
src/structs.rs:198             let r = r2.get_reg_info().ok();
                                          ^~~~~~~~~~~~
src/args.rs:89:12: 89:27 error: the type of this value must be known in this context
src/args.rs:89         if runner.is_err() {
                          ^~~~~~~~~~~~~~~
src/args.rs:216:73: 216:83 error: the type of this value must be known in this context
src/args.rs:216                 radeco_out!("[*] Starting radeco with config: ", runner.is_verbose());
                                                                                        ^~~~~~~~~~
src/args.rs:216:17: 216:87 note: in this expansion of radeco_out! (defined in src/args.rs)
src/args.rs:228:58: 228:68 error: the type of this value must be known in this context
src/args.rs:228                 radeco_out!("[*] Writing output", runner.is_verbose());
                                                                         ^~~~~~~~~~
src/args.rs:228:17: 228:72 note: in this expansion of radeco_out! (defined in src/args.rs)
error: aborting due to 5 previous errors
error: Could not compile `radeco`.

Caused by:
  Process didn't exit successfully: `rustc src/main.rs --crate-name radeco --crate-type bin -C codegen-units=4 -g --cfg feature="default" --out-dir /home/username/.config/radare2/r2pm/git/radeco/target/debug --emit=dep-info,link -L dependency=/home/username/.config/radare2/r2pm/git/radeco/target/debug -L dependency=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps --extern radeco_lib=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/libradeco_lib-1972cdcc2aa244d7.rlib --extern r2pipe=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/libr2pipe-7486d38511f6d9ac.rlib --extern docopt=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/libdocopt-c2a0ac91deaa6c56.rlib --extern rustc_serialize=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/librustc_serialize-3561541d79c18212.rlib --extern log=/home/username/.config/radare2/r2pm/git/radeco/target/debug/deps/liblog-bf16bb9a4912b11d.rlib` (exit code: 101)

Replace instruction pointer with address when used as operand

GSoC Tasklist (sushant)

Tasklist for GSoC-2015:

ESIL Parser in Radeco.
Develop tests for the ESIL Parser.
Dominator tree

Constant folding.
Tests for constant folding.
Type Propagation.
Integration into radare2.

Improvements to DOMTree

Dominator tree construction was one of the first analysis implemented in radeco. This needs some love. As such, it is works but is inconsistent with the other analysis API in radeco. A refactor is needed.

Since DOMTree is not currently used anywhere in radeco, we can afford to make breaking changes (and probably do this when needed).

NOTE: petgraph has recently added dominator tree construction to its set of graph algorithms. It might be worthwhile to look into this and ride off their analysis instead of reimplementing/refactoring this inside radeco.

-h output is not the same as --help

Short options for --version --verbose --output and --shell

GSoC Tasklist (dkreuter)

Tasklist for GSoC-2015:

Graph data structures, processing, API
Develop tests for graph infrastructure
Implement pattern matching on the graph.
Test pattern matching
Convert the parsed ESIL into SSA-ESIL.
Develop tests for SSA-ESIL.

Variables propagation (*x = ?; *x → *x = t = ?; t)
Tests for that.
Phi elimination.

Default VM implementation

With the current esil-rs implementation, I find myself using the following pattern quite regularly.

// Initializations
let mut p = Parser::init(None);
while let Some(ref opinfo) = self.instruction_source.next() {
    let esil = opinfo.esil.as_ref().unwrap()
    while let Some(token) = p.parse::<_, Tokenizer>(esil) {
       let result = {
           // Do some operations with tokens returned.
      }
      p.push(result);
    }
}

It would be nice to have a default Evaluator / Consumer / VM implementation that would do this for us, while allowing us to customize it for the needed operation.

Lower contribution entry barrier

I really recommend using another language like C, C++ or Python3 to allow much more people to contribute. I'd recommend Python to allow really fast and easy progress, functionality is much more important than speed, especially in the early stage, later cython, pypy or c-extension can be used to speed up critical parts.

The target audience is barely familiar with Rust and doesn't want to learn a new language for just this project to contribute. Many people at our chair are looking forward to radeco, but are deterred by Rust.

This project is an awesome idea in general, but I can assure you it'll be way more successful if it's not based on Rust.

What do you think?

EDIT:
Switching language seems to be a bad option, so the other thing to improve is to lower the entry barrier by in-repo documentation.

radeco does not recognise `ucall`

Other variants of call have type field which is not a call. These are currently not being recognised as call instructions. Reported by @Maijin.

Minidec Panics

I ran into a couple panics when running minidec. I'm using rustc version rustc 1.13.0-nightly (a7b2232d2 2016-09-07).

First at the very beginning of the run I get the following panic. Execution, however, continues.

...
[*] Constructing ...
thread '<unnamed>' panicked at 'not yet implemented', /home/sam/.cargo/git/checkouts/esil-rs-86f6c3f12c1d8ed5/master/src/parser.rs:166
stack backtrace:
   1:     0x7f59e6083923 - std::sys::backtrace::tracing::imp::write::h46f28e67d38b4637
   2:     0x7f59e60877fd - std::panicking::default_hook::{{closure}}::h1d3243f546573ff4
   3:     0x7f59e6086a8a - std::panicking::default_hook::h96c288d728df3ebf
   4:     0x7f59e6087088 - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   5:     0x7f59e604d1ff - std::panicking::begin_panic::h0914615a412ba184
   6:     0x7f59e604eb9f - <esil::parser::Parser as esil::parser::Parse>::fetch_operands::h4f14395fe3fda996
   7:     0x7f59e6041b6e - <radeco_lib::frontend::ssaconstructor::SSAConstruct<'a, T>>::run::h2ddb588b2a2b0311
   8:     0x7f59e6046664 - radeco_lib::frontend::containers::ssa_single_fn::he1c8cf8aa5ab0a43
   9:     0x7f59e6014822 - std::panicking::try::do_call::h1c70469e16982e0c
  10:     0x7f59e608f2c6 - __rust_maybe_catch_panic
  11:     0x7f59e6019e84 - <F as alloc::boxed::FnBox<A>>::call_box::hc5ae4f213bb2fd4e
  12:     0x7f59e60859b0 - std::sys::thread::Thread::new::thread_start::h5b631f48cd23f128
  13:     0x7f59e57d8183 - start_thread
  14:     0x7f59e52da37c - clone
  15:                0x0 - <unknown>

Some functions seem to be decompiled correctly, but at least one (always seems to be from a small subset of the functions in the binary) panics in the following way:

...
  [*] Writing out IR
thread 'main' panicked at 'assertion failed: i == ssa.regnames.len()', src/middle/ir_writer.rs:383
stack backtrace:
   1:     0x7f59e6083923 - std::sys::backtrace::tracing::imp::write::h46f28e67d38b4637
   2:     0x7f59e60877fd - std::panicking::default_hook::{{closure}}::h1d3243f546573ff4
   3:     0x7f59e6086a8a - std::panicking::default_hook::h96c288d728df3ebf
   4:     0x7f59e6087088 - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   5:     0x7f59e60147af - std::panicking::begin_panic::h0914615a412ba184
   6:     0x7f59e600c243 - radeco_lib::middle::ir_writer::IRWriter::emit_il::h0527167121961ec6
   7:     0x7f59e602330d - minidec::main::h87fa1fd4e3efb403
   8:     0x7f59e608f2c6 - __rust_maybe_catch_panic
   9:     0x7f59e6086301 - std::rt::lang_start::haaae1186de9de8cb
  10:     0x7f59e5201f44 - __libc_start_main
  11:     0x7f59e6009288 - <unknown>
  12:                0x0 - <unknown>

After this panic, minidec stops and produces an incomplete output.

Move r2 module to r2pipe.rs

The r2 module that implements some of the basic commands in order to make r2 easier to use from rust seems to be useful in repos other than radeco-lib too. I propose we move it to r2pipe, which will give user's an option to either use raw r2pipe or use r2 implementation that returns structs that are convenient to use.

esil is not parsed properly

parser.rs fails to parse esil expressions that contain DUP opcode:
0,zf,=,cf,401528,+,eax,+,0,cf,=,DUP,0xffffffff,<,?{,1,cf,=,},eax,=,=,0xffffffff,eax,&,!,?{,1,zf,=,}

Also expressions with 'ds' are not parsed:
esp,[4],ds,=,4,esp,+

Not all stages are dumped

[0x100000f30]> #!pipe target/debug/radeco -o win  -p =r2,=esil,=cfg,=ssa,=const,=dce
[0x100000f30]> !find win
win/a.out.run/a.out.dot
win/a.out.run/a.out.esil
win/a.out.run/a.out.insts

thread 'main' panicked at 'called 'Option::unwrap()' on a 'None' value', ../src/libcore/option.rs:330
stack backtrace:
   1:     0x7f9f2b2bca08 - sys::backtrace::tracing::imp::write::h3675b4f0ca767761Xcv
   2:     0x7f9f2b2bc80e - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44519
   3:     0x7f9f2b2bb0c6 - sys_common::unwind::begin_unwind_inner::hfb5d07d6e405c6bbg1t
   4:     0x7f9f2b2ba8f5 - sys_common::unwind::begin_unwind_fmt::h8b491a76ae84af35m0t
   5:     0x7f9f2b2ce0c4 - panicking::panic_fmt::h98b8cbb286f5298alcM
   6:     0x7f9f2b2ce128 - panicking::panic::h4265c0105caa1121SaM
   7:     0x7f9f2b1fdc8f - frontend::parser::Parser::emit_insts::ha2af8ea72bd93276qdi
   8:     0x7f9f2b1a84b5 - utils::Runner::run::h02fcf46af8b11481sOa
   9:     0x7f9f2b176a12 - main::h9cef0bb901591b93Ohb
  10:     0x7f9f2b2cb684 - sys_common::unwind::try::try_fn::h14622312129452522850
  11:     0x7f9f2b2c8d8b - __rust_try
  12:     0x7f9f2b18902c - main
  13:     0x7f9f2a5937af - __libc_start_main
  14:     0x7f9f2b176438 - _start
  15:                0x0 - <unknown>

`FnIdx` (in `RModule`) should have a corresponding trait.

The current implementation uses u64/usize which is kind of hacky. We could do much better with a dedicated trait for this.

dkreuter feature wishlist

Flow reshaping
Graph overlays
Generating DWARF debug info

radareorg / radeco Goto Github PK

radeco's Introduction

Radeco

Is this ready yet?

Usage

Trace Log

Profiling

Radeco-lib project layout

License

radeco's People

Contributors

Stargazers

Watchers

Forkers

radeco's Issues

Radeco

Radeco

Recommend Projects

Recommend Topics

Recommend Org