基于MBR 的bootkit的进展 鬼影-TDL4-BMW

以前写的做个总结，留念 
1，MBRBOOTKIT –鬼影
?0?3鬼影系列
?0?3特点：只支持XP 系统，基于国外的开源版本修改。
?0?3从MBR里，挂中断13H,驻留高端内存，挂NTLDR 加载，对NTOS的函数进行HOOK,在NTOS初始化过程中，加载病毒驱动，从而进行一系列操作。
?0?3所有病毒代码都在 MBR区域里，位于操作系统之外，格式化硬盘，重装系统均无法解决。
?0?3缺点：只支持XP系统，对自己的保护不足，很容易检测和修复。
2，MBRBOOTKIT –TDL4
?0?3TDL4系列
?0?3在欧美流行，国内比较少见，技术水平高于鬼影。
?0?3支持所有的WINDOWS操作系统。甚至是64位WIN7,并且在 64位WIN7上支持绕过PatchGUARD及驱动加载签名验证，如果这种技术一旦流行开来，对64位WINDOWS系统的安全打击将是致命的 。
?0?3Mbr-ldr16-ldr32(ldr64)-drv32(drv64)
?0?3MBR部分的主要功能是搜索ROOTKIT加密分区中的 LDR16模块，并将其加载进内存，将控制权交给他
?0?3LDR16:
   加载运行后会HOOK int 13h挂钩硬盘的读写操作，然后会加载磁盘最后加密扇区中的原始备份MBR到内存中，并将控制权交给原始MBR去执行。而后者会加载操作系统引导模块。而系统引导模块则通过INT 13H来读取加载系统启动的文件。而每次读取操作都要经过TLD4的钩子处理。
  在钩子程序中判断是否是读取特定的文件，是则进行处理，否则直接下传。
   其中要进行处理的一个文件是kdcom.dll
   这个DLL和系统调试相关。Ldr16会在挂钩程序中对这个文件的特征进行判断，是否符合，是则进行处理。包括了同时针对32位和64位程序的处理.
