Hacker News Reader

Comment by ma2rten | Hacker News Reader

I've long had this idea to build a decompiler (a program that maps binaries back to source code) using machine learning. The problem in decompilation is that you loose information when you compile source code. Machine learning could help even recover things like most likely variable names. There is also tons of training data that can be easily generated.

View on HN

> recover things like most likely variable names

This is already being researched! See http://jsnice.org/ for recovering variable names from minified javascript.

I remember testing it by coding a binary search with single letter variable names. It managed to rename them to the more canonical "lo"/"mid"/"hi" names just by recognizing that the code pattern is typically used for a binary search.

I was just about to post a link! Very interesting project, and the folks behind jsnice are super cool, too.

Neural nets can't magically create information that's not there; all it can do is combine the data in the binary with its learned 'experience', and make what amounts to educated guesses about what the decompiled code might be. That has value, obviously, but it's not 'recovering' anything, really, it's 'assuming'.

Or possibly improving upon. A variable being badly named isn't rare.

yep that with a auto-spell checker would make a darn good tool! something like MS word spell checker that goes suggestion-by-suggestion and clicking yes/no/manual for var names :)

Cast it as a reinforcement learning problem: you produce a candidate decompilation, try to compile it, and score it based on the similarity to the initial binary.

I've had the same idea, but instead it could "decompile" spaghetti code with horrible variable names into something readable.

It seems like a reasonable (almost believable even) first stage to software finally coming to eat the jobs of its creators.

Our jobs will just move an abstraction level higher. We used to have to worry about registers and stuff, then we automated that. We used to worry about memory, then we automated that. We used to worry about CPU stuff, then we automated that for most applocations.

Eventually we're going to become technical PMs. As long as there will be fuzzy unclear problem descriptions, there will be jobs for people who can codify and standardize processes.

"First they came for the assembly programmers..."

"And then they ate the universe, and there was no-one left to care."

Plenty of paperclips, though.

> Our jobs will just move an abstraction level higher.

This seems a little optimistic in terms of the average software developer's ability to think at higher and higher levels of abstraction.

It's not an easy skill, and not that many people are very strong in it.

Just look at how programmers today react to mathematical paradigms and explanations (category theory, anyone) in any practical setting.

You say that, but I've written software unrolled loops in assembler on ARM because that's what we needed.

I'd really appreciate something that takes my hacked-together code and cleans it up and makes it presentable. That's usually the second phase of the job anyway, which could be automated.

It would be interesting to automatically generate the training data and feed it to the ML module in real time.

You could hard-code an interactive agent that periodically peeked and coerced the input (between itself and the ML function). This way the ML module is coercible.

It would even be more cool if the ML function itself learned the interactive agent function as part of itself.

In a completely different approach, a neural net was trained on input-output pairs and stack traces of a program. The neural net learned the algorithm. The advantage is that all algorithms could be "neuralized".

How is that an advantage?

The neuralized algorithms become really hard to debug? I think of it as a magicians curtain.

There's been dozens of such projects at this point. http://apk-deguard.com/ is one example.

Reply on news.ycombinator.com