243A software program is only as weak as its weakest link. This is true both from
a security standpoint and, to a lesser extent, from a reliability and robustness
standpoint. You could expend considerable energy on development practices
that focus on secure code and yet end up with a vulnerable program just
because of some third-party component your program uses. The same holds
true for robustness and reliability. Many industry professionals fail to realize
that a poorly written third-party software library can invalidate an entire
development team’s efforts to produce a high-quality product.
In this chapter, I will demonstrate how reversing can be used for the auditing
of a program when source code is unavailable. The general idea is to reverse sev-
eral code fragments from a program and try to evaluate the code for security
vulnerabilities and generally safe programming practices.
The first part of this chapter deals with all kinds of security bugs and demon-
strates what they look like in assembly language—from the reversing stand-
point. In the second part, I demonstrate a real-world security bug from a live
product and attempt to determine the exact error that caused it.
Defining the Problem
Before I attempt to define what constitutes secure code, I must try and define
what the word “security” means in the context of this book. I think security