1. 信息收集的版图为什么必须延伸到APP和其他资产

做信息收集的人最容易犯的一个错误，就是把目光死死盯在域名和IP上，觉得把子域名跑完、端口扫完就万事大吉了。我刚开始接触这块的时候也是这个思路，结果在一次内部复盘会上被问了一句“那他们的移动端谁在看”，当场哑火。后来才慢慢意识到，一个组织在互联网上的暴露面，远远不止几个网站。移动应用、小程序、公众号、对外接口、代码仓库、云存储、第三方协作平台，这些全都是资产，而且往往是防护最薄弱的那一环。

这篇内容就是围绕“APP及其他资产”这个方向，把我自己在实际项目里做信息收集的完整思路和操作细节梳理一遍。核心解决的问题是：当你已经把常规的域名、IP、端口信息收集做完之后，接下来该往哪些方向延伸，用什么方法去发现那些容易被忽略的资产，以及怎么把这些零散的信息串成一张完整的资产地图。适合有一定信息收集基础、想把自己的资产梳理能力从Web端扩展到移动端和周边生态的安全从业者，也适合企业里负责资产管理、攻防演练蓝队梳理的同行参考。

需要提前说明的是，这里讲的“信息收集”是站在资产管理与风险自查的角度，目的是帮助组织搞清楚自己到底有多少对外暴露的东西，哪些是已知的、哪些是“影子资产”。所有操作都应当在获得合法授权的前提下进行，这一点不需要我多强调，但每次都得说，因为这是底线。

2. 移动端资产收集的整体思路拆解

2.1 为什么APP资产是信息收集的“第二战场”

Web端的资产梳理经过这么多年的发展，方法论已经相当成熟了：子域名枚举、证书透明度日志、DNS历史记录、端口扫描、指纹识别，一套组合拳下来基本能覆盖七八成。但移动端不一样，APP的发布渠道是分散的，安卓有各种应用市场，iOS有App Store，还有大量企业内部使用的、根本不上架的APP。这些APP里面打包了接口地址、密钥、配置信息，一旦被逆向或者抓包，暴露出来的攻击面可能比Web端还大。

我个人的经验是，一个中等规模的组织，Web端可能有三五十个对外域名，但移动端APP里涉及的接口域名往往能翻倍。原因很简单：移动端开发节奏快，接口经常换，老版本APP里还残留着已经废弃但服务器没下线的接口。这些“僵尸接口”就是典型的影子资产，运维不知道、安全团队不知道，但攻击者知道。

2.2 资产收集的三个层次：已知、未知、隐藏

我把移动端和其他资产的收集分成三个层次来理解，这样思路会比较清晰。

第一个层次是已知资产，就是组织自己清楚存在的APP、小程序、公众号。这部分相对好办，直接从官方渠道获取安装包或者访问入口就行。第二个层次是未知资产，指的是组织内部不同团队各自开发的、没有统一登记在册的APP，比如某个业务部门自己找人做的小工具。第三个层次是隐藏资产，指的是APP背后关联的服务器、接口、第三方服务，这些在APP本身之外，但通过分析APP能挖出来。

这三个层次的收集方法完全不同。已知资产靠沟通和登记，未知资产靠搜索和比对，隐藏资产靠逆向和抓包分析。下面我会逐个展开。

2.3 工具选型背后的取舍逻辑

说到工具，市面上能用的东西很多，但我不太喜欢一上来就堆工具列表。工具是服务于思路的，思路不清楚，给你再好的工具也是乱扫一通。我在移动端资产收集上常用的工具组合大概是这样的：抓包用中间人代理类的工具，逆向用反编译和静态分析类的工具，资产发现用网络空间测绘平台配合关键词搜索。

选中间人代理而不是直接改包，是因为移动端很多请求有证书绑定，直接改包容易触发校验，而中间人代理配合证书安装能更自然地观察流量。选静态分析而不是纯动态，是因为静态分析能一次性把APP里所有硬编码的字符串、URL、密钥都提取出来，效率比一个个点界面高得多。网络空间测绘平台则是用来做交叉验证的，把从APP里提取出来的特征放到测绘引擎里搜，往往能发现同一组织名下的其他资产。

提示：工具的选择要根据目标APP的技术栈来定。原生安卓和React Native打包的APP，逆向难度和关注点完全不同。前者重点看smali代码和so库，后者重点看打包后的js bundle。

3. 安卓与iOS应用的具体收集方法

3.1 安卓APK的获取与初步处理

