对时下流行的Android应用加固技术分析

我是一名奋战在安全第一线的程序猿，爱好和平，爱好打包不平， Freedom Forever ！ 最近移动安全太火，火的我都忍不住玩了一把，最近几个月在研究各家的安全加固方案，大多 dex 加密、反调试等技术，玩着玩着就没了意思。

前段时间，突然发现有的企业客户端 apk 的加固方式发生了一些变化，勾起了我的兴趣，好东西不敢私藏，分享出来供大家把玩。

加固技术分析

这个 apk 文件中包含了一个 classes.des 文件，如下所示

请出神器 JEB ，反编译后的程序结构如下所示。

怎么什么都能看到？没道理啊，明明之前得知这个应用是加固了的，经常看到的“ Proxy ”，“ Wrapper ”等关键词呢（ 普及一下，安全加固的开发人员经常这样命名加固程序逻辑 ）？仔细又看了一眼，猛地发现“ secneo.apkwrapper ”，打开一看，醍醐灌顶，原来在这。

下面我们分析一下加固效果，怎么想分析什么就分析什么呢？

在下花了一下午时间从 Application 分析到 Activity 再到各种逻辑代码，终于发现原来保护的是指定 package 下的“网络通信”和“数据库操作”模块。

从一名移动安全从业人员的角度讲，我们分析一个应用一般主要分析的 Activity 等四大组件的逻辑功能，从而找到应用的安全弱点。而数据操作部分在四大组件被分析的情况下再保护起来还能起到多大的保护效果有待考证。

与我的“老师”（也是行业中的大牛了）就该问题仔细讨论了一下，发现这家公司这么做的原因可能是：

大多数移动安全厂商其实的加固方案是整体 dex 加密技术，定制版加固与免费版加固方案上没有区别，都是可执行文件的加密保护。

这种应用加固方案在 Android  Art 模式和 Android5.0 上兼容性不好，只能采用“ 预编译” 的方式来兼容，但这种预编译的方式会带来严重的程序效率问题（设想一下应用一执行到受保护的程序逻辑的时候要先编译一下）。而 secneo( 其实就是棍棍加固 ) 采用保护部分逻辑的方式来躲避这种效率低下的影响（需要预编译的代码块变少）。带来的不良影响不言而喻：

（1）应用只能受到部分保护，仍然可以被逆向分析，程序敏感逻辑被分析，即使不能“二次打包”，也可以轻易的分析程序弱点。  （2）应用在运行到被加固的功能模块需要经过编译过程，程序运行效率大大变低。应用中关于数据的操作响应效率大大受到了影响。

形象化的加固方案思路如下

整体 dex 加固（笑脸）

定制版 dex 加固（哭脸）

终于分析完了，总结一下。我觉得这种方式的保护效果有限，有糊弄客户的嫌疑。Android 系统在迭代，安全加固的方案也要迭代，而不是逃避。

从事安全研究多年，始终觉得移动安全也一样，要从应用的方方面面着手，包括系统层和驱动层。技术小文一篇，希望大家一起努力，共同迎来移动安全从业人员的春天!

[参考信息来源TheFounder，喜欢文章请点赞鼓励。转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）]