找下PowerTool 0.40最新版的茬 (1)

显示全部楼层 · 发表于 2011-8-13 18:41:27

本帖最后由 dl123100 于 2011-8-15 14:39 编辑

刚看到PowerTool 0.40出正式版了，随便找了一个测试环境看了下它的一些功能。

下面是0.40新增或改进项目的一点问题。
1、PT新版新增了调试寄存器的检测，但是由于对调试寄存器了解不够深入，有一些错误。
本来准备拿一些比较特殊的改写调试寄存器来测试，但是一看显示界面，大囧。
QQ截图20110813233654.png

最新版误将几个DRX调试寄存器的名字写作CRX（正确的名字应该是DR0---DR7），作者对调试寄存器的了解还得加深。
PT遇到某个调试寄存器的值非零就提示该处可能被hook，实际上某些还原软件也可能对它做手脚，但并不是hook。
另外，只检测几个DRX的值，而没有检测相应的一些重要标志位，更不说一些组合方式利用调试寄存器了。

2、PT新版加入了内核入口点的检测，但是由于对syscall（系统调用）机制的不熟悉，会导致正常系统出现一些误报或者漏报。
PT不支持2000系统，就似乎默认了syscall只是某一种，只显示KiFastCallEntry的地址。
而事实上，即使在Win 7环境下，三种syscall入口都是可能的。
这里由于PT直接将KiFastCallEntry固定为内核入口点，导致检测不了hook。
另外，由此也导致PT的内核入口点检测读取错误的、不起作用的“入口”地址，通过交叉分析，可能得出存在hook的结论。

3、PT新版修正了之前版本将MBR启动代码的16位汇编解析为32位汇编的问题。
不考虑重定位，显示时，PT将启动地址标为00000002，而不是00000000，总感觉怪怪的。
未命名.jpg

4、PT新版加入了woodmann论坛Kayaker的代码，实现在Win7快速遍历指定内核区域。
http://www.woodmann.com/forum/en ... s-space-in-Windows7
不过Kayaker的代码只是demo性质的，存在一些问题，比如最基本的校验，可能导致崩溃。

5、PT新版改进了网络连接的显示，本想测试解析IP库是否存在问题，结果测试中出现了蓝屏，所以顺便看了下网络连接的枚举。
Win7下的枚举，PT使用了debugman的《WIN7下向NSI取TCP UDP信息》提供的代码。
http://www.debugman.com/discussi ... 4%BF%A1%E6%81%AF/p1
可惜原帖给出的代码本身存在一些问题，比如分配释放pool的逻辑存在问题，可能导致蓝屏。
一个典型的下PT在Win7枚举网络连接导致蓝屏时的栈回溯如下：

945a7464 81c57b92 00000003 1a501172 00000000 nt!RtlpBreakWithStatusInstruction
945a74b4 81c58673 00000003 945a7940 000001ff nt!KiBugCheckDebugBreak+0x1c
945a7878 81dc91d9 000000c2 00000006 0000108e nt!KeBugCheck2+0x6a1
945a78ec 88c1bc15 945a7948 00000000 8cb300b8 nt!ExFreePoolWithTag+0x129
WARNING: Stack unwind information not available. Following frames may be wrong.
945a79a8 88c2d635 945a7a5c 945a7a50 878b3030 kEvP+0x3c15
945a7a6c 88c37dbd 878b3030 8cb300b8 0000f428 kEvP+0x15635
945a7bec 81c4311a 878b3030 8cb300b8 00000000 kEvP+0x1fdbd
945a7c0c 82118a40 8cb300b8 8cb30128 923aff38 nt!IofCallDriver+0x7e
945a7c2c 82119bd6 878b3030 923aff38 00000000 nt!IopSynchronousServiceTail+0x258
945a7cc8 82120332 00000178 8cb300b8 00000000 nt!IopXxxControlFile+0x740
945a7d04 81da8173 00000178 00000000 00000000 nt!NtDeviceIoControlFile+0x4c
945a7d04 7702a364 00000178 00000000 00000000 nt!KiFastCallEntry+0x163
001f8878 77000844 74f8e074 00000178 00000000 ntdll!KiFastSystemCallRet
001f887c 74f8e074 00000178 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
001f88dc 75c01830 00000178 002221c4 00000000 KERNELBASE!DeviceIoControl+0xee
001f8908 013e6762 00000178 002221c4 00000000 kernel32!DeviceIoControlImplementation+0x80
001ff260 00000000 00000000 00000000 00000000 PowerTool+0xa6762

显示全部楼层 · 发表于 2011-8-13 23:54:11

本帖最后由 dl123100 于 2011-8-15 01:43 编辑

