PE格式：手工实现IAT导入表注入劫持

DLL注入有多种方式，今天介绍的这一种注入方式是通过修改导入表，增加一项导入DLL以及导入函数，我们知道当程序在被运行起来之前，其导入表中的导入DLL与导入函数会被递归读取加载到目标空间中，我们向导入表增加导入函数同样可以实现动态加载，本次实验用到的工具依然是上次编写的PE结构解析器。

增加空间插入DLL

1.首先我们先来编写一个简易的DLL文件，这里可以使用C/C++或其他任何一种语言。

2.其次由于要操作导入表，我们需要再次复习一下导入结构的定义 _IMAGE_IMPORT_DESCRIPTOR 该IID结构，是一个数组，默认最后一项以全部为0作为结束符。

要添加IID数组的话，需要修改此处IID数组，增加一块区域，但这块内存一般与IID中的OriginalFirstThunk和FirstThun都有关联，这就导致我们必须整体将其移动到一个新的位置才可以，不能被覆盖。

typedef struct _IMAGE_IMPORT_DESCRIPTOR {
    union {
        DWORD   Characteristics;            // 0 for terminating null import descriptor
        DWORD   OriginalFirstThunk;         // RVA to original unbound IAT (PIMAGE_THUNK_DATA)
    } DUMMYUNIONNAME;
    DWORD   TimeDateStamp;                  // 0 if not bound,
    DWORD   ForwarderChain;                 // -1 if no forwarders
    DWORD   Name;
    DWORD   FirstThunk;                     // RVA to IAT (if bound this IAT has actual addresses)
} IMAGE_IMPORT_DESCRIPTOR;
typedef IMAGE_IMPORT_DESCRIPTOR UNALIGNED *PIMAGE_IMPORT_DESCRIPTOR;

IMAGE_THUNK_DATA32

typedef struct _IMAGE_THUNK_DATA32 {
    union {
        DWORD ForwarderString;      // PBYTE 
        DWORD Function;             // PDWORD
        DWORD Ordinal;
        DWORD AddressOfData;        // PIMAGE_IMPORT_BY_NAME
    } u1;
} IMAGE_THUNK_DATA32;
typedef IMAGE_THUNK_DATA32 * PIMAGE_THUNK_DATA32;

默认情况下一个_IMAGE_IMPORT_DESCRIPTOR结构的大小为20字节也就是0x14我们再来看一下数据目录表中导入表的位置与大小。

Import RVA = 0x7604
Size = 0xc8

也就是说我们需要找一块或者是自己增加一块空间，该空间的大小应该在 0xc8 + 0x14(一个结构大小) = 0xDC的位置。

再来看看文件与节表的对其参数，其中内存对齐 0x00001000 而文件对其值为 0x00000200

这里我们就直接扩展最后一个节，并按照文件对齐值为它增加0x200字节的空白区域，使用WinHEX操作，找到文件末尾，右键选择编辑粘贴0字节，然后输入512也就是十六进制的200.

由于是直接扩展的最后一个rsrc区段，所以定位到这块空白区域只需要：

文件偏移 0x8400 + 0x8000 = 0x10400
内存偏移 0xB000 + 0x8000 = 0x13000

3.接着找到原IID结构的位置，如上我们知道原始RVA为0x7604，计算 0x7604 - 0x1000 + 0x400 = 0x6A04 大小为0xC8，也就是从0x6A04 - 0x6AB4拷贝下来，右键选择复制十六进制数值。

然后将其粘贴到偏移为0x1040也就是刚才开辟的空间上面，这里需要注意了：由于我们需要增加一个IID结构，所以先要空出黄色部分的空间，其次最后的红色部分全部填充0标志结束符。

在原来的0x6a04出构建新的IID结构，

dllname 文件偏移 = 0x6a14 RVA = 0x6a14 - 0x400 + 0x1000 = 0x7614
import_by_name = 文件偏移 = 0x6a20 RVA = 0x7620

PE文件加载前，OriginalFirstThunk和FirstThunk都指向Import_by_name结构数组，现在可以填充他们了。

OriginalFirstThunk = 文件偏移：0x6a04 相对RVA：0x7604

first Thunk 文件偏移：0x6a0c 相对RVA: 0x760c

开始填充结构数据，如下所示。

黄色代表：OriginalFirstThunk
淡红色代表：TimeDateStamp
绿色代表：FirstThunk
黄色代表：ForwarderChain
紫色代表：dllname
大红代表：导出msg函数名称

最后转到我们后面导入表的位置，在后面填充这些位置。

7604 = OriginalFirstThunk
7614 = dllname
760c = FirstThunk RVA

