mahaloz

I would call any traditional decompiler deterministic, though these can rely on probabilistic models to infer how to undo these optimizations.

A talk I did on this at Reverse Con (clipped to the important part): https://youtu.be/VP29biKLoSw?t=891

Many of these decompilers can infer what optimizations occurred by hints/patterns that are left behind.

This can be fundamentally different at times from LLMs, which have shown a degradation on unique architectures. I still believe the best approach will be a mixed method. Get 80% of the way there with traditional methods, and take the last 20% (which is the hardest) home with LLMs.

Answered above, but the gist is people have tried: https://decompilation.wiki/fundamentals/neural-decompilation..., and yet general LLMs from Anthropic and OpenAI appear to match or beat all of these works :(

Interesting. A lot of data shows IDA Pro is significantly better than Ghidra: https://decbench.com/

Based on today's results, IDA Pro is ahead by 15 percentage points, which would mean, statistically, IDA Pro will recover perfect source code for 15% more functions than Ghidra on average.

Creator here! Since I saw some questions below, I'd like to clarify some things.

Kuna is originally Ghidra ported to Rust, but it has changed quite a bit since. The results shown in the screenshot on the site are not a feature in Ghidra, which includes the Switch layout and some of the variable simplification. It's from Ghidra, previously talked about here [1].

> It would be cool to see agentic interpretation of function and variable names.

On DecBench, which I also created last week, you can see just that for Codex and Claude when given only assembly [2]. They dominate, but also have some significant recall problems.

> Why not train an LLM to be a decompiler instead of make one

Over the last two decades, this has been attempted _many_ times [3]. To date, there has been no successful project/paper that can compete with traditional decompilers on fundamental metrics. I speculate this is due to their inability to abstract the many-to-one mapping of optimization to code. This can change, but I desired to take a different approach.

If frontier labs continue to get better, they will become the de facto decompilation users. Why not get LLMs to help LLMs? Design a core decompiler that helps them more than others :).

[1]: https://www.youtube.com/watch?v=VP29biKLoSw

[2]: https://decbench.com/leaderboard/?dataset=sample-set

[3]: https://decompilation.wiki/fundamentals/neural-decompilation...

Thoughts and reasons behind developing a decompiler by learning from other decompilers.

Since we’re talking about decompilers, might as well mention the community around the research area: http://decompilation.wiki/

As well as the research history (slated to be updated in a few days): https://mahaloz.re/dec-progress-2024

A summary of our human study at NDSS 2026 on humans (of different skill levels) using LLMs to reverse-engineer.

Paper link: https://www.zionbasque.com/files/papers/dec-synergy-study.pd... Challenges code: https://github.com/mahaloz/dec-synergy-study

I love this use case! Do you have any public links acknowledging/mentioning/showing this use case? Including it in the Applications portion of the Dec Wiki would be great.

I agree with many other sentiments here that if it can replace decompilers, then surely it can replace compilers... which feels unlikely soon. So far, I've seen four end-to-end binary-to-code AI approaches, and none have had convincing results. Even those that crawled all of GitHub continue to have issues of making fake code, not understanding math, omitting portions of code, and (a personal irritant for me) being unable to map what address a line of decompilation came from.

However, I also acknowledge that AI can solve many pattern-based problems well. I think a considerable value can be extracted from AI by focusing in on micro decisions in the decompiler process, like variable types, as recent work has.

Welp, that's a really sad typo... I've made a post-publication edit to the article now, but my shame is immortalized in Git: https://github.com/mahaloz/mahaloz.re/commit/90b760f53ef51b7...

I like using it for library function comments, variable name recovery, and sometimes types. The comments are usually hit or miss, but I find the variable names to be a bit better than auto-generated ones. I implement most of this in my decompiler plugin: https://github.com/mahaloz/DAILA; check it out if you are interested :).

Would you be able to specify what section? Some sections are more sparse than others, but each page should at least have a few citations. In general, there is about 80+ decompilation projects (decompilers) referenced in the wiki.

As others have said, the standardization of metrics is still something debated, but at the same time, this space has been explored by various top-tier papers that your paper did not cite. For example, DREAM [1], evaluated using the classic metric of goto-emittence. Rev.ng [2], evaluated using Cyclomatic Complexity and gotos. SAILR [3], evaluated using the previous metrics and a Graph Edit Distance score for the structure of the code.

I feel that without a justification for dropping previously established metrics by the peer review process, you weaken your new metrics. However, I still think this is an interesting paper. It just could be made more legit by thoroughly reading/citing previous work in the area and building an argument for why you may go against it.

[1]: https://net.cs.uni-bonn.de/fileadmin/ag/martini/Staff/yakdan... [2]: https://rev.ng/downloads/asiaccs-2020-paper.pdf [3]: https://www.usenix.org/system/files/sec23winter-prepub-301-b...

It’s always cool to see different approaches in this area, but I worry its benchmarks are meaningless without a comparison of non-AI based approaches (like IDA Pro). It would be interesting to see how this model holds up on metrics from previous papers in security.

Oh my gosh, that is really bad. That's my bad. The code snippet has been corrected to have the correct variable names. Thanks for the find :)

That's awesome! That's exactly how modern decompilers deal with a special type of goto occurrence. They reduce gotos (or completely eliminate them) by introducing a `while(true)` loop, followed by corresponding `continue` and `breaks`... we all, of course, know that `while(true)` did not exist in the source, but it's a nice hack!

We even do this in the angr decompiler, found here: https://github.com/angr/angr/blob/8e48d001e18a913ecd4ed2e995...

For a while now I've worked as the founder and lead of the BinSync team to make a plugin suite that unifies the many decompilers we use today.

There is still much more to do, but it's in a state that is usable. Try it out :). I would also love feedback. As a PhD student, this is my first larger design of a software architecture.

Well, uh, no one is working on it yet hehe. When I'm aware someone is working on something, I try to have them PR as soon as possible so a running Draft PR show's everyone it's locked. If you don't seen a draft PR, it means its up for grabs :). Honored to have anyone with extra time help out <3.

A extremely trivial command injection that existed in Netgear routers up until last December. Shown to be WAN-side exploitable with a attacker-controlled website.

Ayyy I know this article is about the actual thesis, but it’s super cool to see Hawaiian on a top article title here. Although I don’t believe it was coined by a Native Hawaiian, it’s still fun to see Hawaiian make its way into science!

Wow this was actually just the code reference I was looking for to extend decomp2dbg into Ghidra. I had seen ida2dwarf before, but not this sleek Python approach to it. It does still seem though that you need to run this script after every time you change something in Ghidra, which is less than ideal for me. With this, I think it will be possible now for seamless Ghidra support.

Ty ty, I'll be sure to give credit where credit is due. Ofc Robert Xiao worked on this, lol.

Ty for the shoutout <3