当发现加载该文件时候，LDR16会搜索加密分区中的LDR32,或LDR64组件，根据所处的不同系统，然后加载代替内存中的kdcom.dll。从而完成了内存中的劫持。除此之外LDR16还要做的一件事就是改变内存中的 BCD 信息。后者是 WINDOWS在VISTA以后引入用来代替BOOT.INI的注册表hive文件.
TDL4会修改BCD中的BcdLibraryBoolean_EmsEnabled键，默认的标志是“16000020”,将其替换为“26000022” ?6?2 BcdOsLoaderBoolean_WinPEMode键。从而启动系统的 WINPE系统模式。而在WINPE模式下，将不会进行代码完整性验证，从而让系统不会验证kdcom.dll的数字签名。而这种模式只需要挺过验证期后，即可通过将/MININT参数设置为一个无效的值而禁止该模式。
?0?3LDR32/LDR64
为了确保系统初始化的成功，LDR32/LDR64必须支持kdcom.dll的功能函数
对于32位和64位系统来说，导出函数都是一样的。但对于TDL4的LDR32/LDR64来说只需要在KddebuggerInitialize1进行进行处理即可，对其他的函数则直接返回成功即可。通过这种简单的方法，使TDL既能在系统启动早期就进行初始化，又达到了禁止系统调试器的效果，真可谓一石二鸟的效果。
在系统初始化的早期阶段Phase1Initialization 会调用KdDebuggerInitialize1，而后会进行TDL的初始化
而对于LDR32/LDR64的代码基本相同，因为采用同样的C代码编译的。
当调用KdDebuggerInitialize1后 ，LDR32/LDR64会进行一系列的初始化
调用未公开的函数IoCreateDriver来为LDR32/LDR64创建一个驱动对象，因为kdcom.dll本身不作为一个驱动程序被加载。同时将初始化函数作为参数传递给IoCreateDriver。
?0?3通过调用IoRegisterPlugPlayNotification，注册一个即插即用的回调。
?0?3而当该即插即用回调被调用的时候，将会搜索TDL4加密分区中的主ROOTKIT驱动DRV32/DRV64，是32位还是64位取决于当前是哪个操作系统。而后将该主ROOTKIT驱动（DRV32/DRV64）加载进内存并进行必要的配置后，调用其驱动程序的入口点
?0?3DRV32/DRV64：
?0?3一旦LDR32/LDR64被成功初始化后，ROOTKIT主功能模块将被加载，其主要功能就是隐藏自身，防止被安全软件发现。当安全软件试图访问ROOTKIT关键部分的扇区的时候返回给虚假的结果，比如访问MBR,磁盘最后区域的时候，返回的都是虚假的正常信息。
?0?3通过对ATAPI.SYS的设备对象劫持，而该种方式的挂钩将不会引发PTACH GUARD的保护机制。
?0?3除此之外，该ROOTKIT还创建了监视线程，检测其的对象HOOK,及MBR是否被恢复，如果发现被恢复，则重新感染MBR.
?0?3优点：强大的 兼容性，支持所有WINDOWS系统，强大的隐藏保护功能，在中毒的系统下很难获得原始的MBR信息，强大的自我保护功能，在内核线程中，保护自己的HOOK和MBR,一旦被还原，就立刻再HOOK和感染，比较难以清除。
?0?3缺点：目前的 ARK工具越来越强大，还是有办法进行检测和修复。而且进入WINPE 下修复，则基本可以秒杀了。
BIOSROOTKIT –BMW病毒
一、BMW病毒BIOS部分
　　增加了ISA模块BIOS部分，名为HOOK.ROM，作用主要是检测MBR部分是否被恢复。如果发现MBR部分已被修复，就将BIOS内的病毒代码约 14个扇区写入MBR中，导致用户反复格式化、高格低格，或重新分区都无效。 
?0?3MBR部分病毒代码执行后，会从第2个扇区开始读6个扇区的病毒代码到0X7C00处，然后跳至该处执行，然后读取第7个扇区中的备份MBR到内存中，验证扇区的有效性，通过验证后，读取分区表中的引导扇区所在的扇区到0X7C00处，验证引导分区的有效性。通过验证后，判断引导分区的类型，目前该病毒支持NTFS和 FAT32，根据不同的分区类型进行不同的处理，再经过解析文件系统找到文件所在扇区，找到相应的Windows系统文件读取PE信息判断其是否被感染过。（XP/2003系统为Winlogon.exe，Win7/Vista系统为Wininit.exe）
?0?3如果Windows系统文件已被感染，则在屏幕上显示"Find it OK!"，然后调入原始MBR，跳到原始MBR处执行；如果Windows系统文件没有被感染，则进行PE感染写扇区，之后在屏幕上显示"Find it OK!"，然后调入原始MBR，跳到原始MBR处执行。
?0?3BMW病毒Windows部分（Winlogon和Wininit文件执行感染）
病毒代码解密后加载指定文件，创建病毒调用CreateThread创建线程，同时跳回原始入口点执行，在病毒线程里先Sleep10秒，然后调用URLDownloadToFileA从黑客服务器下载一个Downloader到本地，验证文件下载成功后，调用WinExec执行，从而下载运行多种恶意程序；该病毒还会下载驱动，命名为c:\my.sys，由之前的病毒代码通过一系列服务函数来创建加载驱动，完成后该病毒线程进入无限Sleep状态。
?0?3c:\my.sys 这个磁盘钩子驱动，会在WINLOGON的感染代码里被加载。驱动对磁盘类驱动disk.sys 进行READ， WRITE ，DEVICEIOCONTROL， 的DISPTACH 进行 hook，防止MBR及相关病毒扇区部分被读取
?0?3BIOS Rootkit存在许多优缺点，就优点来看，其：
?0?31.  能够第一时间获取系统主动权。由于固化于BIOS芯片中的程序在计算机启动时是最先执行的，因此嵌入BIOS芯片中的BIOS Rootkit自然能够第一时间获得系统主动权。
?0?32. 不在硬盘上留下痕迹。BIOS Rootkit主要存在于BIOS芯片中，因此传统的基于硬盘的安全检测程序将会失去作用。
?0?33. 能够重复感染已有操作系统或新装系统。由于BIOS Rootkit存在于BIOS芯片中，因此重装新系统对其毫无作用。
?0?34. 能够对抗几乎所有现有的HIPS、杀毒、审计等安全软件。现有的所有HIPS、杀毒、审计等安全软件几乎都是基于操作系统的，对于存在于硬件中的BIOS Rootkit也毫无作用。
?0?35. 难于检测。BIOS Rootkit一般作为BIOS设计规范中的标准ISA或PCI模块存在，因此难于判断相应模块是否为BIOS Rootkit。
?0?36. 难于清除。即使发现并判断出某个ISA/PCI模块为BIOS Rootkit，也只有通过硬件编程写入的方式才能清除。而硬件编程器并不是每个人都有并能熟练掌握的。
?0?3而BIOSRootkit缺点表现在：
?0?31. 程序编写较为困难。BIOS Rootkit主要依靠汇编程序来进行编写，并且汇编只能调用特定的BIOS中断调用。比如int 19h系统引导中断可以正常调用，而int 13h磁盘中断就无法正常使用，原因是BIOS引导计算机时，磁盘设备还没有准备好。
?0?32. BIOS类型较为繁杂，很难做到通用性很好的BIOS Rootkit。BIOS芯片类型以及其主板类型甚至是主板编号都对BIOS Rootkit有较大限制。加上Award、AMI、Phoenix类型的BIOS各自对硬件调用规范也不尽相同，因此通用性较好的BIOS Rootkit难于实现。
?0?33. BIOS相关技术资料奇缺。BIOS相关资料一直是各大BIOS厂商严格保守的机密，因此BIOS Rootkit编写需要的许多相关电器特性、调用参数等资料都无法找到。
?0?34. 涉及操作系统实/保护模式转换、系统引导等复杂问题。保护模式下的编程，特别就未开源的Windows操作系统来说，BIOS Rootkit对于操作系统流程控制的相关实现较为困难。
?0?35. BIOS空间限制。BIOS芯片空间较为宝贵，一般为512K大小。除了厂家初始加入的固定程序外，可用的剩余空间往往不够放下BIOS Rootkit。
?0?3关于 BMW 的 BIOS部分，修复一直是很麻烦的问题。要做好，必须实现BIOS整个文件解析，打包，拆分。但实际上看病毒的操作，就可以知道。通过BIOS工具CBROM来实现整个过程，病毒所做的只是，把BIOS读出来，用工具加入自己的代码，自动修正BIOS文件后，再将整合后的BIOS文件写回而已。那么我们也可以那么做，把BIOS读出来，检查里面是否有病毒代码，有的话，用工具去除后，再将BIOS代码写回即可。一切都是那么的简单。唯一的困难的，就是你的测试机器，仅此而已。