System and method to create a number of breakpoints in a virtual machine via virtual machine trapping events

Abstract

A system and method for dynamic software analysis operable to describe program behavior via instrumentation of virtualization events.

Description

BACKGROUND

1. Field

The present inventive concept pertains to a system and method to interpret and describe program behavior via instrumentation of virtualization events. The present inventive concept more particularly concerns a system and method to create a number of passive breakpoints in a virtual machine via instrumentation of common virtual machine trapping events.

2. Discussion of Related Art

Many virtualization platforms provide a process to analyze state and behavior of a virtual machine. Such processes are useful for a variety of applications including automated software analysis.

Static analysis of a virtual machine involves inspecting a snapshot of volatile memory as the virtual processor state is paused. By contrast, dynamic analysis involves observing changes to volatile memory and processor state in a running virtual machine to observe the presence of specific behaviors. In observing such specific behaviors, analysts may better understand objectives of malware that may be present within the virtual machine. Examples of dynamic analysis of a virtual machine may include tracking specific function calls or logging reads or writes to specific regions of memory as software executes.

Three conventional mechanisms or strategies for analyzing malware include hardware breakpoints, software breakpoints, and single stepping. Setting breakpoints is a useful mechanism for dynamic analysis, which provides the ability to instrument program execution for a particular piece of software. More specifically, the term “breakpoint” refers to a mechanism that triggers control of execution when software has attempted to execute a specific instruction or set of instructions at a specific location in memory.

When applied to virtualization, using breakpoints can be thought of as a means for controlling the execution of code by a virtual machine using control software running in an entirely separate virtual machine. Note that this is technically different than kernel debuggers, e.g., those commonly used with operating systems sold under the trademarks Linux® and Windows®, as no local debugging mode or software within the virtual machine is necessary. Setting breakpoints is in many cases similar to the concept of “inline function hooking.” Inline function hooking performs a modification of the software under analysis in which the first few instructions of a function are replaced in order redirect execution by analysis (or malicious) software, before returning the flow of control to the intended function. This method achieves the same effect without modifying instructions within the virtual machine.

Hardware breakpoints are used for the purposes of debugging; hardware virtualization platforms include debug registers intended to be used for this specific purpose. Modern architectures, however, contain a limited number, e.g., 4 on x86, and at most 6 on current implementations of ARM. These limited numbers are inadequate for effective malware analysis in many situations, such as when the type of analysis being employed potentially requires hundreds or thousands of code instrumentation hooks to observe software behavior.

Traditional software breakpoints involve directly modifying the code within the guest virtual machine. For example, setting a breakpoint on the x86 architecture involves writing the opcode O×CC or “INT3” instruction to memory at the location of the breakpoint (also called the instrumentation point). Within virtual machine platforms, it is possible to use software breakpoints within a virtual machine. This method is not passive because it requires direct modification of software, which may result in modified software behavior; malware is often structured to protect against such modification. Examples of how malware protects against such modification include actively scanning for software breakpoints or by calculating and verifying check sums on code areas, or measuring code by some other means, to determine if the code has been modified before execution. The presence of software breakpoints in these circumstances will thus alter program execution and prevent accurate determination of intended program behavior.

Another option for code analysis within hardware assisted virtual machine platforms is to single step one instruction at a time within a virtual machine while monitoring a state between each instruction. In practice, for any software running within a modern operating system, this method is far too slow and inevitably causes instabilities within the virtual machine operating system.

Conventional mechanisms for dynamic analysis of software in virtual machine environments are not ideal for analysis of malware. Malware often abuses normal software conventions with respect to operating systems as well as system hardware architecture, which confounds traditional analysis. Conventional analysis can be slow, inadequate, and/or inaccurate. Thus, there is a demand for a system and method operable to describe program behavior via instrumentation of virtualization events that does not suffer from the aforementioned deficiencies.

SUMMARY

