C++博客-曲径通幽-随笔分类-Debug \ Reverse Engineering

Linux下调试死循环

chinloon — Mon, 13 Jun 2011 05:49:00 GMT

最近在工作中发现网络通信收发文件部分，发送一次文件后，就再也不能发第二次了。本以为是协议的问题，后来用TOP发现CPU过高，才通过GDB看到了是一个清空Buffer类的代码有BUG，计算无符号整形的操作溢出了。
具体跟踪方法记录一下。首先正常启动程序，然后进行收发文件操作，触发死循环。而后通过 top -H 查看哪个线程(其实是PID，redhat的线程是fork进程实现的)占用CPU过高，而后gdb -p [pid] attach 之，最后bt 打印堆栈。

chinloon 2011-06-13 13:49 发表评论

一段汇编代码

chinloon — Thu, 06 Jan 2011 04:48:00 GMT

这是从别人博客上摘的一段C嵌汇编码
( http://www.cppblog.com/kevinlynx/archive/2011/01/02/137886.html )

__declspec(naked)
void caller(void* pfn, )
{
    __asm
    {
        pop eax;
        add eax, 3;
        xchg dword ptr[esp], eax;
        push eax;
        ret;
    }
}

下面是调用方法

void print_str( const char *s )
{
    printf( "%s\n", s );
}

{
   ...
caller( print_str, "a string" );
   __asm add esp, 4
   ...
}

原作者讲了一些基础，这里就不提了
看了一遍，发现 "ADD EAX, 3" 的用法有点奇怪（我相信搞破解的人一定比较熟悉，但正常的程序不会这么写。）
初看 EAX 是地址，+3是很危险的，但仔细一看，发现代码是为了从最外层主调函数一路穿越"caller" 直达 print_str，这里牵涉到一个重要问题，就是在CALL指令时，会有将“CALL指令下一条地址压栈”的操作，那么代码思路很明了了，就是为了要造出调用print_str时，ESP(+0) 指向 caller(..)调用的下一个地址。
第一关已经顺利搞定，但又碰到个问题，由于 print_str 的入参是可变的，所以必须用 cdecl调用，那RET之后如何平栈呢？如果直接跳到 caller下一条地址，就丧失了平栈的机会，最终会在某个主调函数上被微软的 stack cookie捕获抛个SEH。
这里就用到文章开头提到的 ADD EAX, 3。
必须要造一个环境，让 caller 调用完成后，给个机会清理现场。于是乎，caller之后就有了 ADD ESP, 4。其实这里的4是与print_str的入参数目相关的，每个参数要多加 4字节，如此一来，整个代码就理顺了。
那为什么是 ADD EAX, 3呢？应该是预估出一条ADD指令占用多少长度，和具体的环境有关。因为没看INTEL手册，这里只能认为ADD 寄存器+WORD的长度是3个字节。我用VC试验了一下，的确是如此，我也尝试了ADD 寄存器+DWORD，长度变为了5个字节。

chinloon 2011-01-06 12:48 发表评论

利用C++对象模型通过父类调用子类特有的虚函数

chinloon — Mon, 18 Oct 2010 10:07:00 GMT

最近QQ游戏开发群里有一位朋友出了一道题，“如何在基类中调用子类独有的函数，而不调用强制转换”。这道题我一时间没做出来，但是如果放宽限制，其实可以玩一个有趣的游戏。
如果题目改为“如何在基类中调用子类独有的虚函数，而不调用Class类型强制转换”，那就可以利用C++对象模型中的虚表的直接访问来实现父类调用子类的特有虚函数。（注意，这里特有是指子类有而基类没有。）
以下是我的解法，也在QQ群里发了，想不到引起群成员小小的轰动，看来游戏开发还是有很多同学对底层不感兴趣啊。

1 #include <stdio.h>
2
3 class CFather{
4 public:
5     virtual ~CFather(){}
6 };
7
8 class CSon : public CFather{
9     virtual ~CSon(){}
10
11     virtual void DoSomething(void){ printf("son is crying\n"); }
12 };
13
14 int _tmain(int argc, _TCHAR* argv[])
15 {
16     CFather* fa = new CSon();
17     DWORD dwDoSomething =  (*(DWORD*)(*(DWORD*)fa+4));
18     _asm MOV ecx, fa
19     _asm CALL dwDoSomething
20
21     system("pause");
22     return 0;
23 }
24
25

chinloon 2010-10-18 18:07 发表评论

伟大的pdb

chinloon — Thu, 22 Jul 2010 00:26:00 GMT

昨晚有客户反应，产品中的某个进程启动后1分钟内会消失，看了log未发现异常。
于是远程过去，想看本溃报告，很遗憾的是，没有生成任何本溃报告（我们用的是Debug系列的api写的Crash Reporter）。情急之下，唯有求助伟大的Windbg了。
attach，g，过一会儿，果然发现是有一处seh。但随即发现缺symbols，于是马上去发布服务器上找相应的pdb文件，放到远程上去，.reload，果然，未知地址被准确地翻译成代码中的标识符。
原来，崩溃的地方是动态加载的一个dll中的一个回调函数，怪不得没捕获到Crash Report。
总结下来，Release版本的PDB生成是个关键，单有Windbg仍旧是巧妇难为无米之炊啊。

chinloon 2010-07-22 08:26 发表评论

使用Windbg调试高CPU占用率的进程

chinloon — Mon, 12 Jul 2010 11:17:00 GMT

最近用户发现某个进程CPU占用率过高，导致服务器假死。
于是想用Windbg尝试调试一下。幸好我们的软件发布时都会保留一份PDB文件。因此Windbg能够准确地找到Symbol，即使是Release Version。
打开Windbg帮助文档，搜索"CPU"关键字，随即找到了“Tracking Down a Processor Hog”。按照上面的方法试了一下，果然可以准确地定位到某个死锁的线程。
现在在工作中，利用Olldbg和Windbg的机会越来越多，在解决问题的过程中，也越发有成就感了。

chinloon 2010-07-12 19:17 发表评论

VC Release Debugging

chinloon — Thu, 01 Jul 2010 06:43:00 GMT

今天在Code Project最新更新中看到"XCrashReport : Exception Handling and Crash Reporting"一文，泛读之后，又读了其中引用的几篇文章。觉得挺不错。主要讲了VC Relase版本如何定位问题，主要思路是打开Link选项"Generate debug info"、添加参数"/OPT:REF"和/ignore:4089 "，用作Release版本产生PDF，且优化的时候能使产生的目标文件更小。效果比较明显。
随便写了一个会崩溃的工程，崩溃后记录其崩溃位置，然后随便打开一款调试器（OD，WinDBG，VC都可）运行debug，然后改EIP到出错的位置下断，GO！
其实，在运行出错的位置，然后改EIP的方法，以前在用OD时会使用到（类似F4或VC调试时的移动EIP），一直觉得ESP和Call Stack应该是分析Crash的重点，有时忽略了EIP的重要性。

chinloon 2010-07-01 14:43 发表评论

C++ 与 Delphi交互的一个问题

chinloon — Sun, 20 Jun 2010 15:34:00 GMT

最近拿到一个第三方厂家的库，由于Delphi的同事看不懂c++的例子，所以让我用C++封装一个简单的Wrapper给其调用。
后来发现一个问题，由于原始的函数声明中的参数使用字符数组 (char szData[MAX_PATH]) 而不是用常用的指针(char *)，给Delphi同事调用后，发现函数调用完退栈时候程序本溃，原因是访问违例，非法地址访问0x72。
这么一来感觉比较奇怪，0x72 这个地址显然是个垃圾地址，一般如果是空指针的话因该是 0x00，如果是野指针，一般也不至于会那么小，0x72与程序加载地址都相去甚远。
在vc6（公司只准用vc6）里跟了一下反汇编，感觉信息缺少比较多，能看到的地方已经堆栈被破坏了。于是用了OD跟一下。发现Delphi调用我封装的函数时，明明2个入参，却传入了3个。多传了个260。260对于vc程序员应该比较熟悉了，就是MAX_PATH的值。于是乎，告知了Delphi程序员，方才得知，原来Delphi是可以在声明时指定数组长度的，也就是说，函数的入参，数组和指针是两种声明，如此一来，水落石出了。

chinloon 2010-06-20 23:34 发表评论