Reverse engineering: what is it really good for? [closed]

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?

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

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.

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.

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.

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.

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.

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’

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.

Filed under: softwareengineering - @ 10:22

Thẻ: assembly, c++, low-level, reverse-engineering

Thiết kế website giá rẻ

Danh mục

Reverse engineering: what is it really good for? [closed]