The present inventive concept described herein remedies the aforementioned problems by providing a unique system and method for dynamic software analysis so that program behavior can be more accurately described via instrumentation of virtualization events. The system and method of the present inventive concept does not require any modification to a virtual machine, or software modification in guest memory, and otherwise avoids many of the shortcomings of conventional methods of analysis.

The system and method of the present inventive concept utilizes both virtual machine introspection and observation of hardware-assisted virtualization trapping events to create a program analysis framework that overcomes shortcomings of conventional methods such as conventional utilization of software breakpoints, hardware breakpoints, and single stepping.

The aforementioned may be achieved in an aspect of the present inventive concept by providing a method to create a number of passive breakpoints in a virtual machine. The method include the steps of triggering a virtualization trapping event in a hardware-assisted virtualization platform, during software execution within a guest virtual machine, intercepting the virtualization trapping event via a hardware-assisted virtualization hypervisor, independently registering the virtualization trapping event via an analysis engine, and/or determining whether the virtualization trapping event includes any arbitrary software execution.

The triggering may be performed by (i) an operating system, and/or (ii) application software. The method may include the step of instrumenting the guest virtual machine to (i) register to receive events, and/or (ii) modify guest execution behavior. The modifying guest execution behavior may include (i) modifying page permissions, and/or (ii) operating in a single-stepping mode. When the guest virtual machine attempts to execute any code contained within a physical page, (i) a permission of the physical page may be set to executable, and/or (ii) a single stepping flag may be turned on.

The aforementioned may be achieved in another aspect of the present inventive concept by providing a method to create a number of passive breakpoints in a virtual machine via instrumentation of common virtual machine trapping events. The method may include the steps of parsing a configuration, installing an executor in a virtual machine, starting the virtual machine, executing malware in the virtual machine, detecting at least one event occurrence of the virtual machine, performing introspection within a memory of the virtual machine, dynamically resolving at least one hook address via a control interface, installing at least one hook in at least one of malware, an affected process, and a kernel of an operating system, and/or logging at least one hook result in a predetermined format.

The aforementioned may be achieved in another aspect of the present inventive concept by providing a system to create a number of passive breakpoints in a virtual machine via instrumentation of common virtual machine trapping events. The system may include an event driven hooking engine operable to manipulate at least one page permission in a virtual machine and/or utilize at least one virtual machine trap exposed by a hypervisor virtualization platform to provide execution at an arbitrary address within one or more processes of the virtual machine.

The system may include a hardware-assisted virtualization hypervisor that may be configured to intercept a virtualization trapping event. The virtualization trapping event may be triggered (i) in the virtual machine, and/or (ii) during software execution within the virtual machine. The system may include an analysis engine that may be configured to (i) register the virtualization trapping event, and/or (ii) determine whether the virtualization trapping event includes any arbitrary software execution.

The system may include an operating system that may be configured to trigger the virtualization trapping event. The virtualization trapping event may be triggered by application software. The engine may be configured to instrument the virtual machine to (i) register to receive events, and/or (ii) modify execution behavior. The modifying execution behavior may include (i) modifying the page permission, and/or (ii) operating in a single-stepping mode. The engine may be configured to, when the virtual machine attempts to execute any code contained within a physical page, (i) set a permission of the physical page to executable, and/or (ii) turn a single stepping flag on.

Additional aspects, advantages, and utilities of the present inventive concept will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the present inventive concept.

The foregoing is intended to be illustrative and is not meant in a limiting sense. Many features and subcombinations of the present inventive concept may be made and will be readily evident upon a study of the following specification and accompanying drawings comprising a part thereof. These features and subcombinations may be employed without reference to other features and subcombinations.

BRIEF DESCRIPTION OF THE DRAWINGS

The present inventive concept is described in detail below with reference to the attached drawing figures, wherein:

FIG. 1 is a diagram illustrating an example of a process of the present inventive concept;

FIG. 2 is a diagram illustrating an example of page tables with virtual memory mapped to physical memory; and

FIG. 3 is a diagram illustrating an example of page tables with virtual memory mapped to physical memory.

