Explanation of special registry key value AppInit_Dlls

Source: SCID Author: smallfrogs

If you have some knowledge about computer security, you should be familiar with a variety of Registry Startup items. Today I will describe a very famous startup Item: AppInit_Dlls key value.

The AppInit_Dlls key value is located under the HKLMMicrosoftWindows NTCurrentVersionWindows registry. Compared with other registry startup items, the special feature of this key value is that any PE file that uses the EXE, DLL, OCX and other types of User32.dll will read this location, load the DLL file pointed to by this key value according to the agreed specifications by calling LoadLibrary.

There are many verification methods, and the most easy to think of is the use of the debugger, when LoadLibrary calls a breakpoint, you will find that User32.DLL reads this key value and uses LoadLibrary to call the DLL file pointed to by this key value. A better way is to take a look at the introduction of KB197571.

The key value of AppInit_Dlls is a very dangerous key value. To some extent, this is the most vulnerable vulnerability in Windows, as long as any malware is modified here, it means that any process using User32.DLL will be injected by the DLL pointed to by AppInit_DLLs. Because the DLL in the process shares the whole process space, it means that the DLL in the process can control the behavior of the whole process. Because User32.DLL is a very common DLL, it provides a majority of Win32 user interfaces, message-related functions, only a few programs will not use User32.DLL, therefore, once a malware modifies the AppInit_Dlls key value, the entire system may be in a very dangerous state.

As we all know, the startup time of Windows service programs can be very early, and it is often started before the user logs on. At this time, the most common Run key value is not necessarily processed, in addition, Windows service programs have high permissions (the default is Local System, which can operate on all resources in the System). Therefore, if a malware is loaded into Windows Services, this is very dangerous. As mentioned above, any process that uses User32.DLL will load the DLL to which the AppInit_Dlls key value points. If it is a Windows service program, it is no exception!

Because AppInit_Dlls is a system-wide Hook, it is really difficult to avoid such hooks. Although using the driver for protection can avoid such problems, however, it is not necessary to use the driver for processing. As mentioned above, only when the User32.DLL module is used will the DLL pointed to by AppInit_Dlls be read. If User32.DLL is not used, AppInit_Dlls will not be used. However, it is very difficult for a program not to use User32.DLL (the command line window does not use User32.DLL) because any windows and messages are related to this module. To ensure a good user experience, 100% of window programs are related to this module. From the perspective of development, the best solution is to completely separate the functional logic of the program from the interface logic. The functional logic module is responsible for the function, and the interface logic module is responsible for the interface display, the two interact with each other using the IPC Mechanism. The functional logic module does not rely on User32.DLL and is processed as an independent process. This avoids the Hook caused by AppInit_Dlls.

There are many defects related to Windows security. The source of these defects is to ensure downward compatibility. I believe MIcrosoft has found and is patching these places. from Windows Vista, we can see that the AppInit_Dlls key value does not work on Windows Vista, so in Windows Vista, this key value has been discarded (this function is similar to another key value, but UAC-based security protection is added ).