今天写到这里，明天开放。
Anti-rootkit如某些大牛说的，现在越来越多人在写了，门槛也越来越低了。但是要写出一个优秀的ark，不仅仅靠得是模仿和不仔细分析就增加功能，需要对系统机制的深入理解，需要作者的思考。
有感于一直以来很多人对ark的误解（当然，不是后面PT作者所想的）和前段时间PowerTool交流群某些人对XueTr作者的人身攻击，主要给出了PT这次5处更新对应项目的一些问题，作为一点回应。

注：这里的“人身攻击”不是后面PT作者所想的一般的批评XueTr，而是赤裸裸地攻击无辜的XueTr作者。

显示全部楼层 · 发表于 2011-8-14 10:16:58

本帖最后由 dl123100 于 2011-8-15 17:22 编辑

一点说明：
1、调试寄存器，顾名思义，这里指P3 x86下用于扩展CPU调试机制的Drx寄存器。
调试器可直接利用它实现硬件断点（这里是内核调试器），rootkit等可以通过设置调试寄存器，可以对指定地址的读取、写入、执行进行控制，达到隐藏目的。
这里PT检测的是全局的Drx寄存器，并不是用户态的per thread context下的drx。

举几个实例：
1、一些反外{过}{滤}挂驱动会修改调试寄存器，达到阻止hook被恢复等目的。
2、360还原保护器会对IO端口下硬件断点，拦截直接IO方式的穿还原。
3、一些反外{过}{滤}挂驱动及微点主防驱动恢复hook前会清零调试寄存器，减少受干扰可能。

2、内核入口点。
这里内核入口点不够明确，就PT检测项目而言指的是系统调用的内核入口点。
wiki:系统调用指程序向操作系统内核请求需要更高权限运行的服务，它提供了用户程序与操作系统之间的接口。
Windows NT下系统调用对应的服务函数一般指的是SSDT和Shadow SSDT两张表内的函数，很多驱动会通过替换这些表内的函数或者改写函数内部代码等方法实现hook，做一些拦截、隐藏等动作。
而由用户态发起请求到分发服务函数有一个过程，由于SSDT和Shadow SSDT相对明显，可以通过对从用户态发起请求到分发服务函数中间过程的代码进行改写，来实现相对隐蔽的hook。
PT准备检测的是便是这部分hook。

待续

显示全部楼层 · 发表于 2011-8-14 10:31:25

拜读大作，嘿

显示全部楼层 · 发表于 2011-8-14 10:38:21

前来膜拜dl大牛

显示全部楼层 · 发表于 2011-8-14 10:41:46

都看不懂

显示全部楼层 · 发表于 2011-8-14 10:44:24

本帖最后由 zuo 于 2011-8-14 10:45 编辑

口条发表于 2011-8-14 10:41
都看不懂

简单来说，PT作者对系统机制的理解不全面，很多地方没有考虑周全，导致漏检测(比如内核入口点只检测了一个）
不过将调试寄存器名称写错有点囧了

显示全部楼层 · 发表于 2011-8-14 10:46:32

zuo 发表于 2011-8-14 10:44
简单来说，PT作者对系统机制的理解不全面，很多地方没有考虑周全，导致漏检测(比如内核入口点只检测了一 ...

我是看不懂那些专业术语

显示全部楼层 · 发表于 2011-8-14 11:02:59

dl123100 发表于 2011-8-14 00:54
今天写到这里，明天开放。
Anti-rootkit如某些大牛说的，现在越来越多人在写了，门槛也越来越低了。但是要 ...

感谢dl牛提出来的问题

CRX的名字确实写错了。。。不过没什么大碍
重要标志位可以自己分析DR7，
不过打算在下个版本，详细列出来

入口点监测，可能没检测全，以后的版本继续加强了。。。

后面几个问题，我也再检查一下，

PT确实还算不上优秀，只能继续改进，
如果只是进程线程文件，确实很多人都可以做，
不过dl牛好像把PT归于这一类了。。。

而且ARK也不可能全部都考虑到，
即使是XT也有考虑不到的地方，枚举不到的模块吧？
PT已经加了很多自己的东西，也不能单纯的说是模仿了吧

群里面有人攻击XT吗？会不会是dl牛过于敏感了

有人习惯用PT，有人习惯用XT，不可能让大家都统一的标准啊。。。
更多的人应该是两个都在用吧。。。

不管怎么说XT在linxer牛和dl牛的努力下，
的确是第一流和最优秀的ARK，但是对用户的要求也很高

而我则努力结合用户的反馈加上自己的想法。
做一个简单易懂的工具，即使不把PT算作ARK，
能在大多数情况下解决病毒就可以了，呵呵

显示全部楼层 · 发表于 2011-8-14 11:08:31

这样的文章一定要在第一页占位观看啊。非常感谢dl大牛的指导了，不过PT交流群的人居然会对XT的作者人参公鸡，这个令我很意外啊，我觉得deker大牛好像也没什么地方得罪人的。

[原创文章] 找下PowerTool 0.40最新版的茬 (1)

评分

评分

评分