IDA的通用解压插件使用和原理.docx
《IDA的通用解压插件使用和原理.docx》由会员分享，可在线阅读，更多相关《IDA的通用解压插件使用和原理.docx（11页珍藏版）》请在冰豆网上搜索。
IDA的通用解压插件使用和原理
使用IDA的通用解压插件
从4.9版开始，IDA就集成了UniversalPEUnpacker通用解压插件，其源代码可以在IDAProSDK中找到。
这个小教程将会演示如何使用这个插件，并简单介绍其内部工作原理。
一个压缩的应用程序
下面是当我们执行这个可执行程序的运行结果：
非常简单的程序，但是，如果我们使用IDA来打开它，会出现下面的警告提示：
IDA检测到异常的输入段，并提示我们文件可能被压缩了…
如果我们看一下它的输入表窗口，我们就会发现：
我们的程序只导入了kernel32.dll中的3个函数。
我们可以看到在加压缩壳的程序种常用到的2个动态链接库函数LoadLibraryA和GetProcAddress，它们通常用于恢复程序的输入表。
使用通用PEUniversalUnpacker
在插件的子菜单种选择UniversalPEunpacker，开始解压：
你会看到插件的选项对话框：
在这个对话框中，我们可以配置一个的地址范围，当程序运行到这个区域（原始的程序入口点区域），它会挂起程序的执行。
你也可以指定一个文件用于保存解压的资源。
按过确定按钮后，插件开始运行，它启动了我们的程序，并自己解压，直到它运行到我们设定的地址范围内。
这时解压已经结束，依照对话框中的提示，我们保存了当前的内存快照。
你会注意到，我们遇到了两个断点，这个我们最后再去讨论它。
为了重新构造原始的程序输入表，插件创建了一个新段：
解压完成后，我们在start（）函数处可以看到更多我们熟悉的代码结构。
我们还可以进一步改进，让这个反汇编结果尽可能的更完美一些！
使用签名
如果我们查看解压后的程序的字符串窗口，我们可以看出我们的程序是使用VirsualC++编译的，我们可以应用相应的FLIRT（快速库识别恢复技术）的库签名。
应用签名库后，最终的反汇编结果如下：
是不是更好了！
插件分析
下面我们仔细研究一下这个插件，看它是如何使用SDK的调试API来完成这些工作的。
主要的操作就是启动这个进程，然后根据调试器捕捉到的一些事件，进行相应的处理，直到我们确认程序已经完全被解压。
我们先设定一个句柄用于接收调试器的事件，并启动这个程序直到它到达入口点。
if（!
hook_to_notification_point（HT_DBG,callback,NULL））
{
warning（"Couldnothooktonotificationpoint\n"）;
return;
}
//Let'sstartthedebugger
if（!
run_to（inf.beginEA））
{
warning（"Sorry,couldnotstarttheprocess"）;
unhook_from_notification_point（HT_DBG,callback,NULL）;
}
事件将会被送到我们声明的句柄，定义如下：
staticintidaapicallback（void*/*user_data*/,
intnotification_code,
va_listva）
{
switch（notification_code）
{
casedbg_process_start:
...
casedbg_library_load:
...
casedbg_run_to:
...
casedbg_bpt:
...
casedbg_trace:
...
casedbg_process_exit:
...
...
}
return0;
}
当我们通过一个函数run_to（）来开始我们的进程时，我们将会收到一个相应的事件dbg_run_to，它表示run_to（）命令被正确的执行。
现在我们来到压缩文件的入口点，在GetProcAddress（）这个函数上设定一个断点，（假定这个解压代码在重构原始输入表之前结束）：
casedbg_run_to:
//Parameters:
thread_id_ttid
dbg->stopped_at_debug_event（true）;
gpa=get_name_ea（BADADDR,"kernel32_GetProcAddress"）;
...
elseif（!
add_bpt（gpa））
{
bring_debugger_to_front（）;
warning（"Sorry,cannotsetbpttokernel32.GetProcAddress"）;
gotoFORCE_STOP;
}
else
{
++stage;
set_wait_box（"WaitingforacalltoGetProcAddress（）"）;
}
continue_process（）;
break;
当程序运行到GetProcAddress（）断点，我们收到一个dbg_bpt事件，我们可以从堆栈中提取出这个地址，然后删除这个断点，并在返回地址设定第二个断点，以便能在GetProcAddress（）函数返回时立刻中止。
casedbg_bpt:
//Auserdefinedbreakpointwasreached.
//Parameters:
thread_id_ttid
//ea_tbreakpoint_ea
{
/*tid_ttid=*/va_arg（va,tid_t）;
ea_tea=va_arg（va,ea_t）;
...
if（ea==gpa）
{
regval_trv;
if（get_reg_val（"esp",&rv））
{
ea_tesp=rv.ival;
invalidate_dbgmem_contents（esp,1024）;
ea_tret=get_long（esp）;
...
if（!
del_bpt（gpa）||!
add_bpt（ret））
error（"Cannotmodifybreakpoint"）;
还记得我们之前在运行解压插件时碰到的两个断点吗？
中断在0x7C80AC28和0x00040C68D，第一个是我们的GetProcAddress（）断点,而第而个是在返回地址上的断点。
在下面的反汇编窗口中，你可以看到进入GetProcAddress（）断点的那个调用指令，现在我们要继续运行直到解压程序恢复了程序寄存器的原始内容，然后跳到解压后的程序的真实入口点：
我们在第二个断点之后开始单步跟踪，直到指令执行到我们之前设定的地址范围。
del_bpt（ea）;
if（!
is_library_entry（ea））
{
deb（IDA_DEBUG_PLUGIN,"%a:
reachedunpackercode,switchingtotracemode\n",
ea）;
enable_step_trace（true）;
...
set_wait_box（"Waitingfortheunpackertofinish"）;
}
else
{
warning（"%a:
bptinlibrarycode",ea）;//howcanitbe?
add_bpt（gpa）;
}
在每一步指令执行时，我们判断其地址是否在我们之前设定的范围之内。
如果我们运行到了那个区域，重新分析这些解压后的代码，调整入口点，重建输入表，保存资源然后……最后来一张内存快照！
casedbg_trace:
//Astepoccured（oneinstructionwasexecuted）.Thisevent
//notificationisonlygeneratedifsteptracingisenabled.
//Parameter:
none
…
/*tid_ttid=*/va_arg（va,tid_t）;
ea_tip=va_arg（va,ea_t）;
if（oep_area.contains（ip））
{
//stopthetracemode
enable_step_trace（false）;
//reanalyzetheunpackedcode
set_wait_box（"Reanalyzingtheunpackedcode"）;
do_unknown_range（oep_area.startEA,oep_area.endEA,false）;
auto_make_code（ip）;
noUsed（oep_area.startEA,oep_area.endEA）;
auto_mark_range（oep_area.startEA,oep_area.endEA,AU_FINAL）;
//marktheprogram'sentrypoint
move_entry（ip）;
set_wait_box（）;
...
set_wait_box（"Recreatingtheimporttable"）;
invalidate_dbgmem_config（）;
...
create_impdir（）;
set_wait_box（"Storingresourcesto'resource.res'"）;
if（resfile[0]!
='\0'）
extract_resource（resfile）;
set_wait_box（）;
if（take_memory_snapshot（true））
gotoFORCE_STOP;
这样，就在IDA数据库中得到了进程的内存映像，我们可以象通常那样来分析这些解压后的代码了。
现在就去看看那些在SDK中的源代码吧！
去了解一下这个插件的所有实现细节。
风暴2007-09-29QQ:
719110750
升级会员 