Stealth breakpoints

Microscopic analysis of malicious code (malware) requires the aid of a variety of powerful tools. Chief among them is a debugger that enables runtime binary analysis at an instruction level. One of the important services provided by a debugger is the ability to stop execution of code at an arbitrary point during runtime, using breakpoints. Software breakpoints support an unlimited number of breakpoint locations by changing the code being debugged so that it can be interrupted during runtime. Most, if not all, malware are very sensitive to code modification with self-modifying and/or self-checking (SM-SC) capabilities, rendering the use of software breakpoints limited in their scope. Hardware breakpoints supported by the underlying processor, on the other hand, use a subset of the processor register set and exception mechanisms to provide breakpoints that do not entail code modification. This makes hardware breakpoints the most powerful breakpoint mechanism for malware analysis. However, current processors provide a very limited number of hardware breakpoints (typically 2-4 locations). Thus, a serious restriction is imposed on the debugger to set a desired number of breakpoints without resorting to the limited alternative of software breakpoints. Also, with the ever evolving nature of malware, there are techniques being employed that prevent the use of hardware breakpoints. This calls for a new breakpoint mechanism that retains the features of hardware breakpoints while providing an unlimited number of breakpoints, which cannot be detected or countered. In this paper, we present the concept of stealth breakpoints and discuss the design and implementation of VAMPiRE, a realization of this concept. VAMPiRE cannot be detected or countered and provides unlimited number of breakpoints to be set on code, data, and I/O with the same precision as that of hardware breakpoints. It does so by employing a subtle combination of simple stealth techniques using virtual memory and hardware single-stepping mechanisms that are available on all processors, old and new. This technique makes VAMPiRE portable to any architecture, providing powerful breakpoint ability similar to hardware breakpoints for microscopic malware analysis

[1]  Peter A. Buhr,et al.  KDB: a multi-threaded debugger for multi-threaded applications , 1996, SPDT '96.

[2]  Andy Oram,et al.  Getting to Know gdb , 1996 .

[3]  Ing-Jer Huang,et al.  Analysis of hardware and software approaches to embedded in-circuit emulation of microprocessors , 2002 .

[4]  Norman Ramsey,et al.  Correctness of trap-based breakpoint implementations , 1994, POPL '94.

[5]  Mark A. Linton,et al.  The Evolution of Dbx , 1990, USENIX Summer.

[6]  Vern Paxson,et al.  A Survey of Support For Implementing Debuggers , 2005 .

[7]  Peter B. Kessler,et al.  Fast breakpoints: design and implementation , 1990, SIGP.

[8]  Samuel T. King,et al.  Debugging Operating Systems with Time-Traveling Virtual Machines (Awarded General Track Best Paper Award!) , 2005, USENIX Annual Technical Conference, General Track.

[9]  Bert Beander VAX DEBUG: an interactive, symbolic, multilingual debugger , 1983, SIGSOFT '83.

[10]  Thomas J. LeBlanc,et al.  A software instruction counter , 1989, ASPLOS III.

[11]  Fredrik Larsson,et al.  Simics: A Full System Simulation Platform , 2002, Computer.

[12]  Mark Scott Johnson Some requirements for architectural support of software debugging , 1982, ASPLOS I.

[13]  Thomas A. Cargill,et al.  Cheap hardware support for software debugging and profiling , 1987, ASPLOS.

[14]  Samuel T. King,et al.  ReVirt: enabling intrusion analysis through virtual-machine logging and replay , 2002, OPSR.

[15]  Jeff Thomas,et al.  Poor man's watchpoints , 1995, SIGP.

[16]  Robert Wahbe,et al.  Efficient data breakpoints , 1992, ASPLOS V.

[17]  Robert Wahbe,et al.  Practical data breakpoints: design and implementation , 1993, PLDI '93.