Sean's Blog

链接

10分钟阅读

1 直接链接、间接链接、静态链接、动态链接

  1. 直接链接 vs 间接链接 这是关于函数调用方式的区别：

直接链接：

// 编译时直接使用函数符号
void app() {
    // 直接调用Vulkan函数
    VkResult result = vkCreateInstance(&createInfo, NULL, &instance);
}

特点：

  • 代码简洁直观
  • 编译时需要链接库
  • 无法处理函数缺失的情况
  • 函数调用开销略小

间接链接：

// 运行时动态获取函数地址
typedef VkResult (*PFN_vkCreateInstance)(const VkInstanceCreateInfo*, const VkAllocationCallbacks*, VkInstance*);
 
void app() {
    // 获取函数指针
    PFN_vkCreateInstance pfnCreateInstance = 
        (PFN_vkCreateInstance)dlsym(vulkanLib, "vkCreateInstance");
    
    // 通过函数指针调用
    if (pfnCreateInstance) {
        VkResult result = pfnCreateInstance(&createInfo, NULL, &instance);
    }
}

特点：

  • 代码较复杂
  • 运行时可以处理函数缺失
  • 可以实现更灵活的错误处理
  • 函数调用可能有额外开销
  1. 静态链接 vs 动态链接 这是关于库文件如何被链接的区别：

静态链接：

# 编译时链接静态库(.lib/.a)
gcc app.c libvulkan.a -o app
 
# 生成的可执行文件包含了库的代码
./app  # 不依赖外部vulkan库文件

特点：

  • 生成的可执行文件较大
  • 不依赖外部库文件
  • 无运行时加载开销
  • 内存占用可能更高（多个程序各自包含库代码）

动态链接：

# 编译时只链接动态库符号(.dll/.so)
gcc app.c -lvulkan -o app
 
# 运行时需要动态库存在
./app  # 依赖系统中的vulkan动态库

特点：

  • 生成的可执行文件较小
  • 依赖外部库文件
  • 有运行时加载开销
  • 内存占用更低（多个程序共享同一份库代码）

这四种链接方式可以组合使用：

  1. 直接链接 + 静态链接：
// 最简单但最不灵活的方式
vkCreateInstance(...);  // 直接调用，库代码已编译进可执行文件
  1. 直接链接 + 动态链接：
// 常见的默认方式
vkCreateInstance(...);  // 直接调用，但库在运行时加载
  1. 间接链接 + 静态链接：
// 较少见的组合
PFN_vkCreateInstance pfn = get_function_pointer();  // 虽然库已静态链接，但仍使用函数指针
  1. 间接链接 + 动态链接：
// 最灵活的方式，如Volk的实现
void* lib = dlopen("vulkan.so", RTLD_NOW);  // 动态加载库
PFN_vkCreateInstance pfn = dlsym(lib, "vkCreateInstance");  // 获取函数指针

在 Vulkan 开发中：

  • 简单应用通常使用直接链接 + 动态链接
  • 需要更多控制的应用（如游戏引擎）可能使用间接链接 + 动态链接
  • 特定场景（如嵌入式系统）可能使用静态链接

如何查看链接的是哪些库

可以使用以下工具查看可执行文件链接了哪些库：

ldd ./app  # Linux

2 FAQ

2.1 静态链接时会递归链接吗，比如链接的库 A 又依赖库 B，会将 B 中的代码也包含进来么，以及是否只包含调用的部分

是的，静态链接会递归链接，并且会采用一定的优化策略。让我详细解释：

  1. 递归链接行为：
// main.c
void main() {
    libraryA_func();  // 使用库A的函数
}
 
// libraryA.c
void libraryA_func() {
    libraryB_func();  // 库A依赖库B
}
 
// libraryB.c
void libraryB_func() {
    // 具体实现
}

链接过程：

  • 链接器发现程序使用了 libraryA_func
  • 链接 libraryA 时发现其依赖 libraryB_func
  • 递归链接 libraryB 中的代码
  1. 按需链接（Dead Code Elimination）：
// libraryA.c
void used_func() {
    // 这个函数被使用，会被链接
}
 
void unused_func() {
    // 这个函数未被使用，不会被链接
}

链接器会：

  • 只链接被实际调用到的函数
  • 未使用的函数代码不会被包含
  • 这种优化称为 ” 死代码消除 ”
  1. 符号解析：
// main.c
extern void func();  // 声明外部函数
void main() {
    func();  // 调用函数
}
 
