Show HN: Assembly to C code Decompiler (opens in new tab)

variable names are almost certainly a lost cause, but IDA pro is pretty good at recovering control flow, which could be turned into C constructs (didn't Dijkstra prove something about expressing any control flow using structured programming constructs?). You'd probably need a bunch of heuristics to tell the difference between a while loop and a for loop. More ambitious would be trying to un-inline functions, which would require liberal use of the de-optimizer and recognizing common sub-structures.

And with any non-trivial amount of optimization, it would lead to horridly looking HLL code. Compilation is a very "lossy" process when optimizations are turned on.

What do they think the people who want this are going to do if they can't buy it legally? I can't imagine it didn't cross their mind that those folks are likely to just...pirate it. Awesome "anti-piracy" measure.

There's some level of restriction, but copies still leak fairly often. Usually you're a few versions behind running pirated copies, rarely more than that.

Many people are however used to working with its output, not due to having purchased copies, but due to having pirated copies.

They certainly don't have a process where you can just "add to cart" on their website and hand them a couple thousand dollars. I'm not sure what extra checks they do through their sales team; maybe they're just trying to make sure that large businesses aren't buying up single-dev "Named" licenses and installing it across their organization, or maybe they're trying to verify that buyers are known security researchers, or something.

Pirated IDA+hex-rays is the industry standard.

My employer has a copy. I'm confident they acquired it legally.

> I don't like to reply to my own posts

Please do! That kind of discussion a big part of HN.

(Since this is your own work, we added "Show HN" to the title.)

I have a few technical questions, as well as a few about your intentions with the software.

How does it handle interrupt calls to the OS? It's not an issue for Windows (because it's all done through library calls, right?) But DOS int21 and Linux int80, for example?

With the x86 work, is the logic all built around protected mode? I've been using IDA to examine/document the assembly of a DOS game, so I'd be interested in the behavior if it's fed real mode code. Further (and tying in to my previous question), the game uses Borland overlays through int3f (it seeks in the binary itself and loads new sections of code into memory, while running, before jumping into the newly-retrieved code). Would that kind of thing be possible to handle automatically? IDA seems to be hard-coded to look for the offset+length tables that are used, and finds the function entry points that way.

More on the business side, you've got a way to request a quote, and the impression I get is that your aim is to run a decompilation business. Where does that leave the software itself? As a proprietary technology that lets you differentiate your business? Or is it your plan to sell the software, release binaries, release code, or some combination? My perspective is that of a hobbyist with a curiosity for reverse engineering and a (strictly non-commercial) project to apply it to, and I'm trying to figure out where this software fits into my world.

can yours be used to reverse engineering SNES games? Feed it the rom and have it split out c code?

Oh, this is written in Common Lisp? Very interesting!

Many instructions of machine code can be written as one C statement. There are some cases of things the cpu can do that are not standardized in C, like "arithmetic shift vs. logical shift." Maybe these instructions would be inlined.