15

I have some innocent/beginner questions:

  • What is reverse engineering good for?
  • As a programmer, should I learn the art of reverse engineering?
  • What are the benefits to a programmer who is experienced with it?
Jon Purdy
  • 20,437
  • 7
  • 63
  • 95
socksocket
  • 269
  • 3
  • 7
  • 5
    Is this question solely about the [disassembly](http://en.wikipedia.org/wiki/Reverse_engineering#Reverse_engineering_of_software) type of reverse engineering, or the others as well? (since "assembly" and "low-level" are in the tags..) – Izkata Aug 15 '12 at 18:13

8 Answers8

25

I like Falcon's answer, but I'd like to add that on some old boring business application world reverse engineering can get you out of some nasty troubles.

At work we do it a lot when doing data integration with a 3rd party system that does not have any new maintenance, so we can know where it should or should not break.

We also use reverse engineer to check code quality (with certain constraints, of course) on 3rd party components we buy, if the source code is not included.

My real point is: reverse engineering is not tied to a single technology or language, but is a process where you learn the internals of a "black box". If you have code you depend on, but you don't or can't trust, you should definitely take a peek under the hood and see what that code is doing.

Community
  • 1
Machado
  • 4,090
  • 3
  • 25
  • 37
  • Heck, we even look into SQL stored procedures of 3rd party systems we rent just to check if they're filling our requirements correctly sometimes. – Machado Aug 15 '12 at 18:36
  • 3
    +1. Even a big-selling software product from a big company can be a bit of a black box at times, what with inadquate, out-of-date, just-plain-wrong, sometimes nonexistent on-line documentation and such. – RalphChapin Aug 15 '12 at 18:39
13

What is reverse engineering is good for?

Reverse Engineering is mainly good for cracking and hacking (remove serial number protection or password prompts), but also for understanding viruses or miracles that other softwares can perform. Sometimes it is a useful skill to have in order to find bugs in programs that you haven't got the source for and to patch them.

As a programmer, should I learn the art of reverse engineering?

Yes, try to learn assembler and to use a decent debugger. It will make you a better developer by understanding things on lower levels, that are closer to the metal.

What will be the benefits of a programmer who is well-experienced with reverse engineering?

You'll be a good hacker/cracker. You could work for other anti virus producers. As a personal example: I once reverse engineered a software to track down an error that occured while establishing an oracle connection. No one else could solve the problem, so I got some fame.

In addition, I'd also like to cite @johannes comment, as he is absolutely right:

I won't limit it to "bad" cracking. Disassembling can be useful to figure out whether the compiler went mad (usually it's your code, though), from a more sysadmin point of view it can be interesting to see where an application fails

Falcon
  • 19,248
  • 4
  • 78
  • 93
  • 8
    I won't limit it to "bad" cracking. Disassembling can be useful to figure out whether the compiler went mad (usually it's your code, though), from a more sysadmin point of view it can be interesting to see where an application fails, ... – johannes Aug 15 '12 at 17:52
  • @johannes: Yes, you're right. May I write that in my answer? – Falcon Aug 15 '12 at 17:56
  • sure, do as you like, I claim no copyright on that ;-) – johannes Aug 15 '12 at 20:17
  • 7
    I'm sorry but this is an absolutely terrible answer. Reverse Engineering is *absolutely not* "mainly for ... cracking and hacking" as defined, and anyone who does not deal with systems programming is being done a disservice by being introduced to it from that ideological perspective. – Chuu Aug 15 '12 at 22:38
  • Agreed with @Chuu. Anyone who's had to figure out how to make some badly documented troublesome system work has had to do reverse engineering. – whatsisname Aug 15 '12 at 23:47
  • Yes, but who does so with assembly code in C? – Falcon Aug 16 '12 at 06:54
  • I've also used it to help determine what versoin of a dll is running in production after the previous employee has departed, and it's unclear what the version differences between source control, development, and production are. – CaffGeek Aug 16 '12 at 13:10
  • Disassembling binaries is a subset of reverse engineering, but I think that's what socksocket was asking about since he included the `assembly` and `low-level` tags. (Which I missed when I made my answer.) – Philip Aug 16 '12 at 16:17
  • @Falcon Off the top of my head, anyone who has ever had to reverse-engineer a driver or study compiler output; which is a very large percentage of systems engineer, and probably all engineers who deal with embedded platforms. – Chuu Aug 16 '12 at 18:05
  • 1
    I don't think it has been mentioned yet, but be careful if you do this on software that is not yours (or don't tell anyone). Almost all commercial EULAs prohibit reverse engineering. You do not want to get a cease and desist letter with copies to someones IP lawyer. – Bratch Aug 17 '12 at 20:03
