说实话每次用readelf -V扫一个二进制看到一长串GLIBC_2.2.5、GLIBC_2.34这种字符串时很多人第一反应就是“哦这程序需要这些版本的 glibc”然后就直接翻过去了。但如果你真被“version GLIBC_2.34 not found”这种报错折磨过就会意识到.gnu.version_r 节不是一串玩具字符串它是动态链接器在运行时用来“对账”的核心账本。作为《详解ELF文件》系列的第三十九篇这篇我就把这节彻底拆开从背景、二进制布局、实测解析到运行时行为一次说透。这篇内容适合做二进制分析、逆向、动态库封装以及被 glibc 版本问题坑过的开发者读完之后你再回去看readelf -V的输出看到的就不再是字符串而是一张有结构的表。1. 为什么动态库会平白多出一张版本账本1.1 一个动态库迭代翻车现场先把故事倒回去。在符号版本机制出现之前.so的世界其实很粗放。假设你写了libfoo.so.1里面导出foo()函数程序 A 链接它之后跑得好好的。后来你升级libfoo.so.1觉得foo()的参数列表太丑顺手改成了新参数然后重新发布。这时候程序 A 再启动动态链接器根本不会拦你它就在新库里找到了foo()符号按旧调用约定传参结果就是要么乱码要么直接段错误。你可能会说不是有 SONAME 吗只要把 SONAME 改成libfoo.so.2不就行了这确实能解决“整个库不兼容”的场景但解决不了更细粒度的问题很多时候同一个库内部一部分符号要保持旧 ABI 兼容一部分符号又可以演进出新版本。如果因为一个符号变了就把整个库的 SONAME 升一版那所有旧依赖都要被迫跟着改维护成本极高。Sun 在 Solaris 上最早引入了“符号版本”这个概念GNU 工具链在 Linux ELF 上也沿用了这一套而且在通用 ELFgeneric ELF基础上做了自己的扩展。核心思路就是不再让符号名成为唯一标识而是给每个符号附加一个“版本标签”。动态链接器在解析符号时不光要找到符号名还要校验版本标签是否一致。.gnu.version_r节就是用来记录“我这个文件从外部依赖里需要哪些带版本的符号”的地方。1.2 ELF版本体系里的三兄弟分工要理解.gnu.version_r不能只看它自己因为 GNU 的符号版本机制实际上由三个节配合完成我习惯叫它们“三兄弟”.gnu.versionSHT_GNU_versym一张半字索引表长度和.dynsym动态符号表一一对应每个动态符号在这个表里有一个版本索引值。.gnu.version_dSHT_GNU_verdef版本定义节回答“我这个文件导出了哪些版本”。动态库导出符号时版本名主要记录在这里。.gnu.version_rSHT_GNU_verneed版本需求节回答“我这个文件需要依赖哪些外部库的哪些版本”。简单说.gnu.version_d是“我提供的”.gnu.version_r是“我索取的”。可执行文件通常不需要导出符号所以一般只会有.gnu.version_r而动态库一般两个节都会有。你在readelf -S里看到的大量GLIBC_XXX字符串源头几乎都是这两个节指向的.dynstr字符串表。这三兄弟不是各干各的它们靠版本索引值互相串起来。.gnu.version表里给每个动态符号一个索引如果这个符号是外部引用那么索引值会指向.gnu.version_r里某个 Vernaux 条目的vna_other如果这个符号是本文件导出的索引值会对应.gnu.version_d里的某个 Verdef 条目。搞懂这个索引关系才算是真正把版本机制看通了。2. 把.gnu.version_r拆开看Verneed与Vernaux2.1 Elf64_Verneed一库一条按文件记账.gnu.version_r节的内容不是一根平铺的字符串列表它是有层级的顶层是一条条 Verneed 结构每个 Verneed 代表“我对某一个外部共享库的版本需求”每条 Verneed 下面又挂着若干条 Vernaux 结构代表“我具体需要这个库里的哪些版本”。在 64 位 ELF 下Verneed 对应Elf64_Verneedtypedef struct { Elf64_Half vn_version; /* 版本号目前固定为 1 */ Elf64_Half vn_cnt; /* 该库对应的 Vernaux 条目数量 */ Elf64_Word vn_file; /* 依赖库文件名相对 .dynstr 的偏移 */ Elf64_Word vn_aux; /* 第一条 Vernaux 相对本结构起始位置的偏移 */ Elf64_Word vn_next; /* 下一条 Verneed 的相对偏移0 表示结束 */ } Elf64_Verneed;一个容易踩的坑是vn_aux和vn_next的基准点它们不是相对于.gnu.version_r节起始位置算的而是相对于当前这条 Verneed 结构自身起始位置算的。如果你手工解析十六进制数据把这两个偏移直接加到节起始地址上解析出来的内容就是错的。我第一次手写解析脚本时就在这里绕了一下后来养成了习惯——凡是 GNU 扩展节里出现“偏移”字段先确认基准点是节头、结构体头还是字符串表再动手。vn_file是相对于.gnu.version_r的sh_link字段所指字符串表通常就是.dynstr的偏移。它存的不是随便一个字符串而是依赖库的 SONAME 或路径名比如libc.so.6、libm.so.6。所以你在readelf -V输出里看到的每个顶层条目基本都对应着当前文件链接时依赖的某个共享库。2.2 Elf64_Vernaux版本需求清单上的每一行每条 Verneed 下面挂的 Vernaux 结构才是真正描述“版本项”的明细typedef struct { Elf64_Word vna_hash; /* 符号名的 ELF hash 值 */ Elf64_Half vna_flags; /* 标志位weak 等 */ Elf64_Half vna_other; /* 版本索引对应 .gnu.version 表中取值 */ Elf64_Word vna_name; /* 版本名字符串相对 .dynstr 的偏移 */ Elf64_Word vna_next; /* 下一条 Vernaux 的相对偏移0 表示结束 */ } Elf64_Vernaux;值得注意的事实无论是 32 位还是 64 位 ELFElf64_Verneed和Elf64_Vernaux这两个结构体都是 16 字节。原因在于虽然 64 位 ELF 里地址字段普遍是 8 字节但这里存放的是偏移量用的是Elf64_Word4 字节。这个特性对手工解析非常友好你可以用同一个 16 字节步长去遍历不需要区分机器位宽。对每条 Vernaux三个核心字段的作用分别是vna_hash符号名的 ELF hash 值。它不是版本名的 hash而是这个版本下某个典型符号名的 hash。动态链接器在做快速查找时先用 hash 做粗筛能省掉大量字符串比较。vna_other版本索引。.gnu.version表里某个动态符号如果取值等于这个值就说明该符号依赖这个版本。vna_name版本名的字符串偏移。GLIBC_2.2.5、GLIBC_2.34这些字符串就是从这里读出来的。2.3 vna_hash、vna_other、vna_name到底怎么联动vna_hash和vna_name之间的关系经常被人弄混。vna_name指向的是版本名vna_hash是对应符号名的 hash不是版本名的 hash。它的算法是 System V ELF hash也就是动态链接器在.hash里用的那套unsigned long elf_hash(const unsigned char *name) { unsigned long h 0, g; while (*name) { h (h 4) *name; if ((g h 0xf0000000) ! 0) h ^ g 24; h 0x0fffffff; } return h; }那这个 hash 到底怎么用假设程序里引用了printf而这个符号在目标 libc.so.6 里是有版本要求的链接器会把printf名字的 ELF hash 值填进某个 Vernaux 的vna_hash同时把版本名偏移填进vna_name再分配一个vna_other索引。运行时动态链接器解析printf时会先拿这个 hash 去版本表里匹配命中后再用字符串精确比对确认版本名。这套设计很像数据库的索引hash 是主索引字符串是回表校验。vna_other的取值规则和.gnu.version表密切相关。.gnu.version里常见的索引值含义是0 表示无版本信息或局部符号1 表示全局但未版本化2 及以上才是真正命名的版本。所以你在解析时看到某个符号版本索引是 3那你就去.gnu.version_r里找vna_other 3的那条 Vernaux才知道它到底依赖的是GLIBC_2.4还是别的。另外vna_flags一般情况下为 0但偶尔你也会看到VER_FLG_WEAK值 2。这个标志表示该版本需求是弱需求匹配时可以宽松一些。实际开发里遇到VER_FLG_WEAK的场景不多但逆向分析时一旦发现它要注意版本匹配逻辑可能会走另一条路径不能按普通强需求去推断。3. 实操把一个真实ELF的版本需求读出来3.1 readelf -V开箱即看的版本视图最直接的观察方式是readelf -V。拿我系统里的/bin/ls举例输出大概是这个样子Version needs section .gnu.version_r contains 3 entries: Addr: 0x0000000000002e20 Offset: 0x002e20 Link: 6 (.dynstr) 0x0000: Version: 1 File: libc.so.6 Cnt: 3 0x0010: Version: 1 Name: GLIBC_2.34 0x0020: Version: 1 Name: GLIBC_2.2.5 0x0030: Version: 1 Name: GLIBC_2.4 0x0040: Version: 1 File: libselinux.so.1 Cnt: 2 0x0050: Version: 1 Name: SELINUX_1.0 0x0060: Version: 1 Name: LIBSELINUX_1.0这个输出已经足够说明问题了顶层File:后面的字符串来自vn_file表示这个二进制依赖了哪些共享库每个File下面缩进的Name:来自 Vernaux 的vna_name表示具体需要每个库的哪些版本。Cnt是vn_cnt的值代表当前这个库下面挂了多少条版本需求。还有一个小命令容易被忽略readelf -d里可以看到动态段入口其中DT_VERNEED和DT_VERNEEDNUM就指向这个节的地址和数量。对比看能帮你确认这个节是否被真正使用0x0000000000000006 (DT_VERNEED) 0x2e20 0x0000000000000007 (DT_VERNEEDNUM) 3readelf -V的打印其实等价于readelf --version-info如果你在写脚本或查资料时看到后面这个写法不要觉得陌生两个是同一个东西。3.2 不依赖工具用Python逐字节解析只会用 readelf 还不足以说你懂了这个节。我建议你至少手动解析一次二进制把解析结果和 readelf 对齐这样对结构体偏移和链接关系的理解会彻底固化。下面这段 Python 脚本就是干这个的我以读取.gnu.version_r节为例把 Verneed 和 Vernaux 遍历出来。先用readelf -S拿到节的Offset和Size比如[29] .gnu.version_r VERNEED 0000000000002e20 002e20 000048 000014 06 0 1这里 Offset 是0x2e20Size 是0x48。然后import struct VERNEED_OFF 0x2e20 VERNEED_SIZE 0x48 # 读取 .gnu.version_r 节内容 with open(/bin/ls, rb) as f: f.seek(VERNEED_OFF) data f.read(VERNEED_SIZE) pos 0 while pos len(data): vn_version, vn_cnt, vn_file, vn_aux, vn_next \ struct.unpack_from(HHIII, data, pos) print(f[Verneed] version{vn_version} cnt{vn_cnt} ffile_off{vn_file} aux_off{vn_aux} next_off{vn_next}) # vn_aux 是相对当前 Verneed 结构起始位置的偏移 aux_pos pos vn_aux for _ in range(vn_cnt): vna_hash, vna_flags, vna_other, vna_name, vna_next \ struct.unpack_from(IHHII, data, aux_pos) print(f [Vernaux] hash{vna_hash:#x} flags{vna_flags} fother{vna_other} name_off{vna_name} next{vna_next}) if vna_next 0: break aux_pos vna_next if vn_next 0: break pos vn_next运行后你会得到一组和readelf -V对应的数字只是还没有字符串。要看到GLIBC_2.34这种文本还得结合.dynstr字符串表。.dynstr的偏移同样可以用readelf -S拿到然后写一个按偏移读 C 字符串的小函数DYNSTR_OFF 0x3b78 # 用 readelf -S 查到的 .dynstr Offset def get_str(offset): with open(/bin/ls, rb) as f: f.seek(DYNSTR_OFF offset) out b while True: c f.read(1) if not c or c b\0: break out c return out.decode() # 拿到 vn_file 和 vna_name 后分别调用 get_str(vn_file)、get_str(vna_name)这样你就能把数字和字符串一一对上。我第一次跑通这个流程时最大的感觉是readelf 那几行输出背后其实就是 16 字节 16 字节地拼接起来的没有任何黑魔法。如果你不想自己维护太多解析逻辑用pyelftools会省事很多它对 GNU 扩展节已经做了封装from elftools.elf.elffile import ELFFile from elftools.elf.gnuversions import GNUVersionNeedSection with open(/bin/ls, rb) as f: elf ELFFile(f) sec elf.get_section_by_name(.gnu.version_r) if not isinstance(sec, GNUVersionNeedSection): raise SystemExit(no .gnu.version_r section) dynstr elf.get_section_by_name(.dynstr) for verneed in sec.iter_versions(): print(File:, dynstr.get_string(verneed[vn_file])) for aux in verneed.iter_aux_versions(): print( Name:, dynstr.get_string(aux[vna_name]), Hash:, hex(aux[vna_hash]), Other:, aux[vna_other])注意sec.iter_versions()出来的对象和原始结构体是一一对应的字段名与vn_*、vna_*保持一致非常适合做二次分析。3.3 三张表联查从符号到版本名的完整链路只有.gnu.version_r还不够真正排查问题时你需要把三张表串起来。假设我想知道/bin/ls里的printf到底依赖 libc 的哪个版本。步骤是readelf -s /bin/ls看动态符号表找到printf那一行通常会显示成printfGLIBC_2.2.5。这个后缀就是版本名但 readelf 是从版本关系里解析出来的本质上还是看版本索引。readelf -V看.gnu.version_r里面能找到File: libc.so.6下挂着的Name: GLIBC_2.2.5。用readelf -x .gnu.version看.gnu.version表找到printf在.dynsym中的符号序号对应的半字值那个值应该正好等于GLIBC_2.2.5条目在.gnu.version_r里 Vernaux 的vna_other。这个联查链路就是动态链接器在运行时做的事只不过它用 hash 加速了匹配。自己做一遍比单纯记结论要牢靠得多。这里顺带提一句.gnu.version表在 ELF 通用基线里的作用它本质上是一个数组数组长度等于动态符号表.dynsym的条目数因此符号序号可以直接用作下标。这也是为什么我在前面强调vna_other和版本索引必须配对理解——它们之间的耦合是整个 GNU 版本机制的核心索引关系。4. 动态链接器运行时是怎么对账的4.1 .dynamic里的DT_VERNEED/DT_VERNEEDNUM入口.gnu.version_r节在运行时不是靠节头定位的动态链接器主要看.dynamic段里的DT_VERNEED和DT_VERNEEDNUM。这两个条目在链接成可执行文件时由链接器自动生成一个指向节的虚拟地址一个表示 Verneed 条目的数量。看readelf -d输出时你会看到类似这样的行0x0000000000000006 (DT_VERNEED) 0x2e20 0x0000000000000007 (DT_VERNEEDNUM) 3这里DT_VERNEEDNUM的值 3 指的是顶层 Verneed 的数量不是 Vernaux 的数量。用什么结构体去遍历取决于这个数量。加载器会把版本需求信息解析成内存里的链表结构每个库的依赖项挂在对应的link_map对象上供后续符号查找使用。从这个角度说.gnu.version_r本质上是一份被加载器在进程启动早期就读取的“配置文件”。如果你用LD_DEBUGversions跑一个程序能看到加载器打印出类似“checking for version”的调试信息那就是它在逐条处理这份配置。4.2 解析符号时版本匹配的判定过程动态链接器解析一个外部符号时不是找到同名符号就直接用。它会先从.gnu.version表里取出这个符号的版本索引。如果索引是 0 或 1代表无版本需求或未版本化的全局符号那行为比较宽松如果索引是 2 及以上就说明该符号对版本有精确要求。接下来加载器会在依赖库的符号表中搜索名字匹配的符号。找到候选符号后还需要检查候选符号的版本是否与需求一致。在通用 ELF 的重定位体系里重定位项本身不额外记录符号版本版本信息全靠.gnu.version表和.gnu.version_r表间接映射所以这个“检查版本”的步骤就必须由动态链接器在查找过程中完成。GNU 的实现在_dl_lookup_symbol_x这层做了版本匹配先用 Vernaux 里的vna_hash快速过滤再用版本名字符串做精确比对。命中则候选生效不命中则继续往下一个库找符号直到所有依赖遍历完毕。这里有个容易误解的点不是从所有库里挑一个“最高版本”的符号而是严格按需求版本去匹配。如果最后没找到匹配版本动态链接器就会报出我们常见的错误。这也是为什么同一个未定义符号在多个库里都有同名实现也不能随便绑定版本不匹配就是绑定失败。4.3 一眼认出运行期版本报错最常见的运行时版本错误长这样./app: /lib64/libc.so.6: version GLIBC_2.34 not found (required by ./app)这个报错的意思是加载器在解析./app的某个未定义符号时发现它需要一个GLIBC_2.34版本但当前系统/lib64/libc.so.6的版本需求表里没有提供这个版本。注意这里的“没有提供”通常有两种可能一是系统 glibc 确实太老没定义过GLIBC_2.34二是 glibc 有这个版本名但对应符号由于某种符号版本裁剪没有被导出。后一种情况比较少见但一旦遇到排查起来更隐蔽需要对比.gnu.version_d和.gnu.version_r两边的版本集合。还有一个报错是undefined version: GLIBC_PRIVATE。GLIBC_PRIVATE是 glibc 内部用于其各模块之间通信的版本标签从来不对外部应用开放。如果你的应用链接了某个需要GLIBC_PRIVATE的库很可能是在构建时无意间绑到了 glibc 内部符号这种程序换到任何正常发行版上都可能崩。看到这类报错第一反应不应该是去改LD_LIBRARY_PATH或者粗暴换库而是先用readelf -V 程序确认它到底需要哪些版本再对照目标系统的readelf -V /lib64/libc.so.6看版本集合差在哪里。这样定位问题通常比瞎试快得多。5. 实践中绕不开的版本需求坑5.1 新构建产物拿到旧环境上跑不起来这是我在实际项目里遇到最多的场景开发机用最新的发行版工具链和 glibc 都很新编出来的二进制在开发机上跑得好好的拷到客户的旧服务器上一跑就是version GLIBC_2.34 not found。原因说起来一点都不神秘编译时链接器会根据当前环境里动态库的符号版本把符号版本号记录到.gnu.version_r里。新环境里很多符号默认版本是GLIBC_2.34旧环境根本没有自然就解析失败了。排查时先用readelf -V看看可执行文件里依赖了哪些高版本符号然后逐个确认每个版本名所对应的符号是否可以替换成较低版本。比如有些代码只是用了较新的memcpy优化符号或者编译器自动生成了对新版本__libc_start_main的引用。判断清楚后解决办法通常是在旧环境用旧工具链重新编译或者在使用新工具链时通过-Wl,--hash-stylesysv等参数尽量降低对高版本符号的依赖注意这个手段有限不能解决所有问题更稳妥的是把构建环境容器化到与目标环境相同或更低版本的系统上。这类问题最坑的地方在于编译时完全无感编译器和链接器都不会提醒你“这个二进制以后跑不到旧系统上”。所以如果你的软件需要分发到多种系统上我建议在 CI 流程里加一道检查对产物执行readelf -V并核对版本名集合超过某个阈值直接构建失败。5.2 不用readelf时010 Editor模板同样能看做逆向或恶意样本分析时经常没有条件直接跑readelf -V或者你更想在一个十六进制编辑器里看到结构体字段与字节的对应关系。这时候 010 Editor 的 ELF 模板很好用。我第一次用 010 Editor 解析 ELF 时还踩过一个设置上的小坑打开文件后如果模板没有自动运行需要在“模板”菜单里手动选择 ELF.bt并且在模板选项里设置好解析语言设置完之后Template Results 面板会按照 ELF 规范把节头表、程序头表、动态段都解析成树状结构找到.gnu.version_r节点就能直接看到Elf64_Verneed、Elf64_Vernaux的每个字段。在 010 Editor 里核对字段最重要的收获是“眼见为实”四个字你能看到vn_aux字段的值再跳到 Verneed 结构起始地址加这个偏移的位置正好就是第一条 Vernaux。这个过程跑一遍以后再回去看规范文档或其他书就很容易理解那些“相对偏移”的描述了。想系统补 ELF 底层知识的网上流传的 ELF 入门书 PDF 也值得备一份配合本文的实操步骤看比单纯从头翻书印象深得多。5.3 写版本脚本时如何让.gnu.version_r干净可控如果你是动态库的维护者可能更关心生成动态库时.gnu.version_r会不会被写得很乱。这里最常见的坑是用版本脚本version script给导出的符号打版本标签但符号没被正确归入某个版本段。比如__attribute__((visibility(default))) int foo(void) { return 42; }配合版本脚本VER_1.0 { global: foo; local: *; };这样链接出来的动态库会有.gnu.version_d定义VER_1.0同时 libc 符号被引用时也仍然会生成.gnu.version_r。如果你在脚本里漏掉了某个符号该符号就会被local: *;规则隐藏外部模块引用它时在符号表里就找不到了。这时候问题不会直接体现在.gnu.version_r里但你动态库对外暴露的版本集合就变了。另一个和.gnu.version_r直接相关的问题是链接时出现 “undefined version” 错误。这通常发生在版本脚本声明的版本名与某个被引用符号在依赖库中的版本名不匹配时。链接器会把本文件的符号和外部依赖的版本信息比对版本不一致就会报错。这里有个链接选项值得记-Wl,--no-undefined-version它会在符号版本分配不当时直接报错而不是默默生成一个奇怪的版本需求建议在自己的构建脚本里加上。如果你要检查生成的动态库对外版本需求是否干净最直观的命令是objdump -T libdemo.so | grep UNDUND行里带GLIBC_...的就是本库引用了外部库的版本化符号这些符号会出现在.gnu.version_r里。而左边带.*和VER_1.0的导出符号则会出现在.gnu.version_d里。两边对着看整个版本关系就清楚了。最后说一点我自己的体会.gnu.version_r从来不是孤立存在的它是 ELF 符号版本机制里负责“需求侧”的角色。真正让你对动态库兼容性问题有掌控感的方法不是背结构体而是拿着 readelf 把.gnu.version、.gnu.version_d、.gnu.version_r三张表对照着多查几次再亲手解析一次字节。这套功夫花下去以后任何版本相关报错在你眼里都会变成一张清晰的对账表而不是一串含义不明的字符串。