机器狗发表评论(0)编辑词条

此病毒采用hook系统的磁盘设备栈(文件系统设备堆栈)来达到穿透目的的，危害极大，可穿透目前技术条件下的任何软件硬件还原！基本无法靠还原抵挡。目前已知的所有还原产品，都无法防止这种病毒的穿透感染和传播。

虚拟机内试验过后发现确实能穿透各种还原精灵，冰点还原精灵6.0 6.1 6.2等在其淫威下完全失去效用，还原精灵和还原卡似乎也无法幸免。

猜测应该是还原业内人士开发研制的，这种技术的应用极为少见，且如果精通这种技术的高手要做病毒不会用这种hook系统的磁盘设备栈的方式，完全可以有更强更好的方式达到彻底毁灭还原行业的方法；所以这个病毒应该是针对现在99％还原产品做的病毒。

病毒特点：

文件名为explorer.exe，图标为一只机器狗

中毒那么就会修改userinit.exe文件。而且这个文件的大小和时间都不会变，唯一改变的就是文件内容，所以如果想知道是不是穿透了必须对比感染前后的userinit.exe的文件内容，才能对比出来。

解决办法：
治标的办法是用任务管理器关闭usrinit.exe和userinit.exe和explorer.exe然后用没有中毒的userinit.exe替换系统文件夹下的userinit.exe和usrinit.exe文件。然后立即断电重启。进入系统使用机器狗免疫工具进行免疫。

推荐超级巡警的机器狗免疫程序（目前最新你版本是1.2）

-----------------------

原文：http://www.sidiubide.cn/read.php?142

样本脱壳

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不常见，也不需要稳定



机器狗：
http://www.esfast.net/downs/explorer.rar



IGM：
http://www.esfast.net/downs/IGM.rar



写穿还原的工具：
http://www.esfast.net/downs/SectorEditor.zip

---------------------------------
关于文件系统设备堆栈的说明

若干关于 file system driver stack

写这个文章的初衷是想知道究竟一个读写文件的irp都是怎样被处理的.....

大家都知道这样的一个读写文件irp是发送给file system的driver的file system把这个irp交给了下层的device

这个device叫logical volume device,它由device的vbp里面的realdevice指针指出(不一定就会是这个device,而应该是这个device所在的stack 的最上层的device).那这个device是个什么东西呢?它是怎么来的呢?按照道理,这个irp应该被发送到disk的驱动去才对?那个这个 device是disk的驱动创建的么?如果不是,那中间都有些什么步骤呢?

本文就是回答上面这些问题的.

用softice 看看就知道file system转发的irp并不是vpb指向的那个device,而是另外一个叫volsnap的driver创建的device. 再跟踪看看,volsnap创建的device是跟vpb的device在同一个stack里面,而且volsnap创建的device的下一个 device就是vpb的device.

好了.至少知道了确实file system driver要把irp转发到vpb指向的device去.那接下来呢?irp又会到哪里?

再跟踪下去.irp到了一个由partmgr.sys创建的device里,看看这个partmgr...它是一个disk driver 的filter(多用注册表,当初我在这里花了好长时间才发现这个东西是一个filter),所以partmgr把这个irp转发到了disk driver.disk driver接着发给了acpi.sys,然后acpi.sys转发给了atapi.sys创建的一个device去,看看这个device的 stack,已经是1了,irp就到尽头了,接下来的就不是irp的流程了,而是所谓的port/miniport流程了.

大致的把整个的结构过了一次,里面有很多的疑问,下面要一一解释,最好是能用device tree看看这个过程,看看哪些是pdo哪些是fdo,看看每个device的stack值都是多少,自己模范下看看能不能了解irp的流程.

上面的整个irp的流程是很大的.顶层device的stack达到了8,首先你就会奇怪这么庞大一个device stack是怎么建立起来的?

先说最上面的部分
file system在受到一个mount的fs control的时候,创建了一个无名的device,并且保存了vpb 的 realdevice所在的stack的最上层的device,以后所有的irp都转发到这个保存的指针上面.注意这里并没有attach到那个 device的stack上面,而是直接使用指针call driver的.这里会有一个问题,在file system mount以后,再attach到volume device的stack上的device 收不到 file system传递过来的irp,至于这个问题怎么解决,msdn里面有说,把这个filter driver设置成启动时加载,至于为什么这样作了就能行,这个在后面会有解释.

