网恋选我，我撒网贼6

360安全客 安全知识 621473 4

 

声明

  1. 本文纯属虚构，若有雷同，纯属巧合。
  2. 本文及本人并未对任何社区进行攻击、扰乱等行为。
  3. 本文中出现的技术仅做讨论、研究之用，不以任何形式开放、出售与 APP 相关的源代码。
  4. 本文中出现的数据、代码、截图均已做脱敏处理。

 

前传

这个事情要从很久很久以前说起…

我有一个朋友，母胎单身，去年不知道从哪拱到了一棵大白菜，感觉人生到达了巅峰。

有一次，我与他相遇夜宵，凑了一局。 两杯啤酒顿顿顿下肚，只见他脸色红润，情绪激昂，只差一匹汗血宝马就可以出征长沙，血战沙场。

于是大放厥词，口出狂言道： 忆往夕，吾已鳏独二十有五载，看今朝，新春必携伴归乡探亲。

……

很可惜的是，可能是因为没有经验或者性 格不合，两人还没到过年就吹了，老死不相往来。

那几天，他悲痛欲绝，哀哀戚戚，无心工作，借酒消愁，感觉人生已经到达了低谷。

然后我去安利他看爱情公寓。 喜剧，也许能缓解一下心情。

后来突然有一天跟我说要他练级，练到 99 级！

咱也不知道咋练、练啥，咱也不敢问。。。

……

这货上网搜了一下陌生人社交软件，下载了一个比较热门的 APP。

练级第一天，点击匹配，匹配成功，开始聊天，于是：

然后就没然后了，他说这是他人生中遇到的第一次滑铁卢，感觉人生已经到达了低谷中的低谷。

练级第二天，看到社区里有漂亮的小姐姐发自拍，能收到好多赞和评论，真是一群有趣的灵魂啊，于是也决定自己发一张。

练级第三天：

不禁令人感慨，人生呐，就是如此的起起落落落落落落。

然后呢，就又来找我了，让我帮帮他。

这位胸 dei，谈恋爱俺不会，聊天俺也不会，那我只能手动帮你点个赞了。

这位仁兄一听，灵机一动，道: “那你帮我搞个软件，能自动帮别人点赞也行。高手靠实力，新手靠运气，只要我给一万个人点赞，总有那么几个人能看到我的自拍，然后被我那无处安放的魅力所吸引的。”

嗯, 他说的好像有道理。

于是有了正文。

 

正文

因年代久远，当时的分析与现在 APP 的协议已经很多对不上，我只能尽量复盘。

大伙们，编故事真的不容易。

……

需求很明确：

  1. 从社区里获取小姐姐们的动态
  2. 点赞

抓包

这个 soeasy ，主要是抓获取动态和点赞的两个请求。

首先打开 Charles，然后给把代理端口反向转发到手机里。

adb reverse tcp:8888 tcp:8888

再给手机设置代理

adb shell settings put global http_proxy 127.0.0.1:8888

结果发现一挂上代理就无法正常发送请求。

这种情况一般有几种可能：

  1. SSL Pinning 证书绑定
  2. 代理检测
  3. SSL 双向校验

根据我多年的经验，第一判断就是 sslpinning，于是我用 3 秒钟时间打开 objection， 执行 android sslpinning disable。 关于 Frida 和 objection 的安装和使用，我的另一位母胎不单身的好友已经写过多遍，可以参阅。

然后再次抓包，然鹅不管用。

那么先观察一下抓包的情况，发现 Charles 并没有出现 SSL 错误的提示，可以完整的看到请求的报文。

然鹅，response 却返回 400。由此可得，这是一个 SSL 双向校验，因为代理可以正常拦截到发送包，说明不是代理检测，如果有代理检测，那么这个数据包并不会通过代理发送出去。而且可以正常解密，更是说明也没有做证书绑定。

因为做双向验证，就需要在客户端里放一个证书，那么直接在 APK 里的 assets 中就可以找到一个 .p12 和一个 .cer 的文件，那么这两个就是客户端的证书了。

