Conditional Branch
Conditional Branch是Ollydbg的一个插件,用于
记录跳转的插件.
我在浏览
http://bbs.kanxue.com/showthread.php?t=59965的时候发现了它.
所以手痒下载下来试了试,但是试了好多遍发现,这个插件没能发挥作用.
我以为是我的问题,结果费劲的把它的说明文件读了一遍,读完了也没什么新的发现.
蛋裂中........
我以为是插件的问题,所以把文件cbl_gui.dll与Conditional_Branch_Logger.dll拷到了桌面上,被分析的程序也在桌面上,
这时使用这个插件,结果正常了,于是花了段时间研究了一下,发现是cbl_gui.dll存放路径的问题,
插件一般放在插件目录中,才会起作用,就算把cbl_gui.dll放在Ollydbg的插件目录中也是无效的.
但是如果放在其他的某些地方,则会有效[例如:被分析的文件目录下,C:\,C:\WINDOWS\system32等]
[个人认为是是系统环境变量产生的效果]
如果你细心的话,Ollydbg载入下载的插件Conditional_Branch_Logger.dll成功,
但是当你使用插件Conditional_Branch_Logger.dll的菜单Configuration时,
状态栏显示上面的错误,cbl_gui.dll,因为cbl_gui.dll的路经出错.
Ollydbg的状态栏有文字闪过,其实就是下面的数据.
Text strings referenced in Conditio:.text, item 88
Address=0087402C
Disassembly=push 0087E90A
Text string=ASCII "cbl_gui.dll failed to load correctly"
这就说明Conditional_Branch_Logger.dll没有找到cbl_gui.dll文件
其实,不太清楚这个算不算Bug,所以发出来大家看看.
Conditional_Branch_Logger.dll的下载地址:
http://bbs.pediy.com/showthread.php?t=59777@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
在使用Ollydbg的过程中,我们经常需要知道进入子过程的源地址,
现在以系统自带的记事本为例进行说明,
0100739D > $ 6A 70 push 70
0100739F . 68 98180001 push 01001898
010073A4 . E8 BF010000 call 01007568
010073A9 . 33DB xor ebx, ebx
010073AB . 53 push ebx ; /pModule => NULL
010073AC . 8B3D CC100001 mov edi, dword ptr [<&KERNEL32.GetModuleHandleA>] ; |kernel32.GetModuleHandleA
010073B2 . FFD7 call edi ; \GetModuleHandleA
010073B4 . 66:8138 4D5A cmp word ptr [eax], 5A4D
010073B9 . 75 1F jnz short 010073DA
010073BB . 8B48 3C mov ecx, dword ptr [eax+3C]
当我们在调试程序的时候,进程需要进入过程分析代码,当然这种情况下我们当然知道是从哪里来到这个过程的,
但是有时候我们已经在子过程中,我们想知道到底是从哪里来到这个子过程的,这时候我们该怎么办呢?
有人说为什么不利用右键菜单里的
Find references to>>selected command,快捷键是Ctrl+R,
[这个方法对于push xxxxxxxx这样的指令比较有效.]
当然,大家用事实说话,我们在010073B2处F7跟入,来到下面的位置.
7C80B741 > 8BFF mov edi, edi ; kernel32.GetModuleHandleA
7C80B743 55 push ebp
7C80B744 8BEC mov ebp, esp
7C80B746 837D 08 00 cmp dword ptr [ebp+8], 0
7C80B74A 74 18 je short 7C80B764
7C80B74C FF75 08 push dword ptr [ebp+8]
7C80B74F E8 C0290000 call 7C80E114
7C80B754 85C0 test eax, eax
7C80B756 74 08 je short 7C80B760
然后右键Find references to>>selected command,快捷键是Ctrl+R,显示的数据如下:
--------------------------------------------------------------------------------
References in kernel32:.text to GetModuleHandleA
Address Disassembly Comment
7C80B741 mov edi, edi (Initial CPU selection)
7C80B7C4 call GetModuleHandleA
7C81FDB2 call GetModuleHandleA
7C82F3B9 call GetModuleHandleA
7C83ABD6 call GetModuleHandleA
其实,我们想知道的是下面的这条指令,但是查找出来的结果里面没有.
010073B2 . FFD7 call edi ; \GetModuleHandleA
有人要说这样的情况,难道你不会看堆栈吗?确实这种情况,看堆栈确实可以看出来
0007FF2C 010073B4 磗. /CALL to GetModuleHandleA from NOTEPAD.010073B2
0007FF30 00000000 .... \pModule = NULL
0007FF34 00000000 ....
下面给一种情况,不知道你能不能看出跳转源地址.
对记事本程序下断点,命令行输入bp CreateFileW.F9运行程序,程序在下面的位置断下.
可能有些朋友要说,bp CreateFileW后,程序载入后,就被断下了.为什么要F9到程序运行?
F9到程序运行主要就是为了与bpx CreateFileW对比分析,
7C810800 > 8BFF mov edi, edi
7C810802 55 push ebp
7C810803 8BEC mov ebp, esp
7C810805 83EC 58 sub esp, 58
7C810808 8B45 18 mov eax, dword ptr [ebp+18]
7C81080B 48 dec eax
7C81080C 0F84 4EFF0100 je 7C830760
7C810812 48 dec eax
7C810813 0F84 C7060000 je 7C810EE0
现在你能分析出,这个CreateFileW函数到底是哪里调用了吗?
右键Find references to>>selected command,快捷键是Ctrl+R
显示的数据如下:
------------------------------------------------------------------------------
References in kernel32:.text to CreateFileW
Address Disassembly Comment
7C801A4E call CreateFileW
7C810800 mov edi, edi (Initial CPU selection)
7C814E00 call CreateFileW
7C820A8B call CreateFileW
7C820E92 call CreateFileW
7C827752 call CreateFileW
7C82D2DC call CreateFileW
7C831BBA call CreateFileW
7C835B9F call CreateFileW
7C83F5AC call CreateFileW
7C83FFE6 call CreateFileW
7C8428C5 call CreateFileW
7C85783E call CreateFileW
7C85EC2E call CreateFileW
7C860C0B call CreateFileW
7C866104 call CreateFileW
7C866134 call CreateFileW
7C869FB5 call CreateFileW
7C86A110 call CreateFileW
7C86A2F7 call CreateFileW
7C86A450 call CreateFileW
7C86A6E1 call CreateFileW
7C86A705 call CreateFileW
7C86A9E7 call CreateFileW
7C86AADE call CreateFileW
7C86AB00 call CreateFileW
7C870634 call CreateFileW
7C870698 call CreateFileW
其实说了这么多话,就是要找一种方法,
利用函数[或自过程]入口,找到调用地址.
当然这个函数不一定在系统自带的DLL中,不排除自编写的函数.
====================================================================
现在介绍一下我用的两种方法
1>Run Trace
2>堆栈分析
=====================================================================
这种方法定位的地址,虽然比较靠近关键数据,但是有时候找到关键地址所需的工作量也不小.
如果大家有更直接,更简洁的方法,希望能够拿出来与大家分享一下.
[招生]科锐逆向工程师培训(2024年11月15日实地,远程教学同时开班, 第51期)