A common technique that hackers use to diguise themselves on compromised systems is installing a "rootkit", which is typically a program or suite of programs used to cover up evidence of intrusion and to hide tojans and other applications and data (such as agents used in Distributed Denial of Service (DDOS) attacks). One of the most powerful rootkit techniques is to alter the behavior of the operating system by running as a kernel driver in privileged mode. These applications are capable of hiding processes, files, directories, registry keys and values. They also alter the access control mechanisms and manipulate the Operating System in other ways.

The IPD uses some of the same techniques as rootkits to attempt to block new drivers from being installed or executed by anyone, including Administrator or System. The goal is to block any new device drivers from executing at all, even on a compromised system.

For more information on rootkits, see www.rootkit.com.

The IPD uses undocumented service function hooking to alter access rights on driver-related registry keys, values and files to be read-only no matter what account is requesting access. This effectively prohibits the Service Control Manager or user applications from changing service and driver keys and values in the registry and from adding to or replacing existing driver binaries in the %SystemRoot%\system32\drivers directory.

• The IPD provides Registy protection for existing drivers. It blocks changes and additions to registry keys and values within the "services" section of the registy (HKLM\System\CurrentControlSet\Services), including the ControlSet00x ones.

• The IPD provides file protection for existing drivers. It blocks the writing, deleting and adding of files and directories within the %SystemRoot%\system32\drivers directory (not including the etc directory).

The IPD restricts all processes except some system processes(*) from obtaining the following privileges:

• Debug Privilege
• TCB Privilege
• Create Token Privilege
• Assign Primary Token Privilege

The IPD forbids any process from opening \Device\PhysicalMemory.

The IPD forbids any process, except select system processes, from creating threads in others processes and from writing in the virtual memory space of other processes.

The IPD blocks driver loading via SystemLoadAndCallImage.

(*) See h_tok.c for a list of the system images that are permitted these privileges.

The IPD starts immediately at boot time, but does not engage until 20 minutes after startup.

For a complete list of system calls that are intercepted, click here.

Download the lastest release (Source and Binaries)

The IPD and accompanying source code are licensed under an Open Source license that lets you use, view and modify the source code. See the readme file that accompanies the distribution or click here for the precise terms.

To install the IPD device driver, open a command prompt and change your working directory to the location of your unzipped distribution. Execute the ipdinstall.exe program to install and start the driver:

ipdinstall.exe install

The driver is installed for "automatic" startup, which means it will automatically start at system boot. The driver engages 20 minutes after it has started.

IMPORTANT:

* Once the Driver is started it may not be stopped.

* Once the Driver is engaged it may not be removed. Even if the appropriate Service Control Manager function call marks the driver for deletion, the driver will still not be removed.

IPD can only be removed before it engages 20 minutes after startup. After removing the IPD, you must reboot the computer. If the driver has already engaged then you will have to reboot and remove it within 20 mintes of boot up.

Issue this command to remove the dirver:

ipdinstall.exe remove

The IPD attempts to block known methods for loading and executing device driver code. There may be undocumented or undiscovered methods for installing and executing driver code. As new methods are discovered the IPD can be updated to counter those methods.

The IPD is designed to alter the operating system's normal operating behavior. In doing so, there will be some loss of functionality. The following are some of the constraints you may encounter:

\Device\PhysicalMemory issues:

NTVDM requires access to \Device\PhysicalMemory on startup. This means that no 16-bit applications will work (unless an NTVDM session was running before the IPD driver engaged and the 16-bit application is not configured to run in it's own memory space). Some screen savers will not work because of this.

Legitimate device drivers may attempt to open \Device\PhysicalMemory during normal operation. The IPD will block these attemps and so may cause unexpected results. So far, we have not encountered any device drivers that do this after startup.

Debugging Programs:

The IPD blocks the ability to debug programs.

There is no support. Bug reports should be sent to
bugs@pedestalsoftware.com.