ELF二进制文件中存储自校验和的合适位置咨询

前三个可选位置的可行性分析 #

1. 头中的填充字段 #

• 可行性：加载时内核确实会跳过填充字段（比如ELF头的e_pad、节头的保留字段），写入数据不会影响程序运行。
• 问题：这类字段属于ELF标准保留字段，不同编译器/链接器可能会修改这些字段，未来的ELF标准也可能复用它们，同时strip、objcopy等工具可能会清空或修改填充区域，导致校验和丢失或程序兼容性问题。仅适合临时测试，不建议生产环境使用。

2. SHT_NULL节头 #

• 可行性：SHT_NULL是ELF节头表的第一个表项，标准强制要求存在，且其字段（除sh_type=SHT_NULL外）均为未使用状态。内核加载时会跳过对SHT_NULL的处理，工具链（如readelf、objdump）也会忽略其非必要字段。只要保持sh_type不变，将校验和写入其他字段（如sh_addr、sh_size）完全可行，且不会改变文件大小。
• 注意点：部分旧版链接器可能对SHT_NULL字段有特殊处理，但符合ELF标准的工具都会兼容这种用法，风险极低。

3. .data段的全局数组 #

• 可行性：这是最规范、兼容性最好的方案。只要给全局数组定义唯一符号（如__self_checksum），生成校验和的工具可以通过解析ELF符号表（用nm或直接解析符号表结构）找到该数组的偏移地址，写入校验和；程序运行时直接读取该全局变量即可。
• 解决定位问题的替代方法：如果不想依赖符号表，可以通过自定义链接脚本将数组固定在.data段的指定偏移位置，工具直接定位到该偏移写入即可。完全符合ELF规范，无兼容性风险。

其他可行的存储位置 #

除了你列出的选项，还有几个更优的选择：

• 未使用的节头/段头表项：如果链接器生成的节头表/段头表存在多余的空表项（类型为SHT_NULL/PHT_NULL），可以复用这些表项的字段存储校验和，原理和SHT_NULL一致，不会影响程序运行。
• .note节：ELF的.note节用于存储注释元数据（如编译信息、Build ID），可以编译时添加自定义.note节专门存储校验和，或复用现有.note节的空闲填充空间。该方案完全符合规范，工具链对.note节的处理非常友好。
• 节的对齐填充区域：ELF节（如.text、.data）通常按页大小或特定字节数对齐，节的实际内容大小可能小于对齐后的大小，中间的填充区域为0。可以将校验和写入这些填充区域，只要不超过节的对齐范围，加载时会被映射到内存但不会被程序使用，不会影响运行。

总结 #

无需退而求其次选择文件末尾：

• 优先推荐方案3（.data全局数组），规范且无风险；
• 方案2（SHT_NULL节头）是次优选择，无需修改程序代码，仅需操作二进制文件；
• 方案1（填充字段）不建议用于生产环境；
• 上述其他可选位置也可根据你的实际场景灵活选用。

内容的提问来源于stack exchange，提问作者Andrew Guschin