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

zhaozj2021-02-17  69

VXD technology and its application in real-time anti-viruses (11/03/1999) At present, the domestic Windows9x platform anti-virus products are mostly static anti-virus software, guiding ideology is "dominant", this way the shortcomings It is a virus that may have caused a serious hazardous anti-virus software before being cleared. It should be "defending the main to kill", which is removed when the virus invaded, which is real-time anti-virus technology. ---- Windows9x uses both IntelCPUs RING0 and RING3 two protection levels. The system process is running in RING0, thus having access to the system all resources; and the ordinary user process runs in Ring3, only to access its own program space, not allowing the system resource to access many operations to be limited. Obviously this ordinary user process is unable to work with real-time anti-virus, and must make the background monitoring process run in Ring0 priority, and the foundation of this is VXD technology. I. Features of VXD technology --- VxD, is a virtual device driver, used as an interface between Windows9x systems and physical devices. However, it is not only for hardware devices, but also for various software "devices" prepared by VXD specification ---- VXD technology is: By loading VXD with RING0 highest priority, running on RING3 applications It is possible to control the action of VXD at a certain interface, thereby achieving the purpose of the control system. Real-time anti-virus software to use VXD technology, the key is 2: (1) VXD Has the highest operation permission (2) Many windows9x system underlayer can only call in VXD, if you want to make VXD as an intermediary . Vxd as an agent in the system, the application passes it to complete anything you can't do. Through this means, the Windows9x system has left the expansion interface for ordinary applications. Unfortunately, this technology also used the virus, CiH virus is using VXD technology to resident, infecting documents, destroying hard drives and Flashbios. ---- WINDOWS9X system has many VXDs, each VXD provides 4 services, pm (protection mode) API, V86 (virtual 86) API, Win32 service, and VXD service, the first three suppliers 16-bit protection mode, V86 mode, and 32-bit protection mode, VXD services are only available for other VXDs to develop VXDs developed with users. In addition, the application can communicate with VXD supporting the IOCTL interface by calling the API function DeviceIoControl, performs low-level operations that Win32API not supported. Second, the implementation of VXD technology ---- VXD operation is based on register, so it is generally written in assembly language, and its key part is a similar control process similar to the message processing process of the normal window, which is different in its processing. Objects are control messages sent by the system. These messages have a total of 51 species. In VxD self-loaded to the entire life cycle, the operating system continues to send various control messages to it, and VXD is selected according to their own needs, and the rest is ignored. When the system sends a control message to the VXD, the message is placed in the EAX register and puts the system virtual machine (VM) handle in the EBX register. ---- For dynamic VXD, the most important news has three: sys_dynamic_device_init, sys_dynamic_device_exit, and W32_DeviceioControl, the message code is 1BH, 1CH, 23H, respectively. When VXD is dynamically loaded to memory.

