返回介绍

19.4 构建处理器模块

发布于 2024-10-11 21:05:48 字数 6130 浏览 0 评论 0 收藏 0

构建和安装 IDA 处理器模块的过程与构建和安装插件和加载器的过程非常类似,它们之间只存在一个主要的差异,如果不遵照这个差异,可能导致 IDA 无法使用你的处理器。构建过程中的一些细微差异包括以下几点。

  1. Windows 、Linux 平台和 OS X 平台处理器的文件扩展名分别为.w32/.w64 、.ilx/ilx64 和.imc/.imc64 。

  2. SDK 示例处理器(及我们自己的处理器)的构建脚本将新建的处理器二进制文件存储在<SDKDIR>/bin/procs 目录中。

  3. 要安装处理器模块,需要将已编译的处理器二进制文件复制到<IDADIR>/procs 目录中。

  4. Windows 处理器模块需要使用 SDK 提供的一个自定义 MS-DOS 存根1

    1. MS-DOS 头部存根包括一个 MS-DOS 文件头,以及警告用户 Windows 程序不能在 MS-DOS 模式下运行的代码。

  5. 基于 Windows 的处理器模块需要采用插件和加载器不需要的一个自定义后续处理步骤(post-processing step)。这个步骤用于在已编译处理器二进制文件中的特定位置插入一个处理器描述字符串。这个描述字符串在 IDA 的“加载文件”对话框的处理器下拉列表部分显示。

在构建一个基于 Windows 的处理器模块时,你需要使用 SDK 提供的一个自定义 MS-DOS 存根(/module/stub)。要使用自定义 MS-DOS 存根,必须指示链接器使用你的存根,而不是以其他形式包含的默认存根。在使用特定于 Windows 的编译器时,有时候你可以通过使用模块定义(.def )文件指定备用的存根。Borland 构建工具(被 Hex-Rays 采用)支持使用.def 文件指定替代存根。如果你碰巧使用的是 Borland 工具,SDK 包含的/module/idp.def 文件可供你使用。GNU 和微软链接器均支持.def 文件(只是使用的语法稍有不同)。但是,它们都不支持备用的 MS-DOS 存根的规范,因此,很明显,你使用这类编译器时可能会遇到问题。

假设在某个时候,你设法使用 SDK 提供的自定义 MS-DOS 存根构建了你的处理器模块,那么,你仍然必须在处理器二进制文件中插入处理器描述注释。/bin/mkidp.exe 实用工具即用于这一目的。你可以使用下面的语法调用 mkidp ,给一个处理器添加一段注释:

$ mkidp module description

这里, module 是你的处理器模块的路径,而 description 是你的模块的文本描述,如下所示:

Long module name:short module name

要给我们的 Python 处理器模块添加一段描述,可以使用下面的命令行:

$ ./mkidp procs/python.w32 "Python Bytecode:python"

mkidp 实用工具尝试在文件中偏移量为 128 字节的命名模块中插入所提供的描述,插入描述的空间位于 MS-DOS 存根与 PE 头部之间(假设这样的空间存在)。如果由于 PE 头部过于接近 MS-DOS 存根的结尾部分,而没有足够的空间,你将收到以下错误消息:

mkidp: too long processor description

这时,操作是否成功更多地取决于你使用的工具,因为使用微软链接器构建的处理器有足够的空间可以插入描述,而使用 GNU 链接器构建的处理器却没有足够的空间。

为了消除困惑,并使用微软工具或 GNU 工具,我们开发了一个叫做 fix_proc 的实用工具,读者可以在本书网站的第 19 章部分下载该工具。 fix_proc 实用工具使用和 mkidp 相同的命令行语法,但是,它还提供了其他功能,可以在使用大多数编译器构建的处理器模块中插入一段处理器描述。执行 fix_proc 后,它用 SDK 提供的存根替换处理器现有的 MS-DOS 存根(因而不需要在构建过程中使用.def 文件)。同时, fix_proc 执行必要的操作,重新定位处理器的 PE 头部,创建足够的空间来保存处理器描述字符串,最后将描述字符串插入到处理器二进制文件中的正确位置。在对处理器模块执行所需的“后续处理步骤”时,我们用 fix_proc 代替 mkidp

说明  严格来讲,你不需要为处理器模块使用 SDK 的 MS-DOS 存根。只要 IDA 在处理器模块的 128 字节处发现一个描述字符串,IDA 就不会出错。在 fix_proc 中,我们用 SDK 存根替代现有的 MS-DOS 存根,只是为了避免任何与用于存储描述字符串的空间有关的冲突。

