Sign in to follow this  
Followers 0
Bramming

Reverse engineering

22 posts in this topic

Hey. I have been interested in computers for a while. I have been coding a bit of python and java and recently started learning c (i bought the K&R 2. edition book). I've also worked a bit with debugging programs using Ollydbg. The problem for me is. I used Ollydbg like 2 years ago, and back then i was a windows user. However last year i switched over to linux (ubuntu to be more precise) and i feel like i wont ever go back. I really like trying to patch programs to behave the way i want, because its exciting to try and figure out how a program works, however some questions keeps popping up in my mind:

1. Isn't it a waste of time learning to reverse linux programs when most are open-source anyways?

2. Isn't it a waste of time learning to reverse windows programs when i only use linux?

3. If i go on learning to reverse windows programs, will i learn anything i can use in the linux-world?

I'm also wondering about how constructive debugging is. Would it be better to delve deeper into C programming instead, to try and contribute to the open-source community (which i really want, just seems like its way out of my league)

I hope this thread isn't too confusing, also apologies for bad language. English isn't native to me :)

and, Thanks for your time:)

0

Share this post


Link to post
Share on other sites

None of that is mutually exclusive. The way windows compiles down binaries to assembly is a bit different than linux, but once you understand assembly and the differences it really isn't that complicated. There are plenty of reasons to learn assembly including the fact that you'll probably write better C code in some circumstances when you understand what is happening at a lower level. Lastly debugging isn't just for reverse engineering, in fact most of the time you don't even debug because you don't necessarily want to run the binary. Debugging is extremely useful for tracking down unexpected behavior when you don't see anything in the high level code that would cause it. You can follow along the execution, watch the stack and the variables and see exactly what is happening rather than just the output of the application.

0

Share this post


Link to post
Share on other sites

Linux users usually reverse engineer Windows programs in order to write compatible open source implementations. A lot of Linux programs are written using the results of work of reverse engineering.

0

Share this post


Link to post
Share on other sites

Linux users usually reverse engineer Windows programs in order to write compatible open source implementations. A lot of Linux programs are written using the results of work of reverse engineering.

I agree and disagree. I agree on the visual level, but down to the code level is probably not that useful.

I am not sure how much a linux developer would get out of reverse engineering most of the code from a .NET environment. Mono isn't completely compatible with many of the Windows libraries. Also, most .NET programs are written in C# which is like an object orientated C, but doesn't translate over well so I don't know how helpful that would be either.

On the agree side. Front end development can be copied fairly well from just looking at the program, and SQL development is fairly straightforward. I think the only real reason you would want to reverse engineer Windows at the code level would be to figure out complex math functions or to figure out a certain company's business rules.

However, if the program is written in a comparable language, then it might be useful in both OS situations, but then coding in the same language you may run into "line-by-line" copyright problems which makes open source development difficult. Someone eventually will call you on it, and then you don't look so hot in the open source community.

0

Share this post


Link to post
Share on other sites

Linux users usually reverse engineer Windows programs in order to write compatible open source implementations. A lot of Linux programs are written using the results of work of reverse engineering.

I agree and disagree. I agree on the visual level, but down to the code level is probably not that useful.

I am not sure how much a linux developer would get out of reverse engineering most of the code from a .NET environment. Mono isn't completely compatible with many of the Windows libraries. Also, most .NET programs are written in C# which is like an object orientated C, but doesn't translate over well so I don't know how helpful that would be either.

On the agree side. Front end development can be copied fairly well from just looking at the program, and SQL development is fairly straightforward. I think the only real reason you would want to reverse engineer Windows at the code level would be to figure out complex math functions or to figure out a certain company's business rules.

However, if the program is written in a comparable language, then it might be useful in both OS situations, but then coding in the same language you may run into "line-by-line" copyright problems which makes open source development difficult. Someone eventually will call you on it, and then you don't look so hot in the open source community.

Nobody ever mentioned .net and the original poster was talking about C. This is really not related or useful.

0

Share this post


Link to post
Share on other sites

Nobody ever mentioned .net and the original poster was talking about C. This is really not related or useful.

Livinded,

I'm not sure if you were trolling or what this post was about so I thought I would send another post to clarify my post.

The original poster said:

"2. Isn't it a waste of time learning to reverse windows programs when i only use linux?

3. If i go on learning to reverse windows programs, will i learn anything i can use in the linux-world?"

