做移动端安全和逆向的兄弟十有八九都在抓包工具上栽过跟头。电脑里Charles开得好好的手机也装好了证书Wi-Fi配置里手动填了电脑IP和监听端口可一打开目标AppCharles上只有稀稀拉拉几个CONNECT真正的业务请求全都不见踪影。我之前分析猫眼这类影视票务App时就踩过这个坑折腾了大半天才发现问题不在证书而在流量根本没走到Charles这边来。这篇文章就围绕Android逆向里的高频场景——用Charles配合Drony做定向流量转发解决不走系统默认通道的App抓包问题并以猫眼App为例把完整思路和操作细节讲明白。适合正在学移动安全逆向、或者调试自研App时被抓包卡住的开发者参考。所有方法请务必放在自有设备或已授权环境里使用别去动那些没有授权的线上服务。1. 为什么你的Charles抓不到猫眼App的流量1.1 Charles抓HTTPS的底层逻辑Charles表面上是个抓包工具本质上是一个位于客户端与服务器之间的中间人。手机流量到Charles这里时Charles自己扮演服务器对真正的服务器来说Charles又扮演客户端。原本一条直连的HTTPS通路被拆成了两段独立会话。关键点在于证书。手机连上Charles后App发出请求Charles不直接转发而是先和真实服务器完成握手拿到服务器证书后立刻伪造一张同名证书返回给手机端。手机上的App要是信任了Charles的根证书就会和Charles完成TLS握手Charles再和服务器完成另一段TLS握手。两边都是HTTPS但Charles同时掌握两段会话的密钥所以它能解密看到明文请求和响应。这个机制依赖一个前提App发出的流量必须经过Charles。对普通App来说只要系统网络栈读取了Wi-Fi里配置的HTTP中继设置流量自然就被转发到Charles。Android上基于OkHttp、Volley等标准网络库开发的应用默认会遵守系统中继设置所以很多App一次就能抓到。可猫眼这类大厂App往往不走寻常路问题就出在这里。1.2 猫眼这类App为什么不走系统默认通道我分析猫眼App时发现它的很多请求压根不走系统网络栈的默认中继。原因通常有两个层面。第一是自研网络层。部分请求会用自研的Socket通道直接建立TCP连接或者使用非标准端口系统Wi-Fi里的HTTP中继设置对这种连接不起作用。第二是证书绑定SSL Pinning。猫眼App在客户端内置了服务端证书的公钥或哈希值白名单握手时如果发现返回的证书不在白名单里直接断开连接。所以就算你把Charles根证书装进手机它也不认。它为啥要这么做一方面是安全考虑防止中间人攻击和数据篡改另一方面也有反爬、防刷单、防接口被批量扒取的现实需求。对做安全测试和逆向分析的人而言理解这种机制是基本功毕竟只有先弄懂对手怎么设防才能知道自己的防护哪里薄弱。1.3 流量进不来和证书解不开要分清很多兄弟一上来就折腾证书其实证书是解密环节的问题而流量能不能到Charles是更前置的问题。用Charles抓不到App数据要先判断卡在哪一环。现象问题环节方向Charles里连CONNECT记录都没有流量路由想办法让App流量经过Charles比如用Drony有CONNECT但握手失败或证书错误证书信任解决用户证书信任、系统证书安装、SSL Pinning请求出现在SSL Proxy列表但内容是乱码解密配置检查SSL Proxying是否开启目标域名和端口是否覆盖这两个问题得分开排查混在一起只会越调越乱。我自己排查的顺序是先看流量是否到达Charles再处理解密问题。2. Drony在整套方案里扮演什么角色2.1 Drony到底是什么Drony是一个面向安全测试和开发调试的Android工具核心能力是在系统层建立一个本地回环网络接口把所有流量接管下来再按照你设定的规则转发到指定目标。你可以把Drony想象成一个交通警察站在路口发现车牌是猫眼App就手势引导它必须走电脑Charles那条道。这和我们平时说的开全局网络代理不一样。普通方式下App可以决定自己听不听系统设置但Drony在系统网络层接管流量后应用层面很难感知和规避。正因为这一层介入得足够深它才能搞定那些不走系统默认通道的App。我最初用Drony其实是拿来做调试自研Android应用时抓包用的。后来发现它在分析第三方App的网络行为时也非常好用尤其是遇到某些App无视Wi-Fi中继设置的情况Drony几乎是最省事的解法。2.2 为什么应用绕不过Drony要理解Drony为什么有效得先想清楚App能绕开Charles的关键在哪儿。App不读取系统HTTP中继配置所以流量依然走原始的网络路径但它没法阻止系统把整个设备的网络流量交给一个虚拟网络接口。Drony正是利用这一点在系统层建立回环通道它接管的是网络包级别的流量而不是应用层配置级别的流量。应用层不认HTTP中继系统层的路由规则它躲不掉。这就像快递员可以假装没看见家门口的请放驿站的纸条但小区保安把整个小区的入口都封了快递车必须从唯一的大门进那就躲不掉了。需要说明的是Drony的接管范围是可配置的。你可以让它接管所有App也可以只接管指定App这样调试目标明确也不影响其他应用正常上网。2.3 打开Drony后先认识这几个配置项Drony的界面比较朴素英文为主第一次打开会弹窗请求创建本地回环连接这里要点允许。核心配置项有这么几个Log level日志级别。调试时选Verbose可以看到详细的连接转发过程排错很管用。Lock Wifi / Lock Mobile Data是否接管Wi-Fi或蜂窝网络流量。我一般只开Lock Wifi避免蜂窝流量被转发后产生额外消耗。Default proxy全局默认转发目标。格式是电脑IP:端口比如192.168.1.100:8888。Rules规则列表可以按应用维度设置转发动作指定某个App发起的流量是走Charles还是直连。初学者第一次跑通建议先把全局默认目标设成电脑IP加8888让所有流量都走一遍Charles链路通了再收缩规则只保留目标App。这样可以快速验证通路有没有问题后面再精细控制。3. 完整实操从准备到抓到猫眼App的第一个JSON3.1 环境准备我一向推荐用电脑 真机的组合来做这类分析。模拟器虽然方便但网络结构和真机有差异Drony在模拟器里偶尔会出现兼容性问题排查起来反而多一层干扰。软件方面电脑上装好Charles手机上装好Drony和猫眼App。电脑和手机必须在同一局域网内能互相访问这是最基本的前提。手机如果开了省电模式或杀后台策略记得允许Drony在后台运行不然一旦被系统回收流量接管就断了。另外准备一台已经root的测试机最省心或者用Android Studio自带的模拟器配合处理。如果是日常使用的手机建议别拿主力机折腾系统证书风险不值得。3.2 电脑端Charles配置第一步打开Charles确认监听端口。菜单栏点Proxy → Proxy SettingsHTTP Proxy里默认端口是8888。记住这个端口后面手机端填地址要用。第二步开启SSL Proxying。菜单栏点Proxy → SSL Proxying Settings勾选Enable SSL Proxying然后在Location里添加一条*:443。生产环境调试建议缩小范围只写你要分析的域名加443端口比如api.maoyan.com:443。用通配符整体监听只适合在受控环境里临时开用完就关。第三步确认电脑防火墙放行了8888端口。同一局域网下手机浏览器直接访问http://电脑IP:8888如果Charles里出现一条访问记录就说明手机到电脑的网络通路是通的。这一步很关键能提前排除防火墙问题。很多兄弟搞了半天抓不到包最后发现是电脑防火墙把从手机过来的连接拦了相当冤枉。3.3 手机端安装并信任Charles根证书手机浏览器访问http://chls.pro/ssl下载得到Charles根证书文件。然后在系统设置里找到加密与凭据相关的入口选择安装CA证书把这个文件导入。这里要给刚入门的朋友提个醒Android不同版本的证书安装入口差异很大。Android 8以前叫安装证书Android 9以后藏在加密与凭据里有的定制ROM还叫从存储设备安装证书。入口名字不统一但逻辑一致装进CA证书分类就行。证书装完还不是万事大吉。默认情况下Android 7.0及以上版本的App不会信任用户安装的CA证书只信任系统内置证书。所以光装到用户凭据里很多App依然会握手失败。解决办法是把证书提升为系统证书这需要设备有root权限把证书文件复制到系统证书目录并修改为和原来文件一致的权限。没有root权限的话建议用官方模拟器或者专用测试机来练习别在主力机上强行改系统文件。3.4 Drony配置把猫眼App流量导向Charles这一步是整个方案的核心动作。打开Drony先到Settings → Network里打开Lock Wifi让Drony接管Wi-Fi流量。然后设置全局默认转发目标填电脑的局域网IP和Charles端口格式192.168.1.100:8888。接下来进入Rules页面新建一条规则。第一次验证通路时可以不针对具体App做限制让默认转发规则覆盖所有流量。等确认Charles能收到包了再回来把规则收紧只让猫眼App走Drony转发其他App选择直连。Drony提供的Action选项看起来有点抽象实际操作中Translate和Direct就用得最多。想把流量导向电脑选Translate它会按规则把流量转发过去想让某个App正常上网选Direct直连即可。选好之后记得保存并启用规则。我做这套配置时踩过最大的坑是把Wi-Fi系统设置里的手动中继和Drony同时打开了结果流量被双重接手Charles收到的不是CONNECT请求而是一堆奇怪的连接重置。后来改成二选一问题立刻消失。调试阶段建议要么系统设置做完整配置要么Drony全权接管别混着来。3.5 打开猫眼App看Charles结果一切配置完成后打开猫眼App在首页上下滑动点进电影详情页过几秒再切回Charles。正常情况下Charles会话列表里会冒出一批HTTPS请求主域名基本集中在接口域名上。单击某个会话右侧切到Contents页签如果证书链路没问题就能看到明文数据。猫眼这类App的接口响应多数是JSON里面会包含电影列表、评分、上映日期等信息。对我这种做逆向分析的人来讲初看到这些明文JSON时基本等于拿到了App和服务器的通信地图后续分析参数怎么生成、加密字段怎么来都从这里下手。需要注意如果Charles里看到的全是CONNECT请求内容面板是空的说明流量到了但TLS握手没完成早先说的证书问题这时才真正浮出水面。3.6 从响应里提炼数据接口特征拿到JSON以后别急着收工。分析接口结构才是这活儿的价值所在。我会先观察几个固定字段返回码、错误信息、数据块、分页信息。比如一个电影列表接口data里可能有list数组数组元素携带电影ID、标题、上映时间、想看数等字段。顺着这些字段你能反推前端页面哪些区域对应哪些接口哪些参数是分页下发的哪些字段是埋点上报的。紧接着观察请求参数。很多请求会带时间戳、签名、设备ID。时间戳好认一串标准Unix时间签名通常是32位或64位十六进制字符串位置在sign或sig字段。这些字段的值在每次请求里都在变说明有加密逻辑。找出加密函数并把参数复现出来就是逆向分析深入的方向。这一节要强调做协议复现和接口分析务必只在授权范围内进行。分析自己开发的应用、或者经过授权的测试目标都是正当的学习去抓取未授权平台的数据用于商业用途风险非常大别碰。4. 高频问题与排查方案4.1 Android 7证书不生效的典型表现与处理证书装完Charles握手依然失败提示证书不受信任这是Android 7以上环境最常见的问题。原因前面说过App默认不信任用户CA证书。判断是不是这个原因可以看Charles的报错类型如果出现类似Certificate not trusted或unknown authority的信息基本就是证书信任链没建立。解决办法按优先级排序有root权限的设备把证书从/data/misc/user/0/cacerts-added/复制到/system/etc/security/cacerts/文件名必须改成证书哈希值.0格式权限改成644重启生效。没有root就考虑用官方模拟器或者安装调试版本的测试环境在清单文件里配置networkSecurityConfig只对调试场景放开用户证书信任。我曾经在一台非root手机上折腾了几个小时最后发现根本绕不过系统限制老老实实换到测试机上操作五分钟搞定。经验就是别和系统机制死磕工具不对就换。4.2 流量到了Charles但解密失败现象是会话列表里有大量CONNECT点开内容却一团乱码或者直接报错。这说明流量路径已经打通卡在TLS层。先检查SSL Proxying里的域名覆盖范围。如果你只添加了api.maoyan.com:443但实际接口跑了api.maoyan-common.com:443那后者自然解不了密。解决方法是把目标域名和端口覆盖全或者临时用*:443做范围外测试仅限调试期。再检查SSL Pinning。如果App做了证书绑定Charles和服务器握手时返回的证书会被App拒绝最常见的表现是Charles报错或连接被重置。对于SSL Pinning的场景普通抓包方案确实不太够需要借助Hook框架对证书校验逻辑做动态patch。具体操作涉及代码注入和运行时修改我会在后续文章里单独展开。这里想提醒的是要不要绕过Pinning取决于你有没有获得授权授权范围内做安全测试没问题否则绕Pinning本身就是不受欢迎的行为更要谨慎。4.3 Drony启动后部分App断网或很卡Drony接管全局流量后如果你把默认转发目标设成Charles而Charles没开或者电脑不在线所有走转发的App都会卡住。现象是微信、浏览器打不开网页猫眼倒是能出数据。这种情况下Charles相当于成了整个网络通道的单点故障。解决思路很简单给不需要分析的App配置直连规则。在Rules里把常用App的Action设为Direct只留目标App走转发。这样既满足调试需求又不影响其他应用正常上网。另外Drony这类本地回环转发会带来额外的延迟转发链路本身的性能损耗没办法完全避免。我习惯在Drony的日志级别上做取舍平时用Error级别排查问题再切Verbose减少日志写入带来的额外开销。4.4 高频问题速查表故障现象可能原因解决办法Charles完全没有猫眼的请求记录流量路由未打通配置Drony接管流量确认转发目标IP和端口正确手机上访问电脑IP:8888不通防火墙拦截放行电脑端8888端口确认同一局域网CONNECT记录有内容乱码SSL Proxying未覆盖域名调整域名和端口临时可用*:443HTTPS握手报证书不受信任Android 7用户证书不被信任用root设备安装系统证书或改用测试环境连接被重置、证书校验失败可能命中SSL Pinning授权环境下考虑Hook方案否则放弃该目标其他App也断网默认转发目标不可达给非目标App配Direct直连规则最后分享一个我自己的小习惯每次分析目标App我都在Charles里先按域名过滤把无关域名全部排除只留几个核心API域名。这样日志干净定位问题也快。抓包工具只是最初级的一环真正的难点在于理解加密参数的生成逻辑和通信协议设计。这套Charles Drony的方案希望能帮你在Android逆向这条路上少踩几个坑少走我当年走过的冤枉路。