某汽车社区App 签名和加解密分析 (二) : Frida Dump so

公众号: 奋飞安全
• 阅读 1561

一、目标

App安全的主战场在Native层,分析Native层的so,最趁手的兵器就是Frida和Unidbg了。

今天我们的目标是 某汽车社区App v8.0.1 so 的分析。

二、步骤

特征字符串定位

我们在上一篇教程 某汽车社区App 签名和加解密分析 已经定位了,数据加密和解密函数再java层的位置。

某汽车社区App 签名和加解密分析 (二) : Frida Dump so

按照常理来说,这个java类文件中,应该有个 System.loadLibrary("libxxx") 来方便我们定位对应的so。

可惜的是,这个样本里找不到。原因大概率是脱壳不完整。

既然没这么简单,我们再回忆一下加密串的特征:

1、sd= 开头

2、数据都是大写的M开头

3、== 结尾,那大概率是Base64

有共性就好办了,我们在Native层匹配下 M 开头的字符串,匹配到了就打印Native层的堆栈。

if(string.toString().length > 50 && string.toString().indexOf("M") == 0){
    var threadef = Java.use('java.lang.Thread');
    var threadinstance = threadef.$new();

    console.log("[NewStringUTF] bytes:" + string);
    console.log(Thread.backtrace(this.context, Backtracer.FUZZY)
            .map(DebugSymbol.fromAddress).join("\n"))
}

跑一下

某汽车社区App 签名和加解密分析 (二) : Frida Dump so

结果是出来了,但是这个结果很有料呀。 没听说过江湖上有 1ef38371-d2a4-4ade-8510-d08f5c05fe5f-32.so 这种名号的so。

全局搜索

这个奇怪的so在apk里面肯定是找不到了。我们在手机里去找一找。

要玩好Android,那么linux命令不可少,搜索文件用find命令

find / -name '1ef38371-d2a4-4ade-8510-d08f5c05fe5f-32.so' -print

我去,没道理呀,居然搜不到?当然不会是我们find命令输错了。

在加密或者加壳的手段下,是可以实现手机只有加密文件,只在内存中加载解密后的so。

Frida Dump So

今天的重头戏就是这个了。so在内存里面,如何把它搞出来?

第一步: 把冰箱门打开

var libxx = Process.getModuleByName("210f3bcc-51b1-4f3c-9ca4-c429ad93ded1-32.so");
console.log("*****************************************************");
console.log("name: " +libxx.name);
console.log("base: " +libxx.base);
console.log("size: " +ptr(libxx.size));

打印出了这个神奇的so的地址和大小

*****************************************************
name: 210f3bcc-51b1-4f3c-9ca4-c429ad93ded1-32.so
base: 0xc380c000
size: 0xec9000

第二步:把大象塞进冰箱

var file_path = "/data/data/com.clxxx.lxxxlxxxbxxx/" + libxx.name + "_" + libxx.base + "_" + ptr(libxx.size) + ".so";
console.log(file_path);

var file_handle = new File(file_path, "wb");
if (file_handle && file_handle != null) {
    Memory.protect(ptr(libxx.base), libxx.size, 'rwx');
    var libso_buffer = ptr(libxx.base).readByteArray(libxx.size);
    file_handle.write(libso_buffer);
    file_handle.flush();
    file_handle.close();
    console.log("[dump]:", file_path);
}

注意: 写so文件的时候,把文件写在 /data/data/包名 目录下,这个目录大概率下是可以读写的。

第三步: 把冰箱门关上

最后把dump的so用adb命令 pull出来。

如果没有pull /data/data/包名 这个目录的权限,那就先copy到 /data/local/tmp 目录下面。

现在可以拖进ida愉快的分析了。

三、总结

先找共性,然后再定位。字符串定位的套路都是一样的。

如果样本没有调用 NewStringUTF 或者 GetStringUTFChars 怎么办?

我觉得还可以考虑libc.so, malloc strcpy 这些标准C函数 Hook一下,应该也会有惊喜。

Linux命令可以熟悉下,关键时刻还是有用的。

某汽车社区App 签名和加解密分析 (二) : Frida Dump so 俄罗斯方块教会了我们,如果你合群,就会消失。

TIP: 本文的目的只有一个就是学习更多的逆向技巧和思路,如果有人利用本文技术去进行非法商业获取利益带来的法律责任都是操作者自己承担,和本文以及作者没关系,本文涉及到的代码项目可以去 奋飞的朋友们 知识星球自取,欢迎加入知识星球一起学习探讨技术。有问题可以加我wx: fenfei331 讨论下。

关注微信公众号: 奋飞安全,最新技术干货实时推送

