声明:本文仅限于技术讨论与分享,严禁用于非法途径。若读者因此作出任何危害网络安全行为后果自负,与本号及原作者无关。
前言:
客户仅提供官网下载地址给我们测试。但是由于官网的版本不是最新的,APP会强制你升级。而升级后的APP,是进行加固后的,无法使用frida进行hook,注入进程。那同样也无法使用SSL Unpinning进行限制客户端校验证书。新版app使用查壳软件显示未加壳,但是查看源代码明显少了很多代码,且很多都是变量声明而已。
绕过更新:
我们要想能对APP渗透测试,一般都是需要抓包和解密的。首先使用burp进行抓包代理,官网版本的APP(以下统称旧版APP),是可以轻松抓到APP的包的(该条请求为检验APP最新版本的请求)。但是内容使用了加密,具体什么加密是不得而知。
获取到请求密文:
vVAK0jos5eT9gmQJaHOaYbqZ1mgXoBH3bee3MTF3G5wNRHRoPPOYokZLT4MQqaPDN%2BLeEYpIzzDJeErDHcDfhY8muosLfOaw35W3BuCxDNtuNFB86RumMBtOcQXT08qw
响应包未json,urldecode后为:
{"duration":"0ms","note":"","code":1,"resultDES":"UX/jHk6yqix2yxZIrf0rSIuOjCy6oGxjCPUfBL2avG+DWy/++NW16+YQHVFQ+Nj2w9VOWGcH4OxFtGxbR6K7I6pY0Q9hkP9gc0K0JLZ5O+PwOW72nzissCiLG+cHqadKHzkPOQDdBUuBoa4W1Jz7fQ=="}
通过desStr和resultDES,一开始我猜测他为des加密,具体是不是,后续再说。
先进入APP,但是一进入APP就提示更新:
通过前言,我们知道是不能更新的。(当然不乏某些技术大佬也可以把新版APP搞定,我技术有限,感觉旧版的比较容易搞)。那我们就明确了目标,要先绕过更新校验。
对于不了解hook和frida的同学,我这边推荐先去网上了解下,还有安装之类的,再来看此篇文章。
首先我们明确一下思路,要怎么绕过这个更新校验呢?
(1)直接反编译,修改APP的版本信息为99.99之类的;
(2)通过修改版本验证请求,使用http层面去绕过;
(3)使用hook,去重写更新函数,或者绕过更新函数;
第一点要app能支持反编译且不存在校验签名。第二点要能知道加密密文的密钥。所以我选择第三种:
通过jadx搜索更新,发现了两处,成功获取到源代码。
类名分别为:com.xxxx.AppUpdate和com.xxxx.WelcomeActivity,通过代码审计可以看到,是先调用的WelcomeActivity,WelcomeActivity再去调用的AppUpdate:
跟踪进入AppUpdate,调用的checkNativeAppVersion():
通过上述代码,我们可以看到,这边就是用于判断是否升级的函数。
public void onResponse(Call call, Response response) throws IOException {
try {
JSONObject jSONObject = new JSONObject(C.s2(new JSONObject(URLDecoder.decode(response.body().string(), DataUtil.UTF8)).getString("resultDES"), Config.WHITE_KEY, Config.IV.getBytes()));
if (jSONObject.optInt("code", -1) > 0) {
JSONObject optJSONObject = jSONObject.optJSONObject("object");
if (optJSONObject == null) {
return;
}
if (WakedResultReceiver.CONTEXT_KEY.equals(optJSONObject.optString("isUpdate", ChatConfig.CARD_TYPE))) {
nativeAppVersionInterface.updateApp(optJSONObject.optString("desc", "当前有新版本,是否需要更新"), optJSONObject.optString(ClientCookie.VERSION_ATTR, ""));
} else {
nativeAppVersionInterface.noUpdateApp();
}
} else {
nativeAppVersionInterface.showError(jSONObject.optString("note"));
}
} catch (JSONException e) {
e.printStackTrace();
nativeAppVersionInterface.showError(e.getMessage());
}
}
当JSONObject.optInt("code", -1) > 0时,是会去进行升级的,否则则执行nativeAppVersionInterface.noUpdateApp()。
这边分析完后,其实我们就可以写js进行hook操作了。
我们的hook思路可以这样设置了:
重写checkNativeAppVersion函数,执行执行nativeAppVersionInterface.noUpdateApp()。
Ps:因为我一开始直接重写了checkNativeAppVersion,只执行了console.log(“enter checkNativeAppVersion”),没有对APP进行启动,这样就会直接卡死在启动页。
附上js代码:
if(Java.available){
console.log('success');
Java.perform(function(){
var appUpdate = Java.use("com.xxxx.AppUpdate");
appUpdate.checkNativeAppVersion.implementation = function(a,b,c,d,e,f){
console.log("enter AppUpdate");//判断是否进入该hook函数,进入会执行该命令
f.noUpdateApp();//直接执行不需要更新函数,APP会自动进入
}
});
}
使用命令:frida -U -l .\xxx.js -f 包名 --no-pause
成功进入:
解密:
已经成功进入该APP,但是如果想成功进行渗透测试的话,还需要能解开APP的加密。通过des字段,初步判断为des加密,再回头看看刚刚更新的那个请求,是有用c.s2()函数进行操作的,大概率s2就是解密函数。
JSONObject jSONObject = new JSONObject(C.s2(new JSONObject(URLDecoder.decode(response.body().string(), DataUtil.UTF8)).getString("resultDES"), Config.WHITE_KEY, Config.IV.getBytes()));
可以看到s2的三个参数,即前面响应包中的json字段里面的resultDES参数,然后其次是Config.WHITE_KEY, Config.IV两个参数,其中Config.IV是以字节数组的形式进行传参的。通过跳转可以看到配置文件的参数。
然后呢,因为获取到密钥和偏移量iv,这样的话des就可以解了。但是问题是解不开。后续的思路就是如果可以直接hook这两个加解密函数的话,是不是就可以不用管他的加解密了。
s1和s2函数不在java层,那我们就需要hook native层的代码。Hook so文件。首先我们先把安装包后缀apk改成zip,然后解压。就可以找到wkb-1.2.2.so的文件了。(路径为lib/arm64-v8a/wkb-1.2.2.so,前面的arm64根据自己测试机的CPU架构进行选择。)直接用ida打开,在导出函数里面搜索des:
里面有很多des的相关函数。可使用以下js进行hook导出函数:
if(Java.available){
console.log('success');
Java.perform(function(){
var point = Module.findExportByName("libwkb-1.2.2.so","desDecryptByteArray");
Interceptor.attach(point,{
onEnter: function(args){
console.log("Hook start");
console.log("args[0]=" + args[0]); //打印我们java层第一个传入的参数
console.log("args[1]=" + args[1]); //打印我们java层传入的第二个参数
},
onLeave: function(retval){ //onLeave: function(retval)是该函数执行结束要执行的代码,其中retval参数即是返回值
console.log("return:" + retval); //打印返回值
}
});
});
}
但是这边很奇怪的是,通过函数findExportByName找到的地址都是为null,一开始以为是还没加载到so文件,但是后续进入APP后还是一样为null。(有知道的大佬可以说下)
这就比较蛋疼了,得手动计算地址。首先先获取so文件的地址,看能不能获取到,若不行,则表示未加载so文件。
var soAddr = Module.findBaseAddress("libwkb-1.2.2.so");
console.log("soAddr:" + soAddr);
有地址出来,说明so文件是存在的,可以正常调用。那么这边就要去计算函数偏移量。之前在网上看到别人的一个公式:
*函数地址=so***初始地址+**函数偏移量+1
但是我后面尝试了好几个,好像不同手机不同的计算方法,也可能我操作的有问题。我这边的函数地址就是:
*函数地址=so***初始地址+**函数偏移量
不用加一。我自己是用这个方法测试计算的:找到一个导出函数可以被查询到的,比如我这边使用的就是JNI_OnLoad函数:
获取JNI_OnLoad的地址为0x79d5d7883c,然后使用这个地址减去so的地址:
0x79d5d7883c − 0x79d5d67000 = 1183c
差值刚好为JNI_OnLoad的偏移量,所以我这边就不用再进行加一操作了。
这样我们就可以成功hook任意函数了。通过我一个个尝试发现,以下函数一个都没调用过:
然后呢,我查找了s2函数的用例,发现被decodeSm4的函数调用过。
我就尝试了一下,hook了sm4EncryptByteArr:
附上js:
var soAddr = Module.findBaseAddress("libwkb-1.2.2.so");
var point = soAddr.add(0x136f0);
Interceptor.attach(point,{
onEnter: function(args){
console.log("Hook start");
console.log("args[0]=" + args[0]); //打印我们java层第一个传入的参数
console.log("args[2]=" + Java.vm.getEnv().getStringUtfChars(args[2], null).readCString()); //打印我们java层传入的第三个参数
console.log("args[3]=" + Java.vm.getEnv().getStringUtfChars(args[3], null).readCString()); //打印我们java层传入的第四个参数
},
onLeave: function(retval){ //onLeave: function(retval)是该函数执行结束要执行的代码,其中retval参数即是返回值
console.log("return:" + Java.vm.getEnv().getStringUtfChars(retval, null).readCString()); //打印返回值
// retval.replace(0); //替换返回值为0
// return retval;
}
});
Ps:通过ida里面的参数,我们可以看到第二个参数为类,我们就没给他打印出来。
我人傻了,一开始的des字眼和偏移量这些都符合des的加密方式,误导了我好久,一直往des方向去找。
尾声:
其实很早我就已经解密成功了,直接通过java层,刚刚发现调用s2的decodeSm4函数,直接hook那边即可成功获取请求和响应的明文:
但是若通过js去操作修改数值,实在太麻烦了,要获取密钥和加密方式,通过脚本自动去加解密,所以我才会去hook native层,获取到密钥。因为上述密钥Config.WHITE_KEY,其实是还有一层加密的,通过hook decodeWhiteKey函数的返回值,成功获取了密钥。
其实后续我也尝试去修改版本号绕过,但是事实证明,代码存在验签:
可以看到,把版本号修改为99.9.99,成功绕过了更新检测,但是他还存在一个盗版验签检测:
验签代码一样需要用hook去绕过。所以前面说的方法一也是行不通的。然后我又突发奇想,有没有可能他密文里面就包含版本信息,那如果我使用99.9.99的版本,抓取密文,然后再安装旧版APP,在他去请求版本更新时,替换密文,是不是可以绕过呢?经过尝试,结果是:可以。他的版本校验就是在服务端,这种方法也可以绕过。
总结:
不用轻易相信别人留下的信息,还是得根据自己的分析得出结论。其实后续我一直在想为什么那个字段是des呢,感觉之前是des加密,后续金融行业都进行了国密改造,然后字段并未更改,导致这种现象,当然只是猜测。至此,已完成对这APP的抓包和加解密。
征集原创技术文章中,欢迎投递
投稿邮箱:[email protected]
文章类型:黑客极客技术、信息安全热点安全研究分析等安全相关
通过审核并发布能收获200-800元不等的稿酬。