Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The rev.ng decompiler goes open source

rev.ng

Post reply on HN
Print view View original

11–20 of 63 posts

Re: The rev.ng decompiler goes open source

#11

Post by vient »

dvzk wrote: post #8
Fnoord wrote: post #2

Price model: > Very briefly: > The rev.ng framework is fully open source. You can decompile anything you want from the CLI. > The UI will be available in the following forms: > free to use in the cloud for public projects; > available through a subscription in the cloud for private projects; > available at a cost as a fully standalone, fully offline application. In comparison, Hopper costs 100 USD with one year of up…

Decompilation is often the least important (and least reliable) part of IDA/Ghidra, so comparing the two is unfair. That said, the scene is perpetually starved for good C decompilers, so more attempts are always exciting.

Huh, for me as a malware analyst previously and a reverse engineer in general, decompilation is the most important part of such tools. It's all about speed, pseudo-C of some kind lets you roughly understand what's going on in a function in seconds. I guess you can become pretty fast with assembly too, but C is just a lot more dense.

Regarding reliability, I would say that Hex-Rays is pretty reliable (at least for x86) if you know its limitations, like throwing away all code in catch blocks. Usually wrong decompilation is caused by either wrong section permissions, or wrong function signature, both of them can be fixed. It can have bad time when stack frame size goes "negative" or some complex dynamic stack array logic is involved, which are usually signs of obfuscation anyway.

It was less reliable 10 years ago though.. Also even now hex-rays weirdly does not support some simple instructions like movbe.

Re: The rev.ng decompiler goes open source

#12

Post by 8organicbits »

felipefar wrote: post #6
Fnoord wrote: post #2

Price model: > Very briefly: > The rev.ng framework is fully open source. You can decompile anything you want from the CLI. > The UI will be available in the following forms: > free to use in the cloud for public projects; > available through a subscription in the cloud for private projects; > available at a cost as a fully standalone, fully offline application. In comparison, Hopper costs 100 USD with one year of up…

I really like licensing models of one-time payments with a pre-defined duration of updates. But I wonder how they enforce it while not making internet access a requirement for the app.

I've been planning to use a non-enforcement model for a future project. Some users will always pay, because of corporate policy or ethics. Some will never pay and will reverse engineer out any software license checks. Asking the user if they have a license keeps the honest ones honest and permits ad-hoc free trials, emergency use, and other reasonable "unlicensed use".

Re: The rev.ng decompiler goes open source

#13

Post by londons_explore »

Idea: automatically name variables and members of structs based on how code interacts with them.

Eg. The next pointer in a linked list should be easy to identify as 'next'.

That would be done by downloading all of GitHub, then seeing what variables in GitHub code have the most similar layouts and interactions, and then if the confidence is high enough, using those names.

Re: The rev.ng decompiler goes open source

#14

Post by aleclm »

albertzeyer wrote: post #5

Checking the team about: https://rev.ng/about And looking at the code contributions: https://github.com/revng/revng/graphs/contributors Isn't it a bit weird that the CEO (aleclearmind) has most commits, even much more than the CTO (pfez)? I often hear the complaints from other CEOs that they don't really find any time anymore to code... Even the CTO usually is more on the managing side and less active in actual codin…

The CTO mostly works on the backend of the decompiler, revng-c, which we just released:

https://github.com/revng/revng-c/commits/develop/

Eventually we'll merge the two repos.

Also, I develop stuff every day. For some reason GitHub is not picking up my user correctly.

> Anyway, if this works, then I guess it's a lot of fun for them.

It is!

Re: The rev.ng decompiler goes open source

#15

Post by qweqwe14 »

londons_explore wrote: post #13

Idea: automatically name variables and members of structs based on how code interacts with them. Eg. The next pointer in a linked list should be easy to identify as 'next'. That would be done by downloading all of GitHub, then seeing what variables in GitHub code have the most similar layouts and interactions, and then if the confidence is high enough, using those names.

Sort of like GitHub Copilot but for reversing?

Re: The rev.ng decompiler goes open source

#16

Post by aleclm »

nextos wrote: post #3

A cool company fueled by one of the best PLT books out there: https://link.springer.com/book/10.1007/978-3-662-03811-6 "He also met a partner in crime, Pietro. Romantically enough, he met him thanks to a book which will turn out to be foundational for company." https://rev.ng/about Congrats on the launch.

About the book, here's the full story: I was getting into compilers, but I was really struggling with the theory, the most famous books weren't doing it for me, and I felt really down.

Then I find this book, which seems very dense, but clear. So I ask my advisor if I could buy it and goes like "well, first check out the university library". I check it out and there's a copy, but... it's taken.

Working in the only group that was doing research on compilers I'm like "who dares do compilers stuff out of our group!?".

I go to the library:

Me: who has the book?

Library guy: can't tell you, privacy reasons.

Me: what's the third letter of its surname?

Library guy: Z

Me: what's the second letter of its name?

Library: I

Me: thanks.

I go here: https://www.deib.polimi.it/ita/personale-lista-alfabetica I found him.

Fast forward, we become friends and we start the company together.

> Congrats on the launch.

Thanks! It was a lot of work.

Re: The rev.ng decompiler goes open source

#17

Post by aleclm »

londons_explore wrote: post #13

Idea: automatically name variables and members of structs based on how code interacts with them. Eg. The next pointer in a linked list should be easy to identify as 'next'. That would be done by downloading all of GitHub, then seeing what variables in GitHub code have the most similar layouts and interactions, and then if the confidence is high enough, using those names.

In the past we were thinking to do something like this by hand. For instance, we detect induction variables, we could rename them into `i`.

However, nowadays, it seems pretty obvious that the right way to do this things is using LLMs.

This said, at this stage, we see ourselves as people building robust infrastructure. Once the infrastructure is there, using some off the shelf model to rename things or add comments is relatively easy.

Basically: we do the hard decompilation work that needs 100% accuracy, and then we can adopt LLMs for things that are OK to be approximate such as names, comments and the like.

Anyway, writing a script that renames stuff is pretty easy. Check out the docs: https://docs.rev.ng/user-manual/model-tutorial/

Re: The rev.ng decompiler goes open source

#18

Post by userbinator »

8organicbits wrote: post #12
felipefar wrote: post #6

Earlier quoted context omitted.

I really like licensing models of one-time payments with a pre-defined duration of updates. But I wonder how they enforce it while not making internet access a requirement for the app.

I've been planning to use a non-enforcement model for a future project. Some users will always pay, because of corporate policy or ethics. Some will never pay and will reverse engineer out any software license checks. Asking the user if they have a license keeps the honest ones honest and permits ad-hoc free trials, emergency use, and other reasonable "unlicensed use".

Some will never pay and will reverse engineer out any software license checks.

For a long time (and might still be; not paying much attention anymore), it was a "rite of passage" in the scene to crack IDA... using itself.

Re: The rev.ng decompiler goes open source

#19

Post by 19h »

londons_explore wrote: post #13

Idea: automatically name variables and members of structs based on how code interacts with them. Eg. The next pointer in a linked list should be easy to identify as 'next'. That would be done by downloading all of GitHub, then seeing what variables in GitHub code have the most similar layouts and interactions, and then if the confidence is high enough, using those names.

Sounds like sidekick for binary ninja
Post reply on HN