VXD technology and its application in real-time anti-virus

The current domestic WINDOWS9X platform anti-virus products are mostly static anti-virus software, the guiding ideology is "to kill the main", the disadvantage of this approach is that the virus may have already caused a serious harm before it is removed. A good anti-virus software should be "in case of the main, to kill as a supplement", in the virus invasion when it cleared away, This is the real time anti-virus technology.

Windows9x uses Intelcpu's RING0 and Ring3 two protection levels. The system process runs in RING0, so it has access and management rights to all resources of the system, while the ordinary user process runs in Ring3, can only access its own program space, does not allow direct access to system resources, many operations are limited. Obviously this common user process is not capable of real-time anti-virus work, the background monitoring process must be run in the RING0 priority, to achieve this is based on the VxD technology.

The characteristics of VXD technology

A VxD is a virtual device driver that serves as an interface between a windows9x system and a physical device. But it is not only suitable for hardware devices, but also applicable to various software "devices" prepared by the VXD specification.

The essence of VXD technology is: by loading the VxD with RING0 highest priority, the application running on Ring3 can control the action of VxD with a certain interface, so as to achieve the aim of control system. Real-time anti-virus software to use the VXD technology, the key is two: (1) VxD has the highest operating permissions (2) Many windows9x system low-level functions can only be invoked in a VxD, the application must be a VxD as an intermediary. VXD as an application in the System Agent, the application through it to do anything itself can not do, by this means, the windows9x system for ordinary applications leave an extension interface. Unfortunately, this technology is also used by the virus, CIH virus is the use of VXD technology to host memory, infection execution files, destroy hard drives and Flashbios.

Windows9x system has a number of VxD, each VXD can provide 4 kinds of services, that is, the PM (Protection mode) API, V86 (virtual) API, Win32 service and VxD service, the first 3 are respectively for the application in 16-bit protection mode, V86 mode and 32-bit protection mode call, The VxD service only provides any of these services to other VxD users with a VxD developed by the user. In addition, the application can communicate with a VxD that supports IOCTL interfaces by calling API functions DeviceIoControl, performing low-level operations that WIN32API does not support.

Second, the realization of VXD technology

The operation of VxD is based on registers, so it is usually written in assembly language, and its key part is a similar control process wndproc the message processing process of ordinary windows, except that its processing object is the control message sent by the system. 51 of these messages, in the VxD from loading to unload the entire life cycle, the operating system to send it a variety of control messages, VxD according to their own needs to choose processing, the rest of the neglect. When the system sends a control message to a VxD, it places the message name in the EAX register and places the system virtual machine (VM) handle in the EBX register.

For a dynamic VxD, the most important messages are three: Sys_dynamic_device_init, Sys_dynamic_device_exit, and W32_deviceiocontrol, the message code is 1BH, 1Ch, 23h, respectively. When a VxD is dynamically loaded into memory.

The system sends a SYS_DYNAMIC_DEVICE_INIT message to it, and the VxD should complete the initialization settings and establish the necessary data structure at this point, and the system will send the Sys_dynamic_device_ when the VxD is unloaded. The exit message VxD should clear the settings and release the relevant data structure when it is received; the system sends a W32_DEVICEIOCONTROL message to the VxD when the application calls the API function DeviceIoControl to communicate with the VxD. It is an important means of connecting applications and VxD, when the ESI registers point to a diocparams structure, the VxD obtains the application data from the input buffer, and then, after processing, puts the result in the output buffer loopback application to communicate the data to each other.

When an application makes a DeviceIoControl call to a VxD, the 2nd parameter is used to specify what kind of control to take, and the control process obtains the control code from the DIOCPARAMS structure +0ch and then handles the code and the meaning of the control code by the application and the VxD themselves, The system has predefined dioc_getversion (0) and Dioc_closehandle (-1) Two control codes when the application invokes API function CreateFile ("\\.\vxdname",...) When dynamically loading a VxD, the system first sends the SYS_DYNAMIC_DEVICE_INIT control message to the control process of the VxD, and if the VxD returns successfully, the system will send a control code Dioc_open to the VxD again (that is, dioc_getversion, the value is 0) W32_deviceiocontrol message to determine if this VxD is capable of supporting the device IOCTL interface, the VxD must clear the 0 EAX registers to indicate support for the IOCTL interface, at which point CreateFile will return a device handle hdevice. It can be used to control a VXD using the DeviceIoControl function.

The same VxD can be opened multiple times, each time a unique handle to this VxD is returned, but only one createfile is kept in the system memory, and the system maintains a reference count for each VXD, plus 1 for each time the meter is opened. When the application invokes the API function CloseHandle (Hdevice) to close the VxD handle, the VxD receives the control-code Dioc_closehandlew32_deviceiocontrol message sent by the system, with the reference count of the VxD minus 1. When the final reference count is 0 o'clock, the system sends a control message sys_dynamic_device_exit to the VxD and clears it from memory. In rare cases, an application can also invoke the API function DeleteFile ("\\.\vxdname") to omit the value of the reference count to remove the VxD directly from memory, which will have devastating effects on other applications that use the same VxD, and should be avoided.

--A typical VxD control process code is as follows:

Beginprocvxd_control

CMP EAX,1BH

; Sys_dynamic_device_init message

JZ Vxd_dynamic_init_handle

CMP eax,1ch

; Sys_dynamic_device_exit message

JZ Vxd_dynamic_exit_handle

CMP eax,23h

; W32_deviceiocontrol message

JNZ Exit_control_proc

MOV ecx,[esi+0ch]

; Take the control code from the DIOC params+0ch

....

; Processing control codes

Endprocvxd_control