Hybrid Android协议加解密分析

前言

App渗透再次遇到加解密，并且这次具体分析与以往状况有点不太一样，于是记录下来。

抓包分析

POST /app/fsOrder/getAllFsOrderListByUser/ HTTP/1.1
accept: application/json
authorization: Bearer
timestamp: 1567065637961
Content-Type: application/json; charset=utf-8
Content-Length: 256
Host: xxx.com
Connection: close
User-Agent: okhttp/3.6.0

{"data":"WmPKAOqVK3nmj2751oQM/1fyZJ/QQIMe2itv4LufWyk87WgwkJScqu68J/IQX1Pr","key":"LywemIhGqlzqDBOXOPxdY+nifhoq2lBILu2N6WUpJ/4Hrp5W4ihHO1vQuw0joHV6JiiFNzP1+j9hqp1VzmZoboHqRa411BltsuxjEmEMyIJqWK/zDKK+jBreRLH5bXCQOm4gYzHMFY6rob7aC8NhfFhc1r9hfIozhoIK2vbzIUc="}

可以看到请求包中数据都做了加密，分别有"data"和"key"两个字段。可以大胆猜测data为请求的数据，而key应该是加密data的密钥。惯用手段是用随机值作为key加密数据作为data，而这个随机值key又以一种固定密钥的加密方式加密之后一并附加到请求包中。而这里明显key的字段远远长于data字段，明显是两种很不一样的加密算法，而返回包也差不多。

HTTP/1.1 200 OK
Date: Thu, 29 Aug 2019 08:00:22 GMT
Content-Type: application/json;charset=UTF-8
Content-Length: 216
Connection: close

{"data":"nt4BMbi2d7oZ/bFg5mwe2w==","key":"o72x8DRL62zUVojRxEsUEP5w2Aa6BXWAZqo8sAFSK9sK47YiGewIIl9LCa1OQ6JgoXn+jVUdENfPSilBBEVwyaJeFFiJ/H24/flwqV/6nVT7YXdvly5dtdXeU6b6iHdpAHtDuaTxy7YJBstNQMo+mB4F6tGvx5D4TK7zpXIMAZk="}

逆向分析Java代码

关键词搜索

因为key和data比较常见搜索结果肯定大多都是第三方SDK的引用，先搜索一下路由getAllFsOrderListByUser，奇怪的是并没有任何搜索结果。于是只能搜索"key"和"data"，果不其然搜索结果都太多了。

多归多正常来说都能在搜索结果找到一些蛛丝马迹，但是这里发现全都是第三方SDK的引用，仔细一看发现主程序的代码少得可怜，并且注意到MainActivity继承了facebook的ReactActivity。

import com.facebook.react.ReactActivity;

public class MainActivity extends ReactActivity {
    /* access modifiers changed from: protected */
    public String getMainComponentName() {
        return "SafetyMonitoring";
    }
}

再结合assets资源目录来看这个app是采用了Hybrid开发模式，部分逻辑写在了javascript上。但这也不意味着加解密就一定在js上面，Google了一下好像还有js调用Android接口的说法，所以这个真的不好直接判断。

但无论如何还是先从Java代码找起，搜索一下常见的加解密函数字段AES、DES、RSA等

alipay.security里的Cipher加解密吸引了我，而且这里还有一些硬编码字段，一度让我以为这就是密钥。追踪一下函数的调用关系，似乎没有找到调用的痕迹，继续分析也无果。

方法剖析Method Profiling

避免其他函数的混淆，我在登陆过程中抓取函数调用栈，看了很久看到com.loc.n.a这里似乎有调用什么方法进行加解密（特别这种命名不清不楚的函数更让人值得关注）

根据Method Profiling调用栈可以清晰的找到函数调用和被调用关系，这种方式我觉得是定位函数最实在的方法。在分析的时候发现某个函数没法正常反编译成java代码。

a(r2, r0)     // Catch:{ Throwable -> 0x00ed }
            byte[] r0 = r2.toByteArray()     // Catch:{ Throwable -> 0x00ed }
            byte[] r3 = com.loc.w.b(r0)     // Catch:{ Throwable -> 0x00ed }
            java.security.PublicKey r0 = com.loc.w.d()     // Catch:{ Throwable -> 0x00ed }
            int r4 = r3.length     // Catch:{ Throwable -> 0x00ed }
            if (r4 <= r5) goto L_0x00bf
            r4 = 117(0x75, float:1.64E-43)
            byte[] r4 = new byte[r4]     // Catch:{ Throwable -> 0x00ed }
            r5 = 0
            r6 = 0
            r7 = 117(0x75, float:1.64E-43)
            java.lang.System.arraycopy(r3, r5, r4, r6, r7)     // Catch:{ Throwable -> 0x00ed }
            byte[] r4 = com.loc.q.a(r4, r0)     // Catch:{ Throwable -> 0x00ed }
            int r0 = r3.length     // Catch:{ Throwable -> 0x00ed }

