Reading Note _ verification mechanism in windows

Common testing methods include:

Black box testing

White box testing

Built-in self-check (BIST, Built-InSelf-Test) refers to building some Test functions within the software code, which can be executed in some situations, or it is called by the automated testing tool to detect problems.

Stress Testing (Stresstesting) is used to test the performance of the Target Program under high loads and low resources.

The authentication mechanism in Windows can simulate extreme and demanding operating environments, so that errors can be exposed more easily.

Verification mechanisms in Windows include driver validators and application validators.

First, let's look at the Driver Verifier, which is mainly used to verify various device drivers and kernel modules. The main driver verification tool is a series of kernel functions and global variables in the internal Kernel File (ntoskernl.exe). The names are mostly Verifier words or begin with Vi and Vf. For example, nt used to verify the memory pool! VerifierFreePool, used to verify nt for IRQL reduction operations! VerifierKeLowerIrql.

(Brief introduction to IRQL)

IRQL (Interrupt Request level) indicates the Interrupt Request level, which is used to prioritize Interrupt requests in windows. Common IRQL levels include:

PASSIVE_LEVEL: the lowest level of IRQL, with no blocked interruptions. At this level, the thread executes the user mode and can access the paging memory.

APC_LEVEL: at this level, only APC-level interruptions are blocked and paging memory can be accessed. When an APC occurs, the processor is upgraded to the APC level. In this way, other APC will be blocked. To perform some synchronization with the APC, the driver can be manually upgraded to this level. For example, if it is upgraded to this level, APC cannot be called. At this level, APC is disabled, and some I/O operations are prohibited, so some APIs cannot be called.

DISPATCH_LEVEL: at this level, DPC and lower interruptions are blocked, and paging memory cannot be accessed. All accessed memories cannot be paged. Because only non-Paging memory can be processed, at this level, the number of APIs that can be accessed is greatly reduced.

DIRQL: Generally, more advanced drivers do not process IRQL at this level, but almost all interruptions are blocked. This is actually a range of IRQL, this is a method that determines that a driver has a higher priority.

Design Principle of driver validators:

The basic design idea of the driver validator is to execute various checks on the driver when the driver calls the device driver interface (DDI) function to check whether it meets the system-defined design requirements.

Windows uses the Import Address Table (IAT) to HOOK the DDI call of the driver by modifying the input Address Table of the verified driver, that is, the IAT Hook method introduced in my blog. The implementation method is to replace the DDI function address in the verified driver IAT table with the address of the verified function. Therefore, when the driver calls the DDI function, it calls the corresponding verification function.

The purpose of the function is:

1. Update the counter or global variable

2. Check the call parameters or perform other checks. if an exception is found, the KeBugCheckEx function is called and the blue screen mechanism is used to report the verification failure.

3. If no problem is found, the original function will be called.

Let's take a look at the execution process of the verification function:

1. initialization Process: The Memory Manager's initialization function MmInitSystem calls the initialization function of the driver validators to initialize the driver validators, it creates and initializes a linked list to store driver verification information. windows uses the global variable MiSuspectDriverList to record this linked list. Each node in the suspicious Drive Linked List is a MI_VERIFIER_DRIVER_ENTRY structure used to record a verified driver.

2. Hook verification function Process

When the system loads a kernel module, it calls the MiApplyDriverVerifier function. The task of this function is to query whether the module to be loaded is in the suspicious driver list, it indicates that this is a verified driver and calls the MiEnableVerifier function to modify its IAT table.

For modules loaded by OS Loader (NTLDR), when the driver validators are initialized (Phase 0 initialization), The MiInitialzeVerifyComponents function of the driver validators traverses all loaded modules, and then call miapplydriverververifier. For drivers to be loaded later, the memory manager's working function (MiLoadSystemImage) will call MiApplyDriverVerifier to give the driver validators a chance to check. After the verification function is attached, once the kernel function is called, its verification function will be executed first.

3. verification process

The driver validators introduced by Windows2000 contain some basic verification items

Automatic check: checks whether memory is used at the appropriate IRQL level, whether an inappropriate stack is switched, and whether the memory pool containing the active timer is released, whether to obtain and release the spin lock at the appropriate IRQL level. After the driver is detached, the system also checks whether all resources have been released.

A special memory pool allocates memory for the driver from a special memory pool. The system has an enhanced monitoring function for this memory pool to detect overflow, underrun, and access errors after release.

The forced IRQL check forces the paging memory used by the driver to expire, and monitors whether the driver accesses paging memory or holds a spin lock at the wrong IRQL level.

Low resource simulation. If a request or other resource request is allocated to the driver's memory, an error is returned.

Pool Tracking records the memory allocated by the driver and determines whether it is all released when released.

I/O verification: allocates IRP (I/O Request Packet) from a special memory pool and monitors driver I/O processing.

Windows XP introduces some new verification items

Deadlock Detection, enhanced I/O verification, and SCSI Verification

Windows Server 2003

IRP Logging)

Windows Vista introduces

Driver Hang Detection, Completion Routine, Cancellation Routine

Security check

Force I/O Request to wait for resolution

Fragmented check

4. enable the driver verification.

In the run dialog box, enter Verifier and click OK to enter the graphic interface. Windows XP is in wizard mode. You can also use the command line mode. The interface is as follows:

After the driver verification is started, you need to restart the system to make the settings take effect, because the system only initializes the suspicious driver linked list during startup. Windows Vista enhances the driver validator so that the verification takes effect without restarting. Windows 7 has not been verified, so should it be.

The information of each driver is recorded in the MI_VERIFIER_DRIVER_ENTRY structure corresponding to the driver in the suspicious linked list. In addition, the global information is recorded in the global variable MmVerifierData. You can use WinDBG to observe these values. Special extension commands are designed in the middle of the WinDBG toolkit ,! Verifier. For more information, see the winDBG help document.

 

Application validators

Similar to the driver validators, the application validators also use IAT hooks to verify that they comply with the design specifications defined by the Windows SDK. The app verifier is included in the app verification kit and can be obtained from the installation disc of Windows XP or the Microsoft website. Detailed descriptions will be provided later.