RELRO 与 BIND_NOW 防护边界：从重定位、GOT 到装载成本与代码虚拟化的分界线

RELRO 与 BIND_NOW 能在装载阶段阻断什么

RELRO 与 BIND_NOW 的组合在 ELF 装载器将控制权交给 init 数组和 main 之前，把全局偏移表（GOT）中由动态链接器填充的部分重映射为只读，从而阻断了基于 GOT 覆写的攻击路径。具体而言，当攻击者能够触发一次任意地址写入但无法直接更改代码段时，传统的利用方式就是覆写 GOT 条目使后续函数调用劫持到恶意逻辑。一旦 GOT 变为只读，这种依赖于装载后写入的重定位利用就被彻底阻断。

该防护依赖 PT_GNU_RELRO 程序头将可写段在装载完成后标记为只读，结合 DF_BIND_NOW 标志要求动态链接器在返回用户代码前解析所有函数符号。Partial RELRO 仅仅将非 PLT 相关的重定位区域设为只读，.got.plt 仍然可写，攻击者可以覆写尚未解析的 PLT 函数条目。只有同时指定 -z relro 与 -z now，编译器驱动 ld 才会同时产生 PT_GNU_RELRO 段与 DF_BIND_NOW 标志，实现完整的立即绑定与全面 GOT 只读。

可以在装载期被控制的攻击建立在动态链接器行为之上：攻击者必须依赖于装载时的惰性绑定机制，在符号首次调用时通过动态链接器写入 GOT，或者在装载完成后利用某次写原语直接篡改已填写的条目。Full RELRO 将整个重定位相关的 GOT 段在 main 之前全部填入正确地址，然后立即 mprotect 为不可写，从根本上消除了装载结束后仍可写入的窗口，也让基于偏移计算的 GOT 覆写变为只能触发崩溃的无效操作。

• 确认 ldflags 中同时给出 -Wl,-z,relro -Wl,-z,now
• 使用 readelf -l 检查是否存在 GNU_RELRO 段
• 使用 readelf -d 确认 BIND_NOW 标志未缺失
• 核查最终 .so 或可执行文件的段映射是否仅包含 R 无 W

ELF 重定位与 GOT 数据面的核心威胁模型

当可执行与可链接格式（ELF）被操作系统加载时，动态链接器需要修正代码与数据中引用的外部符号地址，这个过程称为重定位。对于函数符号，动态链接器通常默认采用惰性绑定：在首次调用时通过过程链接表（PLT）跳转到一段桩代码，由桩代码调用解析函数并将结果写入 GOT，之后调用直接通过 GOT 跳转。此时 GOT 必须保持可写属性，这为运行时内存破坏漏洞留下了直接的函数指针覆写路径。

仅由编译器选项控制的段属性不会主动防御运行时 mprotect 或跨进程攻击，因为攻击者可能通过另一条漏洞链获得足以调用 mprotect 的 system 调用能力，重新将只读 GOT 改为可写，再写入伪造函数地址。因此，理解 RELRO 的边界必须从重定位面的静态数据流出发：它解决的是装载完成后无需再写入的数据段被误写的问题，而不是进程内可信代码被恶意修改的通用内存安全。

静态分析工具可以通过检测 PT_GNU_RELRO 段的存在和段映射属性推断 Full RELRO 已启用，但无法推断 GOT 的内容是否在装载后被外部篡改。例如，在某些定制安卓设备上，内核模块缺失可能导致 RELRO 段仅表现为普通只读段，而系统完整性监视能力不足，攻击者仍有可能利用设备特定的内核漏洞翻转页表写入权限。因此 GOT 覆写防护最终依赖内核与装载器协调维护的页属性，而不是单一的链接选项。

#!/bin/bash
set -euo pipefail

usage() {
  echo "用法：$0 <elf_file>" >&2
  exit 1
}

check_elf() {
  local elf="$1"
  if [ ! -f "$elf" ]; then
    echo "错误：文件 $elf 不存在" >&2
    exit 2
  fi
  if ! readelf -h "$elf" >/dev/null 2>&1; then
    echo "错误：$elf 不是有效的 ELF 文件" >&2
    exit 3
  fi
}

check_relro() {
  local elf="$1"
  if ! readelf -l "$elf" | grep -q 'GNU_RELRO'; then
    echo "失败：未找到 PT_GNU_RELRO 段" >&2
    exit 4
  fi
}

check_bind_now() {
  local elf="$1"
  if ! readelf -d "$elf" | grep -q '(BIND_NOW)'; then
    echo "失败：缺少 DF_BIND_NOW 标志" >&2
    exit 5
  fi
}

