Invention for Reversible managed execution image instruments

Invented by Karim AGHA, Microsoft Technology Licensing LLC

The Microsoft Technology Licensing LLC invention works as follows

Background for Reversible managed execution image instruments

There is a large gap between the technology designs that people can easily understand and the working implementations of computational technology. The design of a product is best done in natural language and with visual descriptions. Computational technology, however, is implemented by bits moving through circuits. The use of high-level languages and development environments has helped bridge the gap between design, and implementation over several decades. The software development cycle includes a high level design that guides the developers to write software in high-level languages. This software is then compiled (possibly using intermediate code like bytecode or Assembly language) into instructions which can be executed by a computer system.

Changing lower-level instruction poses technical challenges. However, there are some mechanisms that can be used to modify them in certain ways. You can dynamically load more instructions via a plug in or dynamically loaded library. Or you can modify jump tables so that one function is replaced by another when a function is called. Debuggers or profilers can insert instructions to stop a program from executing, log the execution of a specific piece of code, etc. Some tools can be used to patch binary files before they are loaded for execution. Self-modifying code is also found in some relatively simple programs. As a result of their execution, some types of malware create copies of themselves. “Sometimes, low-level changes are unwanted. For example, when bugs or malware write bits at memory locations not intended by the software’s original developer.

The most common and widespread method to modify low-level software instructions is to edit a program’s code. The modified source code is recompiled into modified low-level instruction, so that the changes to program functionality caused by source code edits occur when the program is next executed.

