IDA的通用解压插件使用和原理.doc

使用IDA的通用解压插件从4.9版开始，IDA就集成了Universal PE Unpacker通用解压插件，其源代码可以在IDA Pro SDK中找到。这个小教程将会演示如何使用这个插件，并简单介绍其内部工作原理。一个压缩的应用程序下面是当我们执行这个可执行程序的运行结果：非常简单的程序，但是，如果我们使用IDA来打开它，会出现下面的警告提示：IDA检测到异常的输入段，并提示我们文件可能被压缩了如果我们看一下它的输入表窗口，我们就会发现：我们的程序只导入了kernel32.dll中的3个函数。我们可以看到在加压缩壳的程序种常用到的2个动态链接库函数LoadLibraryA和GetProcAddress，它们通常用于恢复程序的输入表。使用通用PE Universal Unpacker在插件的子菜单种选择Universal PE unpacker，开始解压：你会看到插件的选项对话框：在这个对话框中，我们可以配置一个的地址范围，当程序运行到这个区域（原始的程序入口点区域），它会挂起程序的执行。你也可以指定一个文件用于保存解压的资源。按过确定按钮后，插件开始运行，它启动了我们的程序，并自己解压，直到它运行到我们设定的地址范围内。这时解压已经结束，依照对话框中的提示，我们保存了当前的内存快照。你会注意到，我们遇到了两个断点，这个我们最后再去讨论它。为了重新构造原始的程序输入表，插件创建了一个新段：解压完成后，我们在start()函数处可以看到更多我们熟悉的代码结构。我们还可以进一步改进，让这个反汇编结果尽可能的更完美一些！使用签名如果我们查看解压后的程序的字符串窗口，我们可以看出我们的程序是使用Virsual C+编译的，我们可以应用相应的FLIRT(快速库识别恢复技术)的库签名。应用签名库后，最终的反汇编结果如下：是不是更好了！插件分析下面我们仔细研究一下这个插件，看它是如何使用SDK的调试API来完成这些工作的。主要的操作就是启动这个进程，然后根据调试器捕捉到的一些事件，进行相应的处理，直到我们确认程序已经完全被解压。我们先设定一个句柄用于接收调试器的事件，并启动这个程序直到它到达入口点。if ( !hook_to_notification_point(HT_DBG, callback, NULL) )warning(Could not hook to notification pointn);return;/ Lets start the debuggerif ( !run_to(inf.beginEA) )warning(Sorry, could not start the process);unhook_from_notification_point(HT_DBG, callback, NULL);事件将会被送到我们声明的句柄，定义如下：static int idaapi callback(void * /*user_data*/,int notification_code,va_list va)switch ( notification_code )case dbg_process_start:.case dbg_library_load:.case dbg_run_to:.case dbg_bpt:.case dbg_trace:.case dbg_process_exit:.return 0;当我们通过一个函数run_to()来开始我们的进程时，我们将会收到一个相应的事件dbg_run_to，它表示run_to()命令被正确的执行。现在我们来到压缩文件的入口点，在GetProcAddress()这个函数上设定一个断点，（假定这个解压代码在重构原始输入表之前结束）：case dbg_run_to: / Parameters: thread_id_t tiddbg-stopped_at_debug_event(true);gpa = get_name_ea(BADADDR, kernel32_GetProcAddress);.else if( !add_bpt(gpa) )bring_debugger_to_front();warning(Sorry, can not set bpt to kernel32.GetProcAddress);goto FORCE_STOP;else+stage;set_wait_box(Waiting for a call to GetProcAddress();continue_process();break;当程序运行到GetProcAddress()断点，我们收到一个dbg_bpt事件，我们可以从堆栈中提取出这个地址，然后删除这个断点，并在返回地址设定第二个断点，以便能在GetProcAddress()函数返回时立刻中止。case dbg_bpt: / A user defined breakpoint was reached./ Parameters: thread_id_t tid/ ea_t breakpoint_ea/*tid_t tid =*/ va_arg(va, tid_t);ea_t ea = va_arg(va, ea_t);.if ( ea = gpa )regval_t rv;if ( get_reg_val(esp, &rv) )ea_t esp = rv.ival;invalidate_dbgmem_contents(esp, 1024);ea_t ret = get_long(esp);.if ( !del_bpt(gpa) | !add_bpt(ret) )error(Can not modify breakpoint);还记得我们之前在运行解压插件时碰到的两个断点吗？中断在0x7C80AC28和0x00040C68D，第一个是我们的GetProcAddress()断点,而第而个是在返回地址上的断点。在下面的反汇编窗口中，你可以看到进入GetProcAddress()断点的那个调用指令，现在我们要继续运行直到解压程序恢复了程序寄存器的原始内容，然后跳到解压后的程序的真实入口点：我们在第二个断点之后开始单步跟踪，直到指令执行到我们之前设定的地址范围。del_bpt(ea);if ( !is_library_entry(ea) )deb(IDA_DEBUG_PLUGIN, %a: reached unpacker code, switching to trace moden,ea);enable_step_trace(true);.set_wait_box(Waiting for the unpacker to finish);elsewarning(%a: bpt in library code, ea); / how can it be?add_bpt(gpa);在每一步指令执行时，我们判断其地址是否在我们之前设定的范围之内。如果我们运行到了那个区域，重新分析这些解压后的代码，调整入口点，重建输入表，保存资源然后最后来一张内存快照！case dbg_trace: / A step occured (one instruction was executed). This event/ notification is only generated if step tracing is enabled./ Parameter: none/*tid_t tid =*/ va_arg(va, tid_t);ea_t ip = va_arg(va, ea_t);if ( oep_area.contains(ip) )/ stop the trace modeenable_step_trace(false);/ reanalyze the unpacked codeset_wait_box(Reanalyzing the unpacked code);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);/ mark the programs entry pointmove_entry(ip);set_wait_box();.set_wait_box(Recreating the import table);invalidate_dbgmem_config();.create_impdir();set_wait_box(Storing resources to resource.res);if ( resfile0 != 0 )ex