某右sign-v2签名算法追踪及逆向还原

已于 2024-10-07 15:39:42 修改
阅读量1k 收藏 18
点赞数 21
分类专栏： 技术实战 文章标签： 算法 c语言 golang ios
于 2024-10-07 15:23:07 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2403_87731058/article/details/142741144
版权

可以看到 请求中"sign=v2-xxxxxxxxxx"老样子 拖入ida中分析 进行字符串搜索"sign="

第四个看起来比较像 双击字符串进入

按下快捷键X

只有一处 我们还是双击进入

继续按下快捷键X

从函数名来看的话"-[ZYURLRequest obtainMostSuitableRequest]"比较像 此处没什么捷径 只能通过看哪个函数名像 如果选错了就会浪费些时间

双中双击进入 直接F5查看伪代码

可以看到通过传参调用"+[libProtocol sign_data:]"函数来进行签名的 参数又是通过传参调用"+[libProtocol encode_aes:]"得到的

1

2

3

4

5

v240 = +[libProtocol encode_aes:](&OBJC_CLASS___libProtocol, "encode_aes:", v239);

v241 = objc_retainAutoreleasedReturnValue(v240);

v242 = +[libProtocol sign_data:](&OBJC_CLASS___libProtocol, "sign_data:", v241);

v243 = objc_retainAutoreleasedReturnValue(v242);

v249 = objc_msgSend(&OBJC_CLASS___NSString, "stringWithFormat:", CFSTR("?sign=%@"), v243);

直接HOOK

1

2

3

4

5

6

7

8

9

10

11

12

13

14

%hook libProtocol

+ (id)encode_aes:(id)arg1 {

  %log;

  id result = %orig;

  HBLogDebug(@"[Hook] libProtocol encode_aes] ret: %@", result);

  return result;

}

+ (id)sign_data:(id)arg1 {

  %log;

  id result = %orig;

  HBLogDebug(@"[Hook] libProtocol sign_data] ret: %@", result);

  return result;

}

%end // hook libProtocol class end

日志打印如下

先复制出encode_aes的参数 保存hex查看

可以看到参数是明文的 既然是aes加密那就需要key 至于key是什么 如何产生的我们后面再来分析

我们先进入内部查看签名算法是如何实现的 F5代码如下：

关注点在一个函数"MD5String" 先来看下参数是什么

1

2

3

4

5

6

7

8

9

v3 = objc_retain(a3, a2);

v4 = (void *)objc_retainAutorelease(v3);

v5 = objc_msgSend(v4, "bytes");

v6 = objc_msgSend(v4, "length");

v7 = (size_t)v6;

v8 = (void **)operator new(((unsigned __int64)v6 + 16) & 0xFFFFFFFFFFFFFFF0LL);

memcpy(v8, v5, v7);

v28 = v8;

MD5String(&v28);

相信看到这里各位已经明白了参数是什么 参数就是aes加密后的数据 只是做了层转换 从NSData转为byte 根据函数名得知该算法是md5

那么直接编写代码进行测试

1

2

3

4

5

d = bytes.fromhex('8a07d175 47300202 02ead3bc bcbca5a5 19b21e13 1186e096 2a467fa5 661081c1 65d014f7 2a74a7bf 333c2a27 5937de20 25d2c4f9 c232a50a 3e90affc 319ca0ee b0e34df3 016bf74d a231d5da 41fde907 f6242573 f20d38d2 86e61d42 0487db3b bf029d65 a0733533 198b6194 63db3d3c fe234f84 7dcdee21 2521ab89 7f48e3f2 5d002559 7b5e814b 55fe2581 bec64b24 5082bd16 9910e2f8 e24cf3e8 e4346e3c 40f43237 cc75baff 0d97aea6 9f4c04d9 8f6d9f5f 91c31faa dbbda58d 13664d3a f5d7dd77 625f3559 91e74de9 4fcb3149 f9d54897 b2ac8ee4 2a613df6 cbdeda5e 98c9ba39 cdd717f9 19e7cbad 42c171d6 03d09daa b42aa123 66da3320 eddaf432 b655cc97 93280ee9 94687272 7d724658 8492a7b3 8b6ae9a7 bd33d63f 1f122155')

