如何收窄 SO 导出表：保留 JNI 入口并隐藏内部符号

收窄导出表的目标与边界

ELF 共享库的动态符号表记录了可供动态链接器解析的符号。nm 或 readelf 可以读取其中的导出名称与地址；若内部加解密逻辑、协议解析函数或调试接口被意外导出，分析工具就能直接看到这些入口。第一步是识别非必要的公开接口并从导出表移除。

不必要的大量导出符号会显著增加动态劫持的风险。恶意代码可通过 LD_PRELOAD 机制或滥用 Android linker namespace 漏洞，替换同名导出函数以实施参数篡改、返回值过滤甚至控制流劫持。即使不考虑高级攻击，庞大的导出表也为人工分析提供了清晰的函数调用关系图，大幅降低了逆向工程的门槛与成本。

目标并非移除所有符号，而是把导出集限制在虚拟机所需的 JNI 入口和外部必须链接的少数公共 ABI。内部实现函数、静态库带入的残余符号以及不需要外部解析的编译器生成项，应设置为 hidden 或 local，同时保留真实调用方需要的接口。

编译阶段设置默认可见性，链接阶段应用版本脚本，验证阶段再读取最终 SO。三个阶段使用同一份允许清单，才能及时发现配置与产物的差异；发现额外导出时应先确认调用方，再决定隐藏或加入正式 ABI。

诊断工具 nm 与 readelf 的正确用法

验证时可用 readelf -Ws 查看动态符号的 Bind、Vis 与 Ndx 字段，并筛选 GLOBAL 或 WEAK、DEFAULT 且非 UND 的定义。nm -D --defined-only 也能作为便捷视图，但两种工具的列含义不同；审计脚本应基于明确字段判断，不能把一条命令输出笼统称为所有可链接符号的绝对全集。

readelf -s 可以区分符号的节索引和绑定属性，结合-W 宽输出和--dyn-syms 选项可获得更完整的视图，包括符号大小和版本信息。这对于排查因 C++ 符号修饰、版本标记或隐式导出导致的意外符号尤其有用，能够发现 nm 简单输出中可能忽略的细节信息。

如果要检查链接器版本脚本是否生效，先用 readelf -V 查看.gnu.version 和.gnu.version_r 节，确认目标符号是否被赋予了版本名。再对比 nm 输出中该符号的标记，就可以判断脚本中的 local:通配符是否成功抑制了其导出，这是验证脚本逻辑正确性的关键步骤。

自动化检查脚本不应直接对 nm 输出进行模糊匹配，而应基于预期清单文件进行精确排序和 diff 操作。任何缺失或多余的导出都会导致非零退出，并打印具体差异，这样才能在 CI 流水线中可靠拦截符号漂移，确保构建产物始终符合安全设计规范。

• 确认 readelf 报告的.dynsym 数量与 nm -D 输出完全一致
• 检查是否有未预期的高地址符号，可能来自预链接遗留
• 对比不同 ABI 下的 STB_GLOBAL 符号列表，确认无特定泄露
• 验证版本信息中是否出现未定义的 verneed 条目

#!/bin/bash
set -euo pipefail
EXPECTED_FILE="expected_symbols.txt"
SO_FILE="${1:-}"
if [ -z "$SO_FILE" ]; then
  echo "Usage: $0 <shared_library.so>"
  exit 2
fi
if [ ! -f "$SO_FILE" ]; then
  echo "Error: SO file not found: $SO_FILE"
  exit 1
fi
if [ ! -f "$EXPECTED_FILE" ]; then
  echo "Error: expected symbols file not found: $EXPECTED_FILE"
  exit 1
fi
ACTUAL=$(nm -D --defined-only "$SO_FILE" | awk '{print $3}' | sort -u)
if echo "$ACTUAL" | grep -qvE '^[_a-zA-Z]'; then
  echo "Error: unexpected symbol name detected"
  exit 1
fi
EXPECTED=$(sort -u "$EXPECTED_FILE")
DIFF=$(diff <(echo "$ACTUAL" ) <(echo "$EXPECTED" ) || true)
if [ -n "$DIFF" ]; then
  echo "Mismatch between actual exported symbols and expected list:"
  echo "$DIFF"
  exit 1
