SRC挖掘
业务支付逻辑安全案例
某度ID值爆破任意登录
社交应用越权泄露漏洞
某迅相册APP绕过XSS
某度利用上传触发XSS
泄露验证造成签约越权
小程序放包绕过人脸识别
业务逻辑绕过人脸识别
竞争并发拿下挑战赛
某B未绑定导致任意注册
时间校验机制领取VIP
某视频不安全对象引用
无回显SSRF修改利用
社交应用放包越权测回
理财支付漏洞四舍五入
某迅API分享导致重定向
吃货去改包提权超管
某云厂商社区SSRF挖掘
代金卷导致的支付错误
某鹅邮箱附件上传XSS
导出功能导致任意修改
某商城补领优惠券并发
限制购买多次创建绕过
钓鱼供应链挖掘利用
老SQL注入换思路就行
EDUSRC玩通用逻辑
企业功能从限制入手
从逆向角度玩APP测试
小迪安全知识库
-
+
首页
从逆向角度玩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文档(打印)