md5 = hashlib.md5()

md5.update(d)

print(md5.hexdigest())

# f94fd832969b8655eab3078e924b989e

结果发现计算结果不对

好吧 看来它并不是简简单单的MD5算法了 大概率是魔改过的md5算法

那么直接上手 先看下MD5String调用了多少函数

也没几个函数 那么就不管他改了什么 直接上手还原算法吧 当然你也可以下载MD5算法源码进行调试对比算法差异

以下是还原出的算法 直接放源码 由于算法过长 论坛发帖无法放下 所以直接放到附件里了

OK 结果跟手机上算出的一致  到这里sign-v2算法就还原完了

至于AES加密中key的来源 我们大概看下 后续有时间的话我会在帖子中补充

在之前我们Hook了 +[libProtocol encode_aes:] 我们直接在IDA中搜索一下类名"libProtocol"

set_portocol_key和get_portocol_key 看起来比较像设置key和获取key的函数 我们直接Hook

日志打印如下

抓包工具如下

抓包工具对比 可以看到加密key 在Headers["X-Xc-Proto-Req"]字段中 通过调用[libProtocol get_protocol_key]函数获取

而request data为[libProtocol encode_aes]加密后的数据  那么具体aes key是如何产生的呢 这个容我日后再做分析

可以看到response headers['X-Xc-Proto-Res'] 也有疑似加密key的数据

截图对比 [libProtocol set_protocol_key] 设置的参数为respnose headers['X-Xc-Proto-Res']字段的数据

截取response data hex数据查看对比 可以看到[libProtocol decode_aes]参数就是请求返回的数据 而且[libProtocol decode_aes]函数返回的数据是明文数据

最新版本的变化有两处

1.新增了"sign-v2"算法

2.request data 以及 response data 内容进行了加密

OK 我们直接来抓包 具体如何抓包上篇文章有讲 就不在此具体描述了

可以看到 请求中"sign=v2-xxxxxxxxxx"老样子 拖入ida中分析 进行字符串搜索"sign="

第四个看起来比较像 双击字符串进入

按下快捷键X

只有一处 我们还是双击进入

继续按下快捷键X

从函数名来看的话"-[ZYURLRequest obtainMostSuitableRequest]"比较像 此处没什么捷径 只能通过看哪个函数名像 如果选错了就会浪费些时间

双中双击进入 直接F5查看伪代码

可以看到通过传参调用"+[libProtocol sign_data:]"函数来进行签名的 参数又是通过传参调用"+[libProtocol encode_aes:]"得到的

1

2

3

4

5

v240 = +[libProtocol encode_aes:](&OBJC_CLASS___libProtocol, "encode_aes:", v239);

v241 = objc_retainAutoreleasedReturnValue(v240);

v242 = +[libProtocol sign_data:](&OBJC_CLASS___libProtocol, "sign_data:", v241);

v243 = objc_retainAutoreleasedReturnValue(v242);

v249 = objc_msgSend(&OBJC_CLASS___NSString, "stringWithFormat:", CFSTR("?sign=%@"), v243);

直接HOOK

1

2

3

4

5

6

7

8

9

10

11

12

13

14

%hook libProtocol

+ (id)encode_aes:(id)arg1 {

  %log;

  id result = %orig;

  HBLogDebug(@"[Hook] libProtocol encode_aes] ret: %@", result);

  return result;

}

+ (id)sign_data:(id)arg1 {

  %log;

  id result = %orig;

  HBLogDebug(@"[Hook] libProtocol sign_data] ret: %@", result);

  return result;

}

%end // hook libProtocol class end

日志打印如下

先复制出encode_aes的参数 保存hex查看

可以看到参数是明文的 既然是aes加密那就需要key 至于key是什么 如何产生的我们后面再来分析

我们先进入内部查看签名算法是如何实现的 F5代码如下：

关注点在一个函数"MD5String" 先来看下参数是什么

