【移动安全】【Frida hook实例】加密+签名分析

admin 2023年4月2日02:32:27评论115 views字数 2317阅读7分43秒阅读模式

前言

某APP,分析后发现同时存在加密和签名,刚好来总结一下。

burp抓包,存在加密,加密后的内容是一串十六进制字符串。

【移动安全】【Frida hook实例】加密+签名分析
加密

加密分析

看格式猜不出来是啥,可能是对称加密后hex处理了一下,先尝试hook一下javax.crypto.Cipher碰碰运气

android hooking watch class_method javax.crypto.Cipher.getInstance --dump-argsandroid hooking watch class_method javax.crypto.Cipher.doFinal --dump-args --dump-backtrace --dump-returnandroid hooking watch class_method javax.crypto.Cipher.update --dump-args --dump-return

hook后会直接出现大量调用方法的数据包,一般是其他包发起的,比如高德API啥的,所以需要进一步确认目标包是不是也采用的这些加密算法。

【移动安全】【Frida hook实例】加密+签名分析
高德地图加密

找一个存在加密的功能点,比如登录界面,然后进行登录,查看有没有hook到

【移动安全】【Frida hook实例】加密+签名分析
加密算法

上图就是hook到的结果,可以看到堆栈明显和之前的不一样,输入参数进行转string后结果如下,可见为我们输入的手机号,也就证明确实采用了对称加密算法。

{"sign":"547e2eff92ff0ba527a4538e552a9467","func":"user/checkMsgCode","data":{"phone":"13333333333","checkcode":"1234","userid":""}}

此时我们已经确认底层加密使用了javax.crypto.Cipher.doFinal函数,但是该函数输入输出都是byte数组,而数据包中的密文是一串十六进制的数据,因此一定有另一个包装类函数来直接将数据包中的十六进制直接转换成明文,或者将明文直接加密为十六进制字符串

分析刚才的堆栈信息,可以明显看出有一个方法 com.xxx.lib.util.encrypt.AES128Helper.encrypt去调用了javax.crypto.Cipher.doFinal,那么这个类肯定就是包装类了。

看看这个类的所有方法(主要关心加解密方法)

android hooking list class_methods com.xxx.lib.util.encrypt.AES128Helper
【移动安全】【Frida hook实例】加密+签名分析
image-20230321140910017

hook对应的函数,看看加密和解密是否和数据包一致

android hooking watch class_method com.xxx.lib.util.encrypt.AES128Helper.encrypt --dump-args --dump-returnandroid hooking watch class_method com.xxx.lib.util.encrypt.AES128Helper.decrypt --dump-args --dump-return

再次登录触发加密,可见已经找到了和数据包加密数据一致的加解密算法,可直接将明文加密为十六进制数据串,也可以将加密后的十六进制数据串直接转换为明文。

【移动安全】【Frida hook实例】加密+签名分析
image-20230321141349741

然后就是编写brida脚本了,不再赘述了。

签名分析

上面我们已经成功获取到了数据的加解密方式,但解密后的数据如下:

{"sign":"547e2eff92ff0ba527a4538e552a9467","func":"user/checkMsgCode","data":{"phone":"13333333333","checkcode":"1234","userid":""}}

其中存在sign值,该值一般是字符串内容的hash,用于验证请求的合法性,如果我们不知道这个sign值如何生成的,仍然无法篡改数据包。

该值为32位,常见的hash算法有md5HMAC,先尝试hook一下md5相关的方法

android hooking watch class_method java.security.MessageDigest.getInstance --dump-argsandroid hooking watch class_method java.security.MessageDigest.update --dump-args --dump-return --dump-backtrace

然后还是去登录,分析新产生的的日志和堆栈信息,看有没有被调用到

发现这个堆栈和其他的都不一样,而且类名和目标有关,很可疑

【移动安全】【Frida hook实例】加密+签名分析
堆栈

分析一下传入的签名数据

【移动安全】【Frida hook实例】加密+签名分析
image-20230321181026097

转换为字符串为user/login,计算md5的值为739a748bd3c748b88deac114d318d445,确实和解密后的内容一致。

【移动安全】【Frida hook实例】加密+签名分析
image-20230321181214950

因此可以确认此处的sign就是计算的func参数的md5值。

调用他的方法去生成md5值的hook代码如下:

Java.perform(function() {  var clazz = Java.use('com.xxx.lib.util.encrypt.SecurityUtil');  var result = clazz.EncoderByMd5("user/login");  console.log(result);});
【移动安全】【Frida hook实例】加密+签名分析
image-20230321181621917


原文始发于微信公众号(初始安全):【移动安全】【Frida hook实例】加密+签名分析

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年4月2日02:32:27
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   【移动安全】【Frida hook实例】加密+签名分析https://cn-sec.com/archives/1645306.html

发表评论

匿名网友 填写信息