安卓端的优势在于安装包容易获取。官方应用市场可以直接下载，第三方市场如酷安、应用宝等也能找到大部分主流APP。如果目标APP只在企业内部使用，那就需要从其他渠道想办法，比如内部人员分享、设备提取等，这部分涉及社工手段，不在纯技术讨论范围内，我这里只讲公开渠道能拿到的。

拿到APK之后，第一步不是急着反编译，而是先做基础信息记录。我会建一个表格，记录APP名称、包名、版本号、签名信息、下载来源、文件哈希。包名特别重要，因为它是后续在网络空间测绘平台搜索的关键词。签名信息可以用来判断APP是否由同一开发者签名，从而关联到同一组织的其他APP。

# 获取APK基础信息 aapt dump badging target.apk | head -30 # 提取包名、版本号、权限列表

aapt这个工具在安卓SDK的build-tools里就有，用起来很方便。输出的信息里，package: name=后面就是包名，versionName是版本号，uses-permission列出了APP申请的权限。权限列表能透露很多信息，比如一个看起来是工具类的APP却申请了通讯录和定位权限，那就值得多留意一下。

3.2 反编译与敏感信息提取

反编译安卓APK，我用得最多的是apktool加jadx的组合。apktool负责把资源文件和manifest解出来，jadx负责把dex转成可读的Java代码。两个工具配合使用，基本能把APP的结构看个七七八八。

# 用apktool解包 apktool d target.apk -o target_apktool # 用jadx反编译 jadx -d target_jadx target.apk

解包之后，重点看几个地方。AndroidManifest.xml里能看到APP声明的所有Activity、Service、Receiver，以及android:exported属性。如果某个组件设置了exported=true但没有权限保护，那就是一个潜在的入口点。res/values/strings.xml里经常藏着硬编码的URL和API Key，虽然现在很多APP会把敏感信息放到so库或者服务端下发，但老版本APP里还是经常能捡到漏。

jadx反编译出来的Java代码里，我会用全局搜索找几类关键词：http://、https://、api、key、secret、token、password。这些关键词能快速定位到接口地址和凭证信息。实测下来，一个中等复杂度的APP，用这种方式通常能提取出十几个到几十个不等的接口域名。

3.3 iOS应用的收集特点与差异

iOS端比安卓端麻烦一些。App Store下载的IPA文件是加密的，需要先脱壳才能反编译。脱壳需要越狱设备或者特定的脱壳工具，门槛比安卓高不少。如果目标APP没有在App Store上架，而是通过企业证书分发或者TestFlight分发，那获取难度更大。

不过iOS端有一个安卓没有的优势：App Store的搜索结果和开发者页面是公开的，可以通过开发者账号关联到同一开发者名下的所有APP。这个信息在App Store的开发者页面就能看到，不需要任何技术手段。我通常会先把目标组织的开发者账号找出来，然后把它名下所有APP列出来，再逐个分析。

对于能拿到脱壳IPA的情况，分析方法跟安卓类似：提取字符串、找URL、找密钥。iOS的二进制文件用strings命令就能提取出大量可读字符串，虽然不如反编译直观，但胜在快速。

# 从iOS二进制文件中提取URL strings TargetApp | grep -E "https?://" | sort -u

3.4 小程序与公众号的资产关联

小程序和公众号是这几年新增的重要资产类型。小程序的包体可以通过微信开发者工具或者抓包获取，本质上也是一个前端项目，里面同样会包含接口地址和配置信息。公众号的菜单、自动回复、文章里的链接，都可能指向组织的其他资产。

我处理小程序的方式是：先用抓包工具把小程序运行时的所有请求记录下来，然后从小程序的代码包里提取静态资源。小程序的代码包通常不大，反编译后能看到页面结构和网络请求逻辑。公众号则更多是靠人工浏览，把菜单点一遍、把历史文章翻一翻，记录下所有出现过的域名和链接。

4. 其他资产类型的挖掘与关联分析

4.1 代码仓库与云存储的意外收获

代码仓库是信息收集的富矿，但很多人只盯着GitHub，忽略了GitLab、Gitee、Bitbucket等平台。搜索代码仓库的关键是构造好关键词。我常用的搜索词组合是：组织名称+api_key、组织名称+password、组织名称+internal、组织名称+config。很多开发者会把测试环境的配置不小心提交到公开仓库，里面往往包含数据库连接串、云存储密钥等敏感信息。

云存储这块，主要是对象存储服务。很多组织会把静态资源、备份文件、日志文件放在对象存储里，但权限设置不当导致公开可读。发现这类资产的方法有两种：一种是从APP或网站里提取对象存储的域名，然后尝试列举；另一种是用网络空间测绘平台搜索特定的响应特征。

