Hello, and welcome back to the third blog post in the reverse engineering series. In the last two I discussed why someone would want to reverse engineer software. I also gave an example of reverse engineering a small Win32 application. In this one I'm going to show you how to use reverse engineering to find ABEND situations in release software. If you missed the first two, they can be found here and here respectively.

For most intents and purposes you wouldn't analyze a whole program. Well, maybe someone would, but I don't dislike myself that much :). Instead, you would use techniques like we used in the previous blog post, with a smattering of lateral thinking to find the parts of the code you're interested in and you'd analyze those.

Comment (0) Read More...

On your feet soldier!

Welcome back to the second blog post on reverse engineering... Lets get into the meat of it shall we? In this post we're going to take an executable and disassemble it. We're then going to examine it to see if we can figure out what the program flow is, and come up with a very good idea of what the original source code looked like. If you missed the first one, you can find it here .

An example pack for this scenario is attached to this blog post. I'm not going to give you the IDA file because frankly, I want you to follow along and do this as an exercise :). You learn this stuff by doing, not only by reading.

I suggest you get IDA, MASM32, and WinDBG along with it's associated symbol package. You should also download the example pack and Notepad++ with the hex editor plug-in (available on the download page) as you will want to view the CPP files and the binaries.

Comment (0)

I thought I'd take a slight sideways jaunt from the security list that I was going to post and bring up a topic that seems to have several people I know very curious and interested. That topic is reverse engineering. Fair warning, this topic will be covered in four separate blog posts (including this one) at a rate of 1 per week. After that we'll get back to the previously mentioned topics that I said I would cover.

While the topic is related to security (heavily so), and programming, we won't be concentrating specifically on security related examples. That's because while there's a plethora of security related examples we could go over, and reverse engineering is not just related to security.

Comment (0) Read More...

It is an unfortunate fact that most application developers are not well versed in application security.  This mixed with tight deadlines and loose development methodologies, means that your code probably has some issue when it comes to security. This is why you should be doing code reviews.

Code reviews can take the form of third party or internal peer review. In the case of peer review the developers are checking each others work in a team fashion. This is a great way to cut down on common mistakes and implementation decisions. Every organization that does development should include peer review in the process. 

Comment (0) Read More...