Welcome back, in this blog post we're going to cover information disclosure vulnerabilities from a couple of different angles. This is the third post in the security blog series that I've been writing. For the previous one, click here .

In this day and age a company lives and dies on the information it holds. If your information isn't safe, then your company isn't safe in many respects. Information disclosure can be something as benign as giving away a list of services running on ports on one of your machines, to something less benign such as internal addressing map for your network, and at worst the release of your intellectual property or your trade secrets.

Comment (0) Read More...

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...

Today’s article covers the concepts of fail closed and fail open design. These two concepts are extremely simple to grasp through example. So, let’s step aside and let the following short story teach us about fail-open systems design:

Comment (0) Read More...

    In today's software development environment, a developer would be extremely remiss if they did not consider security when designing and implementing applications. Unfortunately, what each developer considers secure programming varies widely. This is partly because when being taught software development (or for you autodidacts, learning it on your own), generally speaking most materials and courses do not cover the information required to make informed security decisions. On top of this, developers are human and do make mistakes, and lets face it guys and gals... we’re lazy. (Excluding Bulletproof developers of course! :)). That is, being human, we sometimes cut corners, and sometimes, they come pre-cut.

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...