對時下流行的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）]

</div> </div>