The drawing figures do not limit the present inventive concept to the specific examples disclosed and described herein. The drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present inventive concept.

DETAILED DESCRIPTION

The following detailed description references the accompanying drawings that illustrate the present inventive concept. The illustrations and description are intended to describe aspects of the present inventive concept in sufficient detail to enable those skilled in the art to practice the present inventive concept. Other components can be utilized and changes can be made without departing from the scope of the present inventive concept. The following detailed description is, therefore, not to be taken in a limiting sense. The scope of the present inventive concept is defined only by the appended claims, along with the full scope of equivalents to which such claims are entitled.

In this description, references to “one embodiment,” “an embodiment,” or “embodiments” mean that the feature or features being referred to are included in at least one embodiment of the present inventive concept. Separate references to “one embodiment,” “an embodiment,” or “embodiments” in this description do not necessarily refer to the same embodiment and are also not mutually exclusive unless so stated and/or except as will be readily apparent to those skilled in the art from the description. For example, a feature, structure, act, etc. described in one embodiment may also be included in other embodiments, but is not necessarily included. Thus, the present inventive concept can include a variety of combinations and/or integrations of the embodiments described herein.

The system and method of the present inventive concept provides dynamic software analysis so that program behavior can be accurately described using various processes including instrumentation of virtualization events. In this manner, the system and method of the present inventive concept does not require modification to a virtual machine.

The system and method of the present inventive concept utilizes both virtual machine introspection and observation of hardware-assisted virtualization trapping events to create a program analysis framework.

In a hardware-assisted virtualization platform, during software execution within the guest virtual machine, the operating system, and application software will trigger various virtualization trapping events. A hardware-assisted virtualization hypervisor is operable to intercept the virtualization-trapping events. An analysis engine is operable to independently register and handle the virtualization-trapping events. In addition to receiving notification of the virtualization-trapping events from the hypervisor, the analysis engine is also operable to read memory within the guest virtual machine. With this combination of instrumenting hardware virtualization events and Virtual Machine Introspection (“VMI”) techniques, the analysis engine is operable to track arbitrary execution with virtual memory.

In the preferred embodiment of the present inventive concept, the method utilizes a hypervisor virtualization platform such as that sold under the trademark XEN® for x86 architecture. It is foreseen, however, that the present inventive concept may utilize any virtualized environment to instrument memory permissions for a guest virtual machine.

The instrumenting of the guest virtual machine provides the user of the present inventive concept with programmatic control, thereby allowing the user to register to receive events, e.g., control register access, access violations, single step, and/or INT3, and/or modify guest execution behavior, e.g., page permissions and/or single-stepping mode.

To introspect or read memory from within the guest virtual machine, the method of the present inventive concept may utilize any number of virtual machine introspection tools. In the preferred embodiment, the method and system of the present inventive concept utilizes LibVMI to read memory from guest virtual machine. This is an open source library that provides a mechanism to resolve the virtual to physical page mapping for any process running within the guest Virtual Machine Operating System, as illustrated in FIGS. 2 and 3. While software libraries such as LibVMI are very convenient for this task, this virtual to physical address mapping can be accomplished in a variety of ways as the underlying OS and system architecture constructs are well documented.

To receive notification about specific virtualization events within the guest operating system, a preferred embodiment of the present inventive concept utilizes LibXC, which is an API exposed by a hypervisor virtualization platform. The hypervisor virtualization platform may be the product sold under the trademark XEN®.

In this manner, the system and method of the present inventive concept is operable to weave together virtual machine trap events for access violations, CR3 modifications, and single stepping to build an event-driven framework that yields code arbitrary execution when the program counter (EIP) encounters any address in any process. In other words, the system and method of the present inventive concept is operable to set permissions of each physical memory page in a guest virtual machine containing an address that a user would like to hook. When the guest operating system attempts to execute any code contained within this physical page, the permissions are set executable and the single stepping flag is turned on. Proceeding via a single instruction at a time, the guest operating system is allowed to execute while the system and method of the present inventive concept determines if a hook has been hit and if the target software being watched within the guest VM has single stepped outside the hooked page. Pages of memory are considered “hooked” if there is an instruction address on the page that is being hooked.

