2006-03-24
Article continued from Page 1
Quite often when performing quality assurance trials of a new software program, all you have to work with is the binary itself. This is a good time to draw the parallel between a source code audit and reverse engineering. They're quite different. A source code audit is just that. As a programmer you would be hired to do quality assurance on the source code of a program in order to find any programming errors that could result in a format string attack or buffer overflow. In contrast, reverse engineering of a binary will result in you looking at the program's contents at the machine instruction level. This is where you have to step beyond the knowledge of C and C++, where the knowledge of Assembler is crucial.
When applications written in C and C++ (or other high-level languages) are compiled, they become an executable that is more difficult to understand. Often programs like Ollydbg, IDAPro, or SoftICE will be used to reveal the underlying set of Assembler instructions. Reverse engineering applications is not necessarily the easiest or most fun part of programming, but it is a necessary step. Understanding Assembly is the key. Outside of university courses in either Computer Science or Computer Engineering, one might want to pick up a book such as Jeff Duntemann’s, "Assembly Language Step-by-Step." Much as the author states in the book itself, a large part to understanding Assembly is in understanding of memory management.
Static and dynamic reverse engineering
To further the argument that the needs to have some reverse engineering knowledge, let's take a further look at its methodology. We can broadly break down reverse engineering into two camps. Those consist of both static and dynamic reverse engineering. Each method has a different approach and can be performed with a variety of tools.In essence, when performing static analysis you are not actually invoking the executable itself. You would, for example, open it up with a tool such as IDAPro, and from there check the strings found in the executable itself. The strings that are extracted via IDAPro will give you a pretty good idea of what the executable itself will do once invoked. During static analysis you can also identify breakpoints to be used later whilst performing dynamic analysis. There is a great deal of information to be gleaned during static analysis. Once done you typically move onto dynamic analysis, which entails actually executing the binary itself. This is where the specific break points of interest found earlier during static analysis are examined.
It's important to take a reality check when considering when to do reverse engineering. Realistically, most of us simply do not have the time or budget to go to a college or university if we've already started our path through the security field. The question begs, then, just how do you learn how to program and by extension reverse engineering while in the field? This author would definitely advise a blended approach to the two. While beginning to take your first baby steps towards programming with C or C++, you would also start with some reverse engineering as well.
Specifically, a recommended approach would be to write your very first “Hello world!” program as is traditionally done. Then compile the code, turning it from source into an executable. Now take the executable and do a static analysis of it via the earlier mentioned IDAPro or Ollydb. This will help equate what you are seeing at the Assembler level with what it was you actually wrote in C or C++. This is the best of both worlds, you might say. You can directly see what high level language programs look like in comparison to machine code, Assembler. This method of learning how to both program and reverse engineer at the same can very well pay off handsomely for you.
Scripting languages
Not everything must be written in C or C++ and understood in Assembly to be useful in the security world. There is no denying the sheer versatility that a scripting language such as PERL or Python brings to the table for a network security professional. Not convinced? HD Moore wrote the Metasploit Framework using PERL, and Dave Aitel wrote CANVAS using Python. These are good examples of the power of both scripting languages. Where and how will PERL and Python impact you as a security analyst? To be honest, if you haven't noticed already, scripting languages can be used as just about every juncture of your work day. If you disagree then it is likely because you are not yet adept at using them yet. Whether it is writing a small script to parse out specific fields of a program's output, or creating a small program to test out specific parts of your webserver or web application, they can all be done with a PERL or Python script.Every language has its own strength, and both PERL and Python are powerful - but of the two it can be argued that nowadays you are probably better off learning Python over PERL. For one, Python is object oriented whereas PERL is not. Also, you don’t have the ";" denoting the end of a line in Python that you have in PERL, as Python takes a different approach when you write code. That plus the fact that the Python syntax is clearly easier to understand than PERL.
For those who plan to do a security test of web-based applications, you will also need a good understanding of the language used to code the program. Today this could be any one of a number of languages, including the ones mentioned about. However, it could also be in PHP or ASP - with PHP being by far the most popular scripting language on the Web. With this popularity comes various security issues, and so to audit PHP applications you would want to have a good understanding of PHP.
Whatever you choice of scripting language to learn, they clearly give you a powerful and easy-to-use tool. Once you are comfortable in using them, you can quickly bang out a script for just about any need. It's absolutely amazing the number of things that can be automated with scripts. And the extensive list of modules for both of these languages is impressive, cutting down on your work that can instead be done with a script. The final advantage I will mention when learning either one of these scripting languages is related to their portability. All you need is the associated interpreter installed and you are good to go whether on win32, *nix, or other operating system. A pretty powerful and handy feature.
Conclusion
This article sought to offer some guidance to security analysts on how to further their knowledge towards an advanced skill set. Sometimes being pointed in the right direction is exactly what one needs to take his career to the next level.Once you are able to devote the time necessary to accumulating the above noted skills, it doesn't stop there. There are still other skills to be developed. That's part of the joy of the computer world, and is often reflected in some of the great work and information shared within the security community. Join some mailing lists and get involved.
One somewhat esoteric area is to specialize in exploit development. This is a natural offshoot of reverse engineering, and should not really be lumped in with reverse engineering itself. Some people that I know are able to do reverse engineering quite proficiently, however they are then unable to then code an exploit for the bug they have found. Quite often this process is non-trivial. It's also often due to a lack of a solid understanding of either C or C++. To be really good at network security, and all of its incarnations you really do need to have a solid ability to program.
While this article was not an exhaustive list of skills that an advanced skill set encompasses it does however touch on the core ones. Remember that one does not need to immerse himself into programming to learn it well. Simply budget your time accordingly and learn as you go. With both time, and patience your abilities will grow. I sincerely hope this article was of interest to you, and as always I welcome your feedback.
