GENESIS

Before I start sharing resources etc. I want to say — I've been into reverse engineering for a while now and the one thing I learned the hard way is that resources alone don't teach you anything. You can watch 100 hours of tutorials, bookmark every blog post, save every cheatsheet, and still not know how to pop a shell when it's in front of you.

The thing that actually made me better was suffering. Sitting with a challenge I had no idea how to solve, analyzing malware that I had zero understanding of what it does. Spending 5 hours on something that someone else solved in 30 minutes. Feeling stupid. Googling the same thing 15 different ways. Failing over and over until something finally clicks.

That's the process. It's not fun and nobody talks about it but that's literally how it should go. Not from courses. Not from resources. From pain.

So when I start sharing materials and challenges here, don't just save them. Actually sit down and struggle with them. If you're not confused and frustrated, you're not learning. I just remember that, sometimes in past (when the AI was not as useful as now), I would suffer over almost everything.

To give an example, one of the important things with malware analysis in VMs is being able to avoid VM detection. Yeah you can actually patch malware etc. It is possible but when malware is highly obfuscated, it takes a lot of time (there are still other ways). But anyways, so basically I had to patch QEMU's source code to hide QEMU keywords, and had to manually go through the whole hypervisor phantom patch for a day. (It is a longer story btw, I know I can apply the patch directly.) Yeah it took a lot of my time, but at the end I learnt a lot.

Don't wait for someone to push you to success. A lot of people just ask me "How can I learn XXX?", "What do you suggest me to do for future?" etc.

Thing is... I am not your guider or something. I am not God or a motivator... You can choose your own path and if you REALLY need my advice to continue improving — you are not actually into cybersec. Just do it and see the results. Failing doesn't mean the end.

As I can't really guess how well everyone knows reversing, I would like to basically go from basics and tell how I learnt things. (I will try to write everyday if possible.)

You can learn reversing for multiple purposes (for solving challenges, debugging apps, exploiting apps, analyzing malware etc.) but we can say one of the fundamental knowledge is being able to READ (not write) assembly. Yeah, you can actually be a professional assembly coder or something — but you will gain literally nothing from it lol.

I'm a book/documentation guy myself which makes it easier to find resources. Yeah, you might get basic knowledge about assembly through videos etc. (but I think it is so boring to watch someone instead of doing it yourself, just like playing games.) Also, the thing is, you will lack research ability if you rely on videos.

Resources

1. Intel Manual — this will be your God. Every time you have a question, just ask it and you will get your answer. Volume 2 has all instruction references.

• Intel Manual (PDF)

2. Programming from the Ground Up (GAS syntax) — to learn how to write in assembly, it is not essential to read this entire book. You might find better videos or better resources but the main thing is, you have to know "Why?" and "How?"

• Programming from Ground Up

3. NASM Documentation — if you want to write in NASM, you have to know its syntax etc. I personally used NASM to practice writing in assembly so it was important for me.

• NASM Documentation

NOTE: TO MAKE IT CLEAR, YOU DON'T ACTUALLY HAVE TO GO DEEP INTO THESE. I WOULD SAY JUST STOP READING WHEN YOU REALIZE YOU UNDERSTAND HOW THINGS WORK AND WHAT ASSEMBLY ACTUALLY IS. PRACTICE WITH PROGRAMMING IN ASSEMBLY BUT DON'T BE HARSH ON YOURSELF. The main thing is, when you reverse and don't know an instruction, you can just use the Intel manual to understand (or just use AI but I think you will not gain the ability to research, but choice is yours).

Last time, I talked about how I learned assembly, but being able to read instructions is actually the easiest part. With compiled binaries, interpreted languages are much easier to analyze — you don't need deep technical knowledge, just a bit of logic is usually enough to understand them (the only time-consuming part is deobfuscating the script).

The thing with binaries is that they can be compiled from many different languages, each with its own unique functions and behaviors. Some binaries are obfuscated in a way that makes them lowkey impossible to reverse. You'll run into C++, Rust, Go, or Delphi, and all of them have extra "stuff" that requires specialized research. You can't learn everything at once — it's impossible. I just wanted to mention that before I forget.

Now, another crucial step is understanding how the system actually works: the CPU, RAM, etc. I honestly learned these randomly over time rather than sitting down to study all day. The best way to learn is to just start analyzing binaries, but to make it simpler, you can read Chapters 1 and 3 of the Practical Reverse Engineering book:

• Practical Reverse Engineering

Linux Resources

• The Linux Programming Interface — Don't read it all; use it as a reference
• Syscall Table (Reference)
• ELF Format — You can actually read this one; it's not too long

Windows Resources

• Windows Internals Part 1 — Use for reference
• Windows Internals Part 2 — Use for reference

Debuggers & Decompilers

For debugging, I use pwndbg (and sometimes r2) on Linux, and x64dbg on Windows. You can use whatever you prefer; there are plenty of others like edb, IDA, etc.

For decompiling (changing from binary back to code), I use Ghidra, dnSpy, or jadx depending on the file type. IDA also supports decompiling if you prefer using that.

• GDB Documentation
• Pwndbg Cheatsheet
• Radare2 Book
• x64dbg Docs — not great but helps
• Ghidra
• IDA User Guide