IDA Pro 64bit 插件编译

今天偶尔打开一个64bit的ida数据库的时候提示什么加载插件失败。而问题的关键是自己并没有这几个64位的插件,只有32位的。其实问题也很容易就解决掉了,代码都是自己的,所以直接编译一个64位的插件就可以了。

1.配置管理器中新建一个配置,名称可以随便设置,只要能区分就可以了。

复制设置选择当前的解决方案配置。

Continue Reading

Immunity Debugger 1.8x Wow64 Plugin v2.0.0.1

Immdbg的版本比较多,本来是想依靠版本号来进行区分的,但是发现得到的版本号都是110,这个版本号和Od1.1的版本号是一样的,后来想用CRC计算,但是这个方法就又麻烦了,于是想了一个灰常简单的办法,至于是什么就不说了。哈哈,说出来丢人,于是就兼容了一下1.8x版本,其实也就是1.83和1.85.上图是1.83的版本效果。

下图是1.83版本的效果:

如果有什么问题就吱一声吧,如果用的是1.7x版本的Immdbg,那么最简单的办法就是升级一下吧。说实话我也没有比较下每次升级都有什么区别,但是高版本的能用就用高版本的吧。

Continue Reading

Immunity Debugger 1.85 Wow64 Plugin v1.0.0.1

大多数的逆向分析人士还是喜欢在XP下进行一系列的分析共做,我也是比较喜欢XP的兼容性和稳健型。但是在除此之外的时间用的基本都是Windows 7 64bit的系统,因为对于32位的XP来说,8G的内存已经成了浪费,虽然偶尔还是会切换到XP下,但是也只能识别2.3G的内存,由于平时不怎么用也就不关心这个鸟系统到底能识别多少内存了。在看雪学院有篇文章是关于如何让xp支持大内存的,但是我的测试效果是直接让膝系统分区表挂掉,于是后来也就懒得试了~

但是在Win7 64位的系统下进行调试会出现诸多的问题,比如上图就是很明显的例子,这个东西和Ollydbg 1.1遇到的状况是一样的。详细可以参考这篇文章:《OllyDbg v1.10 And Wow64》 。至于原理文章中已经解释的很清楚了,着了也就没有必要进行详细的说明了。

Continue Reading

Python加载的文件哪里去了?(2)

其实这个标题并不确切,其实应该是ImmDbg调试器加载的文件哪里去了。加载文件脚本还是下面的样子:

"""
(c) Mars Security. 2009-2012
Institute Of Information Serurity From Mars
Email:root@h4ck.ws
U{By obaby. http: //www.h4ck.org.cn}
"""
#sys.path.append("C:\\Program Files\\Immunity Inc\\Immunity Debugger\\Libs")

DESC="""Load Binary file test!"""

import immlib
import immutils
import os

def main(args):
    imm = immlib.Debugger()
    imm.log ("--------------------------------------------------------------------------------" )
    imm.log ("[*] Start Loading file " )
    imm.log ("--------------------------------------------------------------------------------" )
             
    rcFileHandle = open ('C:\\test.bin','rb')
    rcFileData = rcFileHandle.read()
    
    rcFileLength = len(rcFileData)
        
    imm.log ("[*] FileLength is 0x%08x and filedata is loaded at address 0x%08x" %(rcFileLength,id(rcFileData)))    

    imm.log ("[*] Finished Loading " )
    imm.log ("--------------------------------------------------------------------------------" )
        
    return "[*] Data has been Loaded!"
Continue Reading

Starting to write Immunity Debugger PyCommands : my cheatsheet 『Rw』

When I started Win32 exploit development many years ago, my preferred debugger at the time was WinDbg (and some Olly). While Windbg is a great and fast debugger, I quickly figured out that some additional/external tools were required to improve my exploit development experience.

Despite the fact that the command line oriented approach in windbg has many advantages, it appeared not the best tool to search for good jump addresses, or to list non-safeseh compiled / non-aslr aware modules, etc….  Ok, looking for a simple “jmp esp” is trivial, but what if you are looking for all pop pop ret combinations in non-safeseh compiled modules…   Not an easy task.

It is perfectly possible to build plugins for Windbg, but the ones that I have found (MSEC, byakugan (Metasploit)) don’t always work the way I want them to work, and would still not solve some issues I was having while writing exploits.

OllyDbg and Immunity Debugger are quite different than windbg.  Not only the GUI is very much different, the number of plugins for these debuggers is substantially higher.  After evaluating both of them (they pretty much have the same look and feel), and evaluating the way plugins can be added, I made the decision to focus on Immunity Debugger.

That does not mean OllyDbg is a bad debugger or is limited in what you can do in terms of writing plugins… I just found it harder to “quickly tweak a plugin” while building an exploit.   OllyDbg plugins are compiled into dll’s, so changing a plugin would require me to recompile and test.   Immunity Debugger uses python scripts.  I can go into the script, make a little change, and see the results right away.  Simple.

Continue Reading