实是很降低用户体验的一个不是办法的办法。场景2:制作某游戏外挂,需要注入一个DLL到游戏
进程中去直接调用游戏函数完成某一功能。结果发现该游戏有NP保护,OpenProcess打不开,创建
远程线程也不行,试用其它方法也一一失败。遇到上面的情况,高手们自然是转到Ring0下面去,
使用驱动之类的办法来对付啦,不过吾等菜鸟可就是酒井没法子了 -_-|
不过也别太灰心,凡事总会有办法的。我想我们需要一种持久的、稳定的、不容易被安全软
件屏蔽的DLL注入方法,后来发现,输入法程序就是能完成这一任务的理想人选。输入法程序程序
到底是什么?它没有自己的进程,并且在系统还没有登录时就已被加载(在欢迎界面你也可以调
出输入法),它可以在游戏中打开,也可以在控制台程序中打开,还可以在瑞星保护下的QQ中打
开,在杀软中也可以打开,这不就是我们要找的特性吗。那么,输入法到底是什么呢?根据
Windows的规定,输入法其实就是一个DLL,不过它是一个特殊的DLL,它必须具有标准输入法程序
所规定的那些接口,输入法是由输入法管理器(imm32.dll)控制的,输入法管理器又是由
user32.dll控制的。输入法在系统目录是以IME为扩展名的文件,当在应用程序中激活某个输入法
时,输入法管理器就会在那个应用程序的进程中加载对应的IME文件,注意,加载IME文件跟加载
普通的DLL并没有本质区别,所以,可以认为,输入法其实就是注入到应用程序中的一个DLL文件
,并且,这种“注入”是不会被杀软和游戏NP拦截的(至少目前是)。现在,我们已经有了一个
注入DLL的另类方法,那就是利用输入法。具体流程是这样,首先制作一个标准输入法文件,但是
这个输入法并不完成文字输入工作,它的唯一任务就是用来注入DLL,所以称为“服务输入法”,
然后,制作一个控制程序,来控制服务输入法,当然最后还需要一个用于注入的目标DLL,这样一
共就有3个文件。开始工作后,控制程序首先将服务输入法安装到系统中,然后传递几个参数给服
务输入法,参数中包括了需要注入的DLL文件的名称和路径,然后,控制程序将服务输入法设置为
系统的默认输入法,这样新的程序一打开,服务输入法就会注入那个程序。当然,在服务输入法
安装之前打开的程序不会被注入,这时需要向系统中的所有窗口POST一条
WM_INPUTLANGCHANGEREQUEST消息,该消息可以在指定窗口中后台激活服务输入法,这样,系统中
所有拥有窗口的进程就都被我们的服务输入法注入了。服务输入法注入程序之后,就会根据控制
程序传递过来的参数加载目标DLL,这样目标DLL也就随着服务输入法一同注入到目标程序中了。
注意服务输入法是控制程序用WM_INPUTLANGCHANGEREQUEST消息在所有窗口中自动激活的,如果某
个窗口自动激活失败,你就需要在那个窗口中手工切换到服务输入法,这样才能注入进去了。至
于注入以后,你就可以在窗口中切换到别的输入法,这并不会影响已经注入进去的DLL。
第十种方法:
利用NtResumeThread 实现全局挂钩
一直是Hack 编程中永恒的主题,基本高级的Rootkit 程序多多少少都会使用Hook 技术。 似乎Hook 都被讲烂了,不论是Ring3 的还是Ring0 的网上都有例子。Ring0 的毋庸置疑当然
是全局的了,这里说说ring3 的全局hook。Ring 3 有Ring 3 的优势,稳定是压倒一切的, 因此Mcafee 和其他一些商业的安全软件都还是使用了Ring3 的Hook 技术,无论如何用户是
无法接受蓝屏和死机的。
感兴趣的可以装个Rootkit unhooker 自己看看。
1. 以往的Ring 3全局Hook
纵观网上流行的全局Hook 程序都只用了一个Windows API, SetWindowsHookEx,此函数原型:
HHOOK SetWindowsHookEx( int idHook,
HOOKPROC lpfn, HINSTANCE hMod, DWORD dwThreadId );
idhook 安装的钩子类型,如 WH_GETMESSAGE,WH_KEYBOARD 等 lpfn hook procedure 的指针
hmod 包含 hook procedure DLL 的handle dwThread 为0
使用这个这个API 时候有问题的,只能挂接系统中的所有G U I线程,换句通俗的话说就是有界面
的程序,Windows console 类的程序就无能为力了。
还有一种通过插入注册表来实现
HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\AppInit_DLLs
这种方法简单,但是还是只能挂钩GUI 程序,并且这个键值已经被广大HIPS 所关注,吃力不讨好 。
以上两种效果不好,因此有人有开始另外的做法,枚举所有进程,插入和挂钩 NtCreateProcess
这是非常自然的想法,似乎也把问题解决了,但是仔细思考一下,就会发现很多问题。
a. 时机不对,在NtCreateProcess函数被调用时进程并没有真正被创建,我们无法执行HOOK操作
,
而当NtCreateProcess返回时,进程又已经开始运行
b. 如果是Windows console 创建的进程,你如何去监控这个调用呢?这么说似乎比较抽象,你可
以这么理解,直接在命令行下,cmd,cmd,cmd .... 你可以监控到最后一个cmd 吗,如果只
用SetWindowsHookEx
c. 是否正好站在了华容道,是否足够底层。
似乎很费劲
2. 分析系统创建进程过程,寻找方法
关于这方面内容,可以参考毛德操老师的两篇文章
《漫谈兼容内核之十七:再谈Windows的进程创建》
《漫谈兼容内核之二十二:Windows线程的调度和运行》
下面是他的blog 链接: http://hi.http://m.wodefanwen.com//fatbsd/blog
CreateProcess 是 Kernel32.dll 的导出函数。
操起WinDbg,剁了一下: Windows 2003 SP2
lkd> uf CreateProcessW kernel32!CreateProcessW:
7c802474 8bff mov edi,edi 7c802476 55 push ebp 7c802477 8bec mov ebp,esp 7c802479 6a00 push 0x0
7c80247b ff752c push dword ptr [ebp+0x2c] 7c80247e ff7528 push dword ptr [ebp+0x28] 7c802481 ff7524 push dword ptr [ebp+0x24]
7c802484 ff7520 push dword ptr [ebp+0x20] 7c802487 ff751c push dword ptr [ebp+0x1c] 7c80248a ff7518 push dword ptr [ebp+0x18] 7c80248d ff7514 push dword ptr [ebp+0x14] 7c802490 ff7510 push dword ptr [ebp+0x10] 7c802493 ff750c push dword ptr [ebp+0xc] 7c802496 ff7508 push dword ptr [ebp+0x8] 7c802499 6a00 push 0x0
7c80249b e8a6ac0200 call kernel32!CreateProcessInternalW (7c82d146) 7c8024a0 5d pop ebp 7c8024a1 c22800 ret 0x28
lkd> uf CreateProcessInternalW ....
7c82cf8f ff159814807c call dword ptr [kernel32!_imp__NtCreateProcessEx (7c801498)] ....
7c82daa2 ff159414807c call dword ptr [kernel32!_imp__NtCreateThread (7c801494)] ....
7c82dbdc ff158814807c call dword ptr [kernel32!_imp__NtResumeThread (7c801488)]
大概流程如下:
Kernel32!CreateProcessW
Kernel32!CreateProcessInternalW ntdll!NtCreateProcessEx ntdll!NtCreateThread ntdll!NtResumeThread
因为进程创建后,Windows 必须为它创建一个主线程,然后等待操作系统调度它。
所以调用NtResumeThread的时候,就是我们Hook的最佳时机,因为此时创建进程的主要工作已经
完成,
但是进程并没有调度起来,呵呵,方便干坏事啊。
3. 具体代码实现
基本思路已经清晰了,这里还几个问题。
a. NtResumeThread 函数并不是创建进程才调用,我们怎么区分出哪个是创建进程时 调用的NtResumeThread呢?
其实现实起来不困难,先枚举系统进程一次,将系统进程中NtResumeThread 都挂钩上。每次拦截
搜索“diyifanwen.net”或“第一范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读,第一范文网,提供最新小学教育DLL的11种注入方法 (8)全文阅读和word下载服务。
相关推荐: