-
-
[原创]BIOS Rootkit实现分析与检测技术研究系列之－－IVT Hook 1
-
发表于: 2008-10-29 15:20
-
|
|
|---|---|
|
|
|
|
|
|
|
|
BIOS Rootkit实现分析与检测技术研究系列之－－IVT Hook 2
本节目录 1. 引言 2. 静态剖析leaving.bin 3. 动态调试leaving.bin 4. 小结 5. 附件 引言 上节我们对IVT Hook技术进行了理论铺垫，这节我们通过对实际的BIOS Rootkit进行分析，来加深对IVT Hook技术的理解。对于已发表的BIOS Rootkit，目前只能找到的是：IceLord。IceLord在2007年发表了一篇《BIOS RootKit:Welcome Home,My Lord!》的文章。文中描述了BIOS Rootkit实现的相关技术，并给出了实现的二进制演示文件IceLord.exe（我拿到的是IcLord.exe，这并不影响本文的讨论，下面论述我们姑且叫做IceLord.exe）。而IceLord.exe用于嵌入BIOS的ISA模块文件为：leaving.bin。因此，在这个小节中我们主要对leaving.bin进行讨论。 静态剖析leaving.bin leaving.bin是ISA模块文件，也是整个IceLord.exe的核心。它作为资源类型附加于IceLord.exe文件中。直接用IDA Pro加载分析，如图：  可以看到leaving.bin的标准ISA模块头。大小为16进制40h，即64*512=32K。 在loc_66标号处，如图：  我们看到橙色显示的1600h。用鼠标指向1600h后，IDA把我们引向该字段代表的区域，如图：  我们可以清楚的看到“MZ”标志。我们知道“MZ”是Windows的PE可执行文件开头的特有标志，通过分析，这正是IceLord自带的Payload驱动文件protector.sys。为了不影响IDA对leaving.bin的分析，我们用WinHex把这个程序提取后组成一个新的leaving.bin程序，暂时取名为leaving_new.bin。然后再用IDA加载进行分析。 在《BIOS RootKit:Welcome Home,My Lord!》中，作者提到，IceLord控制CPU流程的方法是通过hook IVT来实现的。即通过hook中断19h来实现。在《IVT Hook 1》小节我们对实模式下的中断向量表IVT（Interrupt Vector Table）进行过介绍。我们注意到，在调用具体中断的过程中，系统在第5、6步的操作是（请参阅《IVT Hook 1》小节）： ------------------------------------------------------------------------------------------------- 5、使用向量号n作为索引，在IVT中找到对应的表项（n*4+IVT表基地址）。 6、将表项中的段地址和偏移地址分别装入CS和IP寄存器中，并开始执行对应的代码。 ------------------------------------------------------------------------------------------------- 对于int 19h中断，系统使用向量号19h（注意这里是16进制的19），然后在IVT中找到表项：19h*4+0（IVT默认加载到内存0000:0000处），即地址0000:0064h处。然后把19h对应的中断处理函数的段地址和偏移地址放入CS、IP寄存器里执行。如果我们把0000:0064h该为0000:xxxx，xxxx代表我们自定义的函数地址，系统就会先执行我们定义的函数，以达到控制系统流程的目的，这种方法就是典型的Hook法。Hook直译为钩子，通过钩子控制程序流程的方法是一种程序员普遍使用的方法，微软公司曾发行过detour函数库来帮助程序员简化这类开发。同时，Hook法被广泛使用在各类Rootkit开发当中，《ROOTKITS－－Windows内核的安全防护》一书对此有详细描述。通过钩子来控制流程的方法同样也适用于BIOS Rootkit（关于如何hook中断的汇编实现，请参阅王爽.的《汇编语言（第二版）》）。 我们来看一下leaving.bin是如何实现对int 19h中断的hook操作的，如图：  leaving.bin程序首先对原始的int 19h调用地址进行保存，以待后面进行恢复调用。然后，hook掉原有地址，加入我们的自定义函数地址。图中New_int19h即为leaving.bin作者自定义的hook函数，当int 19h中断被系统调用时，会首先执行New_int19h，如图：  在新的int 19h中断处理函数中，我们发现leaving.bin的作者又hook了int 13h中断，中断int 13h是标准的处理磁盘的BIOS中断类型。这种思路也符合IceLord在文献中的描述，即hook int 19h，再hook int 13h，以达到操作磁盘的目的。如何检测这种hook操作，我们在这个系列的后续小节进行讨论。 静态剖析leaving.bin的讨论就在此告一段落。 动态调试leaving.bin 在新的int 19h中断处理函数中，我们发现leaving.bin的作者又hook了int 13h中断，中断int 13h是标准的处理磁盘的BIOS中断类型。这种思路也符合IceLord在文献中的描述，即hook int 19h，再hook int 13h，以达到操作磁盘的目的。 这种hook int 19h中断的操作是否真正执行，我们需要验证。验证的执行，我们需要借助Bochs的帮助。我们在上节介绍过Bochs强大的调试功能，它甚至能够调试BIOS和操作系统。在开始调试之前，我们首先来回忆一下Bochs调试器的几条常用调试命令（更详细命令使用请参阅Bochs使用帮助）： ------------------------------------------------------------------------------------------------- b addr 在某物理地址设置断点 c 继续执行，直到遇上断点 s 单步执行 xp 查看内存内容 u 对当前地址进行反汇编 ------------------------------------------------------------------------------------------------- 首先要加载我们的目标文件leaving.bin。结合系列的上一篇介绍，Bochs对于文件的加载是通过改写配置文件来执行的。配置文件后缀名默认为.bxrc，文件由许多选项组成：如romimage：选项，代表需要加载的主BIOS文件的位置，默认为file=../BIOS-bochs-latest。又如boot：选项代表操作系统加载的位置，默认为c，即c盘。在这里我们需要一个特殊的选项：optromimage选项。 optromimage选项允许Bochs加载用户自定义的BIOS附加模块，如ISA模块。这正符合我们的要求。我们的Bochs配置文件的关键选项如下： ------------------------------------------------------------------------------------------------- # filename of ROM images romimage: file=../BIOS-bochs-latest optromimage1: file=leaving.bin, address=0xd0000 vgaromimage: file=../VGABIOS-lgpl-latest ------------------------------------------------------------------------------------------------- 在Bochs安装目录下新建一个bios文件夹，然后把Bochs自带的Linux Demo文件夹下的所有文件拷贝一份到bios文件夹中，并把leaving.bin模块文件也拷贝一份到这里。然后改写.bxrc配置文件相应处为以上选项。特别需要加入optromimage选项，保存配置文件。在该配置文件上点击鼠标右键选择“调试”，Bochs将打开调试窗口开始进行调试，如图：  选择默认选项6，程序跳入BIOS开始执行，我们看到前面分析过的BOOTBLOCK中的跳转语句，这里是jmp far f000:e05b，如图所示：  我们调试的目的是需要查看leaving.bin模块是否真的hook了int 19h中断的调用。最好的方法就是跟踪int 19h中断调用，看其是否跳入leaving.bin自定义的函数地址来。跟踪需要断点的帮忙。在对BIOS设置断点的实际验证中，很多在物理地址设置的断点都未能被出发。由于Bochs没有对设置中断断点的命令，所以我们在这里使用一个笨办法，就是通过u反汇编命令直接在调试窗口查看调用int 19h中断的语句，然后直接在其所在地址下断。首先在调试窗口中输入s单步执行命令，使得程序进入BIOS主程序。然后我们输入命令：u /500，代表从当前位置开始反汇编500条语句，拖动调试窗口下拉条到顶部，我们发现了int 19h中断调用的语句地址为0x000fe2a7，如图：  在地址0x000fe2a7处下断：b 0x000fe2a7。然后输入c执行程序命令，我们成功来到了断点处，如图：  输入s，并进行反汇编：u /20，我们看到了真实的被leaving.bin hook过的中断处理函数入口：0x00097ca2，如图：  对照我们在IDA静态反汇编的结果（对照上面的New_int19h反汇编结果），用Bochs动态调试的得到的与其完全吻合。这也真实了leaving.bin确实如期所说，对int 19h进行了hook操作，进而控制了CPU的执行流程。 继续剖析leaving.bin文件，文献中提到其对于操作系统改写的实现，主要是基于对Ntldr这个Windows启动文件特征码的搜索上，我们在IDA的反汇编结果中也得到了证实，如图：  可以看出程序对特征码0ABF3C033h的识别工作。联系leaving.bin对于hook int13h的一些程序片段，如图：  我们不难发现，leaving.bin对NTLDR文件进行内存特征码搜索的思想，受到了著名Boot Rootkit项目eEye BootRoot的启发。eEye BootRoot项目由eEye公司安全研发人员Derek Soeder和Ryan Permeh创建，是一个旨在研究如何攻击MBR（Master Boot Record）从而实现Rootkit的研究项目。其目的是提供一种先于操作系统执行Rootkit的可能性，并研究对其的检测和防御技术。eEye BootRoot项目在2005年Black Hat USA大会上首次公布。可以访问eEye的网站进行进一步了解。 在完成特征码的搜索操作后，leaving.bin会把保存过的原始int 13h中断向量值，重新写回原处，如图：  这样的写回操作，会干扰我们将在系列后续小节中编写的，IVT Hook检测程序的检测结果，敬请期待。:) 动态调试leaving.bin的讨论就在此告一段落。 小结 在这篇文章中，我们详细讨论了BIOS Rootkit的ISA模块leaving.bin的执行情况。特别从静态和动态两个方面对IVT Hook技术进行了探讨。通过对BIOS Rootkit的实例分析，让我们对IVT Hook技术有了更深的理解。 附件 附件里附上删除了protector.sys的leaving_new.bin和leaving_new.idb，供大家分析。 附件.rar PS：为了给大家直观的印象，在这个小节特意多抓了些图片，影响网页速度了。 待续... 
|
|
|
|
|
|
|
|
|
我要学习.所以同志们不要怕被MJ同学打击
|
|
|
|
|
|
|
|
|
NONAME,在文章里确实没有交代计算机的引导过程，抱歉。
其实Hook住IVT，就是对IVT中的特定中断向量进行Hook。而首当其冲的就是int 19h中断。为什么是int 19h中断？因为在BIOS完成POST（Power On Self Test）操作，顺序加载执行附加模块程序（如ISA扩展模块、PCI扩展模块）后，会调用int 19h中断进行系统的引导工作。也就是把硬盘(如果不是从软盘启动的话)的0柱1头1扇区上的主引导记录（MBR），加载到内存0000h:7c00h处执行。具体情况要复杂得多，可以参考《BIOS Boot Specification》并结合Bochs调试来查看。在调试过程中你会发现，int 19h中断处理程序中，在完成系统引导后，会调用一个int 18h中断。这在《BIOS Boot Specification》中有解释，不过也许会为BIOS Rootkit实现提供了一些新的思路。 我们在ISA附加模块中预先把int 19h进行Hook操作，在系统调用int 19h中断进行系统引导的时候，就会先执行我们的预定程序。而这个预定程序，我们往往会考虑继续扩大对系统资源的控制能力，如继续Hook int 13h中断来取得对磁盘的控制。不能直接Hook int 13h来操作磁盘，是因为这种操作不能成功。具体原因我现在也不是很清楚，我想可能在int 19h进行系统引导后，控制权交给了MBR，由MBR调用int 13h来触发我们的Hook程序，但这时的Hook程序入口点和我们在ISA模块中设定的入口点（由BIOS加载ISA模块到特定内存入口点），已完全不一样，所以找不到我们的Hook程序。不是很肯定，请大牛们指点。 把BIOS Rootkit技术和Boot Rootkit（eEye Bootkit）技术相结合的话，就能使得Boot Rootkit更为隐蔽，并大大提高生存能力。但同时也会降低了通用性。鱼和熊掌不可得兼！这项技术有时间我争取在后续系列中和大家讨论。 不知我这样说，能不能让你有所收获。再次感谢你的支持！
|
|
|
不会的。QIQI说的很有道理，这个研究课题确实很难做到通用，这可能是QIQI在做了许多研究工作之后得出的切身体会。不过，这个研究只是为了证明一种BIOS Rootkit实现和检测的可能性，just for fun！
PS：感谢sudami的支持，也感谢QIQI的支持，每次发帖后基本都是他抢的沙发，是不是自己写了个论坛新贴的提示工具。效率很高，希望多批评、多交流。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
加你QQ了 多交流
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
我也一直在研究brk。这么多年了，感觉通用性刷写问题(包括读)，各厂商bios镜像文件格式问题，执行点问题(和OS启动流程的结合)等等，都有很大突破，真正的通用brk已经可以实现了。
另外个人感觉基于Award的ISA模块的技术，资料非常多，研究的人也很多，它属于很成熟的东西。建议多研究研究AMI，Phoenix、DELL、HP的brk，这些挑战性更大。 这个技术属于交叉学科，关于若干领域。一个人的精力毕竟有限，希望大家建立一个群，多交流。 我的QQ 903121 |
|
|
|
|
|
|
|
|
|