但是想要使用这个证书来与服务端通信，还需要一个密码。

一般来说，我们可以静态分析代码，搜索 KeyStore 或者 client.p12 来逆向分析找到密码，然鹅，这个 APP 做过加固，看不到代码。 那么可以采用更加高效的方式： Hook。

Hook 的原理不再多说，可参阅 《Android 动态分析攻防小结》。
直接上 Frida 脚本:

Java.perform(function () {
    console.log("Hooking...");
    var PKCS12KeyStoreSpi = Java.use("com.android.org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi");
    var String = Java.use("java.lang.String");
    PKCS12KeyStoreSpi.cryptData.implementation = function(a, b, c, d, e){
        console.log(String.$new(c));
        return this.cryptData(a, b ,c ,d ,e);
    }
});

拿到密码之后，就可以打开 Charles 的 SSL Proxy Settings 里导入 p12 证书了，随后在抓包的时候，Charles 会提示你输入密码。 而想要在 Python 脚本里使用，还需要使用 openssl 转换成 pem 证书，然后就可以像这样正常发起 Https 请求了:

response = requests.post(url="https://{}{}".format(ip, path), headers=headers, data=data, verify=False, cert="./client.pem")

于是，终于跨过抓包这个坎了。

Sign

一款安全性合格的产品，请求里必然会有 sign 字段，可以防止篡改的同时还能提高逆向分析的难度。

抓包分析之后发现请求的的 headers 里头有一个 APISign 字段，每一个请求都会通过这个字段对当前的数据以及时间戳进行校验。

按照常规套路，就是反编译之后搜索相关字符串，然后找到加密算法的地方，抠出来。

然鹅，这个 APP 是加固的，首先尝试一下快速脱壳。

结果好像还不错，dump 下来很多 dex，可以开始一顿搜索了。
然鹅：

搜索并没有得到结果，我以为是字符串进行了加密，然后手动打开这堆了 dex 文件，也搜索了其他的一些关键字、API，发现确实没有。 另外发现应该少了一些代码，这说明有一个重要的 dex 可能没有脱下来

逆向分析就跟股市一样，喜欢起起落落落落落落。短时间内也不纠结为什么脱不下来了，来一次不脱壳的纯动态分析逆算法。

无法脱壳下的动态分析口诀只有两个字：猜、试。 说详细一点，就是信息收集之后一步一步的进行猜想和验证。

一

因为 APISIGN 是一个 32 位长的 hex 字符串，那么可以初步猜想，这可能是个 MD5, SHA1 之类的摘要算法。那么这个时候，如果开发者使用了系统自带的摘要 API 那我们就可以通过 Hook 来得到计算之前的数据，从而倒推出签名算法。

关键类: java.security.MessageDigest， 通过对这个类的 getInstance, update, digest 方法进行 hook， 可以得到所有调用系统 API 的摘要算法、摘要数据、摘要结果。 代码这里不给了，自己实现一份不难。

想象很美好，现实却很残酷，通过这个方法并没有成功 Hook 到与请求数据相符合的调用结果，那么基本上这个算法就是自己实现的了。

二

大部分 APP 的网络请求，都是通过调用第三方网络框架发出去的，那么，我们可以先尝试一下能不能找到这款 APP 所使用的网络请求框架。

第一个肯定是龙头：OKHttp

因为之前有写过现成的针对 OKHttp 的抓包、解密工具，所以我就直接尝试启动了一下，结果:

[*OKHttp-InfoIntercept] not found RealInterceptorChain class
[*OKHttp-PacketIntercept] not found CallServerInterceptor class

找不到预设的类名，可能是因为混淆或者 APP 在集成框架的时候，很多人会选择修改包名，因为工具之前没有写智能查找的功能，那么可以使用 objection 手动查找一下。

使用命令: android hooking search classes Interceptor， 先搜一下带 Interceptor 的类名，因为一般来说可以通过他们，直接拦截到发包的调用。

结果发现，还是可以找到 okhttp 的类的。