While I mentioned .NET as an example I also mentioned other languages. I also thought the major theme of my post was that reverse engineering is not only about delving into code, but there can be many layers to it. It could be as simple as viewing an application and copying the user interface.

However, I'm wondering if I took this the wrong way. Maybe I am reading something into your post that wasn't there or maybe my post did not convey the message that I intended. In either way, this was only my third post on this particular forum, so I was surprised by the reaction to it. I was under the impression that flaming was banned in Nubie HQ.

0

Share this post


Link to post
Share on other sites

In regard to visual aspects, reverse engineering, unless you're talking about something in say OpenGL, is going to be a moot point because you're not going to using the same graphical toolkits across most platforms. Generally you are going to develop a visual interface in the style that is native to the operating system to make an application that looks correct. If you are talking about a situation where the interface is created with something like OpenGL then yes, I suppose the visual aspect could be useful but only if you're using a framework that is cross platform. And if you are simply implying that looking at a user interface and creating one that looks like it while not looking at the code then you must not have good grasp of the concept of reverse engineering, as that is more of a clean room implementation if you could even really call it that.

In regard to SQL that is platform (operating system) independent because it is executed in a completely different runtime which has nothing to do with the operating system you are on. SQL queries may change between different SQL implementations, however that is out of the scope of this question.

My post was not intended to flame in any way, but merely correct. I wrote it quickly and did not put much time into it which is why it may have come across as blunt and aggressive.

0

Share this post


Link to post
Share on other sites

None of that is mutually exclusive. The way windows compiles down binaries to assembly is a bit different than linux, but once you understand assembly and the differences it really isn't that complicated. There are plenty of reasons to learn assembly including the fact that you'll probably write better C code in some circumstances when you understand what is happening at a lower level. Lastly debugging isn't just for reverse engineering, in fact most of the time you don't even debug because you don't necessarily want to run the binary. Debugging is extremely useful for tracking down unexpected behavior when you don't see anything in the high level code that would cause it. You can follow along the execution, watch the stack and the variables and see exactly what is happening rather than just the output of the application.

Great! Better writing of C code, and usefulness when things go wrong. Sounds good

Linux users usually reverse engineer Windows programs in order to write compatible open source implementations. A lot of Linux programs are written using the results of work of reverse engineering.

More encouraging usefulness ;)

After reading through all the posts i decided to start with debugging again, as i'm now sure i wont waste my time :)

I'm pleased with the quality of responses. I feel like you all helped me make the decision.

Thanks Aghaster, livinded and heisenbug!

0

Share this post


Link to post
Share on other sites

well, just to clarify something that may have been missed...

the term reverse-engineering is a general term that means figuring out how one thing worked (in this case a windows program) and trying to make something similar or very close to the original (in this case a linux program). This is intentionally without detail because it doesn't intend to refer to a detailed breakdown of any specific type of code, or even refer to code at all for that matter. You can reverse engineer a microwave to create another knock-off microwave with similar functionality. Code may or not even play a part.

Reverse engineering simply means figure out how it works and then try recreate it. It doesn't matter whether it was C/C++/C#/.net or whatever. You can still reverese engineer it and see how it works and try to duplicate it. It will never translate directly. It is the nature of programming. I have had things that were 100% ANSI standard C that didn't even compile on another OS before (although theoretically that should, and usually does, work)!

Don't be too literal or focused on the details. It is certainly worthwhile because you will learn a lot from the process but expect that the code that you get from the source may need to be 100% rewritten for the destination. You might get lucky and be able to salvage some of it. Either way, you will figure out how it works and that is the important part.

0

Share this post


Link to post
Share on other sites

well, just to clarify something that may have been missed...

the term reverse-engineering is a general term that means figuring out how one thing worked (in this case a windows program) and trying to make something similar or very close to the original (in this case a linux program). This is intentionally without detail because it doesn't intend to refer to a detailed breakdown of any specific type of code, or even refer to code at all for that matter. You can reverse engineer a microwave to create another knock-off microwave with similar functionality. Code may or not even play a part.

Reverse engineering simply means figure out how it works and then try recreate it. It doesn't matter whether it was C/C++/C#/.net or whatever. You can still reverese engineer it and see how it works and try to duplicate it. It will never translate directly. It is the nature of programming. I have had things that were 100% ANSI standard C that didn't even compile on another OS before (although theoretically that should, and usually does, work)!

