VEH帮你定位程序崩溃地址

之前朋友有一个服务端程序,总是受到一些人的恶意漏洞攻击,没有源代码,只好反汇编修复了漏洞,并且使用WinLicense加保护授权.

漏洞总不是一次可以修复完的,恶意攻击并没有停止,然后加了WL保护程序在崩溃的时候在没有提示信息,服务器日志中也没有记录任何有用的信息了,这里所需要有用的信息即是崩溃时候汇编代码运行的内存地址.c++写的程序崩溃的时候我们经常可以看到这种包含了运行址,以及访问内存地址相关信息的对话框.

首先想到的办法是使用windbg的adplus -crash dump内存分析,cdb刚attach上目标进程就直接退出了,不错,WL检查到了调试器,自动触发了保护,程序退出进程了.所以通过windbg,od类似的调试器方案是行不通了.

还有一次,攻击影响了客户端,使部分客户端崩溃,通过日志看到的错误内存地址,经过分析发现是在SEH中,即我们平常代码__try{}__except{}的__except{}代码中,关键是这层SEH还被上一层SEH包着,找了很久还是没能有效的定位到崩溃的内存地址.

后来只好电话求助了小明哥,没说别的,就VEH向量化异常处理解决问题.

更多的知识可以看雪http://bbs.pediy.com/showthread.php?t=173853

通过看雪上的这篇文章我们可以了解到,在没有调试器的情况下,程序发生异常,如果有安装VEH,则VEH先处理异常,然后才是SEH,TopLevelEH.

我要的东西很简单,就是程序崩溃的内存地址,即当时发生崩溃的时候,cpu EIP寄存器的值.

代码就很简单了

#define DBG_PRINTEXCEPTION_C             ((DWORD   )0x40010006L)
LONG WINAPI ExceptionHandler(EXCEPTION_POINTERS * pExceptionInfo)
{
	char lpMsg[512]={0};
	switch( pExceptionInfo->ExceptionRecord->ExceptionCode )
		{
		case DBG_PRINTEXCEPTION_C:
			 break;
			 default:
			 {
				 memset(lpMsg,0,512);
				 wsprintfA(lpMsg,"Exp EIP:%x  ExpAddr:%x",pExceptionInfo->ContextRecord->Eip,pExceptionInfo->ExceptionRecord->ExceptionAddress);
				 OutputDebugStringA(lpMsg);
			 }
	}
	return EXCEPTION_CONTINUE_SEARCH;
}
BOOL APIENTRY DllMain( HMODULE hModule,DWORD  ul_reason_for_call,LPVOID lpReserved)
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		{
			AddVectoredExceptionHandler(1, (PVECTORED_EXCEPTION_HANDLER)ExceptionHandler);
		}
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
    return TRUE;
}

不错,写一个dll,然后Exe程序启动进入Main函数后,直接反汇编写段代码,loadlibrary一下dll,即可.

打开DbgView,运行目标进程,崩溃一出现,dbgview中就输出了Eip地址,在反汇编定位到代码处理,具体问题具体分析即可!

时间: 2024-10-11 21:18:28

VEH帮你定位程序崩溃地址的相关文章

Linux 使用core file文件快速定位程序崩溃代码行

问题描述 如果在 Linux下编写程序,有时运行程序的时候程序崩溃,比如说只有"Segmentation fault (core dumped) ",程序比较小的话,还可以一行一行查看,但是如果程序很庞大,一行行查询,效率非常低下.Linux下可以程序可以生成core file文件,借助gdb很快能定位到崩溃的代码行. 解决方案 测试程序,除零操作,程序会崩溃 /* test.c */ #include <stdio.h> #include <stdlib.h>

如何定位Release 版本中程序崩溃的位置 ---利用map文件 拦截windows崩溃函数

1       案例描述 作为Windows程序员,平时最担心见到的事情可能就是程序发生了崩溃(异常),这时Windows会提示该程序执行了非法操作,即将关闭.请与您的供应商联系.呵呵,这句微软的“名言”,恐怕是程序员最怕见也最常见的东西了. 在一个大型软件的测试过程中,初期出现程序崩溃似乎成了不可避免的事.其实测试中出现程序崩溃并不可怕,反而是测试的成功.作为开发的我们更需要关心的是程序中的哪个函数或哪一行导致了系统崩溃,这样才能有针对性的进行改正. 本文描述了自己总结的几种定位崩溃的办法.

VS2005(vs2008,vs2010)使用map文件查找程序崩溃原因

