Go debug/elf.File.DynString 怎么读取 ELF 动态段字符串

在做 Linux 二进制依赖审计时，经常只想回答几个很具体的问题：这个 ELF 依赖哪些共享库，它声明的 SONAME 是什么，是否带有 RPATH 或 RUNPATH。Go 标准库已经把这类读取收敛到 debug/elf.File.DynString，不需要手工按 32 位或 64 位格式切动态节字节。

官方文档：https://pkg.go.dev/debug/elf

DynString 只接受 DT_NEEDED、DT_SONAME、DT_RPATH 和 DT_RUNPATH 四种字符串标签，返回该标签在动态节中出现的全部字符串。没有动态节或没有对应标签时，结果长度可以是 0；传入非字符串标签或遇到损坏结构时才应按错误处理。

先把四种字符串标签分清

DynString(tag) 的返回值是 []string，原因是同一个标签可能出现多次。最典型的是 DT_NEEDED：一个动态链接程序通常依赖多个共享库。其他三个标签通常更少见，但仍应按切片处理，而不是假定只有一个值。

如果任务只是列出 DT_NEEDED，也可以直接调用 File.ImportedLibraries()。Go 标准库的实现里，这个方法就是 DynString(elf.DT_NEEDED) 的便捷封装。想用同一套逻辑同时检查 SONAME、RPATH 和 RUNPATH 时，直接使用 DynString 更统一。

最小程序：一次读取四类动态字符串

下面的程序接收一个 ELF 文件路径，打开后依次读取四个合法标签。示例只做读取与展示，不尝试模拟动态链接器的搜索顺序。

package main

import (
    "debug/elf"
    "fmt"
    "os"
)

func main() {
    if len(os.Args) != 2 {
        fmt.Fprintln(os.Stderr, "用法: elf-dyn ")
        os.Exit(2)
    }

    // elf.Open 会校验 ELF 头，并为后续节读取准备随机访问能力。
    f, err := elf.Open(os.Args[1])
    if err != nil {
        fmt.Fprintf(os.Stderr, "打开 ELF 失败: %v\n", err)
        os.Exit(1)
    }
    defer func() {
        // 关闭由 elf.Open 持有的底层文件，避免批量分析时泄漏句柄。
        if err := f.Close(); err != nil {
            fmt.Fprintf(os.Stderr, "关闭 ELF 失败: %v\n", err)
        }
    }()

    tags := []struct {
        name string
        tag  elf.DynTag
    }{
        {"NEEDED", elf.DT_NEEDED},
        {"SONAME", elf.DT_SONAME},
        {"RPATH", elf.DT_RPATH},
        {"RUNPATH", elf.DT_RUNPATH},
    }

    for _, item := range tags {
        // DynString 会返回同一标签出现的全部字符串，不能只取第一个。
        values, err := f.DynString(item.tag)
        if err != nil {
            fmt.Fprintf(os.Stderr, "%s 读取失败: %v\n", item.name, err)
            continue
        }
        fmt.Printf("%s (%d): %v\n", item.name, len(values), values)
    }
}

构建和调用时给命令保留中文注释，便于团队成员知道参数含义：

# 构建只读检查工具，不修改目标 ELF 文件
go build -o elf-dyn ./main.go

# 将目标路径作为唯一参数；输出内容取决于该文件自身的动态段
./elf-dyn /path/to/your/program

判断是否成功不要依赖某个固定库名。更稳妥的标准是：程序能打开目标文件；每个标签的错误被单独报告；返回长度与目标文件实际携带的标签一致。静态链接产物没有动态节时，读取到 0 项并不等于程序失败。

DynString 隐藏了哪些 ELF 解析细节

从 Go 官方源代码看，DynString 先找到类型为 SHT_DYNAMIC 的节，再读取该节通过 Link 关联的字符串表。动态节条目中的值并不是字符串本体，而是字符串表中的偏移。方法会筛出目标 DynTag，再用偏移取得以 NUL 结尾的字符串。

这层封装还处理了两个容易写错的差异。ELF32 的动态条目大小是 8 字节，ELF64 是 16 字节；标签和值的读取又必须遵循文件头给出的字节序。调用者只传标签即可，不必自己分支处理这些格式。

理解这一点能避免一个常见误区：DynString 不是遍历普通的 .strtab，而是读取动态节关联的字符串表。因此它适合回答动态链接元数据问题，不能替代符号表、DWARF 或任意字符串扫描。

空结果和错误必须分开处理

实际做扫描工具时，我更愿意把“没有值”和“无法解析”分成两类状态。前者通常是目标文件本来就没有该元数据，后者才意味着输入、格式或读取过程出现问题。