Don't be too literal or focused on the details. It is certainly worthwhile because you will learn a lot from the process but expect that the code that you get from the source may need to be 100% rewritten for the destination. You might get lucky and be able to salvage some of it. Either way, you will figure out how it works and that is the important part.

I always thought that reverse engineering = debugging. But your post makes perfect sense:) also i will try to follow your advice. Thanks :)

0

Share this post


Link to post
Share on other sites

What I think is really neat about reverse engineering is finding exploits without ever looking at the code.

If you know enough about software development methodologies, you can look at some software and imagine how the developer wrote it. If you understand development techniques, software deadlines, and project management, you can think of where he might of cut corners in security development.

Some portions of software security is seen as a "feature" and is only added later if there is time, and often there is not. Most software project fall well behind schedule. Non visible features to the user are often cut first.

If you understand the human mind and software development well enough, you can often find several exploits in software simply by looking at the interface or knowing what it does and never looking at the code. That is really fun.

0

Share this post


Link to post
Share on other sites

First of all you don't find exploits in software, you find vulnerabilities. Exploits are what are used to exploit the vulnerability. Second reverse engineering software does involve looking at the code. When you look at a binary in a disassembler or debugger you're looking at the actual code. Albeit different that what the developer most likely wrote because very little code is written in straight assembly these days, it's still a representation of what the developer wrote. If you're just hypothesizing how the developers architected the code and are looking for potential vulnerabilities in that it's not really reverse engineering. You are just using knowledge about certain architecture patterns to guess about certain vulnerabilities that may be present.

0

Share this post


Link to post
Share on other sites

To answer the original poster's question (whether learning to reverse engineer is a waste of time) in a generic way: learning is never a waste of time. It depends on what your end goal is. If your end goal is to create a competing product that is cross-compatible with the reversed program or protocol, then reversing probably won't be a waste of time. If your goal is to simply learn how the technology works, then reversing is definitely not a waste of time. If your goal is unrelated to reversing, then it is a waste of time.

Learning different things will keep you balanced and will add to your current toolset. Knowledge is power. Do what makes sense.

0

Share this post


Link to post
Share on other sites

I'm amazed that interesting replies keep coming up :D

It's great. Definitely keeping this thread bookmarked for reference :)

"Knowledge is power". Awesome quote :D

and once again thanks for the posts. its really nice to see, that people are so helpful to a noob like me. Makes me wish i could somehow give something back to the community :)

0

Share this post


Link to post
Share on other sites

First of all you don't find exploits in software, you find vulnerabilities. Exploits are what are used to exploit the vulnerability.

I wrote that at 5am, and I was sure I said vulnerabilities. Oh, well. You are right. I wrote the wrong word there. Thanks for catching that.

Second reverse engineering software does involve looking at the code. When you look at a binary in a disassembler or debugger you're looking at the actual code.

It it a common misconception that in reverse engineering you must look at the code. Reverse engineering may include looking at the source code, but doesn't necessarily need to involve looking at the source code. It really doesn't even have to relate to software. Anything can be reverse engineered. Heck, you can reverse engineer a chicken nugget or a Popsicle if you want. You can do it anyway your heart desires too. You can look at it physically, chemically, or you can imagine what the inner workings are using your experience or you educated guess.

Diggy wrote a really good description of what reverse engineering was. He did a much better job than I would have. The only part where I disagree, and it's not really disagreeing, I just think he left a little out. I think he left out that you may not need to duplicate the project in its entirety. You can reverse engineer any portion of the project if you so desire. You don't even need to physically duplicate it, you can duplicate it any way you wish. Even in your mind.

If you're just hypothesizing how the developers architected the code and are looking for potential vulnerabilities in that it's not really reverse engineering. You are just using knowledge about certain architecture patterns to guess about certain vulnerabilities that may be present.

Actually, it can be exactly that. It doesn't have to be limited to that, but it very well could be.

Edited by heisenbug
0

Share this post


Link to post
Share on other sites

I didn't say that reverse engineering always meant that you are looking at code, but if you are reverse engineering a binary you are looking at code. Looking at the graphical interface may allow you to duplicate it in a clean room type environment, but it's going to do nothing to help you understand the underlying network protocol that it's using to communicate. Reverse engineering can apply to any technology, product or basically noun that you want to figure out how works or is created, but in this specific instance the topic at hand was software. In order to reverse engineer software, to create a similar product that works just like the original, you will almost definitely need to look at the code in whatever state it is in.

0

Share this post


Link to post
Share on other sites

In order to reverse engineer software, to create a similar product that works just like the original, you will almost definitely need to look at the code in whatever state it is in.

I still don't think you understand my point. I blame my horrible explaination skills.

Let me take you through the process of a simple reverse engineering without looking at the code. I will use a programmer's favorite to explain, the Hello, world script.

For this scenario, let's assume we have the following program, hello.pl, that you have execute permissions to but not read permissions.


#!/usr/local/bin/perl
my $a = "Hello, world!\n";
print $a;

Now this program is fairly straightforward, and it looks like reverse engineering it would be easier than gaining root access. (However probably less fun)

What do you know? Well, you know that the file name is hello.pl and you know that files that end in .pl are commonly perl scripts.

1) The script must be in Perl.

What else do you know?

2) You know that Perl scripts commonly have a shebang line, similar to #!/usr/local/bin/perl or #!/usr/bin/perl

What else do you know? Well, you know that when you run the script it prints to the screen Hello, world and a new line.

3) There must be a print statement in there. You also know that since it has a new line it is probably in double quotes and not single quotes.

Well, you check a few arguments and the output doesn't change.

4) You assume there are no arguments.

So you write your code, never looking at the original source code and you come up with something similar that does the same function and viola you have reversed engineered the software without ever looking at a single line of code.


#!/usr/local/bin/perl
print "Hello, world!\n";

0

Share this post


Link to post
Share on other sites

That really isn't a good example of reverse engineering. You aren't really reversing anything there. You observe behavior and based on what you see you are just implementing that behavior. You have no idea what the original code actually does or even if your version is even close to doing what the original did. For all you know that perl script is a local exploit that is escalating privileges, installing a rootkit, and simply printing out some text to disguise what it's really doing.

0

Share this post


Link to post
Share on other sites

That really isn't a good example of reverse engineering. You aren't really reversing anything there. You observe behavior and based on what you see you are just implementing that behavior.

I'm sorry. I explained it as if I was explaining to a programmer, but it appears from your response that you don't know much about software development techniques. I apologize for the miscommunication. I will explain this a little less technical.

There are two major types of reverse engineering, and I am referring to something called Black Box Testing.

A second Reference that isn't wikipedia.

"In "black box" reverse engineering, systems are observed without examining internal structure, while in "white box" reverse engineering the inner workings of the system are inspected."

Functional testing is common practice in software reverse engineering. The scenario I gave earlier was an example of functional black box reverse engineering.

Edited by heisenbug
0

Share this post


Link to post
Share on other sites

I know what black box and white box testing are, but that example isn't either. In that example you aren't testing anything, you are examining one type of output which has no input. You aren't looking at the system that it is on for any changes or providing any input or variations. For all you know there are switches that affect what the application does and input that the application takes. Regardless I wouldn't call black box or white box testing reverse engineering because it really isn't the goal. In black box and white box testing you are attempting to either ensure that the data that results from an input is correct or try to find some correlation between input and output. A correlation between input and output may help you understand what the thing is doing, but it's not necessarily the main goal. While a correlation may help you to figure out a weakness in whatever the thing is, it doesn't mean that you really understand what is happening. But regardless, this is completely off topic and has nothing to do with your original response, you are simply arguing slightly tangential points.

Edited by livinded
0

Share this post


Link to post
Share on other sites

But regardless, this is completely off topic and has nothing to do with your original response, you are simply arguing slightly tangential points.

Hoping to put this pointless banter to rest, I would like to point out that you are arguing "slightly tangential points" as well. I think we should be focusing on bettering the community by sharing our knowledge, not arguing over stupid points that are correct in your eyes and incorrect in other's.

To reiterate what I said in my previous post: whatever your definition of "reverse engineering" is, if learning it meets your goal, then by all means do it.

1

Share this post


Link to post
Share on other sites

But regardless, this is completely off topic and has nothing to do with your original response, you are simply arguing slightly tangential points.

Hoping to put this pointless banter to rest, I would like to point out that you are arguing "slightly tangential points" as well. I think we should be focusing on bettering the community by sharing our knowledge, not arguing over stupid points that are correct in your eyes and incorrect in other's.

To reiterate what I said in my previous post: whatever your definition of "reverse engineering" is, if learning it meets your goal, then by all means do it.

^^^^

What this guy said.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0