[ $# -ge 1 ] || usage
ELF="$1"
check_elf "$ELF"
check_relro "$ELF"
check_bind_now "$ELF"
echo "成功：Full RELRO 与 BIND_NOW 已启用"

Partial RELRO 与 Full RELRO 的机制差异

链接器通过识别 -z relro 选项创建 PT_GNU_RELRO 程序头，指示动态装载器将重定位相关数据段在装载后立即设为只读。Partial RELRO 只将 .dynamic、.got 等不参与惰性绑定的区域设为只读，而 .got.plt 仍保持可写以便惰性绑定执行。这意味着攻击者只要获得目标进程内的写能力，就可以覆写任何未解析的 PLT 函数条目。

Full RELRO 要求同时启用 -z now，这会强制装载器在跳转到 init 代码之前解析所有 PLT 条目并填入 GOT，然后将整个 GOT 范围连同 .got.plt 一起改为只读。此时装载器产生 PT_GNU_RELRO 段覆盖了完整的 GOT 区域，而 DF_BIND_NOW 动态标志被写入 dynamic section，供运行时环境与审计工具查证。

实践中的区分手段在于观察只读段映射：Partial RELRO 的 .got.plt 仍处于可写段，Full RELRO 的 .got 与 .got.plt 通常合并到一个只读段。攻击者可利用这种段布局差别判断目标是否提供了真正的立即绑定保护，进而选择不同利用策略。对于无法更改编译器选项的闭源 SDK，只能通过 readelf 或运行时 dl_iterate_phdr 确认实际载入内存的权限。

• 对比不同构建配置下的 readelf -l 输出差异
• 验证 .got.plt 段在内存映射中的权限位
• 检查动态节中 FLAGS 字段是否包含 NOW
• 确认链接脚本未显式排除 GOT 段保护

BIND_NOW 的装载期绑定成本与决策

BIND_NOW 的立即绑定要求动态链接器将所有启用的 PLT 重定位在通过 init 数组之前全部解析并填充，这意味着程序启动时要支付所有外部函数的符号查找与地址重定位开销，无论这些函数在本次运行中是否真正被调用。对于大量导入函数的守护进程或大型框架库，这一成本可能导致启动延迟显著增加，因为原本分散在程序生命周期的惰性绑定 I/O 与字符串操作被集中到装载阶段。

成本大小取决于导入符号数量、符号哈希拖链长度以及装载器的缓存策略。在 Android 类系统中，许多系统库往往已在 zygote 阶段预热，因此 BIND_NOW 对应用冷启动的影响可能高于热启动。在一个大范围采用惰性绑定优化的系统中，提升安全性的代价可能在数百毫秒级别，必须根据业务容忍度决定是否为所有组件开启。

内存受限设备应分别记录开启前后的冷启动时延、VSS 和 RSS，再决定是否为所有组件启用 BIND_NOW。GOT 条目提前解析并不自动等于显著内存增长；没有目标构建的基准结果时，只能把性能影响登记为待测项。

• 测量冷启动与热启动下 main 执行前的时间差
• 比较 /proc/pid/smaps 中只读段的大小变化
• 在低端设备上验证 BIND_NOW 是否引入 ANR 风险
• 若启动成本不可接受，仅对关键守护进程选择性启用

RELRO 与 BIND_NOW 不能防护的运行时攻击面

GOT 重写并不是内存破坏攻击的唯一形式。一旦攻击者获得代码执行能力，他们可以通过内联钩子或直接修改代码段来劫持函数，而这些手段不受 GOT 只读属性影响。特别是在没有代码完整性验证的通用 Linux 进程中，装载后的可执行内存页可能被 mprotect 改为可写再注入指令，或者攻击者直接利用已有的 JIT 区域存放载荷，这些攻击方式完全绕过 ELF 层的重定位保护。

动态库延迟加载也是防护盲区：如果程序在运行时通过 dlopen 装载新库，且新库未以 RELRO + BIND_NOW 编译，那么该库的 GOT 会再次暴露可写重定位面。由于装载器无法跨库强制实施全局 RELRO 规则，安全架构必须要求所有动态组件统一编译选项，并对运行时的 dlopen 调用实施白名单控制，但该控制本身并非 RELRO 提供的机制。

符号可见性控制与导出表压缩属于攻击面收敛的另一维度，它们与 RELRO 没有直接关联。攻击者即便无法覆写 GOT，仍可通过分析导出符号定位关键函数地址，进而实施面向返回编程（ROP）或跳转导向编程（JOP）。降低导出符号数量虽然可以减少信息泄漏，但需要配合版本脚本与 -fvisibility 标志，这属于构建期符号管理，不在重定位只读的防护范围之内。

• 审查应用中所有 dlopen 调用的来源可信度
• 评估是否需要针对 .text 段的额外保护措施
• 检查是否存在允许任意内存写的逻辑漏洞
• 确认内核版本是否支持严格的页表保护策略

代码虚拟化与 RELRO 的分工边界

代码虚拟化（VMP）将关键算法编译为自定义的中间语言并在虚拟机中解释执行，其设计目标是使逆向分析难以将指令序列还原为原始业务逻辑。与之不同，RELRO 与 BIND_NOW 仅仅限制装载后 GOT 的写入，对代码段自身的可读性、可反汇编性毫无影响。启用 Full RELRO 的二进制，仍然可以通过静态反汇编、动态跟踪等方式提取算法，业务逻辑并未被隐藏。

开发者经常会误以为将 GOT 变为只读等同于增强了代码段保护。实际上，攻击者可以完整打印 .text 段中的指令流，或者通过调试接口和 ptrace 记录运行时行为，而不需要尝试写入 GOT。RELRO 属于内存破坏防御的技术栈，而代码虚拟化属于逆向分析难度的技术栈，二者在攻击树中的位置截然不同，不能互相替代。将 RELRO 等同于 VMP 会错误地认为已经保护了核心算法安全。

划分边界时先确认要保护的是重定位表写入还是业务逻辑可读性：RELRO 处理前者，VMP 面向后者。两类机制在工程上可以同时启用，但具体启动与内存开销仍需用目标 VMP 配置做基准测试，不能从静态标志推算。

• 列出需要机密保护的核心算法模块
• 确认这些模块已通过 VMP 编译器处理
• 使用 -Wl,-z,relro,-z,now 加固剩余原生组件
• 测试 VMP 与 RELRO 叠加后启动时间与内存增量

通过 readelf 静态审计 RELRO 与 BIND_NOW 状态

使用 GNU readelf 工具审计二进制保护级别是最直接的非侵入式方法。首先查看程序头表：readelf -l <elf> 应当列出 GNU_RELRO 段，该段的内存权限通常为只读，且其虚拟地址范围必须覆盖 .got 和 .got.plt。如果此段缺失，表明未启用任何 RELRO，若段存在但起始地址仅覆盖 .dynamic 区域则极有可能是 Partial RELRO。

接着检查 dynamic section：readelf -d <elf> 寻找 FLAGS 条目中包含 BIND_NOW 或 FLAGS_1 中包含 DF_1_NOW 的标志。如果 BIND_NOW 未置位，即便存在 PT_GNU_RELRO，也仅仅是 Partial RELRO。诊断脚本应当将两种检查结合，并在发现缺失时返回非零状态，以便植入 CI 流水线，确保每次构建产物都符合预期。

静态审计的局限在于无法保证运行时动态链接器的行为符合标志设定。某些嵌入式平台上可能存在裁剪过的链接器，即使读取到 DF_BIND_NOW 也未执行立即绑定。为了降低误报风险，可以在真机环境下注入一个小型验证 SO，该库从 init 数组中检查自身的 GOT 是否可写，并上报状态。

• 编写自动化脚本解析 readelf 输出文本
• 在 CI 流程中设置 RELRO 缺失即构建失败
• 定期抽检第三方依赖库的保护状态
• 记录不同编译器版本生成的默认标志

16 KB 页面对齐、NDK 兼容与 C++ 异常传播的关联边界

Android 推广 16 KB 页大小后，RELRO 机制可能与段对齐策略产生互动。PT_GNU_RELRO 段的起始地址与大小通常保持至少一个页面对齐，但若整个 ELF 的 LOAD 段未对齐到 16 KB，系统装载器在映射只读 RELRO 区域时可能因页分裂而暴露潜在的写回风险。开发者必须同时通过 zipalign 与编译器对齐选项保证 LOAD 段与 RELRO 段在新页大小下依然正确映射。

从 NDK 兼容性视角看，许多项目在引入 Full RELRO 后遇到启动崩溃，根本原因并不是 RELRO 本身，而是未正确处理 C++ 异常或 STL 符号的惰性绑定依赖。当启用 BIND_NOW 时，如果某个共享库引用的符号（如 typeinfo 或 unwind 相关）在装载时无法解析，装载器将立即中止进程，这会暴露之前依赖惰性绑定而掩盖的缺损依赖。必须通过 ndk-build 或 CMake 显式链接正确的 C++ 运行时，并确保异常类通过 RTTI 完整可见。

性能与兼容性最终必须在目标设备上验证。通过单一 ABI 或模拟器得到的结果不能推导至真机，因为内核的页保护策略、链接器的定制行为以及预编译库的装载缓存都存在差异。开发者应当建立包含 RELRO 检查、16 KB 设备上的 LOAD 对齐验证与 C++ 异常回归测试的自动化流水线，以确保防护不会因固件差异而失效。

• 确认所有 LOAD 段 Align 至少为 16384
• 确保 APK 对齐工具适配了目标页大小
• 检视 AndroidManifest 中 extractNativeLibs 配置的影响
• 在 CI 中集成 readelf 段对齐与 BIND_NOW 检查