-
-
[原创]实战某信外挂插件之字符串还原
-
2020-10-2 11:25
8808
-
背景
这是去年分析的一款某信定制版的多开app,用时三天。可能用的dexguard(不确定)保护的,所有的字符串全都加密了。本文介绍下还原方法。
网络验证
其实,破解绑定设备的软件,最基本的原理无非就是软件获取设备信息,然后传给服务端,服务端根据设备回一段特征串(pc机器可能就是二进制汇编,手机就是一些类、成员变量的字符串)。这款多开软件也不例外,传激活码和设备信息到服务端,服务器返回要hook的所有类名,然后在类中初始化所有字符串变量。自己搞服务器,或是直接patch掉java层的代码就能够破解。这是比较通用的方式,本文不分享这个,分享下怎么还原其它字符串。毕竟破解不是目的,看看它最终功能实现才是我想做的事情。
还原字符串
源码保护字符串
字符串特征是逆向分析的突破口,所以,也是正向开发必须被重点保护的。分享下我自己开发软件保护字符串的方式:通常我会将所有的字符串定义都搞成统一格式:final string a = "test"(如这样,c++的话也是一样的);这样操作后,通过python脚本编译代码的时候,可能通过正则将代码中所有的字符串都找出来,然后拼接所有的字符串,最后压缩、加密、分割写会源代码文件,哈哈。程序运行时会在一个类中进行拼接、解密、解压缩,然后初始化hashmap,这样运行时,就可以根据key来获取字符串value了。所以,最好把这个类搞成单例。不过,这个类也成了唯一突破口。这种保护方式,也在一些恶意样本中常被用(比如c#版本的agenttesla)。
混淆工具保护的字符串
被加密的数据如下图:
分析cf函数的实现:
开始,我以为通过扣代码,直接反射调用该方法就能够解密字符串。我尝试后,发现⾃⼰太年轻,⽆法解密数据。分析cf函数的实现,发现它会调用cf12345函数。跟进cf12345函数,发现它会初始化⼀些跟堆栈回溯后关的类名。猜测,这大概是要判定cf调用的调用来源是否合法吧。
初始化堆栈回溯的类:
再回过头来分析cf函数,cf函数的如下部分,正是在进⾏堆栈调用判定。并且,只有调⽤cf函数的类路径、⽅法名、回溯层数不被篡改,调用才能返回正确的结果。这真的是⾼明啊。
既然知道它的校验原理理,那么,我们应该怎么绕过呢。 只要我们想办法去修改给上图v5进⾏赋值就行,这里我对该函数的smlia代码进行修改,将v5改为外部获取就行。我修改为从外部我自己的实现的Ldecrypt/Test类来获取参数值。我修改的⽅式如下:
Test类的实现如下:
再告诉⼤家⼀个我⽐较爱用的技巧:dex文件是java编译生成的,dex可以转成smali,反过来,smali也 可以转回dex,最后dex转成jar,这个jar是可以被java⼯程加载的。也就是我们的解密可以完全在java项⽬里完成,不⽤用开个android项⽬,我感觉java项⽬比较便捷。
只要我们在调⽤用cf⽅方法前,通过Test类传递正确的类路径、方法名,就能够正确解密当前字符串。接下来,怎么批量解密⼀个apk中通过该种⽅法保护的所有字符串呢?
其实,答案很简单。我们写个jeb脚本(或是直接解析smali代码),将所有符合该特征的字符都提取出来,按照上边的方法解密,然后再在smali层进行批量替换解密成功的字符串,还原就ok了了。⼀部分解密结果如下,其中阿拉伯字符串部分加密的字符串(unicode字符串会涉及到转码问题,hex更⽅便)
开发者自己保护的字符串
混淆工具加密部分处理理好后,发现Version下的所有类还都是加密的:
这部分可以看出,加密字符串⻓度都一样,加开后也是一段长度固定的数据。这部分是so中是混淆保护的,根据我多年年的经验,猜测是这部分原理通过从发送设备信息到码平台后,码平台验证过后,云端才下发正确的字符串串,然后内存解密,反射设置Version的属性值。 那我通过写⼀个xposed插件,找⼀个合适的时机,也对Version类进行遍历并dump数据,那这部分的解密结果也有了,如下:
最后
入行是从看雪出发的,没人带靠自学,一路走来跌跌撞撞,感谢看雪。现在,初心未变,我还在别的领域继续追寻技术。很多同路的朋友要不然就钱赚够了,要不然就靠着名声吃饭脱离一线了。我感觉我还能坚持下去,哪怕客户端的未来看似灰暗。解密方式在其它论坛发过,在这里重新记录一下过程。
[培训]《安卓高级研修班(网课)》月薪三万计划
最后于 2020-10-2 11:29
被wuaiwu编辑
,原因: