Of a special registry key “AppInit_Dlls”
If you understand computer security, then the start of a wide range of the registry should understand, I will detail today a very well-known start-up of: AppInit_Dlls key.
AppInit_Dlls key in the registry HKLM \ Microsoft \ Windows NT \ CurrentVersion \ Windows Below, relative to other start of the registry, the key lies in the unique to any use of the User32.dll EXE, DLL, OCX, etc. Types of PE will read this document, and in accordance with the agreed specification under this key point to the DLL file loading, the load is the way call LoadLibrary.
There are many authentication methods, the most likely to think of is to use the debugger, the LoadLibrary calls when the breakpoint, you will find User32.DLL read this key and use the LoadLibrary to call this key point to the DLL files. A better way is to look at the KB197571 introduced.
AppInit_Dlls the key is a very dangerous keys, to some extent, this is a Windows were most likely to use the loophole, for as long as there is any malicious software was modified in here, then it means that any use to User32.DLL the process will be AppInit_DLLs pointing to the DLL by injection. DLL because the process is shared within the space of the whole process, it means that the process inside the DLL can control the whole process of. As User32.DLL is a very, very common DLL, it provides a majority of Win32 user interface, information-related functions, only a handful of the procedures will not use User32.DLL, so once the malicious software modified AppInit_Dlls keys, then the whole System could in a very dangerous state.
As we all know, Windows service time for the start-up procedures can be very early, often before the user log on to complete a start, but this time the most common Run key is not necessarily processed, and Windows service program has a very high authority (Default is the Local System, the system can be inside all the resources to conduct operations), so if a malicious software will be loaded into the Windows service inside, then will be very dangerous. Previously mentioned, any process used User32.DLL, will be the key point to the AppInit_Dlls DLL to load, if it is a Windows service procedures, is no exception!
As AppInit_Dlls is a global system of Hook (system-wide hook), to avoid this kind of Hook is very difficult, although the use of driver protection to avoid such problems, but it does not have to use a driver to handle the . Wen said before, only to User32.DLL when using this module will be the time to read AppInit_Dlls trigger point to the DLL, if we do not use User32.DLL, then AppInit_Dlls will not be used to. But to make a program do not use User32.DLL will become very difficult (not to use the command line window User32.DLL), because any window, and all information related to this module, in order to guarantee a good user experience, 100% of the window And procedures relating to this module. From the development point of view, the best solution is to feature logic and interface logic completely isolated, functional module responsible for the functional logic, interface logic module responsible for the interface, 2 IPC mechanism between the use of an interactive, functional logic modules Do not rely on User32.DLL,, but also as an independent process for dealing with so you can avoid the AppInit_Dlls the Hook.
Windows similar safety-related defects in fact there are many points, these shortcomings point is to ensure that the source of downward compatibility. I believe MIcrosoft has been found and is being repaired such places, from Windows Vista can see, AppInit_Dlls the key in Windows Vista is not working, so in Windows Vista inside, the keys have been abandoned (to switch to another Key similar functions, but an increase of security based on the UAC).
Bookmark:Digg Del.icio.us Reddit
