Quote
The Windows Vista operating system introduces a new type of process, called a protected process, that enhances support for digital rights management functionality in Windows Vista and Windows Longhorn Server. These protected processes exist alongside typical processes in Windows Vista.
Differences between a Typical Process and a Protected Process. The primary difference between a typical Windows process and a protected process is the level of access that other processes in the system can obtain to protected processes.
In earlier versions of Windows operating systems, before Windows Vista, the process model allows a parent process to acquire a handle to and manipulate the state of any child process it creates. Similarly, processes that are created by users with sufficient privileges (that is, a system administrator) can access and manipulate the state of all processes on the system. This behavior remains unchanged for typical Windows processes. However, the level of access to protected processes and to threads within those processes is significantly more constrained in Windows Vista.
Significant Functionality Constraints of Protected Processes. Developers who are accustomed to interacting with typical Windows processes will notice the following significant differences in interacting with protected processes. A typical Windows process cannot take the following actions on a protected process:
1. Inject a thread into another process. A call to CreateRemoteThread requires a handle that must have the PROCESS_CREATE_THREAD, PROCESS_QUERY_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_WRITE, and PROCESS_VM_READ access rights
2. Debug an active protected process. A call to DebugActiveProcess requires PROCESS_ALL_ACCESS.
Which Applications Can Create a Protected Process. Currently only the Windows Protected Media Path can create protected processes.
Vendors of any product that monitors and reports on processes in the system (such as software debuggers, anti-malware applications, and so on) should be aware of the specific constraints on protected processes and should test their software on systems that are running protected processes.
Differences between a Typical Process and a Protected Process. The primary difference between a typical Windows process and a protected process is the level of access that other processes in the system can obtain to protected processes.
In earlier versions of Windows operating systems, before Windows Vista, the process model allows a parent process to acquire a handle to and manipulate the state of any child process it creates. Similarly, processes that are created by users with sufficient privileges (that is, a system administrator) can access and manipulate the state of all processes on the system. This behavior remains unchanged for typical Windows processes. However, the level of access to protected processes and to threads within those processes is significantly more constrained in Windows Vista.
Significant Functionality Constraints of Protected Processes. Developers who are accustomed to interacting with typical Windows processes will notice the following significant differences in interacting with protected processes. A typical Windows process cannot take the following actions on a protected process:
1. Inject a thread into another process. A call to CreateRemoteThread requires a handle that must have the PROCESS_CREATE_THREAD, PROCESS_QUERY_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_WRITE, and PROCESS_VM_READ access rights
2. Debug an active protected process. A call to DebugActiveProcess requires PROCESS_ALL_ACCESS.
Which Applications Can Create a Protected Process. Currently only the Windows Protected Media Path can create protected processes.
Vendors of any product that monitors and reports on processes in the system (such as software debuggers, anti-malware applications, and so on) should be aware of the specific constraints on protected processes and should test their software on systems that are running protected processes.
For the uninitiated, most tools designed to bypass DRM do so by the inject/debug techniques. Also note that this protection is built into the kernel. Any attempts to modify the kernel will result in a BSOD, so there is no way to disable this protection.
This post has been edited by Aegis: 12 July 2006 - 09:16 PM



Help

Back to top









