Windows内核API HOOK 之 Inline Hook

名 字起得好,Inline hook,乍一听,似乎很高深。此处的Inline,我以为,意指将汇编代码直接写入内核API的内存区域。Inline Hook不像用户态Hook或SSDT hook(用C语言就足够),它需要在程序中嵌入汇编代码(Inline Assembly)以操作堆栈和执行内核API对应的部分汇编指令。当然,这些都须以驱动的形式进行。

所谓API Hook,就是用自己写的函数去替代系统API的“职位”,此后,自己写的函数便掌握了以前由被hook的API所“经手”的一切“事宜”。 Windows系统分用户态和内核态,API也就有了用户级和内核级两大类。想要比较底层、彻底地做点事情,当然要hook内核API了(不过hook用 户态API也有诸多用途)。

Hook内核API比较常见的是SSDT hook,一句话——Windows把需要调用的内核API地址全都存在了一个表中(System Service Dispatch Table),要想hook一个内核API,比较简单的办法就是把该内核API在表(SSDT)中保存的地址修改为自己撰写的函数地址。这个道理类似于把 "Windows"先生的"内核API电话簿"给篡改了,当老先生想要打电话给"被hook的api先生"时,他找到的"电话号码"其实已被我们篡改,拨 通电话,我们的"函数小子"开始应答,信息过滤自此开始。

非常不幸,ICESword等检测工具可以轻松判断SSDT是否被篡改,并且会以适当的方式通知用户(比如检索结果的字体变红)。

Inline Hook要比SSDT Hook来得更彻底一点。如果说SSDT Hook只是把某位"内核API先生"绑架,然后用我们的“自己人”来接管其工作,而ICESword却可以从其他联系途径找到被绑架的"内核API先生 "并“报警”,那么——Inline Hook可以说是给"内核API先生"动了手术,让他成为"我们阵营的一分子"。Inline Hook通过硬编码的方式向内核API的内存空间(通常是开始的一段字节,且一般在第一个call之前,这么做是为了防止堆栈混乱)写入跳转语句,这样, 该API只要被调用,程序就会跳转到我们的函数中来,我们在自己写的函数里需要完成3个任务:
1)重新调整当前堆栈。程序流程在刚刚跳转的时候,内核API并没有执行完,而我们的函数需要根据其结果来进行信息过滤,所以我们需要保证内核API能在顺利执行完毕后返回到我们的函数中来,这就要求对当前堆栈做一个调整。
2)执行遗失的指令。我们向内核API地址空间些如跳转指令(jmp xxxxxxxx)时,势必要覆盖原先的一些汇编指令,所以我们一定要保证这些被覆盖的指令能够顺利执行(否则,你的及其就要BSOD了,呵呵,Blue Screen Of Death)。关于这部分指令的执行,一般是将其放在我们的函数中,让我们的函数“帮助”内核API执行完被覆盖的指令,然后再跳回内核API中被覆盖内 后后的地址继续执行剩余内容。跳回去的时候,一定要算好是跳回到什么地址,是内核API起始地址后的第几个字节。
一个朋友曾提出把内核API的被覆盖内容还原,然后执行之——这种方法,我没有试验,但我认为应该不会很稳定,因为内核里常有线程切换,如果你把内核API还原,万一自己函数的线程被挂起,而又有线程要调用给API,这就会出现“Hook 遗漏”。
3)信息过滤。这个就不用多说了,内核API顺利执行并返回到我们的函数中,我们自然要根据其结果做一些信息过滤,这部分内容因被hook的API以及Hook目的的不同而不同。

Inline hook的工作流程:
1)验证内核API的版本(特征码匹配)。
2)撰写自己的函数,要完成以上三项任务。
2)获取自己函数的地址,覆盖内核API内存,供跳转。

Inline Hook的缺点:
1) 不够通用。各个windows版本中,内核API的开始一段不尽相同,要想通吃,就要多写几个版本或者做一个特征码搜索(因为有的内核API在各个版本中非常相似,只是在“特征码”之前或之后加一点东西)。
2) 已被一些检测工具列入检测范围,如果直接从内核API第一个字节开始覆盖,那么很容易被检测,如果把覆盖范围往后推,并加以变形,也许能抵挡一气。具体情况,我才疏学浅,尚未试验。

你可能感兴趣的:(windows,api,汇编,任务,hook,电话)