VS 2005使用map文件查找程序崩溃原因 一般程序崩溃可以通过debug,找到程序在那一行代码崩溃了,最近编一个多线程的程序,都不知道在那发生错误,多线程并发,又不好单行调试,终于找到一个比较好的方法来找原因,通过生成map文件,由于2005取消map文件生成行号信息(vc6.0下是可以生成行号信息的,不知道microsoft怎么想的,在2005上取消了),只能定位在那个函数发生崩溃.这里可以通过生成cod文件,即机器码这一文件,具体定位在那一行崩溃. 首先配置vc2005生成map文件和c

VS2005(vs2008,vs2010 VS2012)使用map文件查找程序崩溃原因

转载http://blog.csdn.net/luxiaoyu_sdc/article/details/6458872 一般程序崩溃可以通过debug,找到程序在那一行代码崩溃了,最近编一个多线程的程序,都不知道在那发生错误,多线程并发,又不好单行调试,终于找到一个比较好的方法来找原因,通过生成map文件,由于2005取消map文件生成行号信息(vc6.0下是可以生成行号信息的,不知道microsoft怎么想的,在2005上取消了),只能定位在那个函数发生崩溃.这里可以通过生成cod文件,即机器

IOS调试技巧:当程序崩溃的时候怎么办 iphone IOS

转载:http://article.ityran.com/archives/1143 有这样一种情形:当我们正在快乐的致力于我们的app时,并且什么看都是无比顺利,但是突然,坑爹啊,它崩溃了.(悲伤地音乐响起) 我们需要做的第一件事就是:不要惊慌. 修复崩溃不是很困难的.假如你崩溃了,并且胡乱的改些东西,而且还在不停的念着咒语希望bug神奇的自动消失,你大多数情况下都会使情况更麻烦.相反的,你需要知道一些系统的方法,并且学习怎么找到崩溃和他的原因. 第一件需要知道的就是在你的代码中准确的找到cr

C++技术问题总结-第15篇 内存泄露有哪些方法定位,崩溃有哪些方法定位

Visual C++内存泄露检测,可采用VLD工具. VLD:Visual Leak Detector.VLD是一款用于Visual C++的免费的内存泄露检测工具.他的特点有:可以得到内存泄漏点的调用堆栈,如果可以的话,还可以得到其所在文件及行号:可以得到泄露内存的完整数据:可以设置内存泄露报告的级别:并且是开源免费的. 官方网址:http://vld.codeplex.com/releases/view/82311 使用步骤: 1)官网下载VLD工具包. 2)解压后得到vld.h, vlda

仅通过崩溃地址找出源代码的出错行

作为程序员,我们平时最担心见到的事情是什么?是内存泄漏?是界面不好看?--错啦!我相信我的看法是不会有人反对的--那就是,程序发生了崩溃! "该程序执行了非法操作,即将关闭.请与你的软件供应商联系.",呵呵,这句 M$ 的"名言",恐怕就是程序员最担心见到的东西了.有的时候,自己的程序在自己的机器上运行得好好的,但是到了别人的机器上就崩溃了:有时自己在编写和测试的过程中就莫名其妙地遇到了非法操作,但是却无法确定到底是源代码中的哪行引起的--是不是很痛苦呢?不要紧,本

iOS-捕获应用程序崩溃日志

作为一名iOS移动应用开发者,为了确保你的应用程序正确无误,在将应用程序提交到应用商店之前,你必定会进行大量的测试工作:而且在你测试的过程中应用程序运行的很好,但是在应用商店上线之后,还是有用户抱怨应用程序会"闪退"!现在作为应用程序的开发人员你肯定会准备打开代码准备修复"闪退"的问题,但是就在这个时候你会发现,到底那段代码?那个地方的问题呢......:这个时候iOS崩溃日志就派上用场了,那么现在我们就来研究怎么获取应用崩溃的日志,以及从日志追踪到代码. (一)什

QSqlQuery 可以让你的程序崩溃

linux平台下. 一个程序总是运行个两三天,或者一两天的时候突然崩溃了,以前发过一个讨论但是也没找到解决办法,使用的数据库是SQLITE 使用GDB跟踪程序,结果找到了崩溃的地方却显示栈被破坏显示不出调用的具体方法,运行了好几次都是这样.定位到了 __memmove_ssse3在libc里面. 为了恢复完整的栈信息在国外大牛那里找来两句话 (gdb)set $pc=*(void **)$esp (gdb)set $esp=$esp+4 执行完就可以查看堆栈了(32位平台).注意这个不能由cor