angr VS decompiler-explorer

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...

One would hope browser and OS vendors would use AI to remediate vulnerabilities but vast majority of software vendors won't ever use it.

Also, automated vulnerability finding is very much real and already used today. This isn't something that has just become viable via LLMs, but I guess LLMs can enhance it:

https://github.com/angr/angr

Check out angr [1], a symbolic execution engine, and claripy [2], its frontend to SMT solvers like z3.

[1] https://angr.io

[2] https://api.angr.io/claripy.html

BAP (https://github.com/binaryanalysisplatform/bap), angr (https://angr.io/) and others already do what you're asking for as more purpose-built solutions for dynamic analysis. Angr specifically in python.

As /u/hkei noted, it's actually quite difficult to do in general, and usually requires some kind of heuristic. For example, see https://github.com/dyninst/dyninst/blob/v12.1.0/dyninstAPI/src/image.C#L476. Full disclosure, I am a Dyninst developer. There is also the python-based angr that might be more amenable to a one-off solution.

I think there's a lot of promise in automation that's been spun off from the CTF community. Angr and Binary Ninja are both very much spinoffs from contest hacking, and are pretty great for helping a skilled hacker find flaws in software.

angr - Platform-agnostic binary analysis framework.

angr uses z3.

https://github.com/angr/angr

Supposedly, the DoD has used angr for some use cases.

Try using angr to automate bug finding

Can I just say, thanks to the person who posted this for waiting until this week to do so. (Side note: I suspect it was due to the recent coverage from C++ Weekly which is a great resource: https://www.youtube.com/watch?v=h3F0Fw0R7ME)

As recently as last week we had some horrible performance problems but it looks like the queue (https://dogbolt.org/queue) is mostly still fine! Other than the long pole of a few of the decompilers being backed up, things are humming along quite smoothly! Josh + Glenn have done some great work on it! (https://github.com/decompiler-explorer/decompiler-explorer/c...)

(dogbolt.org, not .com by the way.)

Also check out this comparison tool https://dogbolt.org/ (https://github.com/decompiler-explorer/decompiler-explorer) - it's a clear illustration that tool effectiveness is highly dependent on the specific binary input and task complexity

The c++-looking code you see is rebuild from the disasm, e.g for clarity, it's supposed to make the low level code more readable, so it does not mean anything about the language. (aside: several other product do that, see https://dogbolt.org/)