Radare2: Support for external decompilers (retdec, snowman, ...)

Created on 15 May 2018  Â·  12Comments  Â·  Source: radareorg/radare2

9017 was closed, but what about the possibility of a more interactive decompiled view, at the very least with xref jumping and type/name editing for variables in the decompiled view?

Such a feature could probably be separated entirely into a plugin (including the mapping of r2 variables to variables in the decompiled view somehow) or implemented as some sort of standardized decompiler interface to be able to plug different decompilers into the same visual-mode module (also making it easier to integrate in the various GUI projects) using some sort of mark-up.

What would be the preferred approach?

enhancement refactor scripting

Most helpful comment

you should integrate a panel for pdc and then let the user decide which decompiler to use via the e cmd.pdc=radeco

All 12 comments

Sounds like a good proposal. Maybe we can add this in the cmd interface. And define some stantard commands to perform actions.

We will need a cursor for x,y to move around words and lines. This may save us from having to use the mouse sometimes. When we dont have any

We can expose this with a command and use it like ~... but for word selection in a scrolled buffer

Then we can ask for action and seek around

We probably need to define a metadata. Some standard outout of the decompiler to get the addr2line

Im thinking in following calls, xrefs, change variable names , rename functions

This would be a different visual mode, so it will require more work to be integrated in panels. Having extra views with this will be desirable so it seems like a dupe of visual and panels.. and we should think a better solution to reuse widgets

On 15 May 2018, at 19:28, Albin Eldstål-Damlin notifications@github.com wrote:

9017 was closed, but what about the possibility of a more interactive decompiled view, at the very least with xref jumping and type/name editing for variables in the decompiled view?

Such a feature could probably be separated entirely into a plugin (including the mapping of r2 variables to variables in the decompiled view somehow) or implemented as some sort of standardized decompiler interface to be able to plug different decompilers into the same visual-mode module (also making it easier to integrate in the various GUI projects) using some sort of mark-up.

What would be the preferred approach?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Maybe as an alternative view of the visual graph. Which makes more sense because it requires the function to be analyzed

On 15 May 2018, at 19:28, Albin Eldstål-Damlin notifications@github.com wrote:

9017 was closed, but what about the possibility of a more interactive decompiled view, at the very least with xref jumping and type/name editing for variables in the decompiled view?

Such a feature could probably be separated entirely into a plugin (including the mapping of r2 variables to variables in the decompiled view somehow) or implemented as some sort of standardized decompiler interface to be able to plug different decompilers into the same visual-mode module (also making it easier to integrate in the various GUI projects) using some sort of mark-up.

What would be the preferred approach?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

It is some kind a part of the radeco integration task. @kriw @sushant94 @chinmaydd @HMPerson1 @sivaramaaa may be interested in this.

retdec is already integrated, 2 years before it was opensourced. and there’s also support for the local one too. we use to have everything integrated in r2 way before IDA or binary ninja, but people is blind or something.

We are currently working with the retdec developers hand by hand to improve the integration requirements and add proper decompilers support to Cutter, the r2 UI.

Initial integration to export all that info from r2 into retdec shouldnt be more than one week, and having it in cutter to make the whole thing interactive with clicks and such will require a bit more of work. but i guess before the end of the year there should be something working in Cutter.

Feel free to jump into the telegram/irc channel if you are interested in contributing to this, we basically lack hands and sleep hours. but if you want to use retdec right now (without types and cutter integration) you can just install the plugin with r2pm.

Also, you may probably want to know the existence of r2dec, a decompiler written in js that runs on top of r2 and builts natively (no external js runtime required). which is heavily integrated with r2 and the results are usually really good, as well as decompilation time is pretty low compared to other alternatives. And it supports several architectures, avr, x86, arm, thumb, arm64, powerpc, wasm, sparc, mips…

r2 is improving the support for detecting local variables, types and such during this GSoC, so you’ll see many improvements in r2dec directly.

On 13 Jul 2018, at 19:51, 0xBEEEF notifications@github.com wrote:

Here is another question that follows. Wouldn't it be possible to integrate RetDec better into the application? As you know, it was published last December under Open Source. A few weeks ago the new IDA plugin was released. As a rule RetDec uses its own IL language (LLVM). As far as I understood it, however, it was tricked here with integration into IDA to somehow use the existing IL language including the locally created definitions (function bodies / structures / variables). Perhaps a similar functionality would be appreciated here. Maybe you should ask if they'll help you. Then two great products would be merged together!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/10102#issuecomment-404906153, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lmbBXbXb9ZSAE2Exya7fO-GMEX8oks5uGN4rgaJpZM4T_9vI.

@wargio @sushant94 @chinmaydd @kriw @HMPerson1 @Vane11ope @radare I just thought - what if we reuse visual panels mode for this? One visual panel (left ) will show the usual disasm, the second - the result of r2dec or radeco output?

I think we need to provide unified command syntax for editing decompiled names, arguments and variables, types. We can share it between both radeco and r2dec (and reuse in case of other decompiler engine).

you should integrate a panel for pdc and then let the user decide which decompiler to use via the e cmd.pdc=radeco

i think we can close this issue

Just wondering, has any of this been implemented?

All of them?

On 28 Dec 2018, at 09:48, Minexew notifications@github.com wrote:

Just wondering, has any of this been implemented?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

@minexew see packages from r2pm. Note though that for now support is very basic and can be improved, but requires code changes from decompiler side too.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

XVilka picture XVilka  Â·  6Comments

YugoCode picture YugoCode  Â·  3Comments

PaquitoRiviera picture PaquitoRiviera  Â·  7Comments

XVilka picture XVilka  Â·  7Comments

MariasStory picture MariasStory  Â·  6Comments