Reversing binaries sounds fun but overwhelming at first. I've messed around with Ghidra and IDA but struggle to make sense of compiler-generated assembly. Any advice on structuring the learning path? Should I focus purely on x86-64 first or jump into ARM stuff? Also, what's the deal with obfuscated code—any techniques to avoid getting lost? Looking for recommendations on exercises or CTFs that force practical reversing instead of just textbook theory.
Reverse Engineering: Where to start for a newbie?
👁️ 4 görüntüleme💬 3 cevap❤️ 0 beğeni
3 Cevap
Started out the same way back in 2019: Ghidra spat out ASCII-jumble that looked like ancient Sumerian, so I kept a notebook of every x86-64 instruction I met, scribbling what each opcode was doing and why the compiler had turned my simple C loops into weird stack shuffles. Wasted weeks jumping straight to ARM decompilation in IDA; turns out the compiler there loves to spill everything to the stack and unroll loops in ways I couldn’t follow without the x86 basics under my fingers first. Quit that detour after I finally debugged a mystery crash that turned out to be a 64-bit overflow hiding in a piece of assembly I’d ignored.
Obfuscated code—ah, the nightmare fuel. I once spent two days tracing a function that looked like a maze drawn by a caffeine-addled M. C. Escher; turns out it was just XOR encryption layered three times with keys baked into the binary’s .rodata. Learned to look for the usual red flags: weird constants that look like scrambled text, jumps that never hit, functions whose names are just junk strings in the string table. Started reversing its easier cousins—stuff from crackmes.one or the Microcorruption CTFs—before I could stomach the real obfuscator challenges.
I remember my first dive into reverse engineering—felt like trying to read a book where every page was written in a language I barely understood. Started with Ghidra like everyone else, but honestly, opening up a stripped binary felt like staring into the abyss. The worst part wasn't the complexity of assembly, it was realizing that without a solid grasp of how compilers *actually* work, you're just guessing what each instruction does. I spent way too long chasing ghosts in decompiled pseudocode before I realized I needed to stop treating assembly like magic and start treating it like a second language.
For learning structure, I’d say don’t jump straight into ARM unless you’re dealing with embedded systems. x86-64 is where most tutorials and resources stick (and it’s what you’ll see 90% of the time in CTFs). Pick up a decompiler, but *also* learn to read raw assembly—set a goal to understand 5 instructions a day until they just *click*. As for obfuscated code… ugh, that’s a whole other beast. I once wasted a week on a binary where the dev literally inserted NOP sleds and fake jumps everywhere. The trick isn’t avoiding getting lost—it’s learning to spot patterns. If you see a block of instructions that look like they’re doing nothing, it’s probably not. And for the love of all things binary, *always* start with known challenges (like those on crackmes.one) before jumping into wild obfuscated messes.
Guess I should start with the basics first—maybe disassemble a "Hello World" binary in Ghidra and trace how it works step by step?
Tartışmaya katılmak için giriş yap
Giriş Yap