The system sends a SYS_DYNAMIC_DEVICE_INIT message, and VXD should complete the initial setting and establish the necessary data structure. When VXD will be removed, the system sends SYS_DYNAMIC_DEVICE_EXIT messages vxd to clear the settings and release the relevant data. Structure; When the application call API function DeviceIOCONTROL communicates with VXD, the system sends a W32_DeviceIocontrol message to VXD, which is an important means of the application and VXD contact. At this time, the ESI register points to a DiocParams structure, VXD acquires the application from the input buffer. The data is transmitted, and the result is placed in the output buffer to return the application to achieve the purpose of transmitting data. ---- Application When you send a DeviceIocontrol call to the VXD, the second parameter is used to specify what is controlled, and the control process acquires this control code from DiocParams Structure 0CH and then performs the code number and meaning of the corresponding processing control code by the application and VXD is agreed, the system prefers two control code for Dioc_getversion (0) and Dioc_CloseHandle (-1), when the application calls the API function createfile (". Vxdname", ". VxDName", when the system is loaded, the system first VXD control process sends a sys_dynamic_Device_init control message. If VxD returns successfully, the system will send the W32_DeviceIoControl message with the VXD to VXD to determine if this VXD can support the device IOCTL interface, VXD must be clear The zero EAX register indicates the support IOCTL interface. At this time, CREATEFILE will return a device handle HDEvice, and the application can be controlled using the DeviceIocontrol function using the DeviceIocontrol function. The same VXD can be opened multiple times with CreateFile, and each of which returns a unique handle of this VXD, but only one VXD is retained in the system memory, and the system maintains a reference count for each VXD, each opens a count value plus 1. When the application call API function closeHandle (HDEvice) turns off the VXD handle, VXD will receive the system's distributed Dioc_CloseHandleW32_Deviceiocontrol message, at the same time that the VXD is reduced by 1, when the final reference count is 0, the system is sent to VXD Control Message Sys_Dynamic_Device_exit, then clear it from memory. In very few cases, the application can also call the API function deletefile (". Vxdname") ignoring the value of the reference count directly to the VXD, which will give a devastating impact on other applications using the same VXD, should be avoided.

- a typical VxD control process code is as follows: BeginProcVXD_Control cmpeax, 1Bh; SYS_DYNAMIC_DEVICE_INIT message jzvxd_dynamic_init_handle cmpeax, 1Ch; SYS_DYNAMIC_DEVICE_EXIT message jzvxd_dynamic_exit_handle cmpeax, 23h; W32_DEVICEIOCONTROL message jnzexit_control_proc movecx, [esi 0Ch]; from DIOCParams 0Ch the access control code ....; Processing the control code endprocvxd_control three, the key technology of real-time anti-virus - Filehooking ---- Application Indirectly obtains control of Windows 9x system by using dynamically loaded VXD, but to implement all file I / O operations in the system Real-time monitoring, also use another key technology -filehooking, intercepting all system calls related to file I / O operations by hooking by a handset. Windows9X uses 32-bit protection mode to install file system (IFS), which is accessible to file system and devices, which receives access to file systems and devices, which receives file I / O requests to the system in Win32API function calls. The request forwarded to the file system driver FSD, which is finally accessed by calling the low level IOS system. Each file I / OAPI call has a specific FSD function, and ifsmanager is responsible for completing the parameter assembly work by the API to FSD, it will call before the assembly of the file I / OAPI function parameter is completed. A HOOKER function called FileSystemapiHookFunction. By installing your own HOOKER function, you can intercept the API calls in the system, and perform a virus check on the relevant files in time to implement real-time monitoring. ---- above-mentioned process is completed by the service user VxD call system VxDIFSMgr provided by the VxD provides a wealth of underlying file operating functions: IFSMgr_InstallSyatemApiHook function is used to install FileSystemApiHookFunction, IFSMgr_RemoveSystemApiHook to dismount Hooker, IFSMgr_Ring0_FileIO used for file and disk fan Learning access, etc. When transferring to SystemapiHookFunction by IFSManager, with 6 parameters: FileSystemapiHookFunction (PIFSFUNCFSDFNADDR, // Corresponding to FSD Service Function Address INTFUNCTIONNUM, / / ​​The FSD service function number corresponding to the API (see below) INTDRIVE, // Drive code (1 = A, 2 = b, 3 = c ...) intResourceFlags, // Resource Sign (see below) INTCODEPAGE, // code page (0 = ANSI, 1 = OEM) PiOREQPIR // Pointer to the ioreq structure) - --- More important in parameters is the FSD function number, drive letter and IOREQ structural pointer 3 items. If you need to interceise a file I / OAPI call, you only need to process the corresponding FSD function number in Hooker - there are multiple Hookers that can be hooked in the system to form a chain. IFSMGR_INSTALLESYSTEMAPIHOOK Install Hooker to return to the previous HOOKER address, each hooker will always call the previous HOOKER before doing a specific process, and finally installed Hooker is first called.

转载请注明原文地址:https://www.9cbs.com/read-30919.html

New Post(0)