Locations of hooks are determined by the configuration of the analysis engine. For example, if users of the analysis engine would like to log every call to the “Connect” function inside the ws2_32.dll library in the Microsoft Windows API, the configuration to the system would specify this as a function to hook. If a hook is hit, then a callback is called. If the target software under analysis has left the hooked memory page, then the permissions for a page are reset to not executable so that the analysis process can hit the page again.

The present inventive concept may include various optimizations to increase efficiency. For instance, a means to detect changes to page tables may be included so if memory is ever remapped the analysis engine will detect and re-resolve related addresses and appropriate pages to identify instrumentation.

Malware can also be present in the form of malicious documents, which requires additional refinements. A non-malicious application with the size and complexity of a document editor presents performance problems and affects the resulting output of the system. In order to reduce the performance cost of monitoring a full, non-malicious application, a reduced set of hooks can be used to instrument the application until it has loaded the malicious document into its memory space. Once the operations to read the malicious document are detected, the normal instrumentation is applied to the document, but filters are put in place to ignore the background activities that the full-featured reader application would take that have no relevance to the actions caused by the malicious document. This filtering is based on tracking the memory regions occupied by the application itself and those used by the document and other dynamic memory. In the case of software sold under the trademark ADOBES Acrobat Reader reading malicious PDF files, the reader application would normally cause thousands of irrelevant entries resulting from the application doing typical activities such as reading its configuration or checking for updates over the internet. The reduced instrumentation effectively filters out these startup activities from the event log. Most readers use well-defined, public system APIs to read document files off disk and, as these are detected for the monitored malicious PDF file, the full instrumentation of the hooking engine is enabled, but continues to filter out background operations based on the memory regions belonging to the application.

In FIG. 1, an interface of the system and method of the present inventive concept is illustrated. Upon initiating a process of the present inventive concept in a host, a configuration is parsed, an executor and malware is installed into the virtual machine, the virtual machine is started, and the analysis engine is started at step one. At step two and in a guest virtual machine, the malware is executed. At step three and in a virtual machine monitor, LibXC and LibVMI are used to detect and respond to events of the guest virtual machine and introspect within guest memory, as well as dynamically resolve hook addresses. Step three is performed via a control interface. At step four, API's of the virtual machine monitor are used to install hooks throughout any one or more of malware, affected processes, and a kernel of the operating system. At step five, hook event results are logged in a format such as, but not limited to, OpenIOC XML, for further analysis.

In this manner, the present inventive concept is operable to permit the user such as, but not limited to, an information security forensic investigator or the like, to perform dynamic software analysis so that program behavior can be accurately described via instrumentation of virtualization events.

The previous description of the presently disclosed inventive concept is provided to enable any person skilled in the art to make or use the present inventive concept. Various modifications will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied alternatively without departing from the spirit or scope of the present inventive concept. Thus, the present inventive concept is not intended to be limited to the description herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The steps of a method, system, or operation described in connection with the present inventive concept disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

Having now described the features, discoveries and principles of the present inventive aspect of this disclosure, the manner in which the present inventive aspect is constructed and used, the characteristics of the construction, and advantageous, new and useful results obtained; the new and useful structures, devices, elements, arrangements, parts and combinations, are set forth in the appended claims.

It is also to be understood that the following claims are intended to cover all of the generic and specific features of the present inventive aspect herein described, and all statements of the scope of the present inventive aspect which, as a matter of language, might be said to fail there between.

Claims

