I found the odd mix of GNU/AT&T and Intel syntax a little disorienting --- especially all the '%', which the author starts out using in the text but then decides to just suddenly stop using halfway through.
The flowchart view is extremely useful, and from my experience of having taught an Asm class before, in which students were required to do both compilation and decompilation, creating such a graphical representation of the program flow really helps to clarify when going from C to Asm and vice-versa. Lacking software to do it automatically, printing out the code and drawing lines works reasonably well.
That "challenge" function should puzzle anyone who knows even the slightest bit of Asm --- not because of its purpose, but because of how it does it. Subtracting one number and then adding another, is entirely equivalent to adding their sum; so that could be simplified to:
call $+5
pop eax
sub eax, 5
sub eax, [eax-15]
ret
The "call $+5/pop" idiom for "where am I" is also used a lot in packers, so those who have such experience with unpacking will recognise it too. Look at enough Asm (particularly compiler output, but I doubt that example was generated by one) and you'll start to pick up on small inefficiencies/stupidities like this; it really tends to dampen your belief in how optimising compilers actually are in practice. ;-)
Eh. 2/5. Your sentence is quite comprehensible and doesn't answer the question for reasons completely unrelated to acronyms. ("an interface" and vague ideas about what it runs on don't tell you what something is)
Not as readable or semantically meaningful as the author's manually decompiled version, but pretty decent.
So if you think x86 assembly sounds really arcane, you should know that you're not strictly required to learn it to start experimenting with reverse engineering: you can start with a decompiler, which is all you need in most cases, and gradually learn how its output corresponds to assembly (which is still necessary to deal with in harder cases). Hex-Rays is the only decompiler I know that doesn't suck, and you are required to fork out high sums to get a legitimate copy of it… but it's easy enough to find a non-legitimate copy to start out with.
Personally, even though I have a fair amount of experience with reverse engineering at the assembly level, I find that using the decompiler lets me understand the "big picture" of a function's purpose much more quickly. Maybe I just need even more experience, and I'd be able to work just as fast from assembly… but I don't think so. I'd rather write my own decompiler to handle the stuff that Hex-Rays doesn't.
> ... you should know that you're not strictly required to learn it to start experimenting with reverse engineering ...
+1. The only assembly I ever learned was some 6502 assembly many, many years ago, and I didn't even learn that very well. But that didn't prevent me from later figuring out how to "crack" a bunch of BBS door games (with SoftICE for DOS) as a teenager. Hell, I'm not even a real programmer, and I was successful in bypassing the license protections on a (Linux) binary from Cisco a few years ago (although, ultimately, that was just NOP'ing out a "jump") using IDA Pro. That took me maybe 30 minutes to do. Thanks, +Fravia! [0]
I am very far from an expert on this stuff but I think that getting started is waaaay easier than people believe.
(N.B.: IDA Pro runs on Windows but even works on (Linux) ELF binaries.)
And its bloody expensive for hobbyist usage [1]. 5.0 is free for non-commercial use but lacks all the features from 6.x and 7.x including Linux and macOS port.
The flowchart view is extremely useful, and from my experience of having taught an Asm class before, in which students were required to do both compilation and decompilation, creating such a graphical representation of the program flow really helps to clarify when going from C to Asm and vice-versa. Lacking software to do it automatically, printing out the code and drawing lines works reasonably well.
That "challenge" function should puzzle anyone who knows even the slightest bit of Asm --- not because of its purpose, but because of how it does it. Subtracting one number and then adding another, is entirely equivalent to adding their sum; so that could be simplified to:
The "call $+5/pop" idiom for "where am I" is also used a lot in packers, so those who have such experience with unpacking will recognise it too. Look at enough Asm (particularly compiler output, but I doubt that example was generated by one) and you'll start to pick up on small inefficiencies/stupidities like this; it really tends to dampen your belief in how optimising compilers actually are in practice. ;-)