能力值:
( LV2,RANK:10 )
|
-
-
2 楼
http://bbs.pediy.com/showthread.php?p=1321599
|
能力值:
( LV3,RANK:20 )
|
-
-
3 楼
谢谢,这个帖子去年已经看过了,但是实际调试中,发现OD清理断点后,清理断点SetContextThread的调用次数与线程的数量不一致。。似乎是少设置了几个线程,不太像是SetContextThread失败了。
|
能力值:
(RANK:20 )
|
-
-
4 楼
anti_od,个人觉得还是利用父进程判断是否是explore.exe。。!拙见
|
能力值:
( LV2,RANK:10 )
|
-
-
5 楼
看了下原贴,要触发这个bug要多线程访问同一地址,在该地址上设置硬断后,清除硬断,在某些情况下SetContextThread清除硬断有可能会失败,而od没有检查结果,直接认为硬断清除成功,导致硬断清除失败的那个线程里依旧会触发这个断点,而此时系统和od都不处理这个断点,导致异常,按照你描述的,SetContextThread的调用次数与线程的数量不一致,所以有些未调用SetContextThread的线程硬断依旧存在。
|
能力值:
( LV2,RANK:10 )
|
-
-
6 楼
你把od的进程名改成explorer.exe呢
|
能力值:
(RANK:20 )
|
-
-
7 楼
对的 哦。。。那就利用系统特性进行反调试吧
|
能力值:
( LV4,RANK:50 )
|
-
-
8 楼
好东西,下载下来研究下。
|
能力值:
( LV3,RANK:20 )
|
-
-
9 楼
上回一个群里说SetContextThread的工作方式是往目标插入APC。
如果这个成立,那么我的想法是:
当一个进程存在N条线程,且这些线程频繁并且快速的调用同一个API时,利用OD对这个API下断点,那么就会往目标进程插入N个用于设置DRX的APC,而当第一个APC或者第X个小于N的APC完成时,目标进程就已经被API中断下来了,此时还有未完成的APC。这些未完成的APC将由OD恢复(F9)之后继续执行,而OD在F9之前已经清空了硬断列表,认为自己已经没有需要接收的异常了,那么当目标进程继续运行时,未完成的APC将得以继续执行,继续往刚才没有设置DRX的几个线程继续设置API断点。那么将导致目标进程接下来产生的API异常没办法处理。
当然这种情况的前提条件也是那些导致崩溃的线程一定调用了该API,否则不会产生无法捕获的断点。
(我对APC并不怎么了解,甚至不了解APC是什么东西,所以这里也是凭空想象,希望知道其ANTI原理的大牛们可以指点一二)
|
能力值:
( LV3,RANK:20 )
|
-
-
10 楼
一个铁子 一个故事 比听相声实惠。
|
能力值:
( LV10,RANK:163 )
|
-
-
11 楼
OD 2.01也有这问题.windbg不会有事.
hook一下NtSetContextThread..按windbg的方法设置.
|
能力值:
( LV3,RANK:20 )
|
-
-
12 楼
是SetContextThread参数的问题吗
|
能力值:
( LV10,RANK:163 )
|
-
-
13 楼
明显不是参数问题,x64dbg也能断,运行不崩(提示错误:EXCEPTION_SINGLE_STEP).
|
能力值:
( LV12,RANK:760 )
|
-
-
14 楼
因为线程APC可以插入,才能SET~(OD会先Get,如果Get成功了,才能Set,但是Get不成set也不成)。
Windbg的方式太高大上了~
|
能力值:
( LV2,RANK:10 )
|
-
-
15 楼
围观。。。
|
能力值:
( LV2,RANK:10 )
|
-
-
16 楼
硬断之后有个 EXCEPTION_SINGLE_STEP 单步是 x64dbg 的问题...
作者说可能是使用的 TitanEngine 调试引擎有问题
|
|
|