Decompile to C

[plafosse]

As an additional layer on top of HLIL we could translate directly to C.

[D0ntPanic]

For those that prefer a more C like syntax for decompilation, a new option has been added to surround scopes in HLIL with { and }. This does not affect the syntax of the individual HLIL instructions in any way. Added in build 2651.

A full C syntax renderer will be added at a later time.

[ccarpenter04]

I definitely like the added option regarding the brackets and would like to see a few a few additional similar options be added in time as well. I don't understand the benefit of building a C layer on top of the HLIL though unless it's just for visualization purposes, could someone expand on the benefits it would offer?

[plafosse]

There are some I would consider minor benefits:

• Ease of recompilation - people frequently want to recompile the code they see, right now thats difficult.
• Ease of understanding - Even though C syntax is arguably worse to read its something many people are familiar with. Some one might not understand that uint32_t var_8 = rax_1.d in HLIL is the same as uint32_t var_8 = (uint32_t)rax_1;

Why would we consider this? There are a few reasons.

• Marketing - Some people complain that Binary Ninja doesn't have a "real" decompiler. (I'd argue we have something better)
• Its easy - I'm pretty sure if Rusty started this task it would take him about a week to get done.

[ccarpenter04]

1. Good point but since it's a renderer then couldn't that be let handled by the community?
2. Another fair point however what if I wanted to have a Kotlin/Native rendering instead of a C rendering. Would you guys consider writing an exposed rendering API so that people who are more familiar with particular languages could write a rendering object that is more familiar to them?
3. I assumed marketing had a big part to do with it, being able to show more than just C style renderings of the HLIL would be beneficial for those with more experience reading, say golang or some such.
4. I'm sure he'd write a nice community API and it would get rid of a lot of complaints in the future as well from people requesting other languages be used to represent the HLIL.

[plafosse]

1. Yes it could be left to the community, but I'd rather have it built into the product. Though for marketing purposes it doesn't have the same impact as first party support.
2. The rendering API is already all exposed. Its honestly really easy to add another view. Take a look at the TokenizedTextView
3. Yes we intend to be able to render HLIL as multiple different High level languages some of those could take significant effort though.
4. There is already a plugin which could be used as a starting point, you just have to iterate HLIL rather than MLIL linear_mlil.py

[ccarpenter04]

1. Understood, I hope you guys continue to invest time in the current renderer since it's finally grown on me some. I was more thinking you would write it and provide first party support but open source it.
2. Oh wow, I'm so used to seeing the term linear disassembly in the UI that I didn't piece it together.
3. I personally don't have any request, I was more just trying to back up the reasonings I think a public API would be good. I actually think developing even more in house would take away the time that would otherwise be spent polishing other aspects. I'm sure your team discussed it and decided it was worth it though.
4. I'll take a look shortly, thanks!

[psifertex]

I will say in general we do love hearing feedback like this. Sometimes it's hard to know what will or won't be used and while I think we'll probably still pursue this based on it being one of the more common "papercuts" for some people, hearing about features you /don't/ want (in exchange for others with time for development being a finite resource!) is very helpful, thanks. :-)