Phantom DLL

Phantom DLL 提供了一项 Windows 自动分析服务，并要求生成一个输出文件。服务接收上传的动态库，将其放入目标环境，然后启动一个会搜索常见 Windows 多媒体 DLL 的应用程序。

关键线索是实际加载的模块名：上传的文件会被当作 winmm.dll。于是，题目就转化成了一次可控的 DLL 搜索顺序劫持。

针对实际加载器构建

我们分别构建了 32 位与 64 位探针，导出常见入口点，并刻意让初始化路径保持精简。最终，64 位版本与自动分析进程的架构一致。

BOOL WINAPI DllMain(HINSTANCE module, DWORD reason, LPVOID reserved) {
    if (reason == DLL_PROCESS_ATTACH) {
        DisableThreadLibraryCalls(module);
        run_probe();
    }
    return TRUE;
}

在 DllMain 中执行繁重任务容易触发加载器锁死锁。探针只进行有限范围的文件检查与一次输出写入，不发起网络连接、不创建子进程，也不进行长时间等待。

先确认执行，再开始搜索

第一个版本把进程与模块上下文写入指定输出文件，从而确认了三件事：

1. DLL 架构正确；
2. DllMain 已在目标进程中执行；
3. 服务会返回生成的输出文件。

确认这些条件后，我们才加入一小组可能存放证据的位置。成功加载的探针找到题目文件，并将其内容复制到指定的结果文件中。

关键结论

面对自动分析类题目，应先厘清加载器契约。一个最小化的执行证明，比复杂载荷更有价值：先确认架构、模块名、入口点执行和输出处理，再加入发现逻辑。

赛事页面：LIGA CTF 2026。