1. A method to create a number of passive breakpoints in a virtual machine for dynamic software analysis of program behavior, the method comprising: instrumenting, by an analysis engine, a guest virtual machine to provide a user with programmatic control configured to (i) register to receive a virtualization trapping event and (ii) modify guest virtual machine execution behavior;responsive to instrumenting the guest virtual machine to receive the virtualization trapping event, triggering the virtualization trapping event in a hardware-assisted virtualization platform, during an application software or operating system execution within the guest virtual machine, wherein the hardware-assisted virtualization platform comprises an event driven hooking engine that is further configured to manipulate at least one page permission in the guest virtual machine and utilize at least one virtual machine trap to provide execution at an address within a memory allocated to a process of the guest virtual machine,intercepting the virtualization trapping event via a hardware-assisted virtualization hypervisor, andreading the memory within the guest virtual machine by the analysis engine to enable the analysis engine to determine whether the virtualization trapping event includes any unexpected software execution; andresponsive to instrumenting the guest virtual machine to modify the guest execution behavior,modifying one or more page permissions,operating in a single-stepping mode by controlling instruction processing by the guest virtual machine to enable the analysis engine to determine any unexpected software execution, andresetting the one or more page permissions.

2. The method according to claim 1, wherein the triggering is performed by at least one of (i) the operating system, and (ii) the application software.

3. The method according to claim 1, wherein when the guest virtual machine attempts to execute any code contained within a physical page, (i) a permission of the physical page is set to executable, and (ii) a single stepping flag is turned on.

4. The method according to claim 1, wherein the modifying of the guest virtual machine execution behavior is conducted based on controlling instruction processing by the guest virtual machine by at least placing the guest virtual machine in a single-stepping mode.

5. The system according to claim 1, wherein the modifying of the one or more page permissions includes setting the one or more page permissions to an executable permission.

6. The system according to claim 5, wherein the resetting of the one or more page permissions includes setting the one or more page permissions to a non-executable permission.

7. The method according to claim 1, wherein the virtualization trapping event is an event that is registered with the analysis engine and operates as a breakpoint.

8. A system with a processor to create a number of passive breakpoints in a virtual machine via instrumentation of common virtual machine trapping events, the system including: a hardware-assisted virtualization hypervisor to intercept a virtualization trapping event, the virtualization trapping event triggered (i) in the guest virtual machine, and (ii) during software execution within the guest virtual machine, wherein the hardware-assisted virtualization hypervisor comprises an event driven hooking engine that is further configured to manipulate at least one page permission in the guest virtual machine and utilize at least one virtual machine trap to provide execution at an address within a memory allocated to a process of the guest virtual machine; andan analysis engine that is separate from the guest virtual machine and the hardware-assisted virtualization hypervisor, the analysis engine to (i) instrument the guest virtual machine to provide a user with programmatic control configured to (i) register to receive a virtualization trapping event and (ii) modify guest virtual machine execution behavior, (ii) read the memory within the guest virtual machine to enable the analysis engine to determine whether the virtualization trapping event includes any unexpected arbitrary software execution, and (iii) modify the guest virtual machine execution behavior by at least modifying one or more page permissions, operating in a single-stepping mode by controlling instruction processing by the guest virtual machine to enable the analysis engine to determine any unexpected software execution, and resetting the one or more page permissions.

9. The system according to claim 8, further comprising: an operating system that triggers the virtualization trapping event.

10. The system according to claim 8, wherein the virtualization trapping event is triggered by application software.

11. The system according to claim 8, wherein the analysis engine to modify the one or more page permissions to an executable permission.

12. The system according to claim 9, wherein the resetting of the one or more page permissions includes setting the one or more page permissions back to a non-executable permission.

13. The system according to claim 8, wherein the analysis engine to, when the virtual machine attempts to execute any code contained within a physical page, (i) set a permission of the physical page to executable, and (ii) turn a single stepping flag on.

14. The system according to claim 8, wherein the analysis engine to modify the guest virtual machine execution behavior based on at least controlling instruction processing by the guest virtual machine by at least placing the guest virtual machine in a single-stepping mode.

15. The system according to claim 8, wherein the virtualization trapping event is an event that is registered with the analysis engine and operates as a breakpoint.