1

2

3

4

5

6

7

8

9

v3 = objc_retain(a3, a2);

v4 = (void *)objc_retainAutorelease(v3);

v5 = objc_msgSend(v4, "bytes");

v6 = objc_msgSend(v4, "length");

v7 = (size_t)v6;

v8 = (void **)operator new(((unsigned __int64)v6 + 16) & 0xFFFFFFFFFFFFFFF0LL);

memcpy(v8, v5, v7);

v28 = v8;

MD5String(&v28);

相信看到这里各位已经明白了参数是什么 参数就是aes加密后的数据 只是做了层转换 从NSData转为byte 根据函数名得知该算法是md5

那么直接编写代码进行测试

1

2

3

4

5

d = bytes.fromhex('8a07d175 47300202 02ead3bc bcbca5a5 19b21e13 1186e096 2a467fa5 661081c1 65d014f7 2a74a7bf 333c2a27 5937de20 25d2c4f9 c232a50a 3e90affc 319ca0ee b0e34df3 016bf74d a231d5da 41fde907 f6242573 f20d38d2 86e61d42 0487db3b bf029d65 a0733533 198b6194 63db3d3c fe234f84 7dcdee21 2521ab89 7f48e3f2 5d002559 7b5e814b 55fe2581 bec64b24 5082bd16 9910e2f8 e24cf3e8 e4346e3c 40f43237 cc75baff 0d97aea6 9f4c04d9 8f6d9f5f 91c31faa dbbda58d 13664d3a f5d7dd77 625f3559 91e74de9 4fcb3149 f9d54897 b2ac8ee4 2a613df6 cbdeda5e 98c9ba39 cdd717f9 19e7cbad 42c171d6 03d09daa b42aa123 66da3320 eddaf432 b655cc97 93280ee9 94687272 7d724658 8492a7b3 8b6ae9a7 bd33d63f 1f122155')

md5 = hashlib.md5()

md5.update(d)

print(md5.hexdigest())

# f94fd832969b8655eab3078e924b989e

结果发现计算结果不对

好吧 看来它并不是简简单单的MD5算法了 大概率是魔改过的md5算法

那么直接上手 先看下MD5String调用了多少函数

也没几个函数 那么就不管他改了什么 直接上手还原算法吧 当然你也可以下载MD5算法源码进行调试对比算法差异

以下是还原出的算法 直接放源码 由于算法过长 论坛发帖无法放下 所以直接放到附件里了

OK 结果跟手机上算出的一致  到这里sign-v2算法就还原完了

至于AES加密中key的来源 我们大概看下 后续有时间的话我会在帖子中补充

在之前我们Hook了 +[libProtocol encode_aes:] 我们直接在IDA中搜索一下类名"libProtocol"

set_portocol_key和get_portocol_key 看起来比较像设置key和获取key的函数 我们直接Hook

日志打印如下

抓包工具如下

抓包工具对比 可以看到加密key 在Headers["X-Xc-Proto-Req"]字段中 通过调用[libProtocol get_protocol_key]函数获取

而request data为[libProtocol encode_aes]加密后的数据  那么具体aes key是如何产生的呢 这个容我日后再做分析

可以看到response headers['X-Xc-Proto-Res'] 也有疑似加密key的数据

截图对比 [libProtocol set_protocol_key] 设置的参数为respnose headers['X-Xc-Proto-Res']字段的数据

截取response data hex数据查看对比 可以看到[libProtocol decode_aes]参数就是请求返回的数据 而且[libProtocol decode_aes]函数返回的数据是明文数据

至此某右的请求及返回数据的加密与解密流程分析完毕 至于aeskey是如何生成的就留到下次分解了 有时间的话我会再编辑到本篇文章末尾

至此某右的请求及返回数据的加密与解密流程分析完毕 至于aeskey是如何生成的就留到下次分解了 有时间的话我会再编辑到本篇文章末尾