接着修正PE文件头，由于改变了PE头中输入表的位置，这里输入表也需要修正，改为13000大小则是dc

接着修正text节，加上0x8000000写属性，将其属性改为 20000E0 即可。

最后修正输入表的位置，即可实现DLL插入。

上面这种方式有时可能会出错，例如改完后出现，原因是读取不到节区，没有注册，有时可以有时就会报错，不同系统之间随机出现。



添加新节并插入DLL

解决的办法是自己新建一个节，并设置好属性，先来仿写一个.hack节，我们在 .rsrc 后面直接添加一个新的。

.hack 虚拟偏移：虚拟偏移(.rsrc) + 虚拟大小(.hack) => 0x0001B000 + 0x00001000 = 0001C000 + 2000 = 1e000

上面公式中为什么需要加上2000 ？ 这是因为需要凑够整数，字节对齐，不然也是不知别的，例如。

  1. 0x00011000 + 0x00004337 = 15337 直接取整 16000
  2. 0x0001A000 + 0x00000AB9 = 1AAB9 直接取 1B000
  3. 0x0001B000 + 0x000025A0 = 1D5A0 取整 1E000

.hack 实际偏移：实际偏移(.rsrc) + 实际大小(.rsrc) => 0x00007800 + 0x00002600 = 00009E00

计算得到.hack虚拟偏移：0x0001C000 实际偏移：0x00009E00 找到节表位置，开始仿写。

在文件末尾，插入1000个0字节填充

最后修正镜像大小，绿色节区数目加1 6改7，蓝色镜像大小加1000，蓝色改为 0001F000，改完保存。

改完后，运行看看，没问题了，改的很成功，已经识别了。

接着找到导入表，所在位置 0x00006DE0 长度 0x50，winhex跟过去。

选中，拷贝下来。

放到开辟的空间中，文件偏移 9e00 处。

修正当前输入表的位置测试是否可以正确识别，新输入表的FOA是 9e00 将其转为RVA = 0x0001E000 大小先保持不变。

改完后，使用工具验证一下，嗯，确实改掉了，程序依旧能打开，这次搬家很成功。

接着在9e90处构建新的IID结构数组，计算得出。

OriginalFirstThunk 文件偏移 = 9e90 相对RVA: 0x0001E090

TimeDateStamp 单独占用一个存储空间，默认填充为0

TimeDateStamp 文件偏移：9E94 相对RVA： 0x0001E094

由于默认情况下OriginalFirstThunk和FirstThunk都指向Import_BY_name结构数组，所以两者是一致的。

FirstThunk 文件偏移：9E98 相对RVA： 0x0001E098

ForWarderChain 文件偏移：9E9C 相对RVA: 0x0001E09C

DllName 文件偏移：9EA0 相对RVA: 0x0001E0A0

导出函数名称：文件偏移：9EB4 相对RVA: 0x0001E0B4

接着将这些数据填充到指定的位置。我们就在输入表的下方构建这个结构吧。

最后我们转到导入表上，将这个结构构造到导入表的最后。

originalFirstThunk = 1e090
dllname = 1e0a0
FirstThunk = 1e098

由于增加了一个结构，所以需要修正导入表的大小，跳转到160处，修正 50 + 20 = 70

确保最后一个节可读可写可执行。

确保绑定输入解除，也就是将1B0 - 1B8位置的内容全部清除掉。

打开，成功的执行了加载MsgDll.dll 文件，因为根目录没有这个文件所以报错，但已经可以加载成功了

使用工具来验证一下，导入表结构已经可以完美的读取到了，说明我们的计算没问题。

再次分析导入表

我知道你很模糊，这里有必要再深入分析一下，这次我把他们分开来写，这样看起来会更清晰。

首先老样子，定位到节表位置，执行命令 PETools c://win32.exe --ShowDataDirectory

winhex跳转到 0x00006DE0 这个位置上，总长度是 0x00000050 我们来分析一下第一个导入表结构，从而让你对齐更加清晰。

两个黄色部分，分别是 OriginalFirstThunk 和 FirstThunk 在加载到内存之前其是相同的。

User32.dll存放位置

RVA = 01a54a 转成 --> FOA = 0x0000714A

714a 所对应的是 user32.dll 导入模块。

IMAGE_IMPORT_DESCRIPTOR 中的 Name 指向了 0x0000714A 里面就是存放着 user32.dll字符串

指向函数LoadIconA

RVA = 1a15c 转成 --> FOA = 0x00006D5C

6d5c里面存放着 1a53e

将其转化为FOA = 713e

她所对应的是 LoadIconA