根据构建处理器所使用的工具,表 19-1 描述了各种处理器的特性。

表 19-1 后处理的 IDA 处理器模块(按编译器)

 初步构建 使用 mkidp 后 使用 fix_proc 后 
工具是否使用.def是否拥有存根是否拥有存根是否拥有描述是否拥有存根是否拥有描述
Borland
微软
GNU

只有拥有有效描述的处理器才会出现在“文件加载”对话框中。换言之,如果没有有效的描述字段,你将不可能选择处理器模块。

与构建加载器模块相比,构建处理器模块过程中的所有这些差异需要我们对表 17-1 中的生成文件进行更多的修改。一个经过修改的用于构建示例 Python 处理器的生成文件如代码清单 19-1 所示。

代码清单 19-1 构建 Python 处理器模块的生成文件

     #Set this variable to point to your SDK directory
     IDA_SDK=../../

     PLATFORM=$(shell uname | cut -f 1 -d _)

     ifneq "$(PLATFORM)" "MINGW32"
     IDA=$(HOME)/ida
     endif

     #Set this variable to the desired name of your compiled processor
     PROC=python

     #Specify a description string for your processor, this is required
     #The syntax is <long name>:<short name>
➊    DESCRIPTION=Python Bytecode:python

     ifeq "$(PLATFORM)" "MINGW32"
     PLATFORM_CFLAGS=-D__NT__ -D__IDP__ -DWIN32 -Os -fno-rtti
     PLATFORM_LDFLAGS=-shared -s
     LIBDIR=$(shell find ../../ -type d | grep -E "(lib|lib/)gcc.w32")
     ifeq ($(strip $(LIBDIR)),)
     LIBDIR=../../lib/x86_win_gcc_32
     endif
     IDALIB=$(LIBDIR)/ida.a
     PROC_EXT=.w32
     else ifeq "$(PLATFORM)" "Linux"
     PLATFORM_CFLAGS=-D__LINUX__
     PLATFORM_LDFLAGS=-shared -s
     IDALIB=-lida
     IDADIR=-L$(IDA)
     PROC_EXT=.ilx

     else ifeq "$(PLATFORM)" "Darwin"
     PLATFORM_CFLAGS=-D__MAC__
     PLATFORM_LDFLAGS=-dynamiclib
     IDALIB=-lida
     IDADIR=-L$(IDA)/idaq.app/Contents/MacOs
     PROC_EXT=.imc
     endif

     #Platform specific compiler flags
     CFLAGS=-Wextra $(PLATFORM_CFLAGS)

     #Platform specific ld flags
     LDFLAGS=$(PLATFORM_LDFLAGS) 

     #specify any additional libraries that you may need
     EXTRALIBS=

     # Destination directory for compiled plugins
     OUTDIR=$(IDA_SDK)bin/procs/

     # Postprocessing tool to add processor comment
➋   MKIDP=$(IDA_SDK)bin/fix_proc
     #MKIDP=$(IDA)bin/mkidp

     #list out the object files in your project here
     OBJS=ana.o emu.o ins.o out.o reg.o

     BINARY=$(OUTDIR)$(PROC)$(PROC_EXT)

     all: $(OUTDIR) $(BINARY)

     clean:
         -@rm *.o
         -@rm $(BINARY)

     $(OUTDIR):
         -@mkdir -p $(OUTDIR)

     CC=g++
     INC=-I$(IDA_SDK)include/

     %.o: %.cpp
         $(CC) -c $(CFLAGS) $(INC) $< -o $@

     LD=g++
     ifeq "$(PLATFORM)" "MINGW32"
     #Windows processor's require post processing
     $(BINARY): $(OBJS)
         $(LD) $(LDFLAGS) -o $@ $(OBJS) $(IDALIB) $(EXTRALIBS)
➌       $(MKIDP) $(BINARY) "$(DESCRIPTION)"
     else
     $(BINARY): $(OBJS)
         $(LD) $(LDFLAGS) -o $@ $(OBJS) $(IDALIB) $(EXTRALIBS)
     endif

     #change python below to the name of your processor, make sure to add any
     #additional files that your processor is dependent on
     python.o: python.cpp
     ana.o: ana.cpp
     emu.o: emu.cpp
     ins.o: ins.cpp
     out.o: out.cpp
     reg.o: reg.cpp

除了后缀以及处理器的默认文件位置这些细微的差别外,主要差异包括描述字符串的定义(➊ )、插入描述字符串的实用工具(➋)的规范以及增加的一个在 Windows 处理器模块中插入描述字符串(➌)的构建步骤。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文