机器狗的原理是什么
答案:1 悬赏:30
解决时间 2021-01-17 19:29
- 提问者网友：难遇难求
- 2021-01-17 01:32
机器狗的原理是什么
最佳答案
- 二级知识专家网友：迷人又混蛋
- 2021-01-17 03:11
机器狗原理：
建立磁盘底层驱动。
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进程写入动态连接库。那么，还原就没用了。还会带来网络负载问题，可能是作者比较仁慈吧。
好了，分析了以上的过程，解决的办法就出来了，就是要通过对操作系统的内核编译，将他所定位的目的地址占据，这样，除非是格式化，否则，任何操作的不会在底层夺取该位置。（不要问权限问题，在底层是没有这个说法的，先入为主。）
建立磁盘底层驱动。
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进程写入动态连接库。那么，还原就没用了。还会带来网络负载问题，可能是作者比较仁慈吧。
好了，分析了以上的过程，解决的办法就出来了，就是要通过对操作系统的内核编译，将他所定位的目的地址占据，这样，除非是格式化，否则，任何操作的不会在底层夺取该位置。（不要问权限问题，在底层是没有这个说法的，先入为主。）
我要举报
如以上回答内容为低俗、色情、不良、暴力、侵权、涉及违法等信息，可以点下面链接进行举报！
点此我要举报以上问答信息！
大家都在看
推荐信息