我们来构建这样一个结构单元，如下图。

将单元填充好

表关系如下，与微软结构定义相同。

关系如图。

添加成功了。

反写也可识别，OriginalFirstThunk 和 FirstThunk 一致。

x64dbg 也可以动态加载进来

调用也没问题。

注意节区属性必须可读可写，改为E0000E0。

导出表解析

导出表默认在DLL中出现较多，EXE文件中出现导出表虽然可以但很奇怪，导出表在数据目录表第一个成员中，IMAGE_EXPORT_DIRECTORY IED结构，使用PETools工具查看如下。

导出表结构定义如下

typedef struct _IMAGE_EXPORT_DIRECTORY {
    DWORD   Characteristics;
    DWORD   TimeDateStamp;            // 文件生成时间
    WORD    MajorVersion;
    WORD    MinorVersion;
    DWORD   Name;                     // 模块真实名称
    DWORD   Base;
    DWORD   NumberOfFunctions;        // 导出元素个数
    DWORD   NumberOfNames;            // 导出元素个数
    DWORD   AddressOfFunctions;     // 指向函数地址的数组
    DWORD   AddressOfNames;         // 函数名字的指针地址
    DWORD   AddressOfNameOrdinals;  // 指向输出序列号地址的数组
} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

winhex 标号

第二项 5ba6031a 指向 TimeDateStamp

计算后得到一个时间戳，将其转为十进制 1537606426 转为时间日期则，没啥可说的。

第五项是Name字段：2280 是RVA 将其转为FOA

跳转到1080处发现时该DLL的原始名称，这个名称就算把名字改掉，名称不会变。

第七八项，代表的时导出函数的个数。

第九项，2258 将其转为FOA跳转过去看看。0x00001058 此处指向228C

将228C转为FOA 0x0000108C 跳过去看看，第一个导出函数名字。

再将2268转为FOA看看 0x00001068 对应2288

再次将2288转为FOA 0x00001088 跳过去看看，同样是第一个函数的字符串。

分析

首先RVA=2258 计算FOA = 0x00001058 其指向函数的RVA地址，程序装入内存后会被展开。

展开后格式如下，红色指向黑色位置，我们有四个函数所以是四个函数的地址。

RVA = 2268 其FOA = 0x00001068 它指向函数名字的指针地址。

2268 指向了 1068 而1068中存放了四个指针，分别指向四个导出函数的名称。

拿2288为例子，转换后变成FOA = 1088 以此类推。


重定位表的解析(拓展)

重定位表在PE中是.reloc，通常情况下EXE可执行文件在映射内存时会独占虚拟空间，所以EXE时不需要重定位信息的，只有DLL才会需要，因为DLL内存不固定，很可能一个DLL被注入到多个进程中，此时就需要对DLL中的数据进行重定位，以确保特定函数还能够被调用到。

重定位表的查找是通过数据目录表的 IMAGE_DIRECTORY_ENTRY_BASERELOC 的条目来查找的，重定位数据采用按页分割的，每个块存放4KB(1000h)的重定位数据，每个重定位块大小为4字节对齐，他们以一个 IMAGE_BASE_RELOCATION 结构。

typedef struct _IMAGE_BASE_RELOCATION {
    DWORD   VirtualAddress;
    DWORD   SizeOfBlock;
//  WORD    TypeOffset[1];
} IMAGE_BASE_RELOCATION;
typedef IMAGE_BASE_RELOCATION UNALIGNED * PIMAGE_BASE_RELOCATION;

首先使用PETools解析，来看一下这个结构。

找到位置 FOA = 0x00001800 大小是 0x00000128 也就是重定位表的位置。

如果想要通过手工找到该位置，其位于PE偏移 1a0位置，此处的第一个DWORD是重定位的RVA，第二个位置则是重定位大小。

使用PETools计算的出其FOA = 0x00001800 同样可以定位到重定位表的位置上。

重定位表的分析，第一个黄色代表重定位数据开始的RVA地址，第二个代表重定位块长度，最后一个

TYpeOffset 是一个数组，数组中每项大小为2字节，高四位代表重定位类型，低12位代表重定位地址，他与VirtualAddress相加得到的是需要修正位置的数据指针。

如下，其中后面的WORD类型，每一个都是一个重定位数据。

以第一个300e为例，将其转为FOA = 0x0000140E，定位过去，程序没被装载，这里为空，装在后可能会重定位修复。

PETools解析后，可对比，计算结果无误。

posted @ 2020-09-20 16:02  lyshark  阅读(1873)  评论(0)  编辑  收藏  举报

loading... | loading...
博客园 - 开发者的网上家园