手机 app 网络抓包纪实

android https Charles Comments

记一次Android app 抓包 起因: 需要做新的ins工具,所以需要去调研竞品的程序实现方式,然后就理所当然的需要使用了抓包了,然后就开始了一个礼拜的苦逼之旅

DAY 1

准备:

  • Android 7.1的 nexus 6 手机
  • Charles
  • MacBook Pro
  • follower-unfollower(竞品) 还有 Instagram 的 Android app

很简单的启动方案,以前抓过,所以 Charles 打开 http 代理设置, 开启 Proxy->External proxy settings ,连接本机的 socks 代理 (ins 需要翻墙访问), Android 端 浏览器 安装 Charles 的证书. 开始抓包, 可以抓到包 ,但是当使用enable ssl proxying 的时候,就开始提示网络异常.所以只能看到 域名(都是i.instagram) 但是 内部的包的内容 是秘钥加密过的 无法看到. 因为 Android 在 7.0以后的版本 就修改了网络安全配置, 不在默认信任用户添加的整数. 所以就导致抓包失败.

两种方案:

  1. 使用7.0 以下的手机
  2. 使用apktool 反编译apk 文件, 添加 信任用户证书的网络安全设置xml 然后重新build 签名后安装

说说第一个吧, 使用了一个Android 5.0的vivo 直接就不能连接 Instagram 方案一(弃) 一天就结束了

DAY 2

昨天的方案一结束之后,使用第二种,失败, 这下 就有点尴尬了.打开Charles 看 报错, 提示: no suitable 算法证书. 打开WireShark看也是提示说 当 APP端 say: client hello 之后 ,服务器端返回就是没有可以用的证书算法. 仔细查看了下使用了 charles ssl proxying 的 client hello 和没有使用charles ssl proxying 的client hello ,发现协商的算法都是那几种, 并没有什么不一样的.

有点僵住了, 开始去网上找方法, 感觉这种抓包不存在抓不到的, 因为app客户端就在自己手上,hack 都应该给hack住. 然后就走叉了, 理解歪了, 说到底是对ssl 不熟还是, 看到有个MITM(Man-In-The-Middel attack) 中间人攻击 欣喜若狂 感觉找到了银弹(sliver bullet) 还特地去傻乎乎抱个主机想玩黑客攻击. 然后一天又结束了.又是充满希望的明天

DAY 3

(绝望)来了之后 开始照着配置配置, 失败了(ノへ￣、)捂脸 想找个好用的MITM的demo 可以直接用的, 于是乎病急乱投医 mitmproxy 的尝试. 当然也失败了, 后来认真一想,Charles 抓包就是这样干的啊, 他就是基于中间人攻击干的抓HTTPS的包的 哎… 这个是app客户端引起的证书认证失败. 又失败了 就开始查看新的方案了,这时候发现了一个Stack Overflow 上的回答 利用Android 的机制 利用Xposed 构建模块 去 hook 网络请求 需要root 查看了下源码:类似这种

        // JustTrustMe 的原理
        findAndHookMethod("org.apache.http.conn.ssl.SSLSocketFactory", lpparam.classLoader, "isSecure", Socket.class, new XC_MethodReplacement() {
            @Override
            protected Object replaceHookedMethod(MethodHookParam param) throws Throwable {
                return true;
            }
        });

需要root 然后有顺带刷机 测试, 一天又过去了, 不过至少还有一个充满希望的明天

DAY 4

(深层次的绝望)一顿折腾之后,发现使用了这个JustTrustMe 模块之后,整个手机都提示证书异常 ,无法连接https了,括弧 browser 括弧. 看它的GitHub 一年没更新过了,而且四天了啥事儿都没搞出来,很尴尬,为了更好的只有继续找方案了 . 然后 看github 里面issue 聊天, 又发现了俩种方案,

  • 一种是 通过反编译,Android app的程序.so文件 (二进制代码)里 修改, 然后替换太屌了, 这个 Tutoraial 是使用的 IG v78 版本.
  • 然后还有就是使用的另外一种框架 Frida 然后利用 V8引擎,和进程双向通信 注入(injection) JS 代码 然后去获取信息 具体的地址 然后又开始等待令人愉悦并且期待的充满新希望的明天了

DAY 5

(另一个层次的绝望–贫穷) 昨天的第一个方案,前面都挺好 到 使用IDA Pro 打开.so二进制源文件, 安装IDA Pro 正版(589-1129…刀) 打扰了, 盗版一直崩…. 但是看整个Tutoraial 挺好的, 即使干看 也很有收获, 主要是 他破解的思路.

方案二: 这个是思路很好

安全等级 策略 信任范围 破解方法
0 完全兼容策略 信任所有证书包括自签发证书 无需特殊操作
1 系统/浏览器默认策略 信任系统或浏览内置CA证书以及用户安装证书 设备安装代理证书
2 system CA pinning 只信任系统根证书,不信任用户安装的证书(android 7.0支持配置network-security-config) 注入或者root后将用户证书拷贝到系统证书目录
3 CA Pinning Root (intermediate) certificate pinning 信任指定CA颁发的证书 hook注入等方式篡改锁定逻辑
4 Leaf Certificate pinning 信任指定站点证书 hook注入等方式篡改锁定逻辑如遇双向锁定需将app自带证书导入代理软件
直接拿他总结的安全等级:
  1. 对应的就是Charles 安装证书 对于7.0 以下的Android 使用
  2. 对应之前的使用apk-tool 反编译apk 然后修改 network-securty-config

后面的两个就是对应App 内部做的一些SSL pinning 操作. 其实这个就需要看源码了 ,看APP用到的各自SSL pinning 的实现方式,然后采取不同的操作方式, 但是Ins 没有源码 ,只有尝试, 但是… 毕竟不是Android 的, 只是说有这个了解吧, 还是学到了很多. 但是如果真的要强行抓 INS 估计还得等以后更了解 Android 之后再处理吧.

最后在绝望深渊发现了一个问题, 这种SSL pinning(绑定) 是基于APP的,老板 叫做的是 去抓包竞品, 并不是INS啊/(ㄒoㄒ)/~~ 竞品应该不会像INS 这么注重安全的. 果然 安全等级就是2. 直接反编译,修改netword-security-config build 再签名 就可以直接用了,就可以查看 i.instagram.com private-api 的数据了.

总结

自己处理问题的目的性还是不够, 容易一条道走到黑,不撞南墙不回头的. 其实在第二天就已经找到处理方案了, 但是觉得理论是存在解决方案.就忽视了自己在这方面的薄弱,反而影响做事的效率. 就是修个灯泡,然后到最后就去造车了 ,明明抓个竞品的网络请求包,后面就是刷机,root,反编译,框架hook…

reference

一些有用的连接 方便以后查看:

z8n24A Computer Engineer

Do Some Interesting Shit.