fi
echo "Validation passed: all exported symbols match expected list."

链接器版本脚本：精确控制导出的核心机制

版本脚本是一个文本文件，通过全局符号块 (global:) 与局部符号块 (local:) 的声明，可以逐个或按模式决定哪些符号保持全局可见。链接时通过--version-script 选项引入，ld 会将该信息写入.gnu.version 节，运行时动态链接器据此执行符号绑定，这是控制导出面的核心机制。

脚本的通配符支持 C 符号名模式，例如"Java_*"可以保留所有静态注册的 JNI 函数，而"*"出现在 local:块中会将未显式列出的符号全部隐藏。这种一次性收拢的方式比逐个使用属性注解更不容易遗漏，特别适合处理大量内部辅助函数的情况。

版本脚本还能为导出符号赋予版本标签，实现 ABI 演化管理。当公共接口发生变化时，可以通过新增版本节点让新旧实现共存，避免因一次链接变更导致所有调用方必须同步更新。在移动应用中，这一能力尤其适合持续升级的 SDK 场景。

然而，版本脚本不能隐藏由重定位需求强制导出的符号，例如.init_array 中的函数指针或 IFUNC 解析函数。这些符号即使未被列为全局，也可能因链接器内部规则而被保留，验证时需单独甄别，不能单纯依赖脚本来解决所有泄露问题。

编译器可见性标志与属性注解的配合

向编译器传递-fvisibility=hidden 会将所有符号的默认可见性设为 HIDDEN，仅通过__attribute__((visibility("default"))) 显式声明的函数和变量才会被提升为 DEFAULT 可见性，从而在链接时进入动态符号表。这是实现细粒度控制的基础编译选项。

这种注解方式适合代码结构清晰、公共接口与内部实现分层明确的项目，开发者只需在头文件的公开 API 声明中加入属性，其余实现文件中的函数自动隐藏，无需维护一个外部的版本脚本文件。这减少了构建配置的复杂度，提高了可维护性。

但当项目需要批量隐藏第三方静态库引入的大量符号时，在每个源文件逐个添加属性就不现实，此时版本脚本或链接器选项--exclude-libs 更为高效。工程上，两种方式常组合使用：版本脚本负责“地毯式”隐藏，属性注解负责个别“白名单”亮出。

inline 函数或模板实例化可能在多个编译单元产生弱定义，但弱符号是否导出仍由编译单元的可见性、链接选项和版本脚本共同决定，链接器不会因为 ODR 处理自动把 hidden 符号提升为全局。验证阶段应直接检查最终 .dynsym，而不是从源码声明推测结果。

JNI 注册方式与导出表的最小化关系

采用静态注册的 JNI 函数必须遵循 JNIEXPORT 和特定命名规则，如 Java_包名_类名_方法名，这些名称会作为动态符号导出。开发者只能将它们加入版本脚本的 global 部分，无法进一步隐藏，否则 Android 运行时无法完成 native 方法绑定，导致 UnsatisfiedLinkError。

动态注册 (RegisterNatives) 则允许在 JNI_OnLoad 中通过一个函数表将 native 方法与本地函数关联，而这些本地函数本身无需导出。此时整个共享库只需导出 JNI_OnLoad（以及可选的 JNI_OnUnload）即可，导出面可压缩到极小，显著降低逆向分析价值。

但动态注册会改变异常传播路径、类加载顺序和线程附着行为，尤其当多个 SO 在同一个 classloader 下注册时，必须仔细处理 JNIEnv 的有效期和局部引用管理，否则容易引入隐蔽的 use-after-free 问题。这需要开发者具备更深厚的 JNI 底层知识。

精简导出表不要求全面迁移到动态注册；静态注册经过版本脚本限制后也能保留清晰接口。选型要结合现有 JNI 数量、注册表维护方式和兼容测试能力，不应只追求最少符号数；两种方案都要用目标 ABI 的加载与调用回归确认。

构建系统集成与编译链接选项落地

