The first programs were written in binary/hexadecimal, and only later did we invent coding languages to convert between human readable code and binary machine code.
So why can’t we just do the same thing in reverse? I hear a lot about devices from audio streaming to footware rendered useless by abandonware. Couldn’t a very smart person (or AI) just take the existing program and turn it into code?
It is not. idk who told you it was.
Disassembling an executable is trivial to do. Everything is open source if you can read assembly. Obfuscation be damned.
Well decompiling is only one step in the reverse engineering process. I would recommend taking a look at the Legend of Zelda: Ocarina of Time decompile projects. They reversed engineered the whole thing, which took years and was a team effort.
In the end they got perfectly readable source code, fully documented. And the most amazing thing is, when compiled with the right compiler and right flags, it recreates the original rom perfectly.
I would also recommend a YouTuber called Kaze. He’s been working on Mario 64 for years, re-writing large parts of the engine to get some pretty cool stuff going.
The hard part isn’t reading assembly. The hard part is figuring out why it’s doing what it’s doing with no comments or function names or anything useful to help.
This is like saying if you can read English you can understand an advanced math or physics paper written in English without having any knowledge or context of those subjects.
I’ve used a decompiler to peek at the source code of an app written in Visual Basic I wanted to recreate as a browser addon. It was mostly successful but some variable and function names were messed up.
Variable names, class names, package structure, method names, etc. won’t normally be maintained in the disassembled code. They are meaningless to the CPU, and just a series of memory addresses. In cases where you have method names being mentioned, it’s likely a syscall, and it’s calling a method from an existing library. I’m not familiar with VB, but at least in .Net and .Net Framework, this would be something like the System.Collections.Generic providing the implementation for List<string> and when .Sort() is called, it makes the syscall to that compiled .dll.
You could chuck it at an AI to reverse compile it into something readable.
Instead of just getting the down votes, I’ll explain why that wouldnt work.
- The AI itself cannot decompile it without the same tools I would use. The AI would then end up with the same starting spot I have.
- Current LLMs do not know how to interpret code logic, and would likely make mistakes in Syscalls, register addresses, and instructions.
- Assembly languages themselves have nothing further than instruction sets. I’m sure there are ways to organize it in the super rare case of actually writing assembly, but not to the effect of object oriented or functional programming.
Lastly, other comments have pointed out decompiled code is extremely expensive to analyze. The output from whatever we decompile would easily exceed the input limits for all existing LLMs.
Thanks. I was thinking that you could have an AI “looking over the shoulder” of a compiler, seeing what comes out for the code going in to it. Basically training it to spot sequences in compiled code in order to guess the instructions that compiled into that code.
We can and have done this, but there’s not much gain, which is why it’s mostly done by hobbyists to their favorite older software whose parent company went bust. It’s especially common for older games.
-
most software packages are ridiculously complicated. it’s not as simple as just running a decompiler and seeing code. It’s labor intensive, and loaded with bugs and errors, many of which you would never catch unless you already had in idea of what was supposed to be there.
-
many applications rely on external services/system packages that may or may not exist on your machine.
-
companies take steps to protect their application from it being reverse engineered, making it that much more difficult to actually pull off.
-
you don’t have access to the documentation/commenting that would be in the uncompiled code, turning a lot of the script into incomprehensible jibberish.
-
all the labor involved means it’s very likely to not pass the cost/benefit analysis. unless you’re able to add something to it; something the other guy doesn’t have… then you’re not going to be getting a substantial market share. It won’t be profitable.
-
Computer code is very complicated, so when humans write code we write in a way we can understand. We name functions and variables with names that make sense, and we put comments in the code so we can understand how it works.
Compliers don’t care about any of those things. Variable names are turned into numbers, and comments are ignored.
You can convert machine code back to source code, it will be missing all those human readable labels and explanations. You can recreate them, but its a major process. Reverse engineering is done sometimes, but there’s a reason is not common.
There’s also the issue of licensing. An important part of free and/or open source software is that you have permission to modify the source code. You probably don’t have a license to use the code if its closed source. There are ways to do this legally but it adds extra hurdles and inconvenience to an already major process.
Yes, and people do do it. It’s just incredibly difficult to do it even for relatively simple programs, and the more complex the program is, the more exponentially hard the reverse engineering will be.
The problem is not necessarily turning it into code, since many decompilers do it already for you nowadays. The issue is understanding what in the world the code is supposed to do. Normally, open source code would be commented and there would be documentation, so it’s easy to edit or build on the code. Decompiled code comes with no documentation or comments, and all the variable names are virtually illegible.
It’s sometimes easier to build something new than to fix what’s broken, and this would be one of those cases where it’s true
people do do it.
giggles under my breath
In addition to the other comments that explained it well… Back in the day, that process was easier in part because executable files had far fewer instructions.
It’s not. I believe lowlevellearning has a tutorial on tearing down binaries. If not him, john hammond does for sure. Both are on youtube. That skill set is usually employed in security research since it pays more than reverse engineering old software with problematic licensing and uncertain ownership.
