純乾貨：Android APP 防破解進化史2015/4/29 14:32:51 來源：中原財經網
Android平臺以其免費和開源的特性使其佔據了移動領域大半壁江山，越來越的人投身到移動應用開發中，但本文恐怕要先給Android應用開發者潑盆冷水，據360發布的《2014年中國手機安全狀況報告》顯示，2014全年，360網際網路安全中心累計監測到Android用戶感染惡意程序3.19億人次，平均每天惡意程序感染量達到了87.5萬人次。同時，Android應用被破解和盜版等事件也層出不窮。
很明顯，Android平臺已經成為惡意程序和破解者攻擊的眾矢之的，於是越來越多的Android開發者開始意識到應用安全的重要性。如何捍衛自己苦心開發的應用安全，開發者們都使用過哪些保護手段， 360加固保（http://jiagu.360.cn/）技術工程師為大家一一分析。
原始社會時期——代碼混淆
最早的應用保護當屬代碼混淆，谷歌官方發布的sdk中就包含ProGuard這種混淆工具。混淆工具會把你用java語言編寫的代碼的類名、變量名混淆為自己定義的格式，這樣可以增加破解者在破解時閱讀難度。
圖1是用ProGuard混淆過的dex文件截圖，從圖中可以看到，左側的類名大多都變成了a、b等這樣自定義字母的形式。在未混淆前，破解者可以根據一個類名叫做HttpGet的文件，大致猜測出它是做http get相關的。而混淆後，變成了a等自定義類名，破解者無法猜測它的含義，增加了閱讀難度。
圖1
但代碼混淆只是簡單的改變類名或者變量的名，只要能找dex，反編譯為smali或者java，花些時間還是可以輕鬆破解的。如果說不用混淆工具我們破解一個apk需要2兩天，那麼用了這個工具，破解者可能需要4天，只是時間成本增加了。
奴隸社會時期——自我校驗
經過漫長的混淆時期，開發者發現他們的應用還是照常被破解。於是新的保護方式又出現了——自我校驗。
簡單說，自我校驗就是在程序中加一些對自己應用的完整性校驗，可以藉助籤名、或計算自己應用dex的md5值等等來完成。有些開發者直接把校驗功能加入到dex中，有些則是通過http協議請求相關服務來得到校驗。有了這種校驗，應用在被二次打包的時候會無法運行。
那這種方法的弊端是什麼？舉一個有意思的例子。在懸崖的拐彎處都會有一個路標，用來正確指示方向。但如果有人故意搞破壞，把路標指示方向弄反，那開車的人被誤導後，順著錯誤的方向行駛，就會發生不幸的悲劇。
這個例子的意思是，計算機在執行指令的時候也是按照預先定義好的邏輯（開發者寫的）去執行，然而如果破解者對開發者校驗的地方近進行了修改，那麼計算機也會按照新的邏輯執行，這種保護措施風險很大，所以也就逐漸沒落了。
封建社會時期——dex文件變形
經歷了兩個時代，開發者也逐漸提高了保護技能。於是很多做java出身的開發者，在經過無數日夜的努力下搖身一變成為了c、c++專家。越來越多的邏輯被寫入到c層，並且所有的校驗也被移到c層，混淆也同樣存在。同時，開發者開始對dex文件AndroidManifest文件做變形處理，這樣做的好處是既能保證應用能正常運行，也能使一些反編譯工具如apktool在反編譯時奔潰。由圖2可見， apktool在反編譯時完全失去了作用。
圖2
但對dex文件和manifest文件的變形同樣有它的弱點。基本世面上的dex變形都可以通過baksmali來得到smali，這樣破解者就可繼續分析。而manifset文件格式官方有明確的規範，破解者按照規範去解析，遇到不正確字節可以推敲，最終還是可以將其還原。
資本主義社會時期
這是一個移動網際網路高速發展的時期，但盜版和二次打包等問題也日益凸顯，在這個開放的時期，為了滿足開發者保護應用的迫切需要，相繼出現了一些基於Android APP加固的第三方產品，通常他們的基本做法有：
1. Dex保護
（1） 隱藏dex文件
既然dex文件中包含了核心邏輯，那麼把dex隱藏，再通過另外的方式加載起來，是不是就能達到保護dex的目的了呢？於是這成為一些第三方加固產品保護應用的方式。
他們通過加密甚至壓縮（早期是不存在壓縮的，只是單純的加密）方式把dex轉換為另外一個文件。而被加固後的apk裡面的dex則是那些第三方加固產品用來啟動和加載隱藏dex的入口，也就是殼。
（2） 對dex文件進行變形
這裡所說的變形，不同於封建社會時期提到的變形。這種辦法不隱藏dex，而是讓dex保留在外面，但是當破解者去分析這個dex的時候，會發現dex裡面的內容是不完整的。
（3） 對dex結構進行變形
此類方法是比較複雜的，了解dex結構的人應該很清楚，dex結構中包含DexClassDef、ClassDataItem、DexCode，這些是dalvik虛擬機運行一個dex必不可少的部分，特別是DexCode，DexCode包含了虛擬機運行的字節碼指令。
部分第三方加固產品開始嘗試這種方式，他們的保護方案中可能抽取了DexCode中的部分，然後對字節碼指令添加nop，或者連ClassDataItem和DexCode一同抽取，或者對上面提到的三個部分都做處理。抽取完之後，還要做修正、修復等工作，總之很煩鎖。因為dex運行時有很多關於dex的校驗，即使校驗通過還有一些偏移問題。
Dex都被抽取修改後為什麼還能運行呢？那是因為在運行之前或者運行之中對這個內存中的dex做修正。修正工作也很複雜，一般選擇在運行之前做修正，這樣可以減少很大的工作量，甚至可能還需要藉助hook來幫忙。
2. So保護
（1） 修改Elf頭、節表
我們知道so其實是一個ELF文件，ELF文件有著自己的格式。有些第三方加固保護是對so文件進行保護，他們的做法是稍微修改一下ELF頭或者節表信息，因為這並不會影響程序的正常運行。
圖3和圖4是對ELF文件頭中的節頭表信息做了修改後，再用010 Editor打開，顯示的異常界面：
圖3
圖4
接著我們用ida打開該ELF文件，發現該文件根本無法打開（一直卡在那裡），如圖5和圖6所示：
圖5
圖6
其次，還有修改程序頭表這種保護方式，如圖7 所示，對PT_NOTE段做了一些修改。在該段的屬性值中填充了一些無效的數字，導致逆向工具無法正常解析。由於系統並不會對PT_NOTE段進行分析，防禦逆向工具的同時保證了該文件能被系統正常加載。
圖7
（2） 選擇開源加殼工具
最常用的當屬UPX殼，因為它支持arm架構的ELF加固。在加殼之後再對原文件做一些處理，這樣對破解者的分析工作又增加了一些難度。
（3） 進程防調試、或增加調試難度
有時候靜態分析是非常局限的，這個時候動態分析的好處就體現出來了，然而動態分析的核心就是調試，而調試一個進程首先要ptrace這個進程，如果能有效的防止進程被ptrace，就能有效的防止動態調試。當然還有其他反調試技術，或者增加調試難度等等。
社會主義時期
這個時期，技術的發展與普及讓人人都是開發者成為可能。而破解者的破解技術和手段也在隨之變化。單一的應用保護措施已經無法有效的應對破解者的攻擊，所以還需要從多重維度和深度對應用進行加固保護。
在上面的資本主義時期提到的幾種保護措施中，遺留了很多問題，比如：
（1） 隱藏dex遺留的問題
首先dex是被完整隱藏起來的，一旦破解者得到了dex，就等於破解完成了一半。如果破解了加殼原理，就可以輕易做出脫殼機。
另外就是實現自定義rom，這種方式可謂最為簡單，只需要在相關的點加一些代碼，然後編譯一個自己的rom，這樣在虛擬機中就可以順利的脫殼了。
還有就是利用Inject原理將目標進程注入,代碼進行hook系統函數來達到脫殼的目的。
（2） Dex結構變形帶來的弊端
隨著安卓5.0的發布，Art步入我們的視野。Art可以直接將dex編譯為本地指令運行。
可是它編譯時需要完整的dex，這怎麼辦？或許有些第三方加固產品選擇了根本不編譯，當然開發者和用戶不知道，因為它表現出來的是程序可以正確運行，但是系統在Art模式下運行的更快這種優勢就永遠得不到體現了。
所以Dex結構變形遺留的問題很明顯，即兼容性和Art模式下的編譯問題。
（3） ELF簡單修改遺留問題
對應修改ELF頭和節頭表信息的技巧很容易被識破和修復，所以只能防住初級破解者。
（4） UPX方面的劣勢
雖然upx是最為so加殼的首選，但是upx代碼邏輯複雜，很難達到定製，特別是讓它同時支持多種架構。
基於上述原因一些第三方加固產品只是簡單的利用upx加殼，並修改一些數據。不過很容易被有upx經驗的人識破並脫殼。
安全防護當然不是絕對的，但既然能發現這些遺留問題和弊端，就一定能找到相應的解決方案。據360加固保（http://jiagu.360.cn/）技術工程師介紹，一款能防得住破解者攻擊、兼容性好、能體現系統各優勢的加固產品就是值得開發者選擇的好產品。