做移动端这行的几乎都撞上过同一个场景手头有个APP或者小程序要接手、要对标、要过一轮安全评审或者单纯想搞清楚它到底调了哪些接口、用了什么框架结果打开一看黑盒一个完全不知道从哪下手。这时候信息收集这四个字就冒出来了。它一点都不玄乎说白了就是把APP和小程序对外暴露的每一处痕迹先摸一遍——包名、签名、接口域名、备案主体、页面结构、请求参数、第三方SDK能拿到的先拿到、先归档。这件事做扎实了后面不管是开发联调、竞品拆解还是授权范围内的安全测试都能少走一大半弯路反过来跳过这一步直接上手改代码或者提测试结论基本都会返工。我把APP与小程序信息收集的完整思路拆开讲先讲清楚收集的到底是哪些维度再分两条线走——小程序这一侧从备案主体核对、AppID识别、代码包静态拆解到接口归集APP这一侧从静态解包、抓包环境搭建到抓包失败时一段一段排查。中间夹着工作机工具链的准备最后落到资产台账怎么落库、合规边界在哪。内容偏实操做移动端开发、测试、安全评审的朋友能直接用刚入门想系统练一遍的读者也能照着走。1. 先把收集什么想明白APP与小程序的暴露面清单1.1 一条主线客户端上能看见的全是资产很多人一上来就问工具抓包用什么、解包用什么其实工具是最不重要的那部分。真正决定效率的是清单——你脑子里得先有一张表知道自己要找什么工具只是帮你把表填满的手段。我一般把移动端信息收集的暴露面分成五层从外到内依次是分发层、载体层、代码层、通信层、服务层。分发层指的是应用市场里的公开信息APP 的名称、版本号历史、更新日志、下载量、开发者主体、隐私政策里列出的权限清单。小程序这一侧对应的是微信公众平台上的主体信息、备案信息、服务类目。这一层几乎零门槛全部公开可查但恰恰最容易被跳过而它提供的主体关联线索往往价值最高——同一个主体名下通常挂着十几款产品顺藤摸瓜能省掉大量时间。载体层是安装包本身或者小程序代码包本身包括包名、签名指纹、文件结构、资源目录。代码层是反解出来的源码、配置和硬编码字符串。通信层是请求域名、接口路径、请求头、签名算法、加密字段。服务层则是从接口反推出来的后台架构比如网关类型、鉴权方式、CDN 选型。这五层是一层层递进的越往后成本越高所以顺序不能乱先把便宜的做完再动贵的。1.2 APP和小程序在信息暴露上的三个本质差异同样是客户端APP 和小程序在能收集到什么这件事上差别很大搞混了会浪费不少功夫。第一个差异是包的可获取性。APP 的安装包你能直接从应用市场下下来是一个完整的 zip 结构解压就能看签名、清单、资源文件一览无余。小程序的代码包虽然也能拿到但路径藏在微信客户端的数据目录里安卓真机上通常需要系统级权限才能读PC 端虽然好拿一些但包体本身可能是加密的得先解密再解包链路明显更长。所以做小程序这一侧的时候一定要预留出拿包这一段的调试时间别指望十分钟搞定。第二个差异是框架的推断难度。APP 是原生、Flutter、React Native 还是 uni-app 打包的通过包结构和 so 库名字基本能一眼看出来。小程序的判断则要靠页面表现导航栏样式、返回按钮位置、页面切换的过渡动画、分包加载的报错文案都是指纹。举个例子一个小程序顶部导航栏的高度如果是动态计算的滚动时标题还会变化那大概率是自研导航栏而不是默认样式这种通常出现在 uni-app 或者 Taro 这类跨端框架的产物里。第三个差异是接口的规范化程度。APP 的接口往往因为多年迭代而显得杂乱同一个业务可能有三套命名风格小程序的接口一般集中在微信侧的统一域名下或者走一套比较规整的签名机制归集起来更省事但也更容易踩到签名校验的坑。理解这三个差异你就能给两条线分配不同的时间预算而不是拿一套方法论硬套。1.3 为什么这一步必须放在动手之前我见过太多人跳过信息收集直接开干结果三种典型翻车。第一种是开发联调时接口对不上前端按文档写完了真机一跑发现字段名和实际返回的完全不一样因为文档早就过期了实际接口只有抓出来才知道。第二种是做竞品拆解时下结论太早看到首页有个功能就以为对方重点在这块实际上人家的核心逻辑藏在二级页面里而这只有把代码包摊开看页面路由表才能发现。第三种最要命做安全评审时漏了资产审了APP忘了小程序而小程序往往因为赶工期、外包交付配置问题更多。信息收集的价值不在于我拿到了多少东西而在于我确认了自己没有盲区。这句话我在团队里反复讲。你手上那张表填满了后面的每一个动作才是有依据的表是空的后面全是猜。2. 小程序侧的信息收集从备案主体到代码包的四个动作2.1 主体与备案信息核对备注字段到底怎么写小程序的公开信息里主体和备案是最先要落下来的两块。主体信息在小程序的关于页面或者微信公众平台的主体信息页就能看到重点记四样东西运营主体的全称、统一社会信用代码后几位、主体的历史更名记录、以及主体名下的其他小程序。最后这一项经常被忽略但它是横向扩展资产最有效的入口。备案这一侧很多人卡在备注字段不知道该写什么提交后被驳回改来改去。我的经验是备注别写空话写清楚谁在用、用来干嘛、面向谁。比如一个内部工具类小程序备注可以写成本小程序为主体自营的内部办公流程查询工具仅面向本单位在职员工使用不对外提供注册。这么写的逻辑是审核关注的是这个小程序的真实用途和受众范围你把这两件事讲明白比写一堆形容词有用得多。反过来如果备注只写业务需要那是给自己找麻烦大概率要补材料。还有几个填写的细节容易出错。负责人信息最好和主体的实际经办人一致手机号要能接通因为备案过程中会有核验环节。服务类目不要贪多选和小程序实际功能最贴合的选多了反而会引发对功能范围的追问。备案通过之后再改主体信息是要重新走流程的所以这一步在立项阶段就该确认清楚别等上线前才发现主体填错。2.2 AppID、页面结构和UI指纹三招判断技术栈AppID 是小程序的身份证格式是 wx 开头的一串字符在小程序的更多资料里能直接看到。拿到 AppID 之后第一件事是去公开渠道查一下它的版本记录和基础信息第二件事是把它作为这个资产的唯一主键记录下来后面所有信息都挂在它下面。判断技术栈有三招都是靠观察不需要任何工具。第一招看页面路径。在开发者工具或者真机调试里看页面栈如果路径形如 pages/index/index 这样规整的目录结构且分包配置清晰那多半是原生开发如果路径里出现了大量相似结构的页面而代码量很小那可能是模板生成或者低代码平台产物。第二招看导航栏行为。默认导航栏的标题是静态的页面切换时整条栏跟着页面一起动而自定义导航栏的小程序标题会随着页面内的状态动态变化滚动时还会出现透明度渐变。这个现象背后是框架在接管导航栏渲染把原本由宿主负责的部分挪到了业务代码里所以才会出现这种标题会变的特征。顶部导航栏的高度也常常是动态算出来的因为要兼容不同机型的刘海屏和胶囊按钮位置代码里通常会去取胶囊按钮的定位信息再反推栏高这种计算逻辑一旦出现就说明导航栏是自定义的。第三招看交互组件。以单选框为例原生小程序用的是内置的 radio 组件样式受平台统一控制各机型表现一致而跨端框架或者自研组件库往往会重写这一层你会看到选中态的颜色、圆角、动效和平台默认的不一样甚至在不同端微信内和外部浏览器表现不同。这些细节单看一条都不足以定论但三招交叉验证基本不会判错。2.3 代码包拿到手之后静态拆解该看哪几处拿到代码包常见的后缀是 wxapkg之后先别急着反编译第一步是确认包有没有加密。PC 端通过微信下载的包有时是加密的直接解压会报错需要先用对应的解密手段处理手机端抓下来的包一般是明文可以直接处理。这一步判断错后面全是无用功所以先拿文本编辑器打开看看文件头是不是可读结构是最快的验证方式。解包之后代码目录里值得优先看的有四个位置。一是应用入口的配置文件里面写着所有页面的路由、窗口样式、分包配置这是整个小程序的骨架图看完就知道它有几个业务模块。二是主逻辑文件业务代码基本都在这一个或几个大文件里虽然变量名被混淆成了 a、b、c但字符串常量不会被混淆接口地址、参数名、状态码全都明晃晃地留在里面。三是工具目录请求封装、加密工具、鉴权逻辑通常都集中在这是理解通信层最快的入口。四是资源目录图片、字体、配置文件对应的业务含义有时候比代码更直白。混淆这件事要说清楚小程序发布时的代码压缩会把函数名变量名短化但不会动字符串字面量所以搜索关键字是最有效的定位手段。搜 request、搜 https://、搜 token、搜 sign你能在几分钟内把接口清单画出来。我个人习惯是先把所有出现过的域名去重列一遍再逐个看它对应的调用位置这样比从头读代码快得多。2.4 接口域名的归集从请求里反推后台架构域名归集完之后下一步是整理接口路径和请求特征。把同一个域名下的路径按前缀分组你会发现后台的设计习惯有的按业务域划分比如订单、用户、支付各自一个前缀有的按版本划分v1、v2 并存说明后台在灰度迁移。这两种风格对后续理解业务边界很有帮助。请求特征里有几个字段是重点。一是鉴权字段看一眼请求头里带的是长字符串还是短令牌能大致判断用的是会话还是令牌机制。二是签名参数如果出现 sign、timestamp、nonce 三个字段同时存在那基本可以确认有签名校验这时候要注意签名的版本不同版本的拼接口径不一样混用会导致请求被拒。三是加密字段如果请求体是一段没法直接读的密文那说明做了整体加密这种情况下接口层面的信息收集就要转向分析加密入口而不是逐个接口去猜。还有一类信息很值得记错误码。小程序的接口报错通常会带一个业务码和一句中文描述把这些错误码收集起来既能帮你理解业务的校验规则也能在后面对比同类产品时看出对方的业务约束有多严。比如登录相关的错误码如果分得特别细——账号不存在、密码错误、账号被锁定分别一个码——说明这套后台是经过业务打磨的反之只有一个笼统的失败码那多半是早期版本。3. APP侧的信息收集静态解包和动态抓包的完整链路3.1 静态视角清单文件、权限和硬编码APP 的静态收集从安装包开始。把后缀改成 zip 解压安卓侧重点看清单文件里面写明了包名、版本号、所有声明的权限、注册的组件和入口页。权限列表是判断这个 APP 性质最快的方式一个视频剪辑类 APP 请求相册和存储权限是合理的但如果它还请求了通讯录和短信权限那就要打个问号记进待确认清单。清单之外还有几处硬编码高发区。一是资源文件里的配置文件很多 APP 会把环境地址、第三方服务的密钥直接写在里面。二是 so 库库名字往往能暴露技术栈和第三方 SDK比如看到某个地图厂商的库名就知道它用了哪家的定位服务。三是字符串资源文件多语言文案里偶尔会残留开发期的测试地址或内部备注这种意外收获比你想象的多。签名指纹要单独记。安卓侧的签名是判断两个包是不是同一主体出的最硬的证据因为签名一旦变更老版本就无法覆盖安装。所以当你看到一个 APP 有多个渠道包时比对签名指纹就能确认它们是不是同一个来源。iOS 侧对应的是描述文件和证书信息能看出开发者账号类型、是否用了企业分发。3.2 动态视角抓包环境怎么搭才不会白忙静态能看到的是代码里写了什么动态能看到的是运行时真正发了什么两者必须对着看。搭环境这一步顺序很重要我按自己常用的流程走先确认抓包工具装在工作机上并能正常启动监听再把工作机的网络地址固定下来接着让手机和工作机处在同一个局域网最后把手机的网络转发指向工作机监听的端口。这里有几个细节决定成败。第一工作机的地址一定要固定别用自动获取因为手机端配置是写死的地址工作机地址一变就全废了。第二监听必须绑到所有网络接口上只绑本地回环的话手机根本连不上。第三工作机的防火墙要放行监听端口这是新手最容易卡住的地方表现为手机配置全对但一条请求都收不到关掉防火墙立刻就好。第四如果工作机上还跑着别的会接管网络的软件记得先停掉否则流量会被别的程序抢走。证书这一步是分水岭。安卓从 7.0 开始用户手动安装的证书默认不被应用信任只信任系统级证书。所以如果你的测试机是高版本安卓直接把证书装成用户证书会看到所有请求都是加密的乱码或者干脆连不上。解决办法有两个方向一是用低版本安卓的模拟器用户证书仍然被信任二是把证书装进系统证书目录但这需要设备有相应权限。选哪条路取决于你的场景如果只是自己开发联调模拟器完全够用如果是真机才能复现的问题那就得提前准备好环境。3.3 抓包失败的排查链路从手机到工具逐段验证抓包失败是所有做移动端的人都躲不过的坎关键不是找人问答案而是掌握一段一段验证的方法。我把自己的排查顺序完整写出来你可以照着走。第一步验证链路通不通。在工作机上用浏览器访问一个外部地址正常说明工作机网络没问题。然后在手机上打开浏览器随便访问一个网页如果抓包工具里能看到这条浏览器的请求说明手机到工作机的转发链路是通的问题出在 APP 本身如果浏览器的请求也看不到那问题就在网络配置上先去查地址、端口、防火墙这三样。第二步区分是没流量还是流量看不懂。没流量指的是抓包工具里完全没有记录这通常是网络配置问题。流量看不懂指的是有记录但内容是密文这就是证书的问题回到上一节的解决办法。这两类问题的处理方向完全不同先分清再动手。第三步看是不是证书固定。有些 APP 会在代码里内置对特定证书的校验普通的抓包方式即使证书装对了也拿不到明文表现为握手阶段就断开或者直接提示网络异常。判断的方法是用浏览器访问同一个域名能正常看到明文但 APP 访问同一个域名不行那基本可以确认。遇到这种情况首先要确认自己是否有相应授权没有授权就到此为止这是原则问题不是技术问题。第四步看协议类型。现在不少 APP 走的是基于 UDP 的传输协议或者 HTTP/2部分抓包工具默认不解析或者干脆不展示表现为有连接但没有可读内容。这时候需要在工具里确认协议解析设置或者换一个默认支持更全的工具。第五步看有没有双向认证服务端要求客户端出示证书的场景在金融类 APP 里很常见这种确实收不到明文属于设计如此不要在这上面耗时间。这套排查走下来八成问题能定位。剩下两成往往是环境玄学比如手机装了某个会接管网络的工具、局域网有隔离策略、或者工作机上同时跑着两个监听同一端口的程序。遇到玄学我的习惯是全部推倒重来用最小环境验证一遍比逐个猜测快得多。3.4 蓝牙与IoT类APP多出来的一条通信链路如果你的目标 APP 是控制硬件的那一类比如通过蓝牙控制开发板、智能家居设备那信息收集就多了一条链路。这类 APP 的通信不经过网络抓包工具看不到得用专门的蓝牙调试手段或者干脆看代码里的协议定义。代码侧能找到的东西其实不少蓝牙服务的 UUID、特征值的读写权限、指令的字节结构、校验方式这些在反解后的代码里通常以常量数组的形式出现很好识别。指令结构一般是帧头 命令字 数据 校验 帧尾找到帧头和校验算法整个协议就通了。这类项目的坑在于不同固件版本的协议可能不一样所以收集到的协议信息一定要标注对应的 APP 版本号否则半年后回看你会分不清手上的协议是哪一版。另外这类 APP 的权限声明通常比较特殊蓝牙权限、位置权限低版本安卓扫描蓝牙需要位置权限往往同时出现这本身就是一个识别特征。看到这个组合基本可以判断它有硬件交互功能收集时记得把这一项单独列出来。4. 工作机环境工具链准备和那几个反复踩的坑4.1 Windows主机上的工具链清单与版本选择信息收集这件事工作机环境的稳定性直接决定效率。我在 Windows 上固定了一套组合讲一下每一项为什么选它。抓包工具我用两个搭配一个界面友好、看请求直观的用于日常浏览和快速定位一个命令行、可编程的用于批量处理和写脚本。为什么不用一个因为图形化工具在请求量大时会卡几百条请求刷起来就很难受而命令行工具写过滤规则、导出结构化数据特别顺手两者互补。导出格式统一选 JSON后面做台账的时候能直接导入省掉手工录入。证书工具要单独准备。抓包工具的证书不是装一次就永久有效的过期或者换了工具都要重装所以工作机上最好固定一个目录存证书文件名标注清楚生成日期和来源别出现到底该装哪一个的困惑。解包和反解工具要选维护活跃的。这类工具更新频率高因为被分析的对象格式一直在变一个两年没更新的工具遇到新版本的包大概率报错。选择标准很简单看最近半年有没有版本更新看 issue 区有没有人反馈新版本包无法处理。这个判断比看 star 数可靠得多。还有一类容易被忽略的是开发侧工具链。安卓侧的构建工具、小程序侧的编辑器它们在构建过程中本身就会产出大量信息比如依赖版本、编译配置、环境变量。如果你分析的是自己团队的项目这些信息直接从工程里拿比从安装包里反推准确得多。有些工程在启动小程序调试时会报登录用户不是该小程序的开发者这不是信息收集的问题而是账号权限没配去公众平台把开发者账号加上就行别在这个报错上浪费时间。4.2 模拟器还是真机取舍标准和实测差异这个问题没有标准答案取决于你要收集什么。模拟器的优势是环境可控、可随时重置、能装低版本系统做证书相关的事情特别方便劣势是部分 APP 会检测运行环境检测到模拟器就改变行为甚至直接退出这种情况下你在模拟器里收集到的信息就是不完整的。真机的优势是行为真实能复现所有机型相关问题劣势是环境搭建麻烦尤其是高版本安卓的证书问题。我的做法是两条腿走基础信息收集、接口清单整理用模拟器快且可重复涉及具体功能验证、性能表现、异常复现的场景用真机。如果两边结果不一致以真机为准因为最终用户用的是真机。还有一点要注意模拟器和真机的网络环境可能不一样。有些模拟器默认走的是宿主机的网络栈有些走的是虚拟网络导致手机端配置的那个地址在模拟器里不生效。这个坑很隐蔽表现为在真机上配置正确的方法在模拟器里完全失效排查半天才发现是网络栈不同。所以每次换环境第一件事都是先用浏览器验证链路别直接上目标应用。4.3 证书与网络环境的隐形坑证书这块有几个反复踩的坑我集中列一下。第一个坑是证书装错位置。安卓的证书分用户证书和系统证书两类装到用户目录里高版本系统下应用不信任。用模拟器的话选低版本系统能规避这个问题但要注意低版本系统在别的方面可能有限制比如不支持某些新特性出现异常时先想想是不是版本问题。第二个坑是系统时间不准。证书校验依赖时间如果设备时间偏差太大证书会被判为未生效或已过期表现为所有请求都失败。这个坑特别容易在虚拟机上出现因为虚拟机暂停恢复后时间会漂移。养成习惯遇到昨天还好今天全废的情况先看时间。第三个坑是局域网隔离。很多办公网络开启了客户端隔离同一个无线网络下的设备之间不能互相通信这就导致手机和工作机明明在同一个网络却连不上。判断方法是用手机 ping 一下工作机地址不通就是被隔离了。解决办法是换网络或者用工作机开热点让手机连后者更方便也更可控。第四个坑是工作机上有多个网络接口。笔记本同时连着有线和无线的时候监听服务可能只绑在其中一个接口上而手机访问的是另一个接口的地址自然连不上。解决办法是手动指定监听所有接口或者干脆禁掉不用的那个。这类问题没有技术含量但排查起来最耗时间所以环境准备好了之后先做一次完整验证再开始正式工作。5. 收集完之后资产台账怎么落库合规边界在哪5.1 台账字段设计让信息能被复用而不是堆着信息收集最大的浪费不是没收全而是收完就散在十几个文档和聊天记录里下次要用的时候找不到。所以台账这件事必须在收集过程中同步做不能等收完了再补。我的台账字段是这么设计的。主键用应用标识APP 用包名小程序用 AppID保证唯一。基础信息包括名称、所属主体、版本号、收集日期、收集人。技术信息包括框架类型、签名指纹、清单中的权限列表、第三方 SDK 清单。接口信息包括域名清单、关键接口路径、鉴权方式、签名版本。最后留一列备注写那些暂时解释不了但值得记一笔的观察。有两个设计细节很关键。一是必须记录收集日期因为技术信息是有时效的半年后的框架判断可能就不成立了标注日期能避免误用。二是必须记录来源和方式静态解出来的和抓包抓到的可信度不一样混在一起会让后面的人误判。我见过因为没标来源把一个测出来的推断当成确定事实写进方案最后返工的案例。5.2 去重与关联把APP和小程序串成一张图单个资产的信息收集完成之后最有价值的一步是做关联。同一个主体名下的 APP 和小程序往往会共用后台服务接口域名会有重叠SDK 选型也会趋于一致。把这些重叠点标出来你就能用一款产品的分析结果去快速验证另一款效率能提升好几倍。关联的抓手有三个。第一个是主体从公开的主体信息出发把同名下的产品列出来。第二个是域名把收集到的域名做交叉比对共用的域名就是共用后台的证据。第三个是签名和证书安卓签名一致说明是同一个开发主体接口证书一致说明是同一套服务端。这三个抓手交叉使用能画出一张相当准确的产品关系图。去重的时候要注意一个陷阱域名看起来一样不代表服务一样。同一个一级域名下不同路径前缀可能指向完全不同的后台系统甚至不同的机房。所以去重的粒度要落到域名 路径前缀这一层只按一级域名去重会丢掉重要信息。反过来域名不同也不代表服务不同CDN 场景下同一个服务可能有多个域名这时候要靠接口返回的结构特征来判断——返回同样的错误码格式、同样的时间戳精度基本可以认定是同一套系统。5.3 合规边界哪些能收哪些必须停手这一节我想单独讲因为它比前面所有技术细节都重要。信息收集这件事有一个前提你分析的对象必须是你自己的或者你获得了明确授权的。自己团队开发的产品随便看这是本职工作。给客户做服务要有书面授权写清楚范围是哪些应用、哪些环境、什么时间段。参加公开的测试项目要严格按照项目声明的规则来规则说不允许的就不做。在这个前提下还有几条线不能越。不要对非授权目标做任何形式的技术分析哪怕只是看看。不要把收集到的接口信息、密钥信息用于授权范围之外的任何用途。不要在分析过程中对目标服务造成压力比如高频请求、批量探测这些行为即使出于好意也可能造成实际影响。另外有一条经常被忽略收集到的数据本身要管好。台账里可能有接口地址、内部字段名、错误码这些东西在你手里是分析材料泄露出去就可能是风险。所以台账要放在受控的位置共享范围要有边界项目结束后该清理的清理。我个人的习惯是每个项目一个独立目录结项时统一归档不留散落在桌面上的中间文件。从技术角度讲能收集和该收集是两回事。技术上能拿到的信息如果和当前任务无关我建议不拿——不是因为拿不到而是因为多拿一份数据就多一份保管责任。明确知道自己要解决什么问题只收集与之相关的信息这既是效率也是纪律。最后分享一个我踩过好几次坑才养成的习惯每次开始一个新目标的信息收集先用五分钟写下来三个问题的答案——我要解决什么问题、我能收集的范围边界在哪、我打算产出什么形式的结果。这三个问题写不出来的话先别打开工具。我试过几次脑子一热就上手最后收了一堆数据整理的时候才发现八成和自己的目标没关系白忙一场。先把目标写清楚再让工具上场这个顺序换不得。
APP与小程序信息收集全链路：静态解包、动态抓包与资产台账
做移动端这行的几乎都撞上过同一个场景手头有个APP或者小程序要接手、要对标、要过一轮安全评审或者单纯想搞清楚它到底调了哪些接口、用了什么框架结果打开一看黑盒一个完全不知道从哪下手。这时候信息收集这四个字就冒出来了。它一点都不玄乎说白了就是把APP和小程序对外暴露的每一处痕迹先摸一遍——包名、签名、接口域名、备案主体、页面结构、请求参数、第三方SDK能拿到的先拿到、先归档。这件事做扎实了后面不管是开发联调、竞品拆解还是授权范围内的安全测试都能少走一大半弯路反过来跳过这一步直接上手改代码或者提测试结论基本都会返工。我把APP与小程序信息收集的完整思路拆开讲先讲清楚收集的到底是哪些维度再分两条线走——小程序这一侧从备案主体核对、AppID识别、代码包静态拆解到接口归集APP这一侧从静态解包、抓包环境搭建到抓包失败时一段一段排查。中间夹着工作机工具链的准备最后落到资产台账怎么落库、合规边界在哪。内容偏实操做移动端开发、测试、安全评审的朋友能直接用刚入门想系统练一遍的读者也能照着走。1. 先把收集什么想明白APP与小程序的暴露面清单1.1 一条主线客户端上能看见的全是资产很多人一上来就问工具抓包用什么、解包用什么其实工具是最不重要的那部分。真正决定效率的是清单——你脑子里得先有一张表知道自己要找什么工具只是帮你把表填满的手段。我一般把移动端信息收集的暴露面分成五层从外到内依次是分发层、载体层、代码层、通信层、服务层。分发层指的是应用市场里的公开信息APP 的名称、版本号历史、更新日志、下载量、开发者主体、隐私政策里列出的权限清单。小程序这一侧对应的是微信公众平台上的主体信息、备案信息、服务类目。这一层几乎零门槛全部公开可查但恰恰最容易被跳过而它提供的主体关联线索往往价值最高——同一个主体名下通常挂着十几款产品顺藤摸瓜能省掉大量时间。载体层是安装包本身或者小程序代码包本身包括包名、签名指纹、文件结构、资源目录。代码层是反解出来的源码、配置和硬编码字符串。通信层是请求域名、接口路径、请求头、签名算法、加密字段。服务层则是从接口反推出来的后台架构比如网关类型、鉴权方式、CDN 选型。这五层是一层层递进的越往后成本越高所以顺序不能乱先把便宜的做完再动贵的。1.2 APP和小程序在信息暴露上的三个本质差异同样是客户端APP 和小程序在能收集到什么这件事上差别很大搞混了会浪费不少功夫。第一个差异是包的可获取性。APP 的安装包你能直接从应用市场下下来是一个完整的 zip 结构解压就能看签名、清单、资源文件一览无余。小程序的代码包虽然也能拿到但路径藏在微信客户端的数据目录里安卓真机上通常需要系统级权限才能读PC 端虽然好拿一些但包体本身可能是加密的得先解密再解包链路明显更长。所以做小程序这一侧的时候一定要预留出拿包这一段的调试时间别指望十分钟搞定。第二个差异是框架的推断难度。APP 是原生、Flutter、React Native 还是 uni-app 打包的通过包结构和 so 库名字基本能一眼看出来。小程序的判断则要靠页面表现导航栏样式、返回按钮位置、页面切换的过渡动画、分包加载的报错文案都是指纹。举个例子一个小程序顶部导航栏的高度如果是动态计算的滚动时标题还会变化那大概率是自研导航栏而不是默认样式这种通常出现在 uni-app 或者 Taro 这类跨端框架的产物里。第三个差异是接口的规范化程度。APP 的接口往往因为多年迭代而显得杂乱同一个业务可能有三套命名风格小程序的接口一般集中在微信侧的统一域名下或者走一套比较规整的签名机制归集起来更省事但也更容易踩到签名校验的坑。理解这三个差异你就能给两条线分配不同的时间预算而不是拿一套方法论硬套。1.3 为什么这一步必须放在动手之前我见过太多人跳过信息收集直接开干结果三种典型翻车。第一种是开发联调时接口对不上前端按文档写完了真机一跑发现字段名和实际返回的完全不一样因为文档早就过期了实际接口只有抓出来才知道。第二种是做竞品拆解时下结论太早看到首页有个功能就以为对方重点在这块实际上人家的核心逻辑藏在二级页面里而这只有把代码包摊开看页面路由表才能发现。第三种最要命做安全评审时漏了资产审了APP忘了小程序而小程序往往因为赶工期、外包交付配置问题更多。信息收集的价值不在于我拿到了多少东西而在于我确认了自己没有盲区。这句话我在团队里反复讲。你手上那张表填满了后面的每一个动作才是有依据的表是空的后面全是猜。2. 小程序侧的信息收集从备案主体到代码包的四个动作2.1 主体与备案信息核对备注字段到底怎么写小程序的公开信息里主体和备案是最先要落下来的两块。主体信息在小程序的关于页面或者微信公众平台的主体信息页就能看到重点记四样东西运营主体的全称、统一社会信用代码后几位、主体的历史更名记录、以及主体名下的其他小程序。最后这一项经常被忽略但它是横向扩展资产最有效的入口。备案这一侧很多人卡在备注字段不知道该写什么提交后被驳回改来改去。我的经验是备注别写空话写清楚谁在用、用来干嘛、面向谁。比如一个内部工具类小程序备注可以写成本小程序为主体自营的内部办公流程查询工具仅面向本单位在职员工使用不对外提供注册。这么写的逻辑是审核关注的是这个小程序的真实用途和受众范围你把这两件事讲明白比写一堆形容词有用得多。反过来如果备注只写业务需要那是给自己找麻烦大概率要补材料。还有几个填写的细节容易出错。负责人信息最好和主体的实际经办人一致手机号要能接通因为备案过程中会有核验环节。服务类目不要贪多选和小程序实际功能最贴合的选多了反而会引发对功能范围的追问。备案通过之后再改主体信息是要重新走流程的所以这一步在立项阶段就该确认清楚别等上线前才发现主体填错。2.2 AppID、页面结构和UI指纹三招判断技术栈AppID 是小程序的身份证格式是 wx 开头的一串字符在小程序的更多资料里能直接看到。拿到 AppID 之后第一件事是去公开渠道查一下它的版本记录和基础信息第二件事是把它作为这个资产的唯一主键记录下来后面所有信息都挂在它下面。判断技术栈有三招都是靠观察不需要任何工具。第一招看页面路径。在开发者工具或者真机调试里看页面栈如果路径形如 pages/index/index 这样规整的目录结构且分包配置清晰那多半是原生开发如果路径里出现了大量相似结构的页面而代码量很小那可能是模板生成或者低代码平台产物。第二招看导航栏行为。默认导航栏的标题是静态的页面切换时整条栏跟着页面一起动而自定义导航栏的小程序标题会随着页面内的状态动态变化滚动时还会出现透明度渐变。这个现象背后是框架在接管导航栏渲染把原本由宿主负责的部分挪到了业务代码里所以才会出现这种标题会变的特征。顶部导航栏的高度也常常是动态算出来的因为要兼容不同机型的刘海屏和胶囊按钮位置代码里通常会去取胶囊按钮的定位信息再反推栏高这种计算逻辑一旦出现就说明导航栏是自定义的。第三招看交互组件。以单选框为例原生小程序用的是内置的 radio 组件样式受平台统一控制各机型表现一致而跨端框架或者自研组件库往往会重写这一层你会看到选中态的颜色、圆角、动效和平台默认的不一样甚至在不同端微信内和外部浏览器表现不同。这些细节单看一条都不足以定论但三招交叉验证基本不会判错。2.3 代码包拿到手之后静态拆解该看哪几处拿到代码包常见的后缀是 wxapkg之后先别急着反编译第一步是确认包有没有加密。PC 端通过微信下载的包有时是加密的直接解压会报错需要先用对应的解密手段处理手机端抓下来的包一般是明文可以直接处理。这一步判断错后面全是无用功所以先拿文本编辑器打开看看文件头是不是可读结构是最快的验证方式。解包之后代码目录里值得优先看的有四个位置。一是应用入口的配置文件里面写着所有页面的路由、窗口样式、分包配置这是整个小程序的骨架图看完就知道它有几个业务模块。二是主逻辑文件业务代码基本都在这一个或几个大文件里虽然变量名被混淆成了 a、b、c但字符串常量不会被混淆接口地址、参数名、状态码全都明晃晃地留在里面。三是工具目录请求封装、加密工具、鉴权逻辑通常都集中在这是理解通信层最快的入口。四是资源目录图片、字体、配置文件对应的业务含义有时候比代码更直白。混淆这件事要说清楚小程序发布时的代码压缩会把函数名变量名短化但不会动字符串字面量所以搜索关键字是最有效的定位手段。搜 request、搜 https://、搜 token、搜 sign你能在几分钟内把接口清单画出来。我个人习惯是先把所有出现过的域名去重列一遍再逐个看它对应的调用位置这样比从头读代码快得多。2.4 接口域名的归集从请求里反推后台架构域名归集完之后下一步是整理接口路径和请求特征。把同一个域名下的路径按前缀分组你会发现后台的设计习惯有的按业务域划分比如订单、用户、支付各自一个前缀有的按版本划分v1、v2 并存说明后台在灰度迁移。这两种风格对后续理解业务边界很有帮助。请求特征里有几个字段是重点。一是鉴权字段看一眼请求头里带的是长字符串还是短令牌能大致判断用的是会话还是令牌机制。二是签名参数如果出现 sign、timestamp、nonce 三个字段同时存在那基本可以确认有签名校验这时候要注意签名的版本不同版本的拼接口径不一样混用会导致请求被拒。三是加密字段如果请求体是一段没法直接读的密文那说明做了整体加密这种情况下接口层面的信息收集就要转向分析加密入口而不是逐个接口去猜。还有一类信息很值得记错误码。小程序的接口报错通常会带一个业务码和一句中文描述把这些错误码收集起来既能帮你理解业务的校验规则也能在后面对比同类产品时看出对方的业务约束有多严。比如登录相关的错误码如果分得特别细——账号不存在、密码错误、账号被锁定分别一个码——说明这套后台是经过业务打磨的反之只有一个笼统的失败码那多半是早期版本。3. APP侧的信息收集静态解包和动态抓包的完整链路3.1 静态视角清单文件、权限和硬编码APP 的静态收集从安装包开始。把后缀改成 zip 解压安卓侧重点看清单文件里面写明了包名、版本号、所有声明的权限、注册的组件和入口页。权限列表是判断这个 APP 性质最快的方式一个视频剪辑类 APP 请求相册和存储权限是合理的但如果它还请求了通讯录和短信权限那就要打个问号记进待确认清单。清单之外还有几处硬编码高发区。一是资源文件里的配置文件很多 APP 会把环境地址、第三方服务的密钥直接写在里面。二是 so 库库名字往往能暴露技术栈和第三方 SDK比如看到某个地图厂商的库名就知道它用了哪家的定位服务。三是字符串资源文件多语言文案里偶尔会残留开发期的测试地址或内部备注这种意外收获比你想象的多。签名指纹要单独记。安卓侧的签名是判断两个包是不是同一主体出的最硬的证据因为签名一旦变更老版本就无法覆盖安装。所以当你看到一个 APP 有多个渠道包时比对签名指纹就能确认它们是不是同一个来源。iOS 侧对应的是描述文件和证书信息能看出开发者账号类型、是否用了企业分发。3.2 动态视角抓包环境怎么搭才不会白忙静态能看到的是代码里写了什么动态能看到的是运行时真正发了什么两者必须对着看。搭环境这一步顺序很重要我按自己常用的流程走先确认抓包工具装在工作机上并能正常启动监听再把工作机的网络地址固定下来接着让手机和工作机处在同一个局域网最后把手机的网络转发指向工作机监听的端口。这里有几个细节决定成败。第一工作机的地址一定要固定别用自动获取因为手机端配置是写死的地址工作机地址一变就全废了。第二监听必须绑到所有网络接口上只绑本地回环的话手机根本连不上。第三工作机的防火墙要放行监听端口这是新手最容易卡住的地方表现为手机配置全对但一条请求都收不到关掉防火墙立刻就好。第四如果工作机上还跑着别的会接管网络的软件记得先停掉否则流量会被别的程序抢走。证书这一步是分水岭。安卓从 7.0 开始用户手动安装的证书默认不被应用信任只信任系统级证书。所以如果你的测试机是高版本安卓直接把证书装成用户证书会看到所有请求都是加密的乱码或者干脆连不上。解决办法有两个方向一是用低版本安卓的模拟器用户证书仍然被信任二是把证书装进系统证书目录但这需要设备有相应权限。选哪条路取决于你的场景如果只是自己开发联调模拟器完全够用如果是真机才能复现的问题那就得提前准备好环境。3.3 抓包失败的排查链路从手机到工具逐段验证抓包失败是所有做移动端的人都躲不过的坎关键不是找人问答案而是掌握一段一段验证的方法。我把自己的排查顺序完整写出来你可以照着走。第一步验证链路通不通。在工作机上用浏览器访问一个外部地址正常说明工作机网络没问题。然后在手机上打开浏览器随便访问一个网页如果抓包工具里能看到这条浏览器的请求说明手机到工作机的转发链路是通的问题出在 APP 本身如果浏览器的请求也看不到那问题就在网络配置上先去查地址、端口、防火墙这三样。第二步区分是没流量还是流量看不懂。没流量指的是抓包工具里完全没有记录这通常是网络配置问题。流量看不懂指的是有记录但内容是密文这就是证书的问题回到上一节的解决办法。这两类问题的处理方向完全不同先分清再动手。第三步看是不是证书固定。有些 APP 会在代码里内置对特定证书的校验普通的抓包方式即使证书装对了也拿不到明文表现为握手阶段就断开或者直接提示网络异常。判断的方法是用浏览器访问同一个域名能正常看到明文但 APP 访问同一个域名不行那基本可以确认。遇到这种情况首先要确认自己是否有相应授权没有授权就到此为止这是原则问题不是技术问题。第四步看协议类型。现在不少 APP 走的是基于 UDP 的传输协议或者 HTTP/2部分抓包工具默认不解析或者干脆不展示表现为有连接但没有可读内容。这时候需要在工具里确认协议解析设置或者换一个默认支持更全的工具。第五步看有没有双向认证服务端要求客户端出示证书的场景在金融类 APP 里很常见这种确实收不到明文属于设计如此不要在这上面耗时间。这套排查走下来八成问题能定位。剩下两成往往是环境玄学比如手机装了某个会接管网络的工具、局域网有隔离策略、或者工作机上同时跑着两个监听同一端口的程序。遇到玄学我的习惯是全部推倒重来用最小环境验证一遍比逐个猜测快得多。3.4 蓝牙与IoT类APP多出来的一条通信链路如果你的目标 APP 是控制硬件的那一类比如通过蓝牙控制开发板、智能家居设备那信息收集就多了一条链路。这类 APP 的通信不经过网络抓包工具看不到得用专门的蓝牙调试手段或者干脆看代码里的协议定义。代码侧能找到的东西其实不少蓝牙服务的 UUID、特征值的读写权限、指令的字节结构、校验方式这些在反解后的代码里通常以常量数组的形式出现很好识别。指令结构一般是帧头 命令字 数据 校验 帧尾找到帧头和校验算法整个协议就通了。这类项目的坑在于不同固件版本的协议可能不一样所以收集到的协议信息一定要标注对应的 APP 版本号否则半年后回看你会分不清手上的协议是哪一版。另外这类 APP 的权限声明通常比较特殊蓝牙权限、位置权限低版本安卓扫描蓝牙需要位置权限往往同时出现这本身就是一个识别特征。看到这个组合基本可以判断它有硬件交互功能收集时记得把这一项单独列出来。4. 工作机环境工具链准备和那几个反复踩的坑4.1 Windows主机上的工具链清单与版本选择信息收集这件事工作机环境的稳定性直接决定效率。我在 Windows 上固定了一套组合讲一下每一项为什么选它。抓包工具我用两个搭配一个界面友好、看请求直观的用于日常浏览和快速定位一个命令行、可编程的用于批量处理和写脚本。为什么不用一个因为图形化工具在请求量大时会卡几百条请求刷起来就很难受而命令行工具写过滤规则、导出结构化数据特别顺手两者互补。导出格式统一选 JSON后面做台账的时候能直接导入省掉手工录入。证书工具要单独准备。抓包工具的证书不是装一次就永久有效的过期或者换了工具都要重装所以工作机上最好固定一个目录存证书文件名标注清楚生成日期和来源别出现到底该装哪一个的困惑。解包和反解工具要选维护活跃的。这类工具更新频率高因为被分析的对象格式一直在变一个两年没更新的工具遇到新版本的包大概率报错。选择标准很简单看最近半年有没有版本更新看 issue 区有没有人反馈新版本包无法处理。这个判断比看 star 数可靠得多。还有一类容易被忽略的是开发侧工具链。安卓侧的构建工具、小程序侧的编辑器它们在构建过程中本身就会产出大量信息比如依赖版本、编译配置、环境变量。如果你分析的是自己团队的项目这些信息直接从工程里拿比从安装包里反推准确得多。有些工程在启动小程序调试时会报登录用户不是该小程序的开发者这不是信息收集的问题而是账号权限没配去公众平台把开发者账号加上就行别在这个报错上浪费时间。4.2 模拟器还是真机取舍标准和实测差异这个问题没有标准答案取决于你要收集什么。模拟器的优势是环境可控、可随时重置、能装低版本系统做证书相关的事情特别方便劣势是部分 APP 会检测运行环境检测到模拟器就改变行为甚至直接退出这种情况下你在模拟器里收集到的信息就是不完整的。真机的优势是行为真实能复现所有机型相关问题劣势是环境搭建麻烦尤其是高版本安卓的证书问题。我的做法是两条腿走基础信息收集、接口清单整理用模拟器快且可重复涉及具体功能验证、性能表现、异常复现的场景用真机。如果两边结果不一致以真机为准因为最终用户用的是真机。还有一点要注意模拟器和真机的网络环境可能不一样。有些模拟器默认走的是宿主机的网络栈有些走的是虚拟网络导致手机端配置的那个地址在模拟器里不生效。这个坑很隐蔽表现为在真机上配置正确的方法在模拟器里完全失效排查半天才发现是网络栈不同。所以每次换环境第一件事都是先用浏览器验证链路别直接上目标应用。4.3 证书与网络环境的隐形坑证书这块有几个反复踩的坑我集中列一下。第一个坑是证书装错位置。安卓的证书分用户证书和系统证书两类装到用户目录里高版本系统下应用不信任。用模拟器的话选低版本系统能规避这个问题但要注意低版本系统在别的方面可能有限制比如不支持某些新特性出现异常时先想想是不是版本问题。第二个坑是系统时间不准。证书校验依赖时间如果设备时间偏差太大证书会被判为未生效或已过期表现为所有请求都失败。这个坑特别容易在虚拟机上出现因为虚拟机暂停恢复后时间会漂移。养成习惯遇到昨天还好今天全废的情况先看时间。第三个坑是局域网隔离。很多办公网络开启了客户端隔离同一个无线网络下的设备之间不能互相通信这就导致手机和工作机明明在同一个网络却连不上。判断方法是用手机 ping 一下工作机地址不通就是被隔离了。解决办法是换网络或者用工作机开热点让手机连后者更方便也更可控。第四个坑是工作机上有多个网络接口。笔记本同时连着有线和无线的时候监听服务可能只绑在其中一个接口上而手机访问的是另一个接口的地址自然连不上。解决办法是手动指定监听所有接口或者干脆禁掉不用的那个。这类问题没有技术含量但排查起来最耗时间所以环境准备好了之后先做一次完整验证再开始正式工作。5. 收集完之后资产台账怎么落库合规边界在哪5.1 台账字段设计让信息能被复用而不是堆着信息收集最大的浪费不是没收全而是收完就散在十几个文档和聊天记录里下次要用的时候找不到。所以台账这件事必须在收集过程中同步做不能等收完了再补。我的台账字段是这么设计的。主键用应用标识APP 用包名小程序用 AppID保证唯一。基础信息包括名称、所属主体、版本号、收集日期、收集人。技术信息包括框架类型、签名指纹、清单中的权限列表、第三方 SDK 清单。接口信息包括域名清单、关键接口路径、鉴权方式、签名版本。最后留一列备注写那些暂时解释不了但值得记一笔的观察。有两个设计细节很关键。一是必须记录收集日期因为技术信息是有时效的半年后的框架判断可能就不成立了标注日期能避免误用。二是必须记录来源和方式静态解出来的和抓包抓到的可信度不一样混在一起会让后面的人误判。我见过因为没标来源把一个测出来的推断当成确定事实写进方案最后返工的案例。5.2 去重与关联把APP和小程序串成一张图单个资产的信息收集完成之后最有价值的一步是做关联。同一个主体名下的 APP 和小程序往往会共用后台服务接口域名会有重叠SDK 选型也会趋于一致。把这些重叠点标出来你就能用一款产品的分析结果去快速验证另一款效率能提升好几倍。关联的抓手有三个。第一个是主体从公开的主体信息出发把同名下的产品列出来。第二个是域名把收集到的域名做交叉比对共用的域名就是共用后台的证据。第三个是签名和证书安卓签名一致说明是同一个开发主体接口证书一致说明是同一套服务端。这三个抓手交叉使用能画出一张相当准确的产品关系图。去重的时候要注意一个陷阱域名看起来一样不代表服务一样。同一个一级域名下不同路径前缀可能指向完全不同的后台系统甚至不同的机房。所以去重的粒度要落到域名 路径前缀这一层只按一级域名去重会丢掉重要信息。反过来域名不同也不代表服务不同CDN 场景下同一个服务可能有多个域名这时候要靠接口返回的结构特征来判断——返回同样的错误码格式、同样的时间戳精度基本可以认定是同一套系统。5.3 合规边界哪些能收哪些必须停手这一节我想单独讲因为它比前面所有技术细节都重要。信息收集这件事有一个前提你分析的对象必须是你自己的或者你获得了明确授权的。自己团队开发的产品随便看这是本职工作。给客户做服务要有书面授权写清楚范围是哪些应用、哪些环境、什么时间段。参加公开的测试项目要严格按照项目声明的规则来规则说不允许的就不做。在这个前提下还有几条线不能越。不要对非授权目标做任何形式的技术分析哪怕只是看看。不要把收集到的接口信息、密钥信息用于授权范围之外的任何用途。不要在分析过程中对目标服务造成压力比如高频请求、批量探测这些行为即使出于好意也可能造成实际影响。另外有一条经常被忽略收集到的数据本身要管好。台账里可能有接口地址、内部字段名、错误码这些东西在你手里是分析材料泄露出去就可能是风险。所以台账要放在受控的位置共享范围要有边界项目结束后该清理的清理。我个人的习惯是每个项目一个独立目录结项时统一归档不留散落在桌面上的中间文件。从技术角度讲能收集和该收集是两回事。技术上能拿到的信息如果和当前任务无关我建议不拿——不是因为拿不到而是因为多拿一份数据就多一份保管责任。明确知道自己要解决什么问题只收集与之相关的信息这既是效率也是纪律。最后分享一个我踩过好几次坑才养成的习惯每次开始一个新目标的信息收集先用五分钟写下来三个问题的答案——我要解决什么问题、我能收集的范围边界在哪、我打算产出什么形式的结果。这三个问题写不出来的话先别打开工具。我试过几次脑子一热就上手最后收了一堆数据整理的时候才发现八成和自己的目标没关系白忙一场。先把目标写清楚再让工具上场这个顺序换不得。