那么将找到的这几个类进行一个 android hooking watch class。在发送一个请求，发现:

可以成功拦截到调用。那么，观察调用栈:

执行 android hooking watch class_method okhttp3.logging.HttpLoggingInterceptor.intercept --dump-args --dump-backtrace --dump-return

于是我们得到了 RealInterceptorChain 的真正类名

很多时候，OKHttp 对请求的加密、Sign 都是在开发者自定义的 Interceptor 里完成的，而 RealInterceptorChain 这个类，是贯穿全部 Interceptor 的一个关键点，具体详情可以阅读 OKHttp 的源码。对其 proceed 方法进行 Hook 在调用栈中即可看到所有的 Interceptor。

于是: android hooking watch class_method okhttp3.internal.http.f.proceed --dump-args --du mp-backtrace --dump-return

运气很不错，一下子就打出来了一条 APP 包名代码里的调用栈，而且还是 pkgname + .net 的包名，一看就是用于网络请求的，信息情报加一： 代码里有一个 .net 的包, 而且这个包并没有被脱下来。这个包基本上一看就知道很关键了。

那么再继续对找到的这个 Interceptor 类进行 hook， 仔细观察返回结果以及调用栈。

很可惜的是，并未在返回结果里找到与请求相符合的 sign 字符串，这说明，sign 的算法方法并不在这个类里面。

调用栈里也没有什么可疑的类或者方法，可以说这条线在这里已经断了。

三

从二中，我们收获到了一个情报: 未脱下来的代码中有一个 pkgname + .net 的包，那么可以先搜索一下，看看这个包中都有一些什么类：

[usb] # android hooking search classes xxx.xx.xxx.net
...... # 具体的类名就不列了
......
Found 54 classes

排除掉一些明显不相关的类，剩下的类不多，只有十几个。一个一个对其进行尝试 hook，功夫不负有心人，在一个没有做符号混淆的类中发现了一个方法:

那么观察一下这个方法的输入输出

看到这个，我就觉得基本上已经结束了。

再详细分析一下输入参数，分别是 URL PATH、用户 ID、时间戳等信息，都是已知或者可以自己生成的参数，返回结果就是 HTTP 报文里的 APISign。

至于为什么这么方法和类没有做符号混淆，原因是这个算法是在 SO 里面的，需要在混淆配置里面排除。

由此，我们又得到了一条新的经验： 下次 Hook 不到算法就直接看 SO。

四

算法调用方法有了，那我们还需要自己逆算法么？no。

Frida-RPC，懒人必备，在也不用手撕 OLLVM, VMP。

rpc.exports = {
    sign: function (xxx1, path, xxx2, t, xxx3, xxx4) {
        var result;
        Java.perform(function () {
            result = xxxxxxx.yyyyyyySign(context, xxx1, path, xxx2, t, xxx3, xxx4);
        });
        return result;
    }
};

sign = script.exports.sign(xxx1, path, xxx2, t, xxx3, xxx4)

完全 OK。 然后再构造一下包体，编码一下逻辑，一个无情的自动点赞机器人就诞生了。

 

正正文

作为一个新世纪的颜值主义者，虽然这哥们长得丑，但我还是希望他能找到一个漂亮的女朋友。于是我添加了一段人脸识别和打分的代码…

原本的逻辑是这样的:

遍历动态列表 -> 是个女的 -> 点赞

然后我加上了 F4ce+- 和 B4ldu 的 AI 颜值评分系统之后，逻辑是这样的：

遍历动态列表 -> 是个女的 -> 识别动态里的全部人脸 -> 评分 -> 大于80分 -> 点赞 -> 关注

最终效果咋样咱也不知道，反正这哥们那几天就抱着个手机在那一直傻乐，前几天跟我说准备跟新的女朋友去旅游，咱也不知道这是哪个新女朋友，咱也不敢问。

 

总结

后来我拿这哥们的账号提取了一点数据，事实证明，B4ldu 的颜值评分比较靠谱。

（完）