Linux ELF 加固推荐方案

1. 适用范围

不适用于：

• Android APK 内的 JNI .so：见 Android Native ELF 加固推荐方案（JNI .so）
• Windows PE：Windows PE 加固推荐方案
• .NET / Java 等托管产物

2. 可选能力

性能提醒

• 压缩保护会在进程启动时解压整个 ELF，文件越大启动越慢；几百 MB 的服务端二进制或大型 .so 尤其明显。
• 如果启用文件 / 完整性校验，启动阶段还要遍历、校验产物，同样越大越慢。
• 函数虚拟化只影响被选中的函数，但会让其运行速度慢数倍到数十倍；热循环、每请求路径、高频回调不要虚拟化。
• 先用未保护产物测冷启动和关键接口基线，再开启保护；CLI 工具对启动时间更敏感。

静态链接程序的导入保护意义有限，重点放在压缩、符号移除和函数保护。

3. 三档推荐方案

3.1 基础档：兼容性优先

3.2 标准档：商业发布

3.3 强化档：高价值目标

4. 符号处理

• 发布前保留一份未 strip 的 ELF，用于函数级保护与崩溃分析。
• 保护完成后再移除符号，或直接启用“移除符号”选项。
• 保留 .symtab 或独立的 debug 文件（如 .debug），按版本归档。
• 对 .so 插件，保留导出符号与版本脚本（version script）的对应关系。
• 不要对系统库、发行版包管理器管理的二进制做修改。

5. 链接方式与运行环境

5.1 PIE 与非 PIE

• PIE / 非 PIE 的加载基址和重定位行为不同，必须分别验证。
• 使用 readelf -h 确认类型（EXEC / DYN）。
• 对 LD_PRELOAD、LD_LIBRARY_PATH 有依赖的程序，验证保护后加载路径不变。

5.2 动态链接与静态链接

• 动态链接程序重点验证导入符号、符号版本和 dlopen。
• 静态链接程序重点验证体积、启动耗时和函数保护。
• 使用 musl 的程序（如 Alpine 镜像）需要单独验证，不要只测试 glibc。

5.3 glibc 与发行版

• 在目标发行版的最低支持版本上验证，不要只在新版 Ubuntu 上测试。
• 确认保护后的二进制仍满足目标 glibc 的符号版本要求。
• 对 CentOS / Debian / Ubuntu / Alpine 等多发行版发布时，分别跑回归。

5.4 容器与服务

• 容器内注意只读文件系统、/proc 限制、seccomp 对反调试的影响。
• systemd 服务、守护进程、fork / exec 模型需要验证信号与退出码。
• 对 Kubernetes 环境，验证探针、优雅退出和日志输出。
• 容器镜像中保留原始二进制与符号文件，便于回滚。

6. 插件与 .so

• 验证 dlopen / dlsym 能正确解析导出符号。
• 验证构造 / 析构函数（__attribute__((constructor))）执行顺序。
• 验证符号版本（symbol version）与 ABI 兼容性。
• 对 Python / Node / PHP 等语言的 native addon，验证模块加载与卸载。
• 对同一进程加载多个版本的 .so，验证符号冲突与命名空间。

7. 构建与发布

编译（Release，保留未 strip 副本）
        ↓
原始产物自测
        ↓
保护（压缩 + 函数保护 + 符号移除）
        ↓
签名 / 校验（按分发方式）
        ↓
目标发行版回归
        ↓
打包 / 发布

关键点：

• 动态库升级时保持 SONAME 与 ABI 兼容。
• 使用容器分发时，在最终镜像中验证，不要只验证构建机。
• 交叉编译的 ARM / ARM64 产物需要在真实设备或对应 QEMU 环境验证。
• 记录输入、输出产物的 SHA-256 与使用的保护配置。

8. 验证清单

• 原始产物在目标发行版可正常运行
• 保护后冷启动、热启动正常
• 所有导出符号、插件、dlopen 正常
• 静态链接 / 动态链接、PIE / 非 PIE 均覆盖
• 目标 glibc / musl 版本覆盖
• 容器、systemd、守护进程场景正常
• 授权、更新、日志链路正常
• x86 / x64 / ARM64 目标均覆盖
• 崩溃栈仍可符号化（保留 debug 文件）
• 最大体积 ELF / .so 的冷启动已单独测试
• 被虚拟化函数的调用延迟 / P95 已对比基线
• 性能指标与基线对比在可接受范围

9. 常见问题

9.1 保护后无法启动

• 检查是否与其他加壳、UPX、完整性校验冲突。
• 关闭反调试与导入保护，只保留压缩，逐步定位。
• 检查 ELF 解释器（interpreter）与动态库搜索路径。
• 对静态链接程序，检查入口点与 TLS 初始化。

9.2 dlopen 失败或符号找不到

• 确认导出符号未被移除或重命名。
• 检查符号版本脚本与 ABI。
• 检查 LD_LIBRARY_PATH、RPATH / RUNPATH。
• 用 ldd、readelf -d、nm -D 对比保护前后差异。

9.3 容器内反调试误判

• 容器共享内核，部分检测手段会误判。
• 通过配置或环境变量关闭反调试，或按环境降级。
• 检查 seccomp 是否拦截了检测所需的系统调用。
• 在真实容器编排环境中验证，不要只在本地 Docker 测试。

9.4 崩溃栈不可读

• 发布前保留未 strip 的 ELF 与 debug 文件。
• 使用 addr2line / eu-addr2line 还原地址。
• 记录构建 ID（readelf -n）与符号文件版本。

9.5 性能下降明显

• 检查是否虚拟化了热循环或高频调用函数。
• 减少虚拟化数量，改用混淆。
• 压缩对冷启动影响较大，服务常驻进程可接受，CLI 工具需重点测试。

10. 相关文档

• Native 加固推荐方案
• Windows PE 加固推荐方案
• Android Native ELF 加固推荐方案（JNI .so）
• CLI 使用文档