• 没有 SHT_DYNAMIC：方法返回空结果和空错误。这在静态链接文件或某些目标文件上可能是正常情况。
• 动态节存在，但目标标签没有出现：返回切片长度为 0，调用方应记录“未声明”，不应伪装成解析失败。
• 传入 DT_STRTAB、DT_STRSZ 等非字符串值标签：方法会返回 non-string-valued tag 错误。数值标签应使用 DynValue。
• 动态节长度不是条目大小的整数倍：返回格式错误，说明输入可能被截断或损坏。
• 动态节的字符串表链接无效：读取关联字符串表时返回错误。

官方实现还有一个值得知道的细节：当某个字符串偏移无法解析成有效字符串时，该条目不会加入结果。做安全审计时，不要把“成功返回”误解成“文件结构已被完整严格验证”；必要时还要结合格式检查器或隔离环境进一步处理。

封装成适合批量扫描的结果结构

如果工具要扫描目录或制品库，直接打印字符串不利于区分“未声明”和“读取失败”。可以先把四组值汇总成结构，再由上层决定输出 JSON、表格或告警。

package inspect

import "debug/elf"

type DynamicStrings struct {
    Needed  []string
    SONAME  []string
    RPath   []string
    RunPath []string
}

func ReadDynamicStrings(f *elf.File) (DynamicStrings, error) {
    var out DynamicStrings
    var err error

    // 每次调用都保留原始切片，便于上层区分 0 个与多个依赖。
    if out.Needed, err = f.DynString(elf.DT_NEEDED); err != nil {
        return DynamicStrings{}, err
    }
    if out.SONAME, err = f.DynString(elf.DT_SONAME); err != nil {
        return DynamicStrings{}, err
    }
    if out.RPath, err = f.DynString(elf.DT_RPATH); err != nil {
        return DynamicStrings{}, err
    }
    if out.RunPath, err = f.DynString(elf.DT_RUNPATH); err != nil {
        return DynamicStrings{}, err
    }

    // 只有解析错误才提前返回；空切片由调用方按“未声明”解释。
    return out, nil
}

这段封装选择“任何一个标签读取失败就整体失败”，适合制品验收。如果业务只关心依赖库，即使 RPATH 损坏也想保留 NEEDED，则可以把每个字段改成“值 + 独立错误”。关键不是哪种结构绝对正确，而是错误策略必须在接口层写清楚。

输入权限和安全边界不能省略

debug/elf 官方文档明确说明：这个包并不是面向对抗性输入加固的解析器，只做基础校验。恶意或畸形文件可能消耗大量资源，甚至导致 panic。因此，从本机可信构建产物读取，和对互联网上传文件做在线解析，是两个不同的安全级别。

面向不可信文件时，至少应补上这些边界：

• 在接收层限制文件大小、数量和分析并发，不把任意大文件直接交给解析器；
• 把解析放进受限进程或容器，设置 CPU、内存和执行时间上限；
• 只授予目标文件的只读权限，不让分析进程接触密钥、宿主目录或写权限；
• 捕获进程级失败并记录输入摘要，不因一个坏文件中断整批任务；
• 将 len(values)==0、err!=nil 和分析进程异常分别计数，避免监控口径混在一起。

常见问题

为什么读取 DT_NEEDED 得到空切片？

先看错误是否为空。错误为空时，常见原因是文件没有动态节、目标是静态链接产物，或者动态节里没有 DT_NEEDED。这不是自动等同于文件损坏。

能把任意 DynTag 传给 DynString 吗？

不能。它只接受四个字符串值标签。像 DT_STRSZ 这类数值标签应该调用 DynValue，否则会得到“非字符串值标签”的错误。

ImportedLibraries 和 DynString(DT_NEEDED) 有什么区别？

在 Go 标准库当前实现中，ImportedLibraries 直接调用 DynString(DT_NEEDED)。前者语义更直观，后者适合统一读取四类动态字符串。

DynString 会解析动态符号吗？

不会。动态符号应使用 DynamicSymbols，需要外部库满足的符号可使用 ImportedSymbols。DynString 只处理动态节中以字符串表偏移表示的那四类标签。

结论

读取 ELF 动态段字符串时，核心写法就是“elf.Open + defer Close + DynString”。真正影响工程质量的不是把 API 调通，而是选对四个合法标签、保留多值结果、区分空结果和解析错误，并对不可信 ELF 加上资源隔离。这样得到的代码既可用于单文件检查，也能稳定扩展到依赖审计和制品扫描流程。