retdec | retargetable machine-code decompiler | Compiler library

by avast C++ Version: v5.0 License: MIT

X-Ray Key Features Code Snippets Community Discussions(2)Vulnerabilities Install Support

kandi X-RAY | retdec Summary

retdec is a C++ library typically used in Utilities, Compiler applications. retdec has no bugs, it has no vulnerabilities, it has a Permissive License and it has medium support. You can download it from GitHub.

RetDec is a retargetable machine-code decompiler based on LLVM.

Support

Quality

Security

License

Reuse

Support

retdec has a medium active ecosystem.

It has 7314 star(s) with 907 fork(s). There are 237 watchers for this library.

It had no major release in the last 12 months.

There are 404 open issues and 417 have been closed. On average issues are closed in 135 days. There are 1 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of retdec is v5.0

Quality

retdec has 0 bugs and 0 code smells.

Security

retdec has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

retdec code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

retdec is licensed under the MIT License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

retdec releases are available to install and integrate.

Installation instructions, examples and code snippets are available.

It has 7142 lines of code, 713 functions and 42 files.

It has high code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of retdec

Get all kandi verified functions for this library.

retdec Key Features

No Key Features are available at this moment for retdec.

retdec Examples and Code Snippets

No Code Snippets are available at this moment for retdec.

Community Discussions

Trending Discussions on retdec

Process hangs, if stderr and stdout are redirected

Why we need to instrument binary when we have a decompiler?

QUESTION

Process hangs, if stderr and stdout are redirected

Asked 2021-Dec-28 at 14:11

I'm trying to call cmake and redirect the output to a pipe.

To reproduce:

git clone https://github.com/avast/retdec (It seems to be every CMake-Project, gradle projects don't work, too)
mkdir build&&cd build
Add a file test.hs:

...

ANSWER

Answered 2021-Dec-28 at 14:11

The buffer size of pipes isn't unlimited. You're creating a deadlock, where the child process is hanging because it's trying to write to a buffer that's full, and your parent process doesn't try to read anything from the buffer until the child process has completed. To fix the problem, you need to use another thread to read from the buffer while the child process is still running. The simplest way to do this is to use readProcess or a similar function in place of createProcess. If this doesn't give you enough flexibility to do what you want, then you'll need to create and manage the other thread yourself, which you can see how to do by looking at how readProcess is implemented.

Source https://stackoverflow.com/questions/70508072

QUESTION

Why we need to instrument binary when we have a decompiler?

Asked 2020-May-21 at 03:04

I'm studying the binary instrumentation techniques and I found many papers claim that binary instrumentation is necessary when the source code is not available.

While maybe we cannot get the original source code, a semantical equivalent one from the decompiler is possible (like RetDec), which, in my mind, is sufficient for many tasks previously done by binary instrumentation, e.g., software fault isolation. Sometimes we even don't have to decompile the binary to the source code -- LLVM IR is enough for many code instrumentation and analysis. And the performance might be even better since we still have the optimizations in the middle end afterwards.

My guess is that (1) the decompiler cannot recover the code well enough for most binary instrumentation task, or (2) the decompiler can only decode a small portion of binary, or (3) it takes long long time for decompiler to recover a big library but binary instrumentation only takes a short time.

Is one of my guesses correct? What is the fact here?

EDIT: Among many binary instrumentation tasks, my focus is mainly on the memory address isolation, which is usually done by masking the address or setting a guard zone in the assembly. Just curious why not adding some checking code in the LLVM IR level if we can decompile the binary to such representation.

...

ANSWER

Answered 2020-May-21 at 02:56

Basically, the problem is that decompilers are "incomplete" in that they can't handle all possible binaries. Then too, with both decompilers and binary instrumentation, there's the problem of determining what in the binary is code and what is data -- it's generally undecidable and you just want to instrument the code, not alter the data.

With binary instrumentation, you can more readily deal with this incrementally, only instrumenting what you know to be code, with "instrumentation" where execution might leave the known code to interrupt and instrument more (or when what was thought to be code is accessed as data, "undo" the instrumentation for the access).

As with everything, there are performance tradeoffs -- the most extreme instrumentation is using an emulator to execute the code while extracting information, but the cost of that is high. Partial instrumentation by inserting breakpoints or inserting code has much lower cost, but is less complete. Decompiling and recompiling may allow for lower runtime cost but higher up-front cost.

Source https://stackoverflow.com/questions/61926092

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install retdec

There are two ways of obtaining and installing RetDec:. We currently support Windows (7 or later), Linux, macOS, and (experimentally) FreeBSD. An installed version of RetDec requires approximately 5 to 6 GB of free disk space.
Download and unpack a pre-built stable or bleeding-edge package and follow instructions in the Use section of its retdec/share/retdec/README.md file after unpacking.
Build RetDec by yourself from sources by following the Build and Installation section. After installation, follow instructions below.
This section describes a local build and installation of RetDec. Instructions for Docker are given in the next section.
Docker support is maintained by community. If something does not work for you or if you have suggestions for improvements, open an issue or PR.
Building in Docker does not require installation of the required libraries locally. This is a good option for trying out RetDec without setting up the whole build toolchain. To build the RetDec Docker image, run. This builds the image from the master branch of this repository.