Bug Hunter Diary

answers. This is one of the reasons why there is not, and probablywill never be, a “cookbook” for bug hunting. Rather than trying andfailing to write a book of generalized instructions, I will describe theapproaches and techniques that I used to find specific bugs in real-lifesoftware. Hopefully this book will help you develop your own style soyou can find some interesting security-critical software bugs.1.1 For Fun and ProfitPeople who hunt for bugs have a variety of goals and motivations.Some independent bug hunters want to improve software security,while others seek personal gain in the form of fame, media attention,payment, or employment. A company might want to find bugs to usethem as fodder for marketing campaigns. Of course, there are alwaysthe bad apples who want to find new ways to break into systems ornetworks. On the other hand, some people simply do it for fun—orto save the world. ☺1.2 Common TechniquesAlthough no formal documentation exists that describes the standardbug-hunting process, common techniques do exist. These techniquescan be split into two categories: static and dynamic. In static analysis, alsoreferred to as static code analysis, the source code of the software, or thedisassembly of a binary, is examined but not executed. Dynamic analysis,on the other hand, involves debugging or fuzzing the target softwarewhile it’s executing. Both techniques have pros and cons, and most bughunters use a combination of static and dynamic techniques.My Preferred TechniquesMost of the time, I prefer the static analysis approach. I usually readthe source code or disassembly of the target software line by line andtry to understand it. However, reading all the code from beginning toend is generally not practical. When I’m looking for bugs, I typicallystart by trying to identify where user-influenced input data enters thesoftware through an interface to the outside world. This could be networkdata, file data, or data from the execution environment, to namejust a few examples.Next, I study the different ways that the input data can travelthrough the software, while looking for any potentially exploitablecode that acts on the data. Sometimes I’m able to identify these entrypoints solely by reading the source code (see Chapter 2) or the disassembly(see Chapter 6). In other cases, I have to combine static analysiswith the results of debugging the target software (see Chapter 5)to find the input-handling code. I also tend to combine static anddynamic approaches when developing an exploit.4 Chapter 1