某电商App sign签名算法解析(六)

一、目标

sign的入参是加密的,不过带有很明显的两个特征,一个是 == 结尾,再一个就是 R4iSK 开头。

有这两个特征,我们就可以入手了。

rc1.png

二、步骤

先从Base64入手

== 结尾的数据大概率是Base64,我们先Hook下

1// Base64 2var Base64Class = Java.use("android.util.Base64"); 3Base64Class.encodeToString.overload("[B", "int").implementation = function(a,b){ 4 var rc = this.encodeToString(a,b); 5 console.log(">>> Base64 " + rc); 6 return rc; 7}

跑一下

rc2.png

结果倒是有了,不过不是我们想要的,先留着吧,说不定以后用的到。

匹配 R4iSK 开头

这个套路我们很熟练了,

1// 靠字符串去定位 2var strCls = Java.use("java.lang.StringBuilder"); 3strCls.toString.implementation = function(){ 4 var result = this.toString(); 5 6 if(result.toString().indexOf("R4iSK") == 0 && result.toString().length < 200) 7 { 8 console.log(result.toString()); 9 10 var stack = threadinstance.currentThread().getStackTrace(); 11 console.log("Rc Full call stack:" + Where(stack)); 12 13 } 14 return result; 15}

愉快的跑一下

rc3.png

这次逮住了,虽然这个 CrashReport 的类名有点怪怪的

Hook 处理函数

1var OperCls = Java.use("com.jxxxxong.sdk.xxcrashreport.a.a.a"); 2OperCls.a.overload('[B').implementation = function(a){ 3 var result = this.a(a); 4 5 var StrCls = Java.use('java.lang.String'); 6 var inStr = StrCls.$new(a); 7 8 console.log(inStr + " >>> " + result); 9 10 return result; 11}

入参是个 byte[] ,返回值是个 看上去像是Base64 但是大概率又不是 Base64 的东东

打印 byte[] 有两种方案,一种是直接转成Hex字符串打出来,一种是赌他实际是个String,直接转成String打印出来。我们这里先尝试转成String

 >>> R4iSKKKKKKKKKBC0CtGnLKMgYWz/LGKKKK==

打印出来的结果是这样的,入参没有打印出来,说明入参不是简单的 String.getBytes()。

往上回溯堆栈

我们继续沿着堆栈上溯,找找 a.o 的init函数,

sub1.png

发现了这个入参的byte[] 经历了 一次 xxcrashreport.a.a.a.b 函数的洗礼。

点进去看看 发现 原来是做了一次zip压缩。 啥也别说了,先 Hook这个b函数

1OperCls.b.implementation = function(a){ 2 var StrCls = Java.use('java.lang.String'); 3 var inStr = StrCls.$new(a); 4 5 console.log(inStr + " >>> "); 6 7 var result = this.b(a); 8 return result; 9}

再跑一下,结果出来了。

1{"msg":[{"appId":"fba8ae5a5078417d90ae1355af234d4f","clientVersion":"10.3.2","buildCode":"92141","appArch":"32"}]} >>> 2 >>> R4iSKKKKKKKKKK3Ckm6NCKyP4XpntPMcsmTiVIdoeOlPYBLNS1PK0O4e747X79c5P3zFQbh3LbJlFUCRaaIQTPKmipOYkJUu6OAqZT1xx6MMacwy/v5yxRvbdYAwdhXVCF7zmi+DHbQ16PPDpn/R9PPnPifGbirJeG9yKKKK

收工~ 太冷了,鲜啤就不上了,上二锅头。

三、总结

原文String调用一次getBytes(),之后转成了 byte[],然后调用 b 函数做一次zip压缩,最后调用一次 a 函数做了一次魔改了Base64操作。

这次app唯一的破绽就在于密文的开头是不变的,所以我们在做加密的时候尽量保证每次的结果都不一样,而且密文要无规律。

ffshow.png 君子务本,本立而道生

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

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

点赞
收藏

评论区

加载中...

相关推荐

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

一、目标App安全的主战场在Native层,分析Native层的so,最趁手的兵器就是Frida和Unidbg了。今天我们的目标是某汽车社区Appv8.0.1so的分析。二、步骤特征字符串定位我们在上一篇教程已经定位了,数据加密和解密函数再java层的位置。按照常理来说,这个java类文件中,应该有个System.loadLibrary("

某电商App 返回数据加密解密分析(四)

一、目标最近在抓包某电商App的时候发现一个加密数据,它在做通讯地址请求的时候,请求数据做了加密。返回数据中的地址信息也是密文。今天我们的目标就是这个数据的加密解密。App版本:v10.3.0二、步骤分析一下1、数据的结尾是"",说明是Base64编码,那么我们可以尝试去HookBase64相关函数,然后打印堆栈。2、返回数据格式是json,那么我

某电商App sign签名算法解析(五)

一、目标李老板:奋飞呀,据说某电商App升级了,搞出了一个64位的sign。更牛的是入参都加密了!奋飞:这么拉风,拉出来咱们盘盘。v10.3.2二、步骤32位和64位我们掌握了那么多方法,先搜字符串呢?还是先Hook呢?子曾经曰过:看到32位签名就要想起MD5和HmacSHA1,看到64位签名就要想起HmacSHA256。那就先搞搞java的密码学相关

某神奇App data加密算法解析(一)

一、目标李老板:奋飞呀,我遇到一个超级牛掰的App,它请求的时候有个data参数加密,用尽了你介绍的所有的方法,都找不到它是如何加密的。奋飞:子曾经曰过,老板的嘴,骗人的鬼。有这么牛掰的App,那么我们这帮兄弟早就失业了。某神奇Appv10.1.0点社区随便打开一篇有评论的文章今天的目标就是这个data二、步骤搜索特征字符串目标是data,所以我

手把手教你从Apk中取出算法

一、目标李老板:奋飞呀,我最近从Apk里面跟踪到一个算法,代码清晰,但是我不会java,把他翻译成python貌似挺费劲的,有没有轻松省力的方法呀?奋飞:有的呀,给我加工资,我来翻译。某电商Appv10.4.5,升级之后老有小伙伴说他的sign算法变了,其实他就是做了点小动作。sign参数没有动,uuid是明文去做签名,但是抓包请求里面找不到明文uu

某小视频App v10.x 手机号加密算法分析

一、目标今天的目标是手机号加密,app变化太快,以前都是明文的。TIP:某小视频Appv10.2.30.24518二、步骤字符串匹配也许是手机号都是1xx开头,也许是这个加密字符串有个特征头。反正经过我们观察,发现它大概率是3sCt开头。而这种加密算法大概率是在Native层去做的。所以我们首选是去hooklibart里面的GetSt