Don't want to take the wind out of anyone's sails, but this program is hardly hard-to-hack. Bravo for getting to grips with ELF, assembly and reverse engineering. But this article represented just the first few steps on a long an intriguing road.<p>If it was hard-to-hack then I would expect (at least) the following:<p><pre><code> * Output messages can't be discovered using "strings"
* Program is self-encrypted
* Password isn't even stored, just hash result.
</code></pre>
The "hard-to-hack" program presented would take about 30 seconds using IDA[1].<p>[1] <a href="http://www.hex-rays.com/idapro/" rel="nofollow">http://www.hex-rays.com/idapro/</a><p>(And I consider myself an <i>amateur</i> at this kind of thing).
Thats brilliant. It reminds me of the size matters article I read a couple of years ago, the most difficult title to google too <a href="http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html" rel="nofollow">http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...</a>
Any chance someone who knows more assembly than me can explain how the symbol names for dlsym() are retrieved?<p>ie I would have expected to see 'ptrace', 'scanf' and 'printf' in the strings output, but they must be obfuscated in some way (otherwise I guess there's no point using the dlopen/dlsym trick at all.)<p>I only see one call to dlsym (at 8048506), so it seems to me the program is doing something tricky to build each symbol name string and then calling a routine there to dlsym() it.<p>That's about where my x86-fu fails me, though, and I remember I should be working on other things. :/
Interesting, but the objdump output is very primitive compared to more advanced disassemblers, which should be able to provide string cross-references etc in-line.