Some embodiments address the technical problem that arises when changing the processor level instructions in a software program. More specifically, they address the challenge of changing the processor level instructions without having to edit and recompile the source code. “Processor-level instructions” is used in this document. Instructions at the virtual machine (e.g. bytecode, Common Language Runtime (MSIL), Microsoft Intermediate Language (MSIL), and/or at an even higher level (e.g. firmware, machine-language) are included. Some embodiments also address related technical issues, such as changing processor level instructions in a running program, or changing the processor level instructions of a programme that was loaded using a binary file from disk, without modifying the binary file.

Some embodiments enable instrumentation of software programs during execution.” A machine with a processor, and a memory that is in communication with the processor, executes a program. The machine executes a digital image of the software program along a path. A pre-execution version of the software program is also stored separately from the execution copy in a computer-readable location. The pre-execution may be on disk and controlled by the developer. However, the execution may be in RAM.

Some embodiments include obtaining an instrumentation context in the machine memory for the execution image of the software program. The context is obtained by the machine executing a high-level language statement.

In some embodiments, instrumentation contexts include a set function identifications that identify at the least one function in the execution image that is on the execution path as well as at least another function in the same execution image but not on the path. In some embodiments the instrumentation context may include identification of other items such as individual instructions as opposed to function IDs.

Some embodiments query an instrumentation context by using a high level programming language query that specifies at lease one query criteria to be met. A query criterion can be a Boolean mixture of constituent query criteria. The query may include a declarative Language-Integrated Query expression in some embodiments.

Some embodiments” receive in machine memory a response to a query that identifies one, more or other items within the execution image of the program which satisfy the query. In some instances, the response to the query identifies all items in the execution image of the program that satisfy the query. However, in other cases, only a subset is identified. In some embodiments functions and low level instructions can be identified as satisfying a query, regardless of whether they have been executed during the current program execution. The one or more identified item(s) are here referred as query-satisfying elements, and satisfying functions are referred as query-satisfying features. The query-satisfying items can include bytecode instructions, Common Intermediate Language instructions, low-level virtual machines, etc.

Some embodiments change the function body of at lease one query-satisfying item in the execution image of the program, while others do this without changing the pre-execution picture. Some embodiments alter a functionality of an execution image by transforming at least one item that is used to satisfy a query. The item is executed differently than it would have been if the item had not first been transformed. Sometimes, every item that answers a query in the execution image of the program is transformed. In other cases, only some items are transformed.

Some embodiments add code to the beginning or end of a query-satisfying functionality, while others inject a bug into at least a query-satisfying feature. Some embodiments replace up to N individual instructions in the query satisfying function without changing the entire function. (N=1, 2, 3, 4 or 5 or any other predetermined value). Others replace one or more operands from at least N individual instruction of the query satisfying function without changing the entire functionality. Some embodiments replace a single low-level instructions without replacing an adjacent low level instruction or any operands of any adjacent lower-level instructions; others replace one or more operands of an individual instruction of a low-level function without replacing the entire function.

Some embodiments reverse transformation of at least a query-satisfying feature without restarting the execution of the software.” Some embodiments revert transformations of at least one function that satisfies a query without reverting to the pre-execution program image. Some do both. They revert transformations without restarting the execution, and without reverting back to the program’s pre-execution images.

From an architectural perspective, certain embodiments provide an architecture for instrumentation that includes a logical process, a memory operable in communication with the processor, an execution image of an application software, and a instrumentation application programming interface (?instrumentation API ?).

In some embodiments, an execution image can be an image of a software program that is currently being executed by the computer system instrumentation. The software program may also have a separate image for pre-execution. The execution image is the same as the pre-execution, except that it does not include the usual address updates or other operations required to link and load an image. In some cases the execution image contains managed code. For example, garbage collection can be automatically managed by the runtime via mechanisms generated by the compiler. Pre-execution images may include one or several signed assemblies, and/or unsigned assemblies. So, an execution picture can be transformed to invalidate the signed assemblies that were used as the basis for the execution image prior to transformation.

In some embodiments the instrumentation API is stored in memory and directly accessible by a high level programming language. The high-level language could be, for example, a language that compiles into bytecode or a Common Language Infrastructure language.

In some embodiments the instrumentation API includes constituent interfaces such as a query and transformation interface. The query interface implements a query interface with code that, upon execution, will identify items in the execution picture which satisfy the query criteria specified in an invocation to the query interface, regardless of whether these items have been executed in the current execution. The transformation interface implements a transformation-interface implementation that, upon execution, transforms an item identified by a query interface implementation. This transformation alters the functionality of the current execution in the sense that the executed item (routine or instruction) has a different functionality from the functionality provided by the execution of that item without transforming it.

For example, the implementation of a transformation interface includes code that upon execution will perform at least the following: add code to the beginning or end of at lease one query satisfying function in the execution picture; insert a fault into at least on query satisfying function in the execution picture; replace a low level instruction in the execution without replacing an adjacent low level instruction and without changing any operand in any adjacent lower-level instructions; and replace atleast one operand in an individual instruction in the execution without replacing an adjacent low low-level instructon In some cases, the architecture transforms a query-satisfying element without changing the pre-execution picture. In some cases the pre-execution is altered, but this modification is not required for the transformation of the execution image.

In some embodiments, the transformations can be reversed, that is, undone, to restore the functionality of the execution image it had before the transformation. In some embodiments, the exact binary content is not restored. However, functionality is (e.g. “black box”). The impact of variables and peripheral devices is restored. The code for the implementation of the transformation interface can in some cases revert the transformation of one or more query-satisfying items without having to restart the execution of the software. In some cases, the transformation interface implementation code reverses transformation of atleast one query-satisfying element without restarting execution of the software program.

In some embodiments, a memory of the instrumentation system stores a query reply which identifies each item in the execution image of the program that meets the query criteria. (A sequence of coordinated queries may be treated as one query response.) In some embodiments the transformation interface implementation code transforms each item that satisfies the query criteria in the program’s executable image.

In some embodiments, memory of the architecture for instrumentation contains an instrumentation background for a currently executed image. The instrumentation background identifies a query-satisfying functionality that has not yet been executed. The present architecture does not limit instrumentation to only items that are currently in the execution path. This is unlike many (if not most) debugger-based instrumentation techniques.

The examples are only illustrative.” This summary is not meant to identify the key features or essential elements of the claimed object matter. Nor is it intended to limit the scope. This Summary is intended to provide a simplified version of some technical concepts which are described in greater detail below. “The innovation is defined by claims and, to the extent that this Summary conflict with the claims then the claims will prevail.