-
-
[原创]ConditionBP Plugin（自动下返回user领空的断点，call调用跟踪）
-
发表于: 2016-5-9 09:59
-
一、插件使用背景
1、OD跟踪时，给一些API下断点时，有时会断在系统的其他模块中，但这些我们是不想要的，于是一般会下条件断点，只有来自用户领空的调用才断下，为了方便该类断点添加了“CondditionBP”功能
2、分析某一类程序时，可能会对一类API感兴趣，因此希望每次在OD启动后，都能自动在这些感兴趣的API上下各类断点，CondditionBP提供配置文件，实现这个功能，免去每次都要挨个下断点的痛苦
3、跟踪某些程序时，可能有反调试，反VM的检测，程序很快就退出了，这时我们想知道这个代码运行的流程，而用“RUN 跟踪”功能记录太多，运行太慢，有时候还会不知道跑哪去了，于是CondditionBP提供了"Trace Call"功能，在每个call上自动下断点跟踪调用
4、插件名称是写第一个功能是起的，可能并不合适，大家自行忽略...
二、插件功能
1、可以配置断点，让OD启动时自动下断 点
2、可以配置条件断点，只有在用户领空的调用才断下
3、可以跟踪程序call调用流程
三、ConditionBP
3.1 配置APIBP.ini
如果"ConditionBPAddr"为0，插件会计算调试进程的地址 ，并以此作为默认的user领空下条件断点
3.2 下只有用户调用的API断点（也可在选中的指令上按快捷键"Ctrl + 1"）
四、TraceCall
在程序load后，选中"TraceCallByOD"或"TraceCallByMap",然后F9运行即可（如果设置了"AutoTrace"，会自动运行）
4.1 TraceCallByOD
利用OD插件自带的call查找功能搜索call，找的call未经过过滤处理，call会很多，执行会略慢，log会比较大，但调用流程记录是最全的
4.2 TraceCallByMap（建议使用）
利用map文件导入call，一般通过IDA导出，call会经过过滤处理，只导入"fn_"或"sub_"开头的call，会省去大量识别出的运行库的call，call量少，执行快，log小，但有可能流程记录不够全
4.2.1 使用IDA脚本导出Map（建议使用）
用IDA打开要分析的程序，待IDA分析完毕后，运行附件中的IDA脚本“exportfunction.idc”，会自动导出map文件到要分析程序的同目录下，直接使用即可
4.2.2 直接使用IDA的map导出功能
1> 用IDA导出map文件，注意只选中"Dummy names"即可
2> 将导出的map文件放到要Trace的sample的同目录下，点击"TraceCallByMap"会自动导入，如果未找到会提示查找map文件位置
4.3 当程序执行结束后，会在"C:\ODPluginLog"(XP系统)下输出log记录，vista以上系统在“%AppData%\LocalLow\ODPluginLog”下,sub call会缩进2个空格，如果在vista以上系统还会显示reloc的call地址，方便在IDA中查看，同时会输出call调用的时间点(ms),如果是用map分析的模式，还会输出备注的函数名
4.4 TraceCall功能只能分析未加壳处理的正常程序，异常call或经过混淆处理的代码会使记录混乱甚至崩溃，请谨慎使用,当然如果能够跟踪到脱壳后的代码，然后抓dump经IDA分析后，再进行"CallTrace"也是可以的。
4.5 可参照IDA脚本“exportfunction.idc”解析出的map文件，增加或删除相关的跟踪call，已抓取自己感兴趣的call信息
五、插件及测试用例
ConditionBP_1.0.2.9.zip
1.0.2.10版(增加debug log实时输出,用DebugView过滤"[ODPluginLog]"即可):
ConditionBP_1.0.2.10.zip
1、OD跟踪时，给一些API下断点时，有时会断在系统的其他模块中，但这些我们是不想要的，于是一般会下条件断点，只有来自用户领空的调用才断下，为了方便该类断点添加了“CondditionBP”功能
2、分析某一类程序时，可能会对一类API感兴趣，因此希望每次在OD启动后，都能自动在这些感兴趣的API上下各类断点，CondditionBP提供配置文件，实现这个功能，免去每次都要挨个下断点的痛苦
3、跟踪某些程序时，可能有反调试，反VM的检测，程序很快就退出了，这时我们想知道这个代码运行的流程，而用“RUN 跟踪”功能记录太多，运行太慢，有时候还会不知道跑哪去了，于是CondditionBP提供了"Trace Call"功能，在每个call上自动下断点跟踪调用
4、插件名称是写第一个功能是起的，可能并不合适，大家自行忽略...
二、插件功能
1、可以配置断点，让OD启动时自动下断 点
2、可以配置条件断点，只有在用户领空的调用才断下
3、可以跟踪程序call调用流程
三、ConditionBP
3.1 配置APIBP.ini
如果"ConditionBPAddr"为0，插件会计算调试进程的地址 ，并以此作为默认的user领空下条件断点
3.2 下只有用户调用的API断点（也可在选中的指令上按快捷键"Ctrl + 1"）
四、TraceCall
在程序load后，选中"TraceCallByOD"或"TraceCallByMap",然后F9运行即可（如果设置了"AutoTrace"，会自动运行）
4.1 TraceCallByOD
利用OD插件自带的call查找功能搜索call，找的call未经过过滤处理，call会很多，执行会略慢，log会比较大，但调用流程记录是最全的
4.2 TraceCallByMap（建议使用）
利用map文件导入call，一般通过IDA导出，call会经过过滤处理，只导入"fn_"或"sub_"开头的call，会省去大量识别出的运行库的call，call量少，执行快，log小，但有可能流程记录不够全
4.2.1 使用IDA脚本导出Map（建议使用）
用IDA打开要分析的程序，待IDA分析完毕后，运行附件中的IDA脚本“exportfunction.idc”，会自动导出map文件到要分析程序的同目录下，直接使用即可
4.2.2 直接使用IDA的map导出功能
1> 用IDA导出map文件，注意只选中"Dummy names"即可
2> 将导出的map文件放到要Trace的sample的同目录下，点击"TraceCallByMap"会自动导入，如果未找到会提示查找map文件位置
4.3 当程序执行结束后，会在"C:\ODPluginLog"(XP系统)下输出log记录，vista以上系统在“%AppData%\LocalLow\ODPluginLog”下,sub call会缩进2个空格，如果在vista以上系统还会显示reloc的call地址，方便在IDA中查看，同时会输出call调用的时间点(ms),如果是用map分析的模式，还会输出备注的函数名
4.4 TraceCall功能只能分析未加壳处理的正常程序，异常call或经过混淆处理的代码会使记录混乱甚至崩溃，请谨慎使用,当然如果能够跟踪到脱壳后的代码，然后抓dump经IDA分析后，再进行"CallTrace"也是可以的。
4.5 可参照IDA脚本“exportfunction.idc”解析出的map文件，增加或删除相关的跟踪call，已抓取自己感兴趣的call信息
五、插件及测试用例
ConditionBP_1.0.2.9.zip
1.0.2.10版(增加debug log实时输出,用DebugView过滤"[ODPluginLog]"即可):
ConditionBP_1.0.2.10.zip
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
