SRC挖掘
业务支付逻辑安全案例
某度ID值爆破任意登录
社交应用越权泄露漏洞
某迅相册APP绕过XSS
某度利用上传触发XSS
泄露验证造成签约越权
小程序放包绕过人脸识别
业务逻辑绕过人脸识别
竞争并发拿下挑战赛
某B未绑定导致任意注册
时间校验机制领取VIP
某视频不安全对象引用
无回显SSRF修改利用
社交应用放包越权测回
理财支付漏洞四舍五入
某迅API分享导致重定向
吃货去改包提权超管
某云厂商社区SSRF挖掘
代金卷导致的支付错误
某鹅邮箱附件上传XSS
导出功能导致任意修改
某商城补领优惠券并发
限制购买多次创建绕过
钓鱼供应链挖掘利用
老SQL注入换思路就行
EDUSRC玩通用逻辑
企业功能从限制入手
从逆向角度玩APP测试
CNVD通用漏洞证书思路
地图Key泄露绕过利用
绕过CDN获取2高2中
小迪安全知识库
-
+
首页
从逆向角度玩APP测试
从逆向角度玩APP测试
**0x1 简述** 在对银行APP进行渗透测试时,遇到了APP被加壳以及流量被加密。此篇文章针对以上问题以修改SO文件方式进行绕过。 **0x2 反编译APP** 首先APP作了加固,加固方式无从得知,从MT管理器提供的加固方法为:**娜迦加固**。仔细分析发现并不是,说明了MT管理器有时候提供的加固方法也会出错。反编译截图如下: image\-20230415154512501 由于反编译后的包较少,直接挨个查看发现了一个可疑函数: private static void copyAssets(String output, String input, Context context) { try { InputStream inputStream \= context.getAssets().open(input); File localFile \= new File(output); byte\[] bytes \= new byte\[65536]; BufferedInputStream bufferedInput \= new BufferedInputStream(inputStream); BufferedOutputStream bufferedOutput \= new BufferedOutputStream(new FileOutputStream(localFile)); boolean first \= true; byte\[] nagic \= {78, 71, 0, 0}; byte\[] magic \= {100, 101, 120, 10}; while (true) { int i \= bufferedInput.read(bytes); if (first) { first \= false; if (!(output.endsWith(Defines.\_DEX) \&\& bytes\[0] \=\= nagic\[0] \&\& bytes\[1] \=\= nagic\[1] \&\& bytes\[2] \=\= nagic\[2] \&\& bytes\[3] \=\= nagic\[3]) \&\& output.endsWith(Defines.\_DEX) \&\& bytes\[0] \=\= 110 \&\& bytes\[1] \=\= 97 \&\& bytes\[2] \=\= 103 \&\& bytes\[3] \=\= 97\) { System.arraycopy(magic, 0, bytes, 0, magic.length); } } if (i \<\= 0\) { bufferedOutput.flush(); bufferedOutput.close(); bufferedInput.close(); return; } bufferedOutput.write(bytes, 0, i); } } catch (Exception e) { } } image\-20230415154629629 仔细分析可以看出magic字段为:\*\*{100, 101, 120, 10}\*\*,换算成ASCII码值为:dex ,可推测为dex文件的文件头,继续往下看会发现最后使用 bufferedOutput.write(bytes, 0, i); 将文件写出,往上追溯代码可以得出输出目录: image\-20230415155240237 按住Ctrl并点击对应变量可以得到输出目录在应用程序的数据目录中.cache目录下,这样我们安装APP并运行后,前往该目录的.cache目录,便可以看到对应的dex文件,这就是原生的dex文件,将其导入IDA继续进行分析 我们在抓包时可以看到API目录为:**mobile**开头的,如下图所示: image\-20230415155702946 接下来直接搜索**mobile**开头的API,找到其中一个查看源码,可以在源码附近发现加密函数:**telecomSMEncrypt** image\-20230415160053204 跟进**telecomSMEncrypt**函数可以发现使用了Native调用so文件里的函数进行加解密: image\-20230415160206246 **0x3 分析so** 那么我们便来分析一下这个so文件,使用ida打开so文件,在左侧函数框处直接搜索:**getNativeSM4EncryptValue**,发现搜索不到,于是搜索**JNI\_Onload**函数,幸运的是这个函数并没有被混淆,于是开始分析: image\-20230415160514393 进入后发现函数名显示出来了,我们进入:**getNativeSM4EncryptValue**函数 image\-20230415160612178 双击进入函数\*\**Z10getSMValueP7\_JNIEnvP8\_jobjectP8\_jstringS4*\*\*: image\-20230415160903415 进入这个函数后发现使用return返回一个函数,继续往里跟: image\-20230415161044925 跟进来发现有SM4加密的特征了,这里分析了一下,推测**byte\_1FFDB9**为key值,**a1**为待加密的原文,我们看上面的**byte\_1FFDB9s**是如何生成的: image\-20230415161426194 分析出来key是32位**byte\_18703A**数组的随机值,并且可以看到依据是**byte\_1FFDB8**的值为0的情况下,推测为每次打开APP都会初始化这个key值。知道key值得生成方法后,我们需要确定SM4算法的模式是什么,我们跟进**SM4Encrypt**函数发现: image\-20230415161816590 得了,ECB模式,不需要IV,所以这里就分析完SM4算法了。这里应该会有一个疑问:**既然每次打开APP时,key都会变,我们都知道ECB模式的SM4算法是使用key进行解密的,服务端肯定不知道key是多少呀,那么是怎么去解密呢?**既然如此,我们继续回头分析后面的代码: image\-20230415162202270 我们注意到上方的代码中出现了:\*\*%s\|%s\|%s\*\*,回去观察请求体发现也出现了两个 **\|** ,因此我们需要确定一下这三个 **%s** 都是什么,我们往前分析v12,v13和v8 image\-20230415162702746 可以看到v12是SM2加密key的值**(但是SM2是非对称加密,没有私钥是无法解出key值的。而私钥只能在服务端有)**,下方图中可以看到v13是SM4加密的值 image\-20230415162846065 再来看v8的值,可以看出v8的值是HMAC加密后的值,这里应该是SM3加密后的值 image\-20230415163022563 那么其实我们只需要固定住key值,之后的所有密文都可以使用我们固定的key值进行加解密了,这里有一个思路:把前面的**byte\_18703A**变量中的所有值改成同一个。 image\-20230415163357418 使用上方方法,修改如下,全部固定成大写的A: image\-20230415163338155 这样做的好处就是获取的key值只能是32个A了,我们就可以直接使用32个A作为key去进行SM4解密了。 **0x4 替换so** 我们将修改好的so进行保存:**Edit \- Patch program \- Apply patches input file...** 然后将其替换值APK路径:\*\*/data/app/\~\~xxxxxxxxx\=\=/lib/arm/\*\*目录下,重启应用程序进行抓包即可。
xiaodi
2026年4月29日 16:19
0 条评论
转发
收藏文档
上一篇
下一篇
手机扫码
复制链接
手机扫一扫转发分享
复制链接
分享
链接
类型
密码
更新密码
有效期
Markdown文件
Word文件
PDF文档
PDF文档(打印)