在我的机器上,file system保存的device是由volsnap创建的一个filter device,在这个filter device下面是vbp指向的device,它有名字叫HarddiskVolume1(名字不一定就是这个),这个device是一个pdo,注意它是一个pdo,按照常规 pdo的创建不是由系统主导的,而是由driver主导了,它一般不在adddevice里面创建,而是由driver在需要的时候手动创建的.为什么说到这个细节呢?因为我们没有这个driver(名字叫ftdisk.sys)的源代码,在反汇编的时候,明白了这个以后比较有目标,这个 ftdisk.sys的代码是非常简单的,ida反汇编一下就发现harddiskv
olumeX这个device并没有attach到什么 stack上面(也算是pdo的一般做法),但是这个pdo却保存了两个指针,一个指向另外一个pdo(70h),一个(74h)指向这个pdo的 stack的最顶的device,而且以后的irp它都发给了这个device,这个device也就是由partmgr创建的device了.

partmgr 其实只是一个filter,挂接到disk driver上面的,那么接下来的stack创建就比较简单了.用device tree向前看,partmgr创建的是一个filter,它attach的device叫dr0,是一个fdo,它对应的pdo叫 idedevicepotolo-3,这个部分的过程就根据的容易了,disk driver是有源代码的,仔细看看就能明白其中的创建关系.看清楚了,这个pdo的stack值是1,所以irp到这里就算是尽头了.

再向下又是一个fdo,ideport(atapi.sys),它创建了上面的那个pdo,ideport我没有详细的反汇编分析,不过可以推测得出来,它对应得pdo是ide0channal0,而这个pdo又是由pciide创建的,你可能会注意到中间多了一个filter acpi.sys创建的一个device,也许你会注意到这个acpi.sys到处创建filter.

再往下就是pci,acpi_hal这些device了,他们的行为都很正常.不详细说了(其实是我没有详细的研究,只有些想当然的想法,不敢拿出来说)

到此,回顾下整个device stack,可以看到这里涉及到好多的device stack,irp并没有按照一个stack 走到底.

最上面的是file system的device
|fs filter| <-比如是filemon
|fs volume| <-一般没有名字,由filesystem在mount的时候创建

fs的volume保存有新的stack(partmgr device的stack? 叫这个名字么?)的最上层device的指针,irp转移到这个stack
|volsnap 创建的无名device |
|ftcontrol创建的storage volume device|

这个device有保存有另外一个stack顶层device的指针,irp再次转移
|partmgr创建的无名filter device|
|disk创建的DR0 fdo |
|acpi创建的filter |
|atapi创建的pdo |

这个就是irp的全流程,它经历了3个device stack.

呼呼
吐口气吧.......

本来这个文章写到这里就算完成了....
但是我还有些心得要写出来.这些属于是无心插柳的结果.只是在我跟踪上面这些结果的时候额外的收获.

先看device tree里面,pnp方式查看,你会注意到有很多的pdo属于pnpmanager,但是他们却没有对应的fdo.很奇怪吧,再看这些pdo的名字,你会发现partmgr赫然在目.奇怪了,它怎么有个fdo呢?

首先要明确的就是凡是有填充adddevice域的driver都会对应一个pdo,这个是必然的,因为adddevice传递进来的参数就有一个是 pdo,还有一个事情就是在某种情况下,即使不填充adddevice域,pnpmanager还是会创建一个pdo.你所看到的大多少没有fdo的 pdo都是这样来的.那什么时候pnpmanager创建这些pdo呢?答案就在系统启动的时候.

你也应该要知道,有些驱动并不是由ntoskrnl加载的,有很多的driver是由loader加载的,win2000 把这些叫做 boot driver.

ntldr 加载必要的driver以后,转移控制权给ntoskrnl的入口函数(kiinitsystem是这样么?),经过一定的步骤以后来到了 ioinitsystem函数,这个函数作一些初始化以后开始了pnp系统,这里ntoskrnl创建一个pnpmanager的root device,并且start了这个device,然后发送query bus relation,这个时候pnp manager读取注册表一一创建每个需要创建的service的pdo,构造device tree,然后调用每个boot driver的driver entry函数,然后是他的add device函数(实际情况比我上面描述的要复杂得多).

