第4章：信息收集——SDK包分析、文档查找与开放端口探测
信息收集这个阶段，说白了就是「知己知彼」。你连对手的底牌都没摸清，谈什么渗透测试？我做了这么多年SDK安全评估，见过太多人上来就掏工具乱扫一气——结果呢？要么漏掉了核心资产，要么被蜜罐耍得团团转。我个人习惯，拿到一个SDK的第一周，70%的时间都在做信息收集。这活越细，后面越省心。
4.1 SDK 包体分析——扒开外衣看本质
拿到一个SDK压缩包，第一步干什么？我建议别急着解压。先检查MD5/SHA256校验值，确保文件完整且未被篡改。我在项目中遇到过一种情况：甲方提供的SDK包和官方仓库的哈希对不上，后来发现是被中间人插了后门。所以，校验这一步不能省。
4.1.1 包结构快速摸底
解压后，先看目录层级。你想想看，一个三方的推送SDK，如果根目录下就躺着 libcore.so 和 config.json，那还好。但如果它带着 res/、assets/、META-INF/，那就复杂了。我一般用 tree 命令先输出全貌，然后再写个小脚本提取特征。
| 文件/目录 | 重点关注原因 | 常见风险 |
|---|---|---|
jniLibs/ 或 lib/ | 包含 .so 原生库，很难反编译 | 隐藏加密逻辑、反调试、C2地址 |
res/raw/ | 资源文件，常放证书、密钥、配置 | 硬编码口令、、自签名根证书 |
AndroidManifest.xml | 权限声明、组件暴露、provider | 权限过度申请、组件可任意调用 |
classes.dex / .aar | Java/Kotlin 业务代码 | 逻辑漏洞、加密算法逆向 |
build.gradle / podspec | 构建配置、依赖版本 | 依赖已知漏洞库（Log4j、OkHttp 旧版） |
unzip -l sdk.aar 先列表再看内容，别一股脑全扔到工作目录。很多SDK包体积大但有效文件不多，提前了解布局能节约时间。
4.1.2 关键文件深度审查
我个人会把精力放在三个方面：
- 构建配置（.gradle / .podspec）：这里面暴露的依赖版本和仓库地址，往往能透出SDK用的第三方组件。我记得有一次，我在一个
.gradle文件里看到了okhttp:3.8.0，那年头正好爆出SSRF漏洞。顺着这个线索，我后来真的找到了一个远程命令执行的入口。 - 原生库字符串：
.so文件用strings命令跑一遍，重点过滤http://、https://、api.、secret、key、password等关键词。硬编码的测试环境和生产环境地址是常见漏洞。 - 权限与组件声明：
AndroidManifest里的uses-permission如果写了40个权限，其中一半跟SDK功能无关，那就要警惕了——这可能是在为将来的隐私采集预留通道。
lib/armeabi下的一个签名校验so文件。结果所有动态分析都打不开它的接口。后来才发现，那个so加载时会校验集成App的签名，不是白名单包名就直接exit。一定要先把这种自保护机制识别出来，否则后面白费功夫。
4.2 文档与情报查找——别当「野人」
你可能会说：「文档有啥好看的？」嗯，这话对那些文档质量差到极点的SDK来说，确实有一定道理。但正式做渗透测试之前，看文档是性价比最高的情报收集手段。为什么？因为文档会告诉你官方期望的集成方式、接口调用顺序以及——它们自己都不好意思写的限制和坑。
4.2.1 公开文档挖掘
- 官方集成指南：重点关注「快速开始」章节，这里会暴露初始化流程和必要参数。配合
AppKey或Secret的输入位置，通常能反推出后端校验逻辑。 - API 参考文档：仔细阅读
init()、setToken()、setCallback()等关键方法的入参说明。我遇到过一种情况：文档里写参数「建议使用UUID」，但代码里实际上做了是否有效的校验——这就意味着后端有存储和验证机制，可以打点。 - 版本更新日志（Changelog）：这里藏着的「修复了某个安全漏洞」往往是你未测试版本的前车之鉴。对照当前SDK版本和漏洞公告，直接能推测可能存在的攻击向量。
4.2.2 非公开情报与泄露搜索
除了官方文档，我建议你做两件事：
- GitHub 搜索：搜
SDK名称 +、SDK名称 + secret。有些粗心的开发者会把示例代码中的测试密钥直接提交到公开仓库。我有一次在GitHub上搜到某知名推送SDK的Master Secret，直接可以用官方控制台接口下推消息给所有注册设备——你不用怀疑人生，这就是真实案例。 - 网络空间搜索引擎：比如 Shodan、Fofa、ZoomEye。搜索SDK默认域名或特定请求路径，看有多少服务暴露在公网。如果发现大量开发者集成的测试/生产环境实例，那你就可以分析这些实例的响应差异。
4.3 开放端口探测——看看SDK在「通话」的对象
SDK本质上是一段代码，它会在宿主App里联网。所以，它的开放端口和网络交互行为是暴露攻击面的最直接窗口。我个人会在集成SDK的测试App上做以下探测，而不是对SDK包本身静态分析——动静结合才完整。
4.3.1 本地端口监听
SDK如果在本机启动了服务端口（比如127.0.0.1:xxxxx），那就意味着它可能提供了跨进程通信能力（IPC）。这类端口的作用通常包括：
- 跨App共享登录或支付状态
- 本地调试接口（一些SDK留了后门用来检测集成状态）
- 对端服务器的健康检查或心跳回复
怎么探测？在集成测试App运行期间，用netstat -an | grep LISTEN查看本机所有监听端口。对比App启动前后多出来的端口，基本就是SDK开的。
| 端口范围 | 常见用途 | 风险程度 |
|---|---|---|
| 1024-49151 | SDK自用服务端口 | 中-高（可能存在未授权访问） |
| 49152-65535 | 动态临时端口，通常是客户端行为 | 低（一般是短连接） |
| 8080/8443 | HTTP/HTTPS代理或调试服务 | 高（很多SDK会留调试接口） |
| 9090/4444 | WebSocket或自定义协议端口 | 中（需进一步分析协议） |
4.3.2 远程目标端口探测
这个就不只是本机了。你可以通过抓包工具（比如Burp、Charles）、流量分析工具（Wireshark、tcpdump）或者直接看strings输出，提取SDK通信的域名和IP。然后对这些目标进行常规端口扫描。
-sV（版本探测），因为你不仅要知道端口开了，还要知道开了什么服务。比如443端口上可能不是标准HTTPS，而是自定义的加密隧道。版本信息能帮你判断后端是否存在已知漏洞。
4.3.3 协议指纹识别
端口开放只是第一步，更重要的是识别协议。用nmap -sV --version-intensity 9能拿到大部分协议指纹。但我还会手动发一个简单的HTTP请求，看响应是不是JSON、XML、二进制块或者纯文本。这能帮我快速判断这个SDK是用RESTful API、gRPC、WebSocket还是自定义二进制协议通信。