注意：对云存储的探测要格外小心，只做只读的列举操作，不要下载或修改任何文件。一旦发现权限配置不当，应当立即通过正规渠道报告，而不是进一步利用。

4.2 网络空间测绘平台的交叉验证

网络空间测绘平台是我做资产关联时最依赖的工具之一。它的核心价值在于：你给它一个特征，它还你一批资产。这个特征可以是一个favicon的哈希、一段特定的HTML标题、一个SSL证书的序列号，甚至是一个特殊的HTTP响应头。

从APP里提取到接口域名后，我会把这个域名的SSL证书信息拿到测绘平台上去搜。同一组织往往用同一张证书或者同一套证书签发体系，通过证书关联能发现大量同组织的其他域名。favicon哈希也是同理，很多组织内部系统用同一套前端框架，favicon是一样的，一搜就能搜出一片。

这张表里的方法我基本每次都会用一遍，尤其是SSL证书关联，命中率非常高。一个组织可能有很多域名，但证书就那么几张，顺着证书摸下去，经常能发现一些连组织自己都忘了的“古董”系统。

4.3 第三方服务与供应链资产的梳理

现代应用很少是孤立的，总会依赖各种第三方服务：支付、推送、地图、统计、客服。这些第三方服务在APP里通常以SDK的形式存在，每个SDK都会连接自己的服务器。梳理这些第三方依赖，一方面能了解APP的完整网络行为，另一方面也能发现一些被遗忘的配置。

比如，某个APP集成了某推送服务，推送服务的控制台里配置了回调地址，这个回调地址可能指向组织的一个内部系统。如果推送服务的账号权限管理不严，攻击者可能通过推送服务间接接触到内部系统。这类供应链风险在近几年的攻防演练中越来越常见。

梳理第三方依赖的方法，安卓端可以在反编译后的代码里搜索常见SDK的包名特征，iOS端可以看Frameworks目录下的动态库列表。把依赖清单列出来之后，逐个去对应的服务商控制台检查配置，看看有没有暴露内部地址或者使用了弱凭证。

5. 实操流程与关键环节记录

5.1 从零开始的一次完整收集过程

假设我现在要对一个目标组织做移动端及周边资产的信息收集，我会按下面的流程走一遍。这个流程是我经过多次项目打磨后固定下来的，不一定最优，但胜在稳定、不容易漏。

第一步，确定目标组织的官方应用清单。去主流应用市场搜索组织名称，把排名前几的APP都下载下来。同时去App Store看开发者账号，把该开发者名下的所有APP列出来。这一步的目的是建立“已知资产”清单。

第二步，对每个APK做基础信息提取。用aapt拿到包名、版本、权限，用apktool和jadx反编译，提取所有URL、IP、密钥、证书信息。这一步会产出大量原始数据，需要耐心整理。

第三步，把提取到的域名和IP放到网络空间测绘平台做关联搜索。用SSL证书、favicon、标题等特征去扩线，把关联到的资产加入清单。

第四步，对小程序和公众号做同样的处理。小程序抓包获取接口，公众号人工浏览记录链接。

第五步，整理所有资产，按类型、归属、状态分类，形成最终的资产地图。

5.2 关键参数的计算与选择

在反编译和抓包过程中，有几个参数的选择会直接影响效率。比如jadx反编译时的线程数，默认是4，如果机器性能好可以调到8或者16，能明显加快大APK的处理速度。再比如抓包时如果遇到证书绑定，需要判断是客户端校验还是服务端校验，客户端校验可以通过hook绕过，服务端校验则需要在服务端配置上想办法。

# jadx指定线程数加快反编译 jadx -j 8 -d output_dir target.apk

还有一个容易忽略的参数是APK的minSdkVersion和targetSdkVersion。这两个值决定了APP能运行在哪些安卓版本上，也间接反映了APP的维护状态。如果一个APP的targetSdkVersion还停留在很老的版本，说明它很久没更新了，里面存在已知漏洞的可能性就更大。

5.3 数据整理与资产地图的构建

收集到的原始数据如果不整理，就是一堆垃圾。我习惯用表格来管理，字段包括：资产类型、资产标识（域名/IP/包名）、来源、关联关系、状态、备注。资产类型分APP、小程序、公众号、域名、IP、云存储、代码仓库等。来源记录是从哪个APP或哪个渠道发现的。关联关系记录资产之间的父子关系或同源关系。

整理完之后，我会画一张简单的资产关系图，用节点表示资产，用边表示关联。这张图不用很精美，用思维导图工具或者甚至手画都行，关键是能直观地看出哪些资产是核心节点，哪些是边缘节点。核心节点通常是那些被多个APP共用的接口域名，边缘节点则是只在一个APP里出现的。

