- 欢迎访问起航教学!
特殊注册表键值AppInit_Dlls
12-14 18:36:14 分类:电脑技巧 浏览次数: 833次
标签:电脑技巧大全,http://www.qihang56.com
特殊注册表键值AppInit_Dlls,
特殊注册表键值"AppInit_Dlls"
如果对计算机安全有所了解,那么各种各样的注册表启动项应该会有所了解,今天我会细述一个很著名的启动项:AppInit_Dlls键值。
AppInit_Dlls键值位于注册表 HKLM\Microsoft\Windows NT\CurrentVersion\Windows下面,相对于其他的注册表启动项来说,这个键值的特殊之处在于任何使用到User32.dll 的EXE、DLL、OCX等类型的PE文件都会读取这个地方,并且根据约定的规范将这个键值下指向的DLL文件进行加载,加载的方式是调用 LoadLibrary。
验证方法有很多,最容易想到的就是使用调试器,在LoadLibrary调用的时候下断点,你会发现User32.DLL读取了这个键值并且使用了LoadLibrary去调用这个键值指向的DLL文件。一个更好的方法就是看看 KB197571 的介绍了。
AppInit_Dlls的键值是一个非常危险的键值,从某种程度上来说,这是一个Windows最容易被人利用的漏洞,因为只要有任何的恶意软件在这里进行了修改,那么就意味着任何使用到User32.DLL的进程都会被AppInit_DLLs指向的DLL所注入。因为进程内部的DLL是共享整个进程空间的,因此意味着进程里面的DLL是可以控制整个进程的行为的。由于User32.DLL是一个非常非常通用的DLL,它提供了大多数Win32用户界面、消息相关的功能,只有极少数的程序不会使用User32.DLL,因此一旦有恶意软件修改了AppInit_Dlls键值,那么整个系统都有可能处于非常危险的状态。
众所周知,Windows服务程序的启动时机是可以非常早的,往往在用户登录之前就完成启动了,而这个时候最常见的Run键值还不一定被处理完,而且Windows服务程序拥有相当高的权限(默认是Local System,可以对系统里面所有的资源进行操作),因此如果一个恶意软件被加载到Windows服务里面,那么是会非常危险的。前文提到,任何进程使用了User32.DLL,都会对AppInit_Dlls键值指向的DLL进行加载,如果是一个Windows服务程序,也不例外!
由于AppInit_Dlls是一种系统全局性的Hook(system-wide hook),要规避此类的Hook的确很困难,虽然使用驱动程序进行保护能够规避此类问题,但也不是非要使用驱动程序进行处理的。前文说过,只有当使用到User32.DLL这个模块的时候才会触发读取AppInit_Dlls指向的DLL,如果不使用User32.DLL,那么AppInit_Dlls是不会被使用到的。但是要让一个程序不使用User32.DLL会变得非常困难(命令行窗口没有使用User32.DLL),因为任何的窗口、消息都和这个模块有关,为了保证有良好的用户体验,100%的窗口程序都和这个模块有关。从开发角度来说,最好的一种解决办法就是将程序功能逻辑和界面逻辑完全分离,功能逻辑模块负责功能,界面逻辑模块负责界面显示,2者之间采用IPC机制进行交互,功能逻辑模块不依靠User32.DLL,,而且作为独立进程进行处理,这样就可以规避AppInit_Dlls造成的Hook了。
类似的Windows安全相关的缺陷点其实还有很多的,这些缺陷点的来源是为了保证向下的兼容性。相信MIcrosoft已经发现并正在修补这些地方,从Windows Vista上可以看到,AppInit_Dlls的键值在Windows Vista上是不起作用的,因此在Windows Vista里面,这个键值已经被抛弃了(改用另外一个键值执行类似的功能,但是增加了基于UAC的安全防护)。
本文来自 http://www.qihang56.com 谢谢支持!
特殊注册表键值"AppInit_Dlls"
如果对计算机安全有所了解,那么各种各样的注册表启动项应该会有所了解,今天我会细述一个很著名的启动项:AppInit_Dlls键值。
AppInit_Dlls键值位于注册表 HKLM\Microsoft\Windows NT\CurrentVersion\Windows下面,相对于其他的注册表启动项来说,这个键值的特殊之处在于任何使用到User32.dll 的EXE、DLL、OCX等类型的PE文件都会读取这个地方,并且根据约定的规范将这个键值下指向的DLL文件进行加载,加载的方式是调用 LoadLibrary。
验证方法有很多,最容易想到的就是使用调试器,在LoadLibrary调用的时候下断点,你会发现User32.DLL读取了这个键值并且使用了LoadLibrary去调用这个键值指向的DLL文件。一个更好的方法就是看看 KB197571 的介绍了。
AppInit_Dlls的键值是一个非常危险的键值,从某种程度上来说,这是一个Windows最容易被人利用的漏洞,因为只要有任何的恶意软件在这里进行了修改,那么就意味着任何使用到User32.DLL的进程都会被AppInit_DLLs指向的DLL所注入。因为进程内部的DLL是共享整个进程空间的,因此意味着进程里面的DLL是可以控制整个进程的行为的。由于User32.DLL是一个非常非常通用的DLL,它提供了大多数Win32用户界面、消息相关的功能,只有极少数的程序不会使用User32.DLL,因此一旦有恶意软件修改了AppInit_Dlls键值,那么整个系统都有可能处于非常危险的状态。
众所周知,Windows服务程序的启动时机是可以非常早的,往往在用户登录之前就完成启动了,而这个时候最常见的Run键值还不一定被处理完,而且Windows服务程序拥有相当高的权限(默认是Local System,可以对系统里面所有的资源进行操作),因此如果一个恶意软件被加载到Windows服务里面,那么是会非常危险的。前文提到,任何进程使用了User32.DLL,都会对AppInit_Dlls键值指向的DLL进行加载,如果是一个Windows服务程序,也不例外!
由于AppInit_Dlls是一种系统全局性的Hook(system-wide hook),要规避此类的Hook的确很困难,虽然使用驱动程序进行保护能够规避此类问题,但也不是非要使用驱动程序进行处理的。前文说过,只有当使用到User32.DLL这个模块的时候才会触发读取AppInit_Dlls指向的DLL,如果不使用User32.DLL,那么AppInit_Dlls是不会被使用到的。但是要让一个程序不使用User32.DLL会变得非常困难(命令行窗口没有使用User32.DLL),因为任何的窗口、消息都和这个模块有关,为了保证有良好的用户体验,100%的窗口程序都和这个模块有关。从开发角度来说,最好的一种解决办法就是将程序功能逻辑和界面逻辑完全分离,功能逻辑模块负责功能,界面逻辑模块负责界面显示,2者之间采用IPC机制进行交互,功能逻辑模块不依靠User32.DLL,,而且作为独立进程进行处理,这样就可以规避AppInit_Dlls造成的Hook了。
类似的Windows安全相关的缺陷点其实还有很多的,这些缺陷点的来源是为了保证向下的兼容性。相信MIcrosoft已经发现并正在修补这些地方,从Windows Vista上可以看到,AppInit_Dlls的键值在Windows Vista上是不起作用的,因此在Windows Vista里面,这个键值已经被抛弃了(改用另外一个键值执行类似的功能,但是增加了基于UAC的安全防护)。
本文来自 http://www.qihang56.com 谢谢支持!
相关热词搜索:
分享到:
收藏
评论排行
电脑技巧 热门排行
- · windows server 2017远程桌面
- · 解决windows蓝屏显示“Stop 0x000
- · Windows 2017系统优化小技巧
- · 在Windows XP/2017中自定义文件缩
- · stop:c00020171a unknown hard error
- · NTFS下Win2017密码丢失怎么办
- · win2017启动正常,而winxp无法启动
- · 安装Office2017双击却无法直接打怎么办
- · 为何你的迅雷下载速度越来越慢
- · 简单提高迅雷下载速度的方法
- · Alt键的12个使用秘诀
- · 笔记本GPRS上网图解教程
- · 我就不关机 拒绝别人关闭计算机
- · 在机房远程关机
- · Windows 7家庭网络共享设置图解
- · 严禁迅雷偷偷上传!
- · 限制迅雷上传速度
- · 轻松解救无法启动的系统组策略
- · 无法升级安装win7 sp1的解决办法
- · 蠕虫和木马常改的系统文件及注册表
- · 教你如何20秒神速进入win XP操作系统
- · 最早黑客:揭秘世界第一批女性电脑高手
- · 在Windows7中新建磁盘分区的方法
- · Vista系统中如何用U盘制作密码重设盘