首页
论坛
课程
招聘

[原创]控制流Java 层 新“加固”方式

2019-11-8 18:27 5352

[原创]控制流Java 层 新“加固”方式

2019-11-8 18:27
5352

Hi大家好,前阵子和MT的作者一起搞了个东西——Java层代码混淆方案。


目前的加固主要是在so层做研究,针对Java层代码的保护非常少。

虽然加固会隐藏dex,但是可以很容易地把它脱出来,脱出来的dex除了一部分方法被Native化了,其它代码都完全暴露在外。

另外加固也会影响APP的性能和兼容性,比如一些壳会废掉了安卓原生的oat执行模式,导致性能下降。





考虑到目前加固存在的一些缺点,我们决定做一套针对Java层的高强度代码混淆方案。目前已经实现了这几个功能:


名称混淆:使用特殊符号对类名、方法名、字段名混淆,使用支持四大组件和View。

常量加密:对字符串和资源ID进行加密

资源混淆:比开源的那个混淆得更彻底

控制流混淆:控制流平坦化和控制流伪造



功能上其实已经实现了ollvm的-fla、-bcf、-sobf,不过-sub指令替换没有做,但做起来倒也不难。

实现原理主要是通过dexlib2进行代码修改,控制扁平化稍微复杂点,通过dex2ir2dex实现。

使用我们的方案进行混淆不需要源代码,输入apk,混淆完输出apk,可以一键完成,只对哪些代码进行混淆也是完全可以控制的。


目前该方案已经在MT管理器上投入使用了几个月,兼容性和稳定性基本没有问题。

之前 一直没放出来 直到朋友用 说效果还不错  寻思放出来 看看



混淆效果如下图 (jadx1.0版本)








IDA效果图




                                          混淆前的控制流程图



                                         混淆后的控制流程图



先说一下优点:

1,保证了 安卓原有的特性 ,支持 Oat,Jit包括 动态编译等 ,原来的壳子 大多数都是基于解释执行的 废掉了 安卓原生的   oat执行模式  (二进制执行模式) 速度会慢很多 这也是各个大厂不喜欢用加固的主要原因

2,Google 对 android 虚拟机的限制越来越严,可能针对java语言本身的混淆,会重视起来

3,可以配合一些特殊字符串 让App 混淆难度提升 ,就算你得到Dex 分析也很困难

4,支持Xposed模块等 加固 因为不需要 初始化Application等


缺点:

1,Dex 的 大小会变大 , 混淆强度可控 用户自行决定 混淆强度




如果有感兴趣的话 也可以私聊我一下


附件是一个加密以后的样本  hook 加密算法的 Xp模块 


这个东西  不是免费的 ... 如果感兴趣可以加我的 QQ或者 微信 296488320



[推荐]看雪企服平台,提供项目众包、渗透测试、安全分析、定制项目开发、APP等级保护等安全服务!

最后于 2019-11-23 14:47 被珍惜Any编辑 ,原因:
上传的附件:
最新回复 (21)
artake 2019-11-8 18:32
2
0
牛逼,沙发沙发,膜拜膜拜
davidangle 2019-11-8 18:34
3
0
还以为开源
Monkeylord 2019-11-8 18:34
4
0
膜拜膜拜,抢占板凳
currwin 1 2019-11-8 18:39
5
0
牛逼!!!+前排。
真东阳不列山 2019-11-8 18:42
6
3
我前两天刚做了东西,专门破这种的控制流平坦化,有需要的私聊
iceway 2019-11-8 18:54
7
0
大佬求开源
琅環玉碎 2019-11-8 19:01
8
0
牛逼,沙发沙发,膜拜膜拜
sudami 25 2019-11-8 19:08
9
0
不知世事 1 2019-11-8 21:06
10
0
大佬!
这个demo 7000多个方法,体积达到小10M,体积可能确实是一个问题,除了供选择混淆的方法以外,是有办法在强度不弱的情况下,减小体积;
还有反混淆的时候也是可以用dex->ir>optir->dex,比so的反混淆还是要小很多
krash 1 2019-11-8 21:11
11
0

我觉得在Java层进行混淆强度实在太弱了,任何一个对Native反混淆有研究的,应该都能还原,因为Native反混淆难度远远高于你这个. Native代码反混淆我能想到的难点就有

  • 函数体识别,函数参数识别,函数调用参数识别.
  • 间接跳转目标识别,如switch;间接函数调用目标识别,比如c++虚函数.
  • 二进制文件patch困难.

这些非常难搞的问题在Java(Dex)这边完全不存在.

珍惜Any 2019-11-8 21:53
12
0
不知世事 大佬! 这个demo 7000多个方法,体积达到小10M,体积可能确实是一个问题,除了供选择混淆的方法以外,是有办法在强度不弱的情况下,减小体积; 还有反混淆的时候也是可以用dex->ir& ...
这个混淆强度可以自定义的,那个demo是最强的混淆。
珍惜Any 2019-11-8 21:54
13
0
有道理,但是什么东西有利有弊吧,看需求比如xp模块加固
珍惜Any 2019-11-8 21:55
14
0
krash 我觉得在Java层进行混淆强度实在太弱了,任何一个对Native反混淆有研究的,应该都能还原,因为Native反混淆难度远远高于你这个. Native代码反混淆我能想到的难点就有 - 函数体识别 ...
有道理,但是什么东西有利有弊吧,看需求比如xp模块加固
UltraPanda 2019-11-10 18:23
15
0
可以进行一下性能测试吗,另外可以放出.jar的文件便于分析吗
supperlitt 2019-11-11 11:07
16
0
我也要把开源提上日程了。。。
弱冠甕卿还仓 2019-11-11 12:17
17
0
supperlitt 我也要把开源提上日程了。。。
你要开源什么
Editor 2019-11-11 15:10
18
0
感谢分享!
弱冠甕卿还仓 2019-11-15 14:42
19
0
混淆后jadx不能显示混淆后的代码么
珍惜Any 2019-11-24 17:17
20
0
弱冠甕卿还仓 混淆后jadx不能显示混淆后的代码么
可以还原的
fixother 2019-11-25 04:12
21
0
很早以前我也高过一版,是通过在反编译出来的smali code 插入if goto 来实现的,但是后来有art 之后在安装apk的时候系统编译oat文件时编译不过去,在当时 Android5 上, 所以就放弃了
schoolyears 2020-2-16 22:22
22
0
插眼
游客
登录 | 注册 方可回帖
返回