ELF 结构能做到和做不到的
PIE 让装载基址随机化,但函数之间的相对偏移与调用关系完全不变,分析时按偏移定位而不是记地址
任何分析手段都有边界,承认边界才能给出可靠的结论。
先说结论
能说清边界,结论才可信。
- 可观察:运行时数据
- 可推:结构与布局
- 不可得:原始源码
- 结论要带置信度
- 成本:影响面:决定分析路径;单个样本约 2-4 小时
能确定的
程序头表决定加载时的内存映射,节区头表只在链接与调试时有意义,可以完全剥离。
凡是运行时会用到的数据,最终都能观察到。
只能推测的
.plt 与 .got 支撑延迟绑定,函数第一次被调用时才把真实地址写进 GOT。
| 对象 | 可还原程度 | 原因 |
|---|---|---|
| 控制流 | 高 | 运行路径可观察 |
| 数据结构 | 中 | 布局可推,命名靠猜 |
| 业务意图 | 低 | 取决于命名与注释 |
| 原始源码 | 不可能 | 编译有损 |
几个具体限制
下面这些是相对确定的细节:
- 静态链接会把 libc 打进二进制,体积 800KB 起步,符号信息也完整得多

怎么给出可靠结论
结论要带置信度:确定、较可能、推测。先看程序头表再谈其它,加载视图才是运行时的真相。
还有几处容易忽略的
这些细节不影响入门,但影响你判断的准确度。
- ELF 的入口是 _start 而不是 main,main 由 libc 的启动代码在初始化之后调用
- strip 只删掉符号表,字符串常量与调用结构依然可读,分析成本没有想象中高
- PIE 让装载基址随机化,但函数之间的相对偏移与调用关系完全不变,分析时按偏移定位而不是记地址
- 拿节区头表判断加载布局,遇到剥过的样本直接读不出
- 把 e_entry 当成 main,跟进去发现是启动代码
- 以为 strip 过的二进制就没法分析了
承认做不到,是专业的一部分。
评论 (3)
补一句:修完要回归,很多人修一半。
终于有人讲清楚「为什么」而不是只给命令。
防御那节写得克制,没有教人打站,这点好评。
发表评论