-
-
[求助]调试某程序时遇到的Anti-Debug, 求各位大牛帮忙想想对策
-
发表于: 2014-7-25 05:59
-
在调试某程序时遇到的Anti-Debug, 使用OllyDbg下断后(不论是软件断点还是硬件断点), 程序正常断下了(可以认为OllyDbg是收到了调试事件的), 此时可以进行各种调试, F9跑起来后程序立马就崩了, 其报告的异常地址正是我下断点的位置, 如下图所示:
有的线程断下了不会崩溃, 有的会崩溃(主线程随便断都不会崩溃), 所以可以认为这道Anti应该是针对特定线程的
按照正常的调试逻辑来说, 其过程应当如下:
执行到INT3断点---程序中断---控制权交给调试器---F9运行后调试器报告已成功处理此次异常---程序继续运行
但是这症状就很像是调试器告诉了Windows自己并未成功处理该异常, 接着Windows就把这个进程判了死刑..弹出窗口告知用户, 找了点资料, 发现有网友说NtSetInformationThread的ThreadHideFromDebugger参数可以导致这样的症状, 看了下WRK的代码, 实际上这个函数是设置了ETHREAD->CrossThreadFlags变量, 于是拿出Windbg查看该程序各个线程的ETHREAD结构, 但是其所有线程的CrossThreadFlags均为80h, 所以也可以排除ThreadHideFromDebugger在捣蛋, 实在没辙了, 求各位大牛帮忙出出对策, 小弟在此先行谢过
有的线程断下了不会崩溃, 有的会崩溃(主线程随便断都不会崩溃), 所以可以认为这道Anti应该是针对特定线程的
按照正常的调试逻辑来说, 其过程应当如下:
执行到INT3断点---程序中断---控制权交给调试器---F9运行后调试器报告已成功处理此次异常---程序继续运行
但是这症状就很像是调试器告诉了Windows自己并未成功处理该异常, 接着Windows就把这个进程判了死刑..弹出窗口告知用户, 找了点资料, 发现有网友说NtSetInformationThread的ThreadHideFromDebugger参数可以导致这样的症状, 看了下WRK的代码, 实际上这个函数是设置了ETHREAD->CrossThreadFlags变量, 于是拿出Windbg查看该程序各个线程的ETHREAD结构, 但是其所有线程的CrossThreadFlags均为80h, 所以也可以排除ThreadHideFromDebugger在捣蛋, 实在没辙了, 求各位大牛帮忙出出对策, 小弟在此先行谢过
|
|
|---|---|
|
|
|
|
|
|
|
|
只测试了头部下断？往下的位置会不会也这样？感觉总不能全部都检测吧，往下的地方有没有call xxxxxxxx 的进去下断看看
|
|
|
|
|
|
|
|
|
|
