Microsoft Technology Licensing, LLC

Nir Ben Zvi

Kristjan Eric Hatlelid

Paul J Leach

Mark Fishel Novak

Arun K Nanda

Vishal Agarwal

Aaron Payne Goldsmid

Pranav Kukreja

David McPherson

Donald H Rule

Ramaswamy Ranganathan

Andrey Lilikov

Nathan Jeffrey Ide

Ping Xie

Hakki Tunc Bostanci

Matthias Hermann Wollnik

Jignesh Shah

Sunil P Gottumukkala

John Richard McDowell

Andrey V Lelikov

Ming Tang

Andrey Popov

Scott Miller

Manoj R Mehta

Resource authorization policies and resource scopes may be defined separately, thereby decoupling a set of authorization rules from the scope of resources to which those rules apply. In one example, a resource includes anything that can be used in a computing environment (e.g., a file, a device, etc.). A scope describes a set of resources (e.g., all files in folder X, all files labeled 'Y', etc.). Policies describe what can be done with a resource (e.g., 'read-only,' &#x201c;read/write,&#x201d; &#x201c;delete, if requestor is a member of the admin group,&#x201d; etc.). When scopes and policies have been defined, they may be linked, thereby indicating that the policy applies to any resource within the scope. When a request for the resource is made, the request is evaluated against all policies associated with scopes that contain the resource. If the conditions specified in the policies apply, then the request may be granted.

Scoped resource authorization policies

A policy that governs access to a resource may be tested against real-world access requests before being used to control access to the resource. In one example, access to a resource is governed by a policy, referred to as an effective policy. When the policy is to be modified or replaced, the modification or replacement may become a test policy. When a request is made to access the resource, the request may be evaluated under both the effective policy and the test policy. Whether access is granted is determined under the effective policy, but the decision that would be made under the test policy is noted, and may be logged. If the test policy is determined to behave acceptably when confronted with real-world access requests, then the current effective policy may be replaced with the test policy.

Testing access policies

Presented is an anti-tampering method that validates and protects specific sections of a binary file. In one embodiment, this method permits a proxy engine to execute (via emulation by a virtual machine) the protected code on behalf of the binary in kernel mode upon successful completion of an integrity check. The integrity check can optionally check only the specific parts of code that the developer wishes to validate. The integrity check can cross binary boundaries. Moreover, the integrity check can be done on a hard drive or in memory. Furthermore, since the encrypted code is executed by the proxy engine in kernel mode, hackers are further deterred from modifying the code. Additionally, a method of creating a protected binary file is described herein.

Authentication of binaries in memory with proxy code execution

Upon a first process encountering a triggering device, a second process chooses whether to proxy-execute code corresponding to the triggering device of the first process on behalf of such first process based at least in part on whether a license evaluator of the second process has determined that the first process is to be operated in accordance with the terms and conditions of a corresponding digital license. The license evaluator at least in part performs such determination by running a script corresponding to the triggering device in the code of the first process. Thus, the first process is dependent upon the second process and the license for operation thereof.

First computer process and second computer process proxy-executing code on behalf of first process

A method of validating software is disclosed. The method may include receiving, at a first function, a first hash and a first version. The first function may validate a second function according to the first hash and first version. The second function may receive a second hash and a second version, and the second function may validate a third function according to the second hash and second version. The first version and first hash may be stored within the first function, for example. The first version and first hash may be stored within a manifest, for example. In another embodiment, a method of validating software may include storing a plurality of functions and storing a version and hash for each function. Each function may be verified according to the respective version and hash, and each function may verify at least one other function.

Renewable integrity rooted system

A method to apply a protection mechanism to a binary object includes using operating system resources to load a binary object from a storage medium along with a manifest and a digital signature. Authentication of the binary object is performed using the digital signature and the manifest is read to determine a category of protection for the binary object. The operating system selects a protection mechanism corresponding to the protection category and injects protection mechanism code, along with the binary object into a binary image on computer RAM. When the binary image is accessed, the protection mechanism executes and either allows full access and functionality to the binary object or prevents proper access and operation of the binary object. The protection mechanisms may be updated independently from the information on the storage medium.

Software protection injection at load time

A mechanism for redirecting a code execution path in a running process. A one-byte interrupt instruction (e.g., INT 3) is inserted into the code path. The interrupt instruction passes control to a kernel handler, which after executing a replacement function, returns to continue executing the process. The replacement function resides in a memory space that is accessible to the kernel handler. The redirection mechanism may be applied without requiring a reboot of the computing device on which the running process is executing. In addition, the redirection mechanism may be applied without overwriting more than one byte in the original code.

Changing code execution path using kernel mode redirection

Growing community of inventors

Redmond, WA, United States of America

Nir Ben Zvi