I don't know anything about reverse engineering but why can't you just change the IF in the decompiled C++? Why do you need to mess around with the assembly instructions?
Calling it "decompilation" is misleading. That term implies that you can get your compiled binary and turn it back into C++. No automated tool exists that allows you to do that - too much information is lost in the compilation process. Function names are one things that's mentioned, but the very structure of the program (which functions are in which classes, etc.) is lost. You could infer this based on your knowledge of how compilers usually work, and how developers usually develop but it's all guesswork.
Instead what we actually do is 'disassembly'. We just perform the minimal processing to get the human readable form of the assembly instructions that make up the binary. This is very hard to directly get you head round, so 'decompilation tools' are then all assistants that help the manual process of understanding the structure of the program. You can see a very basic example of that in the article where the author is looking for references to an address so they can see which functions reference the string.
The gold standard tool in the space is IDA Pro. You can see in these screenshots the visual tool it gives that allows you to group chunks of assembly together into functions and keep track of the linkages to codify the person's understanding as the process continues.
> Calling it "decompilation" is misleading. That term implies that you can get your compiled binary and turn it back into C++. No automated tool exists that allows you to do that
The article shows snippets of decompiled C++ code. No, nobody is claiming that it is the "original" code. But it is C++ code derived from the compiled binary. Decompilation.
Patching a few machine instructions in the compiled executable is easy; decompiling a complex program into C++ code that can be compiled back is amazingly complex.
It's like the difference between cleaning guano from your car with the localized application of a wet rag or by disassembling the car down to the last screw, putting all pieces in a giant dishwasher, replacing all parts that got damaged, and reassembling the car.
Well it's already been compiled. If the `if` is changed and the entire codebase is recompiled it might rearrange large sections of code, significantly changing the resulting binary. The patch will then be potentially quite complex.
So the resulting patch will be significantly smaller if only a few bytes need to be changed.
That would require you know which C++ compiler and which exact version the code was compiled with. Your decompiler would also need to be built for this specific version of the C++ compiler to allow for round tripping. After you have done that, the risk of the patch being unnecessarily large still exists and now you have to mess around with the source code hoping you find a way to rewrite it such that only one byte has changed. That's a lot of effort compared to just changing the instructions directly which for an inexperienced engineer merely requires frequent lookup of a reference sheet.
There is absolutely no need to do any of that, even in cases where you write a lot of new code yourself. 99% of the time it is enough to find the code location, insert a call to a DLL (which can be created in any language of your choice) you injected and be done with it.
I reverse engineered some games trying to fix them.
If they were made in ASM? Well, then it is easy, what you get from the decompiler is probably very close to what went into the compiler.
C? It gets harder, but decompilation to C is possible, you lose function names and whatnot but that is alright.
C++? Then you are 100% screwed, virtual functions, polymorphism, etc... it all becomes just a huge mess, if they used some common libraries it helps (STL, BOOST, etc...) but if they made a ton of custom classes that have virtual functions, polymorphism and composition at same time, then nothing can be done, you will get some ASM that almost looks like non-sense.
That depends on how much time you're willing to invest. The recently DMCA'd re3 project is a full decompilation of Grand Theft Auto 3 and Vice City, through a clever combination of all released versions (eg. the Android version leaked some symbols, Renderware signatures were somewhat recognizable on PC and PS2), pre-existing community knowledge (The mission script format had already been reversed which provided many clues by looking at its interpreter, many memory addresses were known by the modding community, etc.) and just a massive collective effort, it fully reversed the cpp game that is Grand Theft Auto 3 (and VC).
The decompiled code is just a best guess at what the assembly is doing, it's likely not completely correct or close to compilable, changing the asm is the easiest way to make changes.
Instead what we actually do is 'disassembly'. We just perform the minimal processing to get the human readable form of the assembly instructions that make up the binary. This is very hard to directly get you head round, so 'decompilation tools' are then all assistants that help the manual process of understanding the structure of the program. You can see a very basic example of that in the article where the author is looking for references to an address so they can see which functions reference the string.
The gold standard tool in the space is IDA Pro. You can see in these screenshots the visual tool it gives that allows you to group chunks of assembly together into functions and keep track of the linkages to codify the person's understanding as the process continues.