A lot of people think that reverse engineering has to do with taking prebuilt software, running a decompilation process over it, and trying to copy the original software for personal gain. That can be some of reverse engineering, but it isn't the bulk of it. Academic literature on reverse engineering actually has very little to do with that.
The reality is that most developers do some kind of reverse engineering all the time. Whenever we think to ourselves, "I wonder how/why the program did that?" we are asking a reverse engineering question. We are trying to figure out from a previously engineered system the reasons that it was written the way it was, and why it does what it does.
I think that this has become a lot more common place with the boom of Open Source Software and great tools like Eclipse. Personally, if I want to find out what a piece of code like StringBuilder.append() does, I'm just as likely to simply press F3 in Eclipse and go read the code as I am to go off and read the API documentation. If I want to understand how to use class X in my software, I'm just as likely to use Ctrl-Shift-G and search for references for how other people have done it, as I am to search through mailing lists or, again, go to the documentation.
These are all microcosms of reverse engineering, and we developers do them all the time. But there are still some pain-points, and things that could be improved. One big thing is that we have gotten used to using debuggers to set breakpoints and step through problem code. But what do you do if you don't know where the problem code is, and so you can't set a breakpoint? That's where some more advanced techniques can come in handy. I'll dedicate my next post to one possible technique in Eclipse.
---
*Personal point of interest: many people would have said here "That begs the question...". I just thought that I'd add an "educational" note about that, because it is something that kind of gets to me when I read it. I did a minor degree in philosophy, and begging the question is actually a logical fallacy in which a person tries to prove a proposition by making reference to the original assumptions. There is a common example that shows up when people try to market products:
1. The best products are the ones that most people buy.
2. How can you be sure that they are the best?
3. Because the most people have bought them, of course!
Step 3 assumes the axiom is statement 1, and so does not actually answer the question in statement 2. Statement 2 was questioning the validity of 1, and 3 tried to answer 2 by resorting to the assumption (1) which was in question (2). Hence begging the question.
So, in reality when people say "That begs the question", they really mean "That leads to the question". I just wanted to educate the masses.
I am not quite sure where you are going with this last educational comment. I think most people who uses that phrase simply means what you say it means anyway.
ReplyDeleteI would like to say that your little 3-step proof is completely correct, however - if your definition of 'best' is exactly what is described in step 3: That is sells the most. The reason is that best is a subjective term that can only be proven if you have agreed measurable terms.
As for your main topic I agree that things like decompiling code has very little to do with reverse engineering. Simply because you are not really doing what the term mean: doing an engineering task in reverse to figure out how it was done.
And on a pure "satisfaction by completing a challenge" level there is not really any comparison between decompiling some code and then finally "cracking the code" when you have been trying to reverse engineer something and you finally get it
Decompiling does cut down on the time spend tho ;)