点赞
收藏
评论区
推荐文章
某A系电商App x-sign签名分析
一、目标前不久(我去,都大半年了)分析过我们找到了几个伪装成so的jar包。虽然rpc调用ok了,但是它的实际运算过程还是在so里面的。今天我们从它们同族的App来入手,利用Native层字符串定位的方式来定位下在哪个so中去做的运算。App版本:v4.15.1二、步骤特征字符串定位一开始选择的特征字符串是x,后来发现没有xsign好使In
某A系电商App doCommandNative浅析
一、目标李老板:奋飞呀,xsign你都水了好几篇了,一直在Apk里面打转,咱们啥时候分析分析它的so?奋飞:循序渐进嘛,我们上次刚定位了它的so,今天我们来分析分析。App版本:v4.15.1二、步骤Native层的入口先回忆下这个堆栈这个jni函数有两个参数,第一个参数是int型,第二个参数是Object数组我们先上frida看看它是不是我们的目
某电商App 返回数据加密解密分析(四)
一、目标最近在抓包某电商App的时候发现一个加密数据,它在做通讯地址请求的时候,请求数据做了加密。返回数据中的地址信息也是密文。今天我们的目标就是这个数据的加密解密。App版本:v10.3.0二、步骤分析一下1、数据的结尾是"",说明是Base64编码,那么我们可以尝试去HookBase64相关函数,然后打印堆栈。2、返回数据格式是json,那么我
某神奇App data加密算法解析(一)
一、目标李老板:奋飞呀,我遇到一个超级牛掰的App,它请求的时候有个data参数加密,用尽了你介绍的所有的方法,都找不到它是如何加密的。奋飞:子曾经曰过,老板的嘴,骗人的鬼。有这么牛掰的App,那么我们这帮兄弟早就失业了。某神奇Appv10.1.0点社区随便打开一篇有评论的文章今天的目标就是这个data二、步骤搜索特征字符串目标是data,所以我
某站App签名算法解析(一)
一、目标我们来分析某站App的sign签名算法,先搜索一下游戏,抓包结果:二、步骤这个sign依然是32位的字符串都9020年了,这种规模用户的App应该是不会裸奔在java层了,我们就直接一点,在so里面搜索sign可惜没有结果……藏起来的东西一定是重要的东西so层导出函数给java层调用,有两种方法,一种是静态注册,直接会体现在so的导出表
某汽车社区App 签名和加解密分析
一、目标稼轩长短句有云:宝马雕车香满路。从此香车美女就成了标配。这不李老板还没聊几个mm,又开始准备换车了。今天我们的目标是某汽车社区Appv8.0.1。二、步骤脱个壳李老板说这个App很拽,貌似是某个企业版的壳,连Xcube都不好使,调试不了。我们先不管他拽不拽,先用BlackDex把壳脱了先。BlackDex提示脱壳成功,但是对应的目录下只
某小视频App v10.x 手机号加密算法分析
一、目标今天的目标是手机号加密,app变化太快,以前都是明文的。TIP:某小视频Appv10.2.30.24518二、步骤字符串匹配也许是手机号都是1xx开头,也许是这个加密字符串有个特征头。反正经过我们观察,发现它大概率是3sCt开头。而这种加密算法大概率是在Native层去做的。所以我们首选是去hooklibart里面的GetSt
某车联网App 通讯协议加密分析(二) Unidbg手把手跑通
一、目标有一段时间没有写unidbg相关的文章了,这个样本挺合适,难度适中,还适当给你挖个小坑。所以后面是一个系列文章,包含unidbg补环境,TraceBlock对比流程,TraceCode定位差异。掌握好这一系列套路,Native分析可以算入门了。这次先来把so用unidbg跑通v6.1.0二、步骤DumpsoIDA打开 libencryp
某车联网App 通讯协议加密分析(三) Trace Block
一、目标之前我们已经用unidbg跑通了libencrypt.so,那么如何判断跑出来的结果是对是错?再如何纠正unidbg跑错误的流程,是我们今天的目标。v6.1.0二、步骤找到明显的接口来判断checkcode是加密,加密的结果确实不好判断是否正确。不过我们可以试试解密,能解密就是对的,简单粗暴。这里解密函数是decheckcode。public
appdbg: 一个伪装成调试器的虚拟机
一、目标现在的App都不安分,Java层去和Native挤眉弄眼,Native层又喜欢和Jave去暗通款曲。想安安静静的分析一个so太难了。有没有可能把App在Pc上都模拟执行起来,这样Native再去勾搭Jave层的时候就可以节省很多补环境的工作了。appdbg就是这样一个伪装成调试器的虚拟机。作者的介绍是:makeitpossibletorun
公众号:  奋飞安全
公众号: 奋飞安全
Lv1
奋飞,国家高级信息系统项目管理师,独立安全研究员。 http://91fans.com.cn/
文章
60
粉丝
4
获赞
44