// lib1.c
void func() { /*实现1*/ }
 
// lib2.c
void func() { /*实现2*/ }

链接时可能遇到的问题：

  • 符号重复定义（multiple definition）
  • 符号找不到（undefined reference）
  • 循环依赖
  1. 实际例子（使用 gcc）：
# 编译并查看静态链接的内容
gcc -c main.c              # 生成目标文件
ar rcs libA.a libA.o      # 创建静态库
gcc main.o libA.a -o app  # 链接
 
# 查看链接了哪些符号
nm app                    # 查看符号表
objdump -d app           # 反汇编查看代码
  1. 常见问题和解决方案：
# 链接顺序很重要
gcc main.o -lB -lA        # 可能失败
gcc main.o -lA -lB        # 正确顺序
 
# 处理循环依赖
gcc -Wl,--start-group -lA -lB -Wl,--end-group
  1. 链接优化：
// 链接时优化(LTO)
gcc -flto main.c -o app   # 启用链接时优化
 
// 函数级链接
gcc -ffunction-sections -fdata-sections -Wl,--gc-sections

2.2 从反编译难度层面考虑，静态链接和动态链接哪个更难被反编译

Faq

从反编译难度的角度来看，静态链接和动态链接在被逆向工程（反编译、还原逻辑、注入等）方面的区别主要体现在以下几个方面：

✅ 结论总结

链接方式反编译难度特点说明
静态链接✅ 更难所有代码都在一个可执行文件中，函数名/边界更模糊，容易混淆
动态链接❗ 相对更容易模块分离，导出符号明确，可单独分析 DLL，并复用系统调试信息

一、为什么静态链接更难反编译？

1. 代码被“扁平化”融合进一个目标文件

  • 所有库代码都在 .exe 或 .dll 中展开为普通函数，没有模块边界
  • 没有 DLL 导出符号，没有易识别的接口函数
  • 难以区分哪些是你写的、哪些是第三方库的逻辑

2. 没有明显符号接口

  • 比如链接了 OpenSSL、fmt 等库，静态链接后它们的函数不再作为导出符号出现在 PE 的导出表中
  • IDA 等逆向工具难以自动分析函数入口或命名空间结构

3. 配合符号去除 / 混淆工具，难度显著上升

  • 如你使用 /DEBUG:NONE、/PDBSTRIPPED、LLVM obfuscator、strip 工具
  • 即使没有混淆，静态链接的函数也可能没有名字，仅靠地址存在

二、动态链接为何更容易反编译？

1. 符号导出清晰

  • DLL 的函数、类名通过 __declspec(dllexport) 明确导出
  • 可以直接看到如 CreateSomething, ProcessData 等接口

2. 模块独立

  • 每个 DLL 可被独立反汇编，容易单独分析、重建伪代码逻辑
  • 可以用 tools 如 Dependency Walker, IDA, Ghidra 直接浏览结构

3. 运行时 hook 更容易

  • 可以轻松在加载时通过 API 拦截 / 注入 / 替换函数（如 Detours、MinHook）
  • 远程注入 DLL 并劫持导出函数比静态链接更简单可行

三、不过反编译难度 ≠ 安全性

静态链接虽然更难反编译，但并不代表它更安全：

  • 一旦攻击者获取 .exe，还是可以通过逆向工具还原逻辑，只是难度稍高

  • 真正的防御措施应包括：

    • 代码混淆（Obfuscation）
    • 反调试（Anti-debugging）
    • 加壳（Packing）
    • 完整性校验
    • 虚拟机保护（如 VMProtect、Themida）

四、何时选择静态链接以增强反编译难度？

场景推荐方式
希望程序部署后难以拆解、分析逻辑✅ 静态链接、剥离符号、加壳
工具/内核驱动等不希望暴露接口✅ 静态链接，防止 DLL 导出被扫描
大量使用第三方库但希望融合不可识别✅ 静态链接，隐藏依赖结构
插件架构 / SDK / 可拓展模块❌ 动态链接更适合（但更容易反编）

五、建议配置（安全优先）

# 静态链接 CRT（避免 vcruntime DLL）
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded")
 
# Release 模式下关闭调试信息
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /DEBUG:NONE /OPT:REF /OPT:ICF")
 
# 禁用符号导出（适用于非 DLL）
add_executable(myapp WIN32 ${SOURCES})
set_target_properties(myapp PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS OFF)

目录

Graph View