动态调试

突然被问到为什么不直接动态调试因为apk没有也加固，一调试就知道是不是在java层做加密了，于是根据Method Profiling定位到的函数下断点调试

但是奇怪的是再次点击登陆居然没有断下来！Method Profiling抓取到的讲道理应该一定有被调用才对。

到这里大概可以确定加解密是在前端而不是android里面实现了，但是不死心我还是Hook来验证一下，直接hook Javax的Cipher函数，如果有调用的话日志应该就会打印Cipher加密的方式以及密钥key，然而无果。

前端JavaScript分析

搜索

如果真的确定加解密函数在Javascript代码里面的话，事情就变得简单起来了（其实也没有很简单）。对javascript不是特别熟悉，并且也没有办法动态调试Javascript，没有可靠的定位函数的方法，所以也能靠瞎几把搜索。如果对javascript比较熟悉其实可以根据javascript加解密函数名去搜索，大概会稍微比较快，而我这里先根据文件名来看比如这里的jsencrypt.js。

还好这里JavaScript代码不是特别多，结合grep和find全局搜索一下文件名和函数定位到了utils.js

.//assets/XXX/js/utils.js:function AESencrypt(text,key) {
.//assets/XXX/js/utils.js:  var value =AESencrypt(body,key);
.//assets/XXXCompany/js/utils.js:function AESencrypt(text,key) {
.//assets/XXXCompany/js/utils.js:   var value =AESencrypt(body,key);
.//assets/XXX/js/urlLoction.js:function AESencrypt(text,key) {

并找到了加解密函数以及RSA publicKey和secretKey同时硬编码在js文件里

function AESencrypt(text,key) {
    var result = CryptoJS.AES.encrypt(CryptoJS.enc.Utf8.parse(text),CryptoJS.enc.Utf8.parse(key),{
        mode:CryptoJS.mode.ECB,
        padding:CryptoJS.pad.Pkcs7,
    });
    return result.toString();
};
function AESdecrypt(text,key) {
    var result = CryptoJS.AES.decrypt(text,CryptoJS.enc.Utf8.parse(key),{
        mode:CryptoJS.mode.ECB,
        padding:CryptoJS.pad.Pkcs7,
    });
    return result.toString(CryptoJS.enc.Utf8)
};
function RSAencrypt(text) {
    var rsaEn = new JSEncrypt();
    rsaEn.setPrivateKey(rsaPubKey); 
    var enc = rsaEn.encrypt(text);
    return enc;
};
function RSAdecrypt(text) {
    var rsaDn = new JSEncrypt();
    rsaDn.setPublicKey(rsaprivateKey2);

    var dec = rsaDn.decrypt(text);
    return dec;
}

加解密逻辑

var timeS = new Date().getTime();
var key = '';
key += timeS+'123sadsof313r24rsd';
if (key.length > 16) {
    key = key.substring(0,16);
}
var rsaKey = RSAencrypt(key);
var body = dataConter;
var value =AESencrypt(body,key);
var newBody = JSON.stringify({
    data:value,
    key:rsaKey,
});

success: function (data, status) {
    if (status == 'success') {
        var aaPwd = RSAdecrypt(data.key);
        var aaData =AESdecrypt(data.data,aaPwd);
        var newRes = JSON.parse(aaData);
    // successCallBack(data);
    // console.log(newRes)
    if(newRes.code==401){
        window.postMessage(['login401']);
    } else{
        successCallBack(newRes);
    }
}},

细节分析

rsaEn.setPrivateKey(rsaPubKey) RSAEncode这里用公钥作为私钥encode了，一开始没注意还真就用了私钥尝试去解。
这里逻辑也很明了，发包的数据用13位的timestamp+"123"作为密钥key进行AES ECB加密，并且将AES的key进行RSA加密发送到服务器。返回包中，先RSA解密key字段获取AES加密的key，再对data字段进行AES解密。
本地js找加解密的时候也猜想过一种情况，客户端有没有可能先从服务端获取加解密的js文件（这样本地也找不到加解密函数）。为了排除这种想法，要仔细看burp抓取的数据包，有没有对应的js文件。
又能愉快的对移动app进行渗透测试了。