穿透还原的工作原理分析（逆向工程）

穿透还原的工作原理分析（逆向工程）--机器狗

样本脱壳      OD加载样本explorer.exe，对GetModuleHandleA下断，参数为NULL时即为入口点处对此函数的调用，退出CALL之后可以得到入口为 004016ED。     重新加载样本，对004016ED下内存写入断点，中断后StepOver一步，然后在004016ED下断点，F9运行到入口，DUMP。DUMP之后不关闭OD，让样本处于挂起状态，使用ImportREC修复DUMP出来的文件的导入表。     修复之后DUMP出来的文件用OD加载出错，使用PEDITOR的rebuilder功能重建PE之后即可用OD加载，说明脱壳基本成功，但资源部分仍有问题,无法用Reshacker查看 pcihdd.sys的提取 OD加载样本explorer.exe，设置有新模块加载时中断，F9运行 当ADVAPI32.DLL加载时，对CreateServiceA下断点，F9运行 当CreateServiceA中断时，即可提取出pcihdd.sys      pcihdd.sys基本流程如下     1)检查IDT的09（NPX Segment Overrun）和0E（Page Fault ）处理程序的地址，如果09号中断处理程序存在，并且处理程序地址的高8位与0E处理程序高8位不同，则把IDT中0E的高16位设为0。估计是检查0E是不是被HOOK了,我比较龌龊，看不懂这些操作的意思，这样不BSOD？请懂的兄弟跟帖告诉一声      2)通过搜索地址来查找自己的加载地址，查找驱动文件的资源中的1000/1000,并复制到一个全局缓冲区中。     3)创建了/Device/PhysicalHardDisk0及其符号连接/DosDevices/PhysicalHardDisk0     4)只对IRP_MJ_CREATE        IRP_MJ_CLOSE        IRP_MJ_DEVICE_CONTROL        作出响应     其中IRP_MJ_CREATE中会断开/Device/Harddisk0/DR0上附加的设备。这个操作会使磁盘过滤驱动、文件系统驱动(OS提供的，但一些杀毒软件也通过此渠道进行文件系统监控）及其上的文件系统过滤驱动（大多数文件访问控制和监控都是这个层次的）无效(参见http://blog.csdn.net/joshua_yu/archive/2006/02/04/591636.aspx)     在IRP_MJ_CLOSE 中对恢复DR0上的附加在IRP_MJ_DEVICE_CONTROL中对0xF0003C04作出响应，只是把2)中找到的资源数据解密后返回到应用程序。      解密密钥是通过应用程序传入的一个串（密钥种子？）查表后产生(KEY：0x3f702d98) 0xF0003C04的作用：     将用户态传入的整个代码体作为密钥种子对这个代码体进行类似于校验和的运算后得到4字节的解密KEY，然后使用此解密key将驱动自身携带的资源解密（仅仅是XOR），将解密结果返回给用户态。     关于解除DR0上的附加设备：     这种操作应该会影响系统正常的文件系统操作，但是因为实际操作时此驱动被打开和关闭的的间隔很短，所以应该不会有明显影响。      explorer.exe流程      1、释放资源中的pcihdd.sys并创建名为pcihdd的服务，启动服务      2、定位userinit.exe在硬盘中的位置。定位方法如下      1)通过FSCTL_GET_RETRIEVAL_POINTERS获取文件数据的分布信息     2)通过直接访问硬盘(.//PhysicalHardDisk0)的的MDR和第一个分区的引导扇区得到分区参数(每簇扇区数),配合1)中得到的信息来定位文件在硬盘上的绝对偏移量。这里有个小BUG，扇区大小是使用固定的512字节而不是从引导扇区中获取      3)通过对比ReadFile读取的文件数据和自己定位后直接读取所得到的文件数据，确定定位是否正确     3、把整个代码体作为参数传递给pcihdd.sys,控制码0xF0003C04，并将pcihdd返回 的数据直接写入userinit.exe的第一簇      被修改后的userinit.exe 1）查询SOFTWARE/Microsoft/Windows NT/CurrentVersion/Winlogon下的Shell键值 2）创建Shell进程 3）等待网络链接，当网络链接畅通后，则从http://yu.8s7.net/cert.cer下载列表 4）对于列表中的文件每个文件，创建一个新线程下载并执行，线程计数加一（INC） 5）等待所有线程结束后（线程计数为0）结束进程。     对于线程计数的操作并不是原子操作，理论上多CPU情况下有小的概率出问题。不过人家是写针对普通PC的病毒，多CPU不常见，也不需要稳定。      文中所指的病毒就是一般说的新AV终结者 ============================ 机器狗原理： 建立磁盘底层驱动。 1.校验IDT的NPXSegment Overrun（09）和Page Fault（OE）的矢量地址，如果存在，则把高16位设置为0，这个过程和还原软件的原理是一样的，就是对OE的HOOK检验。 2.给自己找个位置，查找驱动资源中的1000/1000，然后COPY到ALLOVER缓冲区中。 3.建立物理磁盘PhysicalHardDISK0的/Device----DosDevices的底层借口，针对“IRP_MJ_CREATE”“IRP_MJ_CLOSE”“IRP_MJ_DEVICE_CONTROL”响应。“IRP_MJ_CREATE”断开/Device/Harddisk0/DR0-1上的附属部件。从而使磁盘OS层提供的应用层文件系统鉴听校验失效。 然后通过“I_M_C ”中恢复DR0-1上的附加。并在I_M_D_C中对0x0004f8E——0xF0003C0F作出响应，把ALLOVER缓冲区中找到的数据解密并返回应用层。通过KEY-s查表产生密钥。0x0004f8E——0xF0003C0F字段会将用户态代码作为源基，对其运算后得到字串KEY，用来对源驱动解密后，反还给用户层。 在这个过程中，有个大家比较熟悉的截面，就是系统由于磁盘底层驱动校验不成功而出现的蓝屏截面，最常见的是初始值0x0004f8E，比如，早期的SATAⅠ在保护卡状态下出现物理坏道（0%—1%），就是这个蓝屏代码。很多由于用户态的软件安装不当，引起的蓝屏也出现在这一区段中。在解除DR0-1上的附属部件时，出现逻辑性错误就导致大家常见的中机器狗后的蓝屏。多见于多处理器平台。一般的PC是不会出现这个错误的，也就是说，大多数中招后都能正常使用，就是木马多多，呵呵。 继续正题，以上过程反映到IE上是这样的：1.释放底层驱动程序（比如变种前的PCIHDD.SYS）或者高位数用户态临时驱动（变种后，可以有可执行程序引导，如“Usrinit.exe”） 2.定位WINDOWS系统中的userinit.exe。（通过MBR和第一引导扇区参数来定位文件磁盘矢量偏移。） 3.并校验RF文件与地位后读取的数据位置的正确性。 4.将获取的代码参数返回给底层驱动，控制0x0004f8E——0xF0003C0F段为，最后将返回值（TQ）直接写入userinit.exe数据所在的第一蔟。这里要大家特别注意以下，通过用户态的shell调用，作者只需一点变动，就可以随即抓取用户态引导文件，所以，目前的该名设权限都是没用的。 甚至，他可以把这个过程省略，象净网先锋那样，把Shell进程写入动态连接库。那么，还原就没用了。还会带来网络负载问题，可能是作者比较仁慈吧。 好了，分析了以上的过程，解决的办法就出来了，就是要通过对操作系统的内核编译，将他所定位的目的地址占据，这样，除非是格式化，否则，任何操作的不会在底层夺取该位置。（不要问权限问题，在底层是没有这个说法的，先入为主。） 所以，对用户的要求是，做好系统，安装好还原驱动后拿过来，修改，否则，先改完了，还原卡或者任何还原软件都是无效的了。