逆向入门:从字符串和导入表开始的静态分析路线
拿到一个陌生二进制,最容易犯的错是直接扔进反编译器看伪代码——几千行,找不到重点。
更高效的做法是先做「信息收集」:它是什么、依赖什么、有什么可疑字符串。
先说结论
先 file/strings/导入表,再定位可疑点,最后才反编译那一段。
- 确认架构与是否加壳(节区熵)
- 字符串常暴露域名、路径、错误信息
- 导入表反映能力:网络、文件、注册表、加密
- 交叉引用把字符串定位到函数
漏洞是怎么产生的
静态分析的优势是「全局可见」,劣势是「可能被混淆」。所以先判断是否需要动态分析配合。
节区熵接近 8 通常意味着压缩或加密,先脱壳再分析。
修复与验证
修复不是改一行代码,而是四件事一起做:
- file / Detect It Easy 确认类型、架构、编译器、是否加壳
- strings -n 6 提取可见字符串,按关键词过滤
- 查看导入表,标记网络/文件/进程操作相关 API
- 在反编译器中按交叉引用定位调用点
- 必要时配合动态调试验证假设
攻击面与检测点
按影响面排序,先修影响最大的:
| 信息 | 来源 | 能说明什么 |
|---|---|---|
| 架构/编译器 | file、DIE | 工具选择 |
| 字符串 | strings | 域名、路径、提示 |
| 导入表 | objdump/PEview | 具备哪些能力 |
| 节区熵 | DIE | 是否加壳 |

几个容易踩的坑
下面这些是最常见的错误做法:
- 上来就反编译几万行:找不到入口
- 忽略加壳:看到的全是壳代码
- 只看字符串就下结论:可能被故意误导
- 不记录分析过程:几天后自己都看不懂
写在最后
静态分析的核心是「带着问题找答案」,而不是「把程序读完」。
安全不是一次加固,是持续的假设:假设输入不可信、假设边界会破、假设有人会看错。
评论 (3)
修复清单比漏洞描述有用多了,很多文章只讲怎么打不讲怎么防。
白名单那条永远是最有效的,正则黑名单迟早绕过。
建议再补一条:把这类检查加到 CI 里,靠人记必然漏。
发表评论