avast / retdec-idaplugin Goto Github PK
View Code? Open in Web Editor NEWRetDec plugin for IDA
Home Page: https://retdec.com/
License: MIT License
RetDec plugin for IDA
Home Page: https://retdec.com/
License: MIT License
[RetDec info] : Running the decompilation command ...
[RetDec info] : Working on input file "C:\Users\morph\Desktop\Sandbox\MalwareTest.exe".
[RetDec info] : Found retdec-decompiler.py at C:\Users\morph\Desktop\Database\Reverse-Engineering\Decompilers\retdec\bin\retdec-decompiler.py -> plugin is properly configured.
[RetDec info] : Running retargetable decompiler plugin:
[RetDec info] : Unfinished decompilation was KILLED !!!
[RetDec info] : Saving IDA database ...
Flushing buffers, please wait...ok
[RetDec info] : IDA database saved into : C:\Users\morph\Desktop\Sandbox\MalwareTest.dec-backup.idb
[RetDec info] : Generating retargetable decompilation DB ...
[RetDec info] : Decompile input ...
[RetDec info] : Local decompilation ...
[RetDec info] : Decompilation command: "C:\Users\morph\Desktop\Database\Reverse-Engineering\Decompilers\retdec\bin\retdec-decompiler.py"
"C:\Users\morph\Desktop\Sandbox\MalwareTest.exe"
--config="C:\Users\morph\Desktop\Sandbox\MalwareTest.idb.json"
--color-for-ida
-o
"C:\Users\morph\Desktop\Sandbox\MalwareTest.exe.c"
--select-decode-only
--select-ranges="0xa50e70-0xa51092"
[RetDec info] : Running the decompilation command ...
Pictures of Settings:
Settings Picture
current plugin make idb.json's entryPoint component in hex string like "entryPoint" : "0x400c00",
but retdec only recognize uint64
RUN: /c/Users/Home/Desktop/b/retdec-v3.0-windows-64b/retdec/bin/fileinfo -c C:/Users/Home/Desktop/b/login.cgi.c.json --similarity C:/Users/Home/Desktop/b/login.cgi --no-hashes=all --crypto /c/Users/Home/Desktop/b/retdec-v3.0-windows-64b/retdec/bin/../share/generic/yara_patterns/signsrch/signsrch.yara
Input file : C:/Users/Home/Desktop/b/login.cgi
File format : ELF
File class : 32-bit
File type : Executable file
Architecture : MIPS (MIPS I Architecture)
Endianness : Big endian
Entry point address : 0x400c00
Entry point offset : 0xc00
Entry point section name : .text
Entry point section index: 8
Bytes on entry point : 03e0002104110001000000003c1c0005279caf34039fe0210000f8218f84807c8fa5000027a600042401fff803a1e82427bd
Detected tool : GCC (4.5.4) (compiler), 80 from 183 significant nibbles (43.7158%)
Error: loading of config failed: entryPoint must be an uint64 value @ line = 26, column = 17
Email from one of our users:
Following up on our twitter exchange I will provide you with some sample files. I would like the ReDec IDA plugin to work on the dol and rel file formats, both of which can be found on Nintendo consoles from Gamecube-Wii U. The processor is PowerPC Big Endian. Dol is simply a stripped elf file while rel is designed to function like a dynamic link library (DLL). The body is almost identical to that of the elf and dol file format and just features a new header with a custom entry function. Full documentation for those formats exists and more importantly, there is also a loader plugin for IDA available here: https://github.com/heinermann/ida-wii-loaders/releases
Both file formats can be easily opened with those and the structure is fully parsed near identical to that of any elf file. Furthermore cutting out a raw function and decompiling it using the ReDec web interface does work fine, but I would prefer to work in IDA to take advantage of the additional convenience and already figured out function names and arguments. See the attached zip file for small samples of both formats that can be opened in IDA with the provided loader. I also included the disassembly export from IDA.
Maybe, we could solve this by using raw decompilation. If not, these formats would have to be supported by RetDec's fileformat library. Explore and decide.
Any reason not to create a bunch of macros dealing with the porting to 7.x and allow continued backward compatibility to 5.x/6.x?
I can submit a PR with the change if its worth it. Mostly just a big conditional compilation blob in defs.h would do the trick, and a small handful of occurrences where class member calls need to be replaced by regular function calls to allow generality. I am not sure how widespread the IDA 6.x usage is nowadays.
I know things were forward ported but its not difficult to maintain backward compatibility even for the CMake build. It does not muddy the code too much either.
I configured it according to the instructions of user_guide:
1. Install Python 3 and Pygments.
2. Download the Windows installation package (Table 2) from the project’s release
page.
3. Copy retdec.dll to the IDA’s plugin directory (<IDA_ROOT>/plugins).
This is my Python3 environment:
C:\Users\*****\AppData\Local\Programs\Python\Python35>python -m pip list
pip (8.1.1)
Pygments (2.2.0)
setuptools (20.10.1)
You are using pip version 8.1.1, however version 10.0.1 is available.
You should consider upgrading via the 'python -m pip install --upgrade pip' command
Then, I copy retdec.dll to the IDA’s plugin directory:
But when using it, this problem has arisen:
Hmm, So what is going on here? Thanks
Thank you very much for a very good decompiler.
The default plugin invocation (run = 0) works fine for 64bit windows executable targets, but 32bit plugin invokes the (run = 1) function always. Asks for a file to decompile and if I give it a reference file to decompile it keeps asking for a file again if I click on any address in the decompile window.
This is using IDA for Windows 7.5.200728
There is no "retdec-idaplugin.sln" file。
I am unsure what you would like me to provide in terms of logs. However, the plugin loaded one time and after a restart it did not load at all. It doesnt recognise any of the keybindings nor do I find any reference of the plugin anywhere in IDA.
Not sure for the cause
I use ida for macOS and I installed this plugin with the user_guide.pdf. I also installed retdec,but now I can't use it in IDA....There is no plugin in my tool
At the moment, when user selects a function to decompile, range of this function, as well as ranges of all functions which call it, and ranges of functions called from it, are decoded and decompiled. Only the selected function is displayed.
This was done to provide retdec
with more context than just one selected function. It might be useful for parameter reconstruction, etc. However, decompilation takes longer than it would if only the selected function was processed. Moreover, this should not be needed, since the necessary context is exported from IDA in JSON database.
Modify it in a way, that only the selected function is decoded and decompiled. If some problems appear, fix usage of JSON info to supply the missing context. If there is not enough info in JSON add it in retdec-idaplugin
and use it in retdec
.
When the attached PE binary file is decompiled through the IDA plugin, statically linked code is not removed, but when I decompile it directly through decompile.sh
, it is removed.
The input and both output C files can be downloaded here.
hello-world.exe
through the IDA plugin via run-ida-decompilation.sh
:
$ run-ida-decompilation.sh hello-world.exe -o hello-world.idpalugin.c
decompile.sh
:
$ decompile.sh hello-world.exe -o hello-world.decompile-sh.c
The input binary file hello-world.exe
contains just main()
with printf("Hello, world!");
. This is exactly what decompile.sh
produces in hello-world.decompile-sh.c
(just a single main()
function and nothing more).
However, hello-world.idaplugin.c
contains not only _main()
but also 47 other functions that come from statically linked code. I would expect them to be removed, just like when the file is decompiled directly through decompile.sh
.
Right now, only one decompilation can run at a time. When second decompilation is triggered before the first one is finished, the first one gets killed and the second one takes its place.
This could be made better by supporting multiple decompilations at one time. There is no principal problem with this. It is possible to run the decompilation script multiple times at one moment. However, the whole thing is not trivial. We would have to make sure these decompilations are not using the same resources - both files on the disc, and internal structures in RetDec plugin. All related structures and actions (e.g. navigation) would have to be duplicated and associated with a single decompilation.
Right now, we have only one plugin version for 32-bit address space (which is itself a 64-bit library, see explanation). It should be possible to also create a 64-bit address space version, which would for now decompile only 32-bit binaries (until we add support for some 64-bit architectures).
It is not enough to kill (qthread_kill()
) decompilation thread using IDA SDK API. The decompilation process (retdec-decompiler.sh
execution) which was created is not terminated.
I tried to use SDK's API for processes, but no luck so far. The matter is more compilated, because retdec-decompiler.sh
itself launches other processes.
I downloaded retdec 3.1
for Windows and unpacked it to C:\retdec\bin
. I also added C:\retdec\bin
to the PATH
system variable. When I open a cmd
shell and type retdec-decompile.sh
the command is found and works as expected.
Furthermore I downloaded the IDA
plugin 0.5
from here and extracted the retdec.dll
to the IDA
plugins directory: C:\Program Files\IDA 7.0\plugins
.
When I load up IDA
and press CTRL + D
to decompile, it shows me the following warning:
This appear to be wrong, since I configure my PATH
environment variable already so I click OK
. The next dialog asks me to select the retdec-decompiler.sh
file so I do that and click Open
:
Again, the Decompilation is not properly configured
opens so it is stuck in an endless loop.
I'm not sure what I'm doing wrong or if this is a bug but how can I fix it?
I'm using the regular IDA Pro 7.x
and not the free version. Also I'm using a custom IDA
plugin so I'm also getting the following warning:
I'm not sure if this matters but it might be worth to be mentioned regardless.
A thread handle leaks every decompilation since the PROCESS_INFORMATION structure has an hThread member which needs to have CloseHandle called on it immediately with every run (defs.cpp, runCommand).
The process handle cannot be closed (or the termination cannot be monitored as PIDs are reused on Windows and cannot be guaranteed) and must be saved and closed in the same way and at the same time as the thread (if option is set) for wrapping the decompilation process launch is killed or gracefully closed.
Also a thread handle leaks because qthread_join and qthread_free are not called in killDecompilation when decompRunning is false but decompThread has a non-nullptr value.
The stability would be increased if these bugs were fixed. On Linux at least the last issue is present, I am not sure how the launch_process return structure must be managed there but similar concepts should apply.
Since update from IDA 6.x to IDA 7.x, plugin's regression tests have stopped working. This concerns only plugin developers, not regular users.
The plugin only works in a regular IDA 7.x, not the freeware version. It looks like there are some obstacles that may or may not be solvable:
If possible, solve them and create a plugin version working in IDA freeware 7.0.
Right now, retdec-idaplugin
is always built with both local and API decompilation modes. In order to build API mode, retdec-idaplugin
needs a bunch of libraries (see IDA plugin libraries in Requirements). It is an extra work to get them (especially if our pre-compiled packages do not work for you). This work is useless, if you are not interested in API decompilation - especially after #8 is solved, there will not be many reasons to prefer it to local decompilation mode.
The whole API decompilation functionality could be compiled conditionaly - controlled by a CMake option. This would allow easier builds that would not need IDA plugin libraries.
Despite following the Windows install instructions to the letter in the users guide, the plugin will not install properly apparently. Installed Python 3.6 followed by pip3 install of Pygments.
When invoked it asks for a non-existent ".sh" file (which obviously wouldn't run on Windows anyhow). Added Python 3.6 path to my PATH variable (making it the one and only default Python binary) and that didn't change anything.
First all of all, kudos for the custom loader plugin support and IDA 7.x
support but I'm still not happy with the decompilation output.
Given a function with the following assembly code:
.text:02008C5C __PerformSyscall:
.text:02008C5C li r0, 0x12
.text:02008C60 sc
.text:02008C64 blr
If I run the retdec
decompiler on it, it produces the following output:
int32_t __PerformSyscall(void) {
// 0x2008c5c
return 0;
}
This is false because:
The function does not define a return value (r3
is not set) hence the return type is void
. Furthermore, the syscall (sc
instruction) is not translated at all. A proper decompilation (in my opinion) may look like the following:
void __PerformSyscall(void) {
asm volatile
(
"li r0, 0x12\n"
"sc"
);
}
Since the syscall instruction does not exist in C
, it has to use inline assembly.
Note that this is just one of many failing examples (all functions seem to just translate to return 0
). In fact, retdec
seemingly cannot deal with the custom plugin at all even though the IDA
database holds all necessary information to perform the decompilation. Therefore, why does it not operate correctly on the database? I would either expect an error message if something went wrong with reading the right data or a "proper" decompilation. Not a default "no-op" decompilation like this.
Note that this is a follow-up issue to the following issue: #3 (Check it out for more information or to download the custom plugin as well as an example binary)
Currently, IDA plugin passes the original binary file to RetDec for decompilation. This has several problems:
A possible solution is to apply (path) changes to the original binary before the decompilation. This would however not solve problem 4. and I'm if it would work for problems 2. and 3.
The best solution would be to establish a communication channel (callback function) between IDA and RetDec, which could be used by RetDec to query IDA about bytes on addresses as needed. Ghidra decompiler does it this way. However, this is currently not possible since RetDec is not a library.
Encoding all the data to JSON config could be a solution that would solve all the problems.
Hello,
I installed retdec and IDA plugin. I get this error when i press Ctrl+D
I installed python 3.8.2 and retdec v4 with IDA plugin 0.9
my OS is windows 7
I ran retdec-decompiler.py with a sample exe with no errors so I think this is a plugin error
note : my exe is in drive C while retdec and python are in drive D.
This decompiler conflict with IDA, IDA need 2.7 python, RETDEC need non 2.7 python....
Please add support python 2.7 version :(
Right now, IDA plugin runs RetDec with --color-for-ida
option to get a highlighted C output that it displays to users.
This option will be dropped in the next RetDec release. Instead, RetDec will be able to generate a JSON C output, which should be used instead.
At the moment, when user selects a function to decompile, retdec
is provided with function's range and a JSON generated from IDA database with metainformation to use. The range is decoded using retdec
decoder, without any hints on control flow from IDA - just as if retdec
was used without IDA plugin.
Although retdec
decoder has an ambition to be as good as IDA, it is not there yet. Moreover, even if it was as good or better, users using retdec
from retdec-idaplugin
would probably appreciate if the decompiled result had the same exact control flow as IDA disassembly - things might get confusing otherwise.
Therefore, it would be the best if retdec
could use control flow information provided by IDA (or any other JSON producer). The following needs to be done in order to make this happen:
retdec-config
- BB ranges, control flow changing instruction, their types, and targets (e.g. (un)cond branches, returns, calls).retdec-idaplugin
to produce this info into JSON.retdec
's decoder
pass to use this info - each control flow changing instruction is inspected in order to determine its type and targets (i.e. next BBs). It should not be hard to query potential JSON info for this info before decoder
tries to determine it on its own.Right now, we perform version checks for API decompilations to make sure, the latest version of RetDec idaplugin is used. We check versions by ==
(exact equivalence). Change it that only versions lesser than the latest one cause error. Therefore, if the latest official version is 0.3
, if we try to use version 0.2
, error is thrown, but if we try 0.4
(next version, used by developer), it is ok.
I was trying to compile the plugin for IDA 7.4 and got multiple errors:
"inf" is not declared
"WOPN_TAB" is not declared
"display_widget"is not accepting a single param
If required I can attach a build log but it is german.
The new RetDec JSON C output contains info on token assembly addresses.
Use this info for ASM <-> C code association - what HexRays does with Tab
.
Does it have the ability to set the only mode, the same as in the API. For example, sel_decomp_ranges='0x81089BE0-0x81089D70', sel_decomp_decoding='only'
Because my file is too big, I need this only mode, I don't know whether I can do this in IDA, thank you!
Using IDA Pro 6.8
, I'm trying to decompile a PowerPC
architecture function in an ELF
file format with the plugin but when I press CTRL + D
I get the following error:
IDA Pro
can disassemble everything just fine and recognizes the architecture correctly as well. Can you guys please look into this problem since PowerPC
is supposed to be supported by retdec
, yet the plugin refuses to work.
RetDec has a basic support for decompilation of Mach-O files. However, when I try to decompile a Mach-O file via the IDA plugin (e.g. this one), the plugin fails with the following error:
Retargetable Decompiler version 0.4 cannot decompile this input file.
IDA loads the input Mach-O file just fine. It would be nice if the IDA plugin supported the same file formats as RetDec.
Hi, I can successfully use the this plugin to generate c
files, but how to compile this c file to regenerate the executable file? I directly use the gcc hello.exe.c -o hello-d
command, but it doesn't seem to work. What parameters should be added? Thank you
IDA View-A
window.Output window
.After the decompilation finishes, its output is shown in a window right next to the Output window
:
The decompilation output should be shown in a window right next to the IDA View-A
window, which is where it opens when skipping step 5 above. That is, it should appear in the usual place.
master
)LoadLibrary(C:\Program Files\IDA Freeware 7.0\plugins\retdec64.dll) error: The specified procedure could not be found.
C:\Program Files\IDA Freeware 7.0\plugins\retdec64.dll: can't load file
[69/721] Performing patch step for 'yara'
-- -- Patching: Development/retdec-idaplugin/build/_deps/retdec-build/deps/yara/yara/src/yara/windows/vs2015/libyara/libyara.vcxproj patched
-- -- Patching:Development/retdec-idaplugin/build/_deps/retdec-build/deps/yara/yara/src/yara/windows/vs2015/libyara/libyara.vcxproj skipped
-- -- Patching: Development/retdec-idaplugin/build/_deps/retdec-build/deps/yara/yara/src/yara/libyara/modules/dotnet/dotnet.c patched
[75/721] Performing configure-msvc step for 'yara'
FAILED: _deps/retdec-build/deps/yara/yara/src/yara-stamp/yara-configure-msvc
cmd.exe /C "cd /D Development\retdec-idaplugin\build\_deps\retdec-build\deps\yara\yara\src\yara && \t:Clean Development/retdec-idaplugin/build/_deps/retdec-build/deps/yara/yara/src/yara/windows/vs2015/yara.sln && "C:\Program Files\CMake\bin\cmake.exe" -E touch Development/retdec-idaplugin/build/_deps/retdec-build/deps/yara/yara/src/yara-stamp/yara-configure-msvc"
文件名、目录名或卷标语法不正确。
[79/721] Performing download step (download, verify and extract) for 'capstone-project'
-- capstone-project download command succeeded. See also Development/retdec-idaplugin/build/_deps/retdec-build/external/src/capstone-project-stamp/capstone-project-download-*.log
[83/721] Building CXX object _deps\retdec-build\src\serdes\CMakeFiles\serdes.dir\basic_block.cpp.obj
The Chinese error message roughly translates to Filename, directory name or drive label's syntax is incorrect
. I was using Ninja generator
Decompilation via RetDec idaplugin gets into troubles if IDA has the file mapped on a different address than RetDec. In such a case, all metadata that come from IDA in config database are wrong when applied on image loaded by RetDec's image loader library.
This happens for object files. E.g. hello.zip, where IDA has main()
on address 0x8000000
and RetDec has it on 0x34
.
The same thing happens if user makes a rebase in IDA. E.g. here mytest.zip, main()
is at 0x8900180
, but in IDA, we can do Edit→Segments→Rebase program to 0x1000000
and run decompilation.
Solution: Probably get segments mappings from IDA and apply them in RetDec. This might be tricky, since RetDec libraries are probably not ready for it.
IDA Version : 7.0
retdec-idaplugin version : v0.9
retdec version: v3.3
Windows version: 10
I get the following errors trying to run a decompile:
Running the command given in the error in a cmd manually gives:
Interestingly, running the command without the --select-decode-only and --select-ranges options appears to start going through the process, I don't know if it's relevant without the options set though:
Can you please implement support for IDA 7.x? The readme states that it's not supported, yet. Here is the porting guide you may want to follow: https://www.hex-rays.com/products/ida/7.0/docs/api70_porting_guide.shtml
Thank you.
Right now, if users/developers want to use retdec-idaplugin
in local decompilation mode with retdec
, they need to either get the pre-compiled retdec
package, or build and install it themselves. Then whey need to configure retdec-idaplugin
in order to use local decompilation.
This could be made much easier - retdec-idaplugin
could take care of everything:
retdec
alongside retdec-idaplugin
.retdec-idaplugin
and retdec
.Investigate problems in these samples. solve them, and add regression tests: samples.zip(MALWARE!).
89442e72227b209b7fcbe467a6b202c1788b850bdfbb52fa22c7762a45b1737c
OutputDebugStringW(L"It was a joke about heroin, but now im going to sell heroin to your mother :P");
CreateMutexW(0, 0, L"Local\\Fabiansomware");
StrStrW(&ExistingFileName, L"winlogon.exe");
20AE07CC27965D330314776C16E8FAA3FA021AB7E4C6FFC86A3593AC4010BDFE.dat
:
WinMain, sub_4018E0, sub_401870
, etc.I tried to run the plugin on Mac. Plugin load seems okay but when I tried to ^D on a function, I only get the error:
Loading of output C file FAILED.
The log stops at [RetDec info] : Running the decompilation command ...
, and manually executing the printed command above works and produces the expected output file.
I've tried to add some debug code, and it seems that std::system()
call returns 0 immediately. I have tried to modify the shebang of retdec-decompiler.sh
to make sure that it's using current bash. I've tried to manually run a code snippet to test it but it successfully executed the decompiler script:
#include <cstdlib>
#include <string>
int main() {
std::string a = std::string("'/usr/local/bin/retdec-decompiler.sh' ..."); // omitted parameters here
std::system(a.c_str());
return 0;
}
https://pan.baidu.com/s/1z_qPUuPWJqVkrEwtYhSKPA Extraction: ugd4
I select a function, activate the plugin, I see on the console (linux-x86_64, idapro 7.2)
$ ida64
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
The GUI seems to be frozen, no refresh, the only option is to ctrl-c.
I have retdec-decompiler.py in the PATH; along with retdec-3.3 installed at usual places.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.