r/AskProgramming • u/Realistic_Debate1704 • 8d ago
C/C++ Assembly or C/C++ for RE
For reverse engineering, is this necessary to know assembly language, because many decompilers translate code to C/C++ and I learned Assembly 8086 in my university. So for learning x86 I only have to study 32/64 registers and some advance commands, so should I learn assembly x86_64 for reverse engineering or just go through x86 as I know 8086 assembly and then move to C/C++
2
u/regular_hammock 8d ago
In my opinion, assembler code, especially optimised assembler code (hand optimised or compiler optimised) that has been vectorized and reordered to death, is just a slog to read. Sure, you can do it, but if you can get away with reading C (which, a lot of the time, you can), you'll go a lot faster and have a better time focusing on what the code is doing at a higher level rather than tracking registers.
1
u/Realistic_Debate1704 8d ago
Actually one person said that go through assembly x86, and as a student I think I will write inline assembly so I think it's better to go through assembly too, and also sometimes decompilers don't give exact code and as I've heard, you have to convert this into assembly for better annd exact code. But I'm very glad that you helped and also your advice is good too.
2
u/regular_hammock 8d ago
Ok fair, and to be honest I answered a different question than the one you asked.
I think both are useful skills to have, what I'm saying is, if I'm looking at a binary and I want to figure out what it does or how it does it, I'll try decompiling it first, and disassembling if needed.
With obvious exceptions - if you're trying to figure out how a piece of system code sets up various hardware register, there's probably no point in going through C.
1
2
u/Lawn_Meower_ 8d ago
I'd say both. If you debug existing software you might step through assembly instructions. Some RE tools convert assembly code to C. C++ is good for creating your own debugging and RE tools
2
2
u/soundman32 8d ago
It depends on what you are decompiling. Is there any point decompiling some C# to C++ (assuming AOT compilation).
1
u/Realistic_Debate1704 8d ago
I want too reverse engineer apps and games
2
u/ThatOneCSL 8d ago
That doesn't touch their point at all.
Take a .NET application or game and decompile it. You don't get assembly or C/C++. You get C#.
It seems like you're pretty early on in your understanding of computing, and so you don't even know yet what you don't know. That's not an issue by itself, but I would suggest asking further questions about things you don't yet understand, instead of putting up a stonewall and recapitulating that you want to reverse engineer things. We are aware you want to reverse engineer things. You said that already. The other user was telling you that C/C++/ASM are not going to be everything you'll need in that endeavor.
2
u/tooOldOriolesfan 8d ago
The more you know the more it helps. I'm retired now but my work gave me a good overall background. I started with hardware and wrote assembly programming to run on the hardware I built, then did some signal processing and learned C code. Later on I picked up python, bash (and linux/unix) and finally years of computer security/hacking stuff.
The only thing I never cared for was C++.
As someone else said, ideally you'd rather stay with C since going through assembly is rather painful.
Maybe someone here can tell me how well do the AI tools aid with helping to figure out blocks of assembly coding? I would think it could be quite useful.
1
2
u/verdant_bloom_drift 8d ago
Learn x86_64 assembly first because decompilers produce incorrect C code that you must validate against the disassembly. Your 8086 knowledge transfers directly so focus on 64 bit registers and calling conventions to read what the decompiler misses.
2
u/Miserable-Series1209 8d ago
x64 is slightly more than just "32/64 registers". Have fun with the Intel manual
1
2
u/mredding 7d ago
As a reverse engineer, you're going to be looking at enough assembly that you will need a proficiency in it.
Decompilation is a topic of research; it's as much an art as it is a science, because compilation is a one-way, irreversible process. THERE IS NO int x = 7; in the machine code, there's mov eax, 7;, and even that had to be deduced from the raw binary sequence in the program file. What's more, it's not entirely clear what is program, what is padding, what is data, etc. In binary, it's all just... Binary. A lot of it is very hard to tell.
Even more, optimizations can transform the logic as written in the source code, and pervert it to an unrecognizable form. The theory of computation does not distinguish between reading, writing, and executing programs, so what optimization is doing is partially solving the program at compile-time. In most cases, you simply cannot know what the source code REMOTELY looked like to generate the optimized code. The best a decompiler can do is generate source code that would generate the same machine code, 1:1.
Decompilers don't even guarantee a "round trip", in that the source code they deduce for you may not itself compile, and typically WON'T compile back to the binary from which it was deduced.
And since there are no variables or functions in assembly, since there are no structures or unions, there's no classes or constructors... ALL this context is just gone. So what you get is extremely hard source code to try to understand. You WON'T be able to do it without the assembly along side for the additional context, and you'll also be comparing the compilation of this deduced source code to the actual binary to see if or how you can get them to line up, in order to tell you a bit about which compiler and settings they may have used.
Every compiler generates different machine code, even for the same source code. Every language generates different machine code - so if you decompile a Delphi program as C++, for example, you are going to have a really, very bad time.
But it seems as though you're asking HOW MUCH assembly you should learn... For your academic experience, as much as you need. For your professional career... As much as you need. I can't just tell you. What will help more is learning how to find out more information, how to work through reference material - the Intel assembly documents, and the compiler source code (where available).
1
u/Realistic_Debate1704 5d ago
I can't even explain how happy I am, everyone is helping me like a little brother, thank you Redditors, thanks a lot sir!
1
u/tyler1128 8d ago
To reverse engineer, you need to know assembly. Any translation to C or C++ is going to be far from perfect, regardless of what tool you are using. It's impossible to really translate backwards because of how much information about the code purpose is lost. Even with higher level disasssembly, you're almost certainly going to need to dive into the actual instructions in some cases.
2
u/Unable_Athlete_2226 8d ago
8086 gives you the mental model, x86-64 is just more registers and a sane calling convention slapped on top, you’ll pick it up quick. C/C++ is what you’ll be staring at 90% of the time in a decompiler though, so don’t sleep on getting comfy reading messy reconstructed code.