13

There's also the drop-dead boring side of reverse engineering. This is when the company you're at has a bit of code or program that is still being used, but no-one claims to know anything about it. So you go through it, document it, write tests, and all that engineering stuff that should be done before a project is started. You do this for a piece of software that is already written, hence "reverse engineering".

It's a lot easier when you have the code, but it's still technically reverse engineering. It's one of those terms that pops up a lot in business meetings when they're talking about legacy projects.

Philip
  • 6,742
  • 27
  • 43
  • +1, particularly true for me. I've worked on some banks where legacy systems did not have a single technical document. – Machado Aug 16 '12 at 13:47
7

Just to expand on the business value of reverse engineering - more than half of the new customers we encounter have an existing system / app (not always in production, mind you), but where the relationship with a previous software development vendor hit the skids.

In about 30% of the cases the customer hasn't got the source for their system at all, and in many cases, much of the real business process, rules and knowledge is locked away in code.

And in a couple of cases where the previous vendors have gotten plain malicious, obfuscated the binaries, timelocked the code etc in order to ensnare the customer indefinitely.

So to answer your question, reverse engineering is often a starting point for new engagements with rather desperate (and burned) customers, and it can be a 'business critical' success factor to extract forgotten knowledge from existing code.

StuartLC
  • 1,246
  • 8
  • 14
3

I would argue that the skill-set for reverse-engineering and the skill-set for debugging are exactly the same - if you are a fantastic debugger, you are also a fantastic reverse-engineer, and vice-versa.

BlueRaja - Danny Pflughoeft
  • 4,901
  • 24
  • 30
1

Sometimes it's used to get some parts/software to inter-operate as far as I understand. Some weird interfaces, bugs in implementation, etc.

But from what I understand, it's a very slippery subject, and so, the already complex laws of software development are taken to the extreme with reverse-engineering.

Coder
  • 6,958
  • 5
  • 37
  • 49
1

Well, with reverse engineering you can be able to reuse code minimising your work.For example,in Symfony2, you can convert a database made from the normal MySQL and convert it to the doctrine format and this is a reverse engineered process made possible in Symfony....and with reverse engineering,you are able to see the code let say 'in 2D'

wanjiku
  • 19
  • 3
0

I am giving just a real world example from my experience.

Once our company took over a project from another company. About half a year into the project we realized that a subproject was without code. When we asked the former company to deliver the code, they politely replied that they couldn't find the code for the subproject. We needed the code because we wanted to change something in that subproject.

I had to reverse engineer the subproject.

First I decompiled the assembly (yes, it is a .NET project). The result of the decompiled assembly is bland and confusing code without names of local variables and a complicated control structure. This is because compilation discards important information which cannot be decompiled.

Then I tried to figure out where to change that code. To do this I streamlined the code to behave the same but in a more concise way. I also guessed the names of the variables from its behaviour. I single stepped through the code many times till I figured out what it is doing.

I didn't reverse engineer everything, only the part we had to change. It was not too bad, about 200 lines of VB code. It took around five days of working time.

nalply
  • 257
  • 2
  • 9