然后pnp就开始了众所周知的enum 工作,这个是委托给worker线程完成的,大部分情况是使用workitem进行的,这个部分显得非常的复杂,跟踪调试非常的不方便(恕我也没有完全的弄明白,先跳过去,以后有机会再详细的讨论这个部分).

跳过了xxx的步骤以后,pnp enum到了主板的南桥芯片(我的是ich4)设备,创建对应的fdo(没有名字,属于pci这个driver),继续enum,得到ich4里面的 mass storage controller,创建pdo也是属于pci的,创建对应的fdo,pciide(中间有个acpi的filter加进来,主要进行电源管理),这个 fdo再enum,创建两个ide channal的pdo,再创建对应的fdo,ideport(由atapi提供,还是有acpi的filter加进来),ideport再enum机器上的硬盘pdo,继续加载acpi的filter,加载硬盘的fdo,也就是disk.sys了,再加载upperfilter, partmgr.sys.

接下来的事情关键了,硬盘的fdo告诉pnp它的bus relations要更新(可以查看disk.sys的源代码观察这个部分进行的事情),然后pnp发送一个 query bus relations的irp给硬盘pdo所在的stack,这个stack的最上部分并不是硬盘的pdo,也不是acpi的filter,也不是硬盘的 fdo,而是partmgr.sys这个driver,它接受到这个irp的时候,安装一个complete routing,然后把irp向下传递,等到控制权再回到手上的时候,partmgr.sys作了一系列的事情,最最重要的就是它发送了一个IO Control irp到另外的一个driver.

接手这个irp的是ftdisk.sys这个driver(指basic volume的情况,如果是dynamic volume的话呢,接受的是dmio.sys这个driver),这个driver然后创建自己的pdo,并且把这个pdo关联(不是attach)到了partmgr.sys所在的stack,实现了上面两个stack之间的关联.这个pdo也加载了自己的fdo,一个叫volsnap.sys提供.

这个irp完成以后,partmgr完成原来的query bus relations irp,可以看到disk.sys创建了若干个pdo,attach到了自己的fdo上面,再这以后,disk所在的stack的top device就不是partmgr.sys了,而是最后一个由disk创建的pdo.而partmgr在系统里面注册了通知消息,它能在以后的 volume change的时候得到通知,然后会发送相应的io control irp到ftdisk,然后ftdisk完成更新.

接下来事情又变得简单了,file system driver加载,在遇到第一次访问磁盘的时候,mount到由ftdisk创建的pdo上面去,再次实现两个stack的关联.

上面就是整个过程的大概流程.

明白了这个过程,要实现一个虚拟xx的就容易了.
说说daemon-tools一类的实现方式吧.

他们基本都提供一个bus driver(d343bus.sys),作为一个 boot driver 由ntldr加载到内存,ntoskrnl在适当的时候会调用它的driverentry以及adddevice函数,这两个函数里面分别加载了fdo和创建了自己的pdo,这个pdo的inf文件里面表示它要加载的driver是一个叫d343port.sys的driver,这个driver再在 scsiport的帮助下create了一个pdo.这个pdo返回的id很有趣,SCSI\\CDRom,SCSI\\RAW,这样的话, windows就把它当作了一个cdrom来处理.再向上的fdo,filter都交给windows来操作了.

如果是一个虚拟硬盘呢?你马上就反映过来了,报告pdo的id为Gendisk一类的就ok.

当然实际的实现远不是这么简单的,bus driver,mini port driver都有很多要注意的地方.
(以上大部分属于想象推测,没有经过严格的认证,有错的地方请包涵).

到这里基本上这个文章又结束了.
也许有人要问这些东西是怎么来的?当然是用softice + 2000代码 + ida来的了,唯一要修改的就是要让softice在所有的外部driver的driverentry调用前正常工作.这个方法在驱网的论坛上能找到http://www.driverdevelop.com/forum/viewthread.php?tid=66643