6. 常见问题与排查技巧实录

6.1 反编译失败或代码混淆严重怎么办

反编译失败通常有两种情况：一种是APK本身做了加固，dex文件被加密了；另一种是代码混淆严重，反编译出来的变量名全是a、b、c。加固的情况需要先脱壳，脱壳工具的选择取决于加固厂商，这个没有万能方案，需要根据实际情况尝试。混淆的情况相对好办，虽然变量名看不懂，但字符串常量通常不会被混淆，搜索URL和密钥依然有效。

我遇到过一个APP，代码混淆到连字符串都加密了，所有URL都是运行时动态拼接的。这种情况下静态分析基本失效，只能靠动态抓包。把APP跑起来，用中间人代理抓所有流量，从流量里提取接口地址。动态抓包虽然慢，但胜在真实，能拿到APP实际运行时的完整请求。

6.2 抓包抓不到数据或数据被加密

抓不到数据的原因很多，最常见的是证书绑定和双向认证。证书绑定可以通过hook框架绕过，双向认证则需要拿到客户端证书。还有一种情况是APP用了自定义的加密协议，流量虽然抓到了但内容是密文。这种情况下需要分析APP的加密逻辑，找到加密函数和密钥，才能解密流量。

排查思路是这样的：先确认代理是否生效，用浏览器访问一个HTTP网站看看能不能抓到。如果浏览器能抓但APP不能，那就是APP层面的问题。然后检查APP是否检测了代理设置，有些APP会检测系统代理并拒绝走代理。最后检查是否有证书绑定，用hook工具打印证书校验相关的调用栈。

6.3 资产关联时如何避免误报

网络空间测绘平台搜索出来的结果不一定都是目标的资产，同一个favicon可能被很多无关组织使用，同一个SSL证书也可能被多个组织共用。避免误报的关键是多重验证：不要只凭一个特征就下结论，至少要用两个以上独立特征交叉验证。

比如，通过SSL证书搜出来一批域名，我会逐个访问这些域名，看页面标题、看页面内容、看备案信息，确认是否与目标组织相关。如果页面标题是“XX管理系统”但内容完全无关，那大概率是误报。如果页面标题和内容都指向目标组织的业务，那基本可以确认。

6.4 独家避坑经验分享

第一个坑：不要忽略老版本APP。很多组织只维护最新版APP，老版本APP的接口服务器可能还在运行，但已经没人管了。这些老接口往往没有WAF保护，是很好的突破口。我的做法是把应用市场里所有历史版本都下载下来，逐个分析，对比接口变化。

第二个坑：不要只盯着主域名。APP里经常出现一些看起来像CDN或者第三方服务的域名，但仔细一看其实是组织自己的。比如img.xxx.com、static.xxx.com这种，很容易被当成CDN忽略掉，但实际上可能是组织自己的静态资源服务器，上面可能存着不该存的东西。

第三个坑：小程序的分包加载。有些小程序用了分包加载，主包很小，但分包里藏着核心逻辑。抓包的时候要注意把所有分包都下载下来，不要只看主包。微信开发者工具里可以查看分包结构，把每个分包都反编译一遍。

第四个坑：云存储的权限继承。对象存储的权限可以设置在桶级别，也可以设置在对象级别。有时候桶是私有的，但某个对象被单独设置成了公开，这种“漏网之鱼”用常规的桶列举发现不了，需要从APP或网站里提取具体的对象URL，然后逐个测试。

7. 把资产收集做成持续性的工作

信息收集不是一次性的任务，而是一个持续的过程。组织的资产在变，APP在更新，新的小程序在不断上线，今天收集到的资产地图，过三个月可能就过时了。我在实际工作中会把资产收集做成一个半自动化的流程：定期跑一遍应用市场搜索，定期抓包分析新版本APP，定期用测绘平台做关联搜索。

自动化能解决重复劳动，但判断和关联还是得靠人。工具能告诉你“这里有一个域名”，但判断这个域名是不是目标的、有没有价值，需要人的经验。我见过太多人把工具跑出来的结果直接当成结论，结果报告里一堆误报，反而掩盖了真正重要的发现。

最后分享一个我自己的小习惯：每次做完资产收集，我都会把整个过程和发现整理成一份内部笔记，记录哪些方法有效、哪些工具好用、哪些地方走了弯路。这份笔记积累下来，就是自己的经验库，下次遇到类似的目标，直接翻笔记就能快速上手。资产收集这件事，技术是一方面，经验的积累同样重要。