What does decompilation do?
RetroGaming
Vintage gaming community.
Rules:
- Be kind.
- No spam, AI slop, or soliciting for money.
- No racism or other bigotry allowed.
- Obviously nothing illegal.
If you see these please report them.
Unless it means something else in this context, decompilation is reversing compilation process.
Basically taking the game and turning it back to source code. With source code it would be easy to fix some issues (if there are any), see how developers implemented certain things, and also be able to run the game on hardware that it never was running on before.
Or patch the game to be run without drm...why? cough i don't know
Rebuild on PC or native to most anything if you have the gumption to do it.
It's literally the process of turning the executable back into actual code (albeit usually much less readable than the original code, since symbols are usually stripped from release builds, so the original variables and functions names are lost), so it can do much more than that.
Once you've fully decompiled something and understand the resulting code, or even some parts of it, you can basically edit the original source code.
Anyone made a good video on how decompilation works?
I don't know.
The gist is... When you write a program/game/... You write source code and then compile it - that means translating the source code into machine readable code. While certain things do usually get lost in this process (e.g. function names, variable names, etc.) you can see the resulting machine code and make a valid assumption about how the original code looked like. This is not a 1:1 reconstruction, but will yield code that should compile to the (basically) same result as the original game.
If you hit a Jackpot, you find a version of the program/game that was used for testing. Those often contain many pieces of information that would otherwise be stripped from the end result (e.g. aforementioned variable names, function names and so on). If not, it's a puzzle solved with guess work and experience.
If you know some specifics about the game (which language was it written in, what compiler was used in which version,...) you can get some better results, as you can take patterns in the machine code and translate them back into what the original code was probably looking like based on the tools used.
In the end it's sadly almost everytime still a manual process in which you look at the resulting source code, make some educated guesses based on patterns that are usually used when programming and specific functions that are probably contained in a game and then check those assumptions by changing the code and see if your changes affect the part of the program you thought you were dealing with.
Say you assume a specific variable/value is the maximum walking speed of the character. Then you change it and try to play the game and see if you can walk faster now. If so, label this value accordingly and go on to the next unknown piece of the puzzle.