type
status
slug
tags
category
icon
password
Property
Jul 26, 2024 11:22 AM
date
summary
🤔 前言
最近项目遇到一个有趣的App，通过简单的hook ssl绕过就能正常抓包，但是数据包里面有Sign签名，签名算法又是使用java2c 并且做了混淆，如果想要对数据包修改，就很麻烦并且还涉及到了反Frida。在这个过程中可谓是一波三折，从frida到xposed再最后到frida折来折去，过程还是学到挺多
📝过程
签名
首先正常使用基操 xposed 绕过ssl可以正常抓包，发现应用有sign签名算法
尝试直接修改数据包(mobile=10086’)，发现因为签名不一致，提示签名校验失败。整理一下思路：应该所有数据包到了后端，应该都会先进行签名校验。如果签名校验不通过则无法修改数据包（越权、注入漏洞都没法正常测试）
尝试逆向分析签名算法，发现签名算法疑似在com.XXXXX.SignUtils类中
发现使用@LDPProtect注解，怀疑是Java2C的一种加密手法，应该是类似下面的这种加密手法。
https://www.imooc.com/article/306075
看见几维安全怀疑应该就是几维加固了，看了几个几维加固的分析文章，一头雾水超纲了……(还是跟着分析尝试了一下无果)
尝试提取so文件查找加密算法sign的具体实现，发现C语言代码做了混淆
逆向/debug 混淆后的C函数比较麻烦，换种思路，使用frida来hook函数，打印签名结果
果然不出所料，发现应用存在反frida ，frida被退出了
xposed
换种hook方式，使用xposed发现lsposed可以正常hook，尝试使用xposed来hook返回值，结果和抓包的一致
和上面hook的结果和抓包的一致，代表就是这个函数进行签名计算
曲线救国：sign函数传递进去了ruqest请求包，那么直接hook请求包，然后修改，这样无需逆向算法就可以得到修改后的sign数值了。
编写代码尝试在sign计算前修改request数值
在这里代码编写新学了YukiHookAPI的xposed框架，还挺好用强烈推荐
- 反射抓取request并打印
- 构造新的数值
- 修改数值
尝试查看数值（reqId、和mobile）被修改成功，没有提示签名签名校验失败
效率太低
虽然使用上面的方式已经可以实现，怎奈效率太低(虽然lspsed已经不用每次重启设备)但是每次修改完代码，需要重新运行等！也是很麻烦，搞起来就是没有frida顺畅也愉快，本来使用frida啪啪啪几秒钟的事情，使用xposed 搞了几个小时才弄好。
反反frida
hook检测frida-os
一开始也说过这个应用会检测frida
于是乎在网上寻找办法，尝试打印so 调用堆栈，看看那个so做了frida检测，使用脚本打印so和堆栈
根据上方信息， 对应用程序过滤（ 就是 fork 子进程）来实现反反调试
通过脚本加载成功运行frida
魔改frida
还有一种思路就是运行魔改服务端frida
运行魔改 frida
直接运行frida成功，没有被检测
frida
解决完frida运行的问题，那后面hook就方便了，直接尝试hook签名算法，直接创建一个RPC接口
加载脚本，尝试rpc调用，可以看到成功调用sign算法
通过python调用
🤗总结归纳
在这次Android逆向工程中，我的主要挑战是破解应用的签名加密算法。该算法通过Java2C技术实现并加入混淆，增加了逆向分析的难度。此外，应用还部署了反Frida机制。我最终成功绕过这些保护措施。
先用Xposed框架绕过SSL认证，成功抓取数据包，但签名校验使简单修改无效。定位到疑似签名算法的类后，代码混淆和Java2C保护使直接逆向不可能。我尝试用Frida hook函数，但应用能检测到Frida并阻止其运行。
于是我用Xposed hook相关函数，成功在签名计算前修改请求数据，但效率低。分析检测细节后，我成功hook关键函数，并修改Frida服务端，使其在不被检测的情况下运行。
有了可靠运行Frida的能力，我创建了RPC接口来hook签名算法，并通过Python脚本调用，大大提高了效率。
这次经历加深了我对Android逆向工程的理解，提升了对hook技术和反反调试策略的掌握，证明了持续学习和灵活适应的重要性。我希望这次实战能为其他安全研究人员提供帮助，特别是在处理加密算法和反调试措施时。