逆向软件开发
关注
专栏目录
ida android sign加密,最右sign-v2签名算法追踪及逆向还原
weixin_39998998的博客
06-02 651
原标题：最右sign-v2签名算法追踪及逆向还原 本文为看雪论坛优秀文章看雪论坛作者ID：尐进本篇文章应该于N个月前就写了，由于拖延症一直拖到现在。其实一直打算写一系列逆向实战，比如某音、某手、某乎、某宝，也不知道会不会有时间且不拖延的写下去。好了言归正传，上次分析的最右APP版本为4.2.1 已经是18年10月的时候了 当时签名算法只有一个"sign" ，而本次分析的是目前最新版本5.5.9 。...
Android逆向笔记-破解某APP签名摘要算法
IT1995的博客
07-13 1585
这里科普几个摘要算法，散列算法（签名算法）有：MD5、SHA1、HMAC 用途：主要用于验证，防止信息被修。具体用途如：文件校验、数字签名、鉴权协议 MD5：MD5是一种不可逆的加密算法，目前是最牢靠的加密算法之一，尚没有能够逆运算的程序被开发出来，它对应任何字符串都可以加密成一段唯一的固定长度的代码。 SHA1：是由NISTNSA设计为同DSA一起使用的，它对长度小于264的输入，产生长度为160bit的散列值，因此抗穷举(brute-force)性更好。SHA-1设计时基于和MD4相同原理
【iOS逆向】某运营商签名算法分析
小陈的技术博客
10-09 1350
分析某运营商App的x-lemon-sign签名
逆向签名_sign
A345545108的博客
05-04 1267
在安卓(Android)开发中，Context是一个非常重要的概念，它代表了应用程序的当前状态信息。3、获取系统服务：通过Context，您可以获取系统级别的服务，例如获取系统的传感器、网络状态、存储管理等。如果去逆向so文件有点太麻烦了，一般DES加密的key是固定的，所以我们可以通过多次hook得到DES的key值，如果发现就是固定的，那么就可以直接拿来使用了。4、应用程序级别的操作：Context还可以用于执行应用程序级别的操作，如发送广播、获取应用程序包名、获取应用程序的数据目录等。
Android APK签名总结-- V1签名和V2签名使用和区别
yzwfeng的专栏
06-07 6631
jarsigner 是JDK提供的针对jar包签名的通用工具, 位于 apksigner 是Google官方提供的针对Android apk 签名验证的专用工具 位于 Android SDK/build-tools/SDK version/apksigner.bat 在Android Studio 中点击菜单 Build -> Generate signed apk … 可以打包签名不管是apk 包,还是jar 包,本质都是zip 格式的压缩包,所以他们的签名过程都差不多(仅限V1签名), 以上两个工具都可
SO逆向入门实战教程三：V2-Sign
lilac的博客
06-03 1万+
文章目录一、前言二、准备三、Unidbg模拟执行四、算法还原五、尾声 一、前言 这是SO逆向入门实战教程的第三篇，上篇的重心是Unidbg的Hook使用，本篇的重点是如何在Unidbg中补齐JAVA环境以及哈希算法的魔改。 侧重新工具、新思路、新方法的使用，算法分析的常见路子是Frida Hook + IDA ，在本系列中，会淡化Frida 的作用，采用Unidbg Hook + IDA 的路线。 主打入门，但并不限于入门，你会在样本里看到有浅有深的魔改加密算法、以及OLLVM、SO对抗等内容。 对样本.
Android逆向入门3——怎样才能找到sign算法
lilac的博客
07-24 8894
鸽鸽鸽 明天更新
安卓逆向-豆瓣app签名算法分析与解密（下）
qq_23594799的博客
09-07 2587
文章目录1、反汇编豆瓣APP2、定位签名计算位置3、获取豆瓣APP的签名4、HMAC Hash加密逻辑分析5、代码实现6、项目地址 完整工程上传到了GitHub上，仅限于研究使用，欢迎star 项目地址：https://github.com/bestyize/DoubanAPI 1、反汇编豆瓣APP 我们用强大的jadx来反汇编豆瓣app 选择文件-打开。然后找到豆瓣app的安装包后打开。 2、定位签名计算位置 点击搜索图标，我们搜索一下在上一节找的_sig是在哪里组装的 双击进去，可以看到一个叫做
某招聘网站搜索结果接口之acw_sc__v2逆向
非专业程序员小田
05-03 1358
JS逆向，JS逆向学习，JS生成cookie，加密分析
Android逆向-实战sign分析-某某合伙人_v4.0.9
哔_哩哩!的博客
06-13 4272
1.基础分析 1.1.基础分析 工作中经常会对一些app进行安全审计，一般在拿到应用后可以使用APK Helper工具对应用做个简单分析，了解目标的包名，版本号，名称等基础信息，之后再安装到手机上熟悉下应用的业务，该应用属于哪类app，之后就是思考业务上可能存在的攻击点。 本次目标是一个电商应用，简单使用后可知应用存在登录，购买，支付等众多攻击点，这里我们就从登录入手。 登录逻辑的常见审计思路有： 1.审计客户端与服务端交互时是否直接将用户名密码进行明文传输。 2.客户端是否将用户登录的错误分开提醒如单独提
最新xhs旋转滑块验证码分析（含识别与轨迹算法）
吴秋霖的博客
06-03 3936
旋转滑块验证码纯算法+协议过！高通过率含流程分析
iOS逆向_使用frida、ida逆向某app的网络请求signature验签生成算法
weixin_33795093的博客
05-13 4232
准备 通过Charles抓包发现，请求中有一个验签参数signature,每次请求网络都会变化。 请求地址： http://xxxx.xxxxxx.com/api/article/v2/get_category 参数： { "content":{"muid" :"f7e2cb93-5cf3-4b9f-a035-30555c13a167"}, "signature":"6c171c8f2bb05c...
[网络安全自学篇] 八十二.WHUCTF之隐写和逆向类解题思路WP（文字解密、图片解密、佛语解码、冰蝎流量分析、逆向分析）
热门推荐
杨秀璋的专栏
06-04 1万+
这是作者网络安全自学教程系列，主要是关于安全工具和实践操作的在线笔记，特分享出来与博友们学习，希望您喜欢，一起进步。前文分享了Easy_unserialize解题思路，详细分享文件上传漏洞、冰蝎蚁剑用法、反序列化phar等。这篇文章将详细讲解WHUCTF隐写和逆向题目，包括文字解密、图片解密、佛语解码、冰蝎流量分析、逆向分析。第一次参加CTF，还是学到了很多东西。人生路上，要珍惜好每一天与家人陪伴的日子。感谢武汉大学，感谢这些大佬和师傅们（尤其出题和解题的老师们）~
JS逆向系列之猿人学爬虫第16题-window蜜罐
自成背后的博客
06-27 3395
JS逆向系列之猿人学爬虫第16题题解
PCA（主成分分析）算法的应用场景
最新发布
huanfeng_AI的博客
11-09 133
需要注意的是，PCA并不适用于所有场景。例如，当数据之间存在非线性关系时，PCA可能无法完全揭示数据的内在结构。此外，PCA对初始变量的顺序和标签敏感，不同的变量顺序可能导致不同的主成分结果。因此，在选择数据分析方法时，需要根据具体的数据和任务需求来决定是否使用PCA。
算法基础-链表
August的专栏
11-05 241
当链表的长度为偶数时，head找到的中点是靠后的，因为fast相对slow移动只快了1步，而head.next找到的中点是靠前的，因为fast相对slow移动快了2步。这2种方式寻找链表的结点主要区别是 当链表的长度为奇偶数时，找到链表中点的位置一个靠后，一个靠前。使用快慢指针寻找链表的中点有2种方式，分别是fast=head;当链表为奇数时 [1->2->3->4->5]当链表长度为奇数时，找到的中点2种方式是一样的。当链表为偶数时 [1->2->3->4]
STL set
hls0611的博客
11-09 101
练习题：P1059 [NOIP2006 普及组] 明明的随机数。
【LeetCode】【算法】160.相交链表
passer__jw767的博客
11-05 342
Leetcode 160. 相交链表
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值