在 CMake 中，可以通过 set_target_properties 为目标添加 LINK_FLAGS "-Wl,--version-script=${CMAKE_CURRENT_SOURCE_DIR}/map.txt"以及设置 C_VISIBILITY 和 CXX_VISIBILITY 目标属性为 HIDDEN。同时使用 target_link_options 注入-Wl,--exclude-libs,ALL 来消灭静态库符号导出，实现多环节控制。

对于 ndk-build，Android.mk 中 LOCAL_LDFLAGS 承担链接阶段参数，LOCAL_CFLAGS 设置-fvisibility=hidden，而版本脚本可以通过 LOCAL_LDFLAGS += -Wl,--version-script=path/map.txt 引入。需要注意路径必须相对于 Android.mk 或以绝对路径给出，否则 ndk-build 的 out 目录定位可能出错。

CMake 的 IMPORTED 目标链接预编译 SO 时，当前项目的可见性标志不会重写该库已有的导出表。应向供应商获取精简导出的正式版本，或把该库的实际导出纳入验收；发布前直接修改闭源 ELF 可能破坏 ABI，不应作为默认修复。

所有链接选项在交叉编译工具链中的表现应至少在 ARMv7、ARM64 和 x86_64 三个常用 ABI 上实测一次，因为不同架构的链接器对版本脚本中通配符的解析存在细微差异，可能导致某些符号在一种 ABI 下隐藏成功，在另一种下却仍为 GLOBAL。

• 确认 CMakeLists.txt 中 APP_PLATFORM 和 minSdk 与 NDK API 可用性匹配
• 检查是否对所有 SHARED 目标应用了统一的可见性属性
• 版本脚本路径使用${CMAKE_CURRENT_SOURCE_DIR}避免相对路径错误
• 验证 ndk-build 的 LOCAL_EXPORT_CFLAGS 不会反向覆盖可见性
• 使用 readelf -d 检查 SO 是否确实携带了 (VERSIONED) 和 BIND_NOW 标志

自动化验证闭环：从构建产物到 CI 门禁

交付风险的防范不能依赖人工抽查，必须在 CI 流水线中嵌入符号验证步骤。具体做法是维护一份与代码仓库同步的 expected_symbols.txt，列出每个 ABI 下允许导出的所有符号，构建完成后立即运行前述对比脚本，确保每次提交都符合规范。

预期清单的生成应基于版本脚本或属性注解反推，而非从某次构建的 nm 输出直接保存，否则会将一次性的意外符号永久合法化。首次建立清单时，可以由安全工程师与 Native 开发共同评审当前的动态符号表，逐项确认其必要性再固化到文件中。

当验证脚本发现新增导出符号时，必须以非零状态返回并阻塞发布，同时打印差异供开发人员决策该符号是应该加入白名单还是需要链接阶段进一步隐藏。这种做法把符号可见性从“事实状态”转变为“设计决策”，显著提升了工程团队的安全治理水平。

导出表检查完成后，可把 BIND_NOW 与 RELRO 作为独立的链接安全项记录。它们不改变符号可见性，也不能代替白名单对比；分开报告可以避免把重定位保护误写成导出限制。

常见陷阱与如何避免兼容性断裂

-Wl,--exclude-libs 只抑制链接时从静态归档库自动导出的符号，不作用于 libc++_shared.so 这类动态库。启用前应列出目标 SO 从各个 .a 带入的定义，确认没有把公共 ABI 需要的静态库符号一并隐藏；跨动态库依赖则应从 DT_NEEDED 与未定义符号表另行核对。

符号可见性限制不会自动解决 C++ ABI 兼容问题。如果公共 API 使用 STL 容器或 std::string 作为参数，各编译单元对类型布局和运行库的假设仍需一致；这类问题应通过 ABI 与运行库检查处理，不能归因于导出表设置。

Android 的动态链接器会按 API 级别和 namespace 规则解析依赖。即使导出表配置正确，SO 通过 dlopen 加载时仍可能因路径、依赖或 namespace 不匹配而失败；这需要单独执行加载验证。

符号隐藏不等于代码混淆或 VMP。它只减少动态符号表中的名称，函数机器码仍位于 .text 段并可被静态分析。应把导出限制视为基础构建控制，再按业务风险选择其他代码保护措施。