標籤：行動裝置 App 安全 android應用 反編譯工具 破解
前言
有安全資料顯示，2014全年，Android使用者感染惡意程式3.19億人次，平均每天惡意程式感染量達到了87.5萬人次。同時，Android應用被破解和盜版等事件也層出不窮。很明顯，Android平台已經成為惡意程式和破解者攻擊的眾矢之的，於是越來越多的Android開發人員開始意識到應用安全的重要性。
一、什麼是“打包黨” 他們專門對最熱門或新秀APP下手，先將其破解，然後再以植入木馬、插入廣告、篡改支付連結等形式封裝成新的APP，這個過程也叫做二次打包。更有開發人員爆料，專業“打包黨”的月收入超過百萬，這簡直是對正版開發人員最赤裸的攻擊和挑釁。
尼瑪！一寸代碼一寸血，一寸光陰一寸金，全白費了！
二、“打包黨”一般都做些什麼植入木馬，惡意計費 “打包黨”謀取暴利的形式多樣，如在APP中植入木馬程式，使用者下載後，通過惡意計費、竊取使用者帳號和密碼等方式來擷取利益。為了蒙蔽使用者和節約成本，二次打包的APP通常和正版基本沒有差異，使用者在毫不知情的情況下使用後，一旦遭遇經濟損失，最終開發人員就要為此背黑鍋，還會使正版APP的品牌形象受損。
植入廣告，賺取廣告費 當一個團隊辛辛苦苦開發的APP，有了幾十萬、上百萬的使用者時，可能已經成為了“打包黨”捕獵的對象。他們會在二次打包的過程中以植入或替換廣告的形式來賺取廣告收入，廣告有按展示次數、點擊次數、安裝啟用量等不同的計費形式。以展示次數為例，為了謀取更多利益，二次打包的APP會頻繁的對使用者進行廣告提醒，給使用者造成騷擾，體驗感極差，但“打包黨”並不care，他們只關心怎樣儘可能多的賺到錢。
可以想象，一邊是團隊拚命的開發和推廣，另一邊則坐收漁翁之利，不勞而獲。APP越火爆，給“打包黨”帶來的利益就越多，完全淪為了“打包黨”賺錢的工具。
直接截取開發人員的財路 除了遊戲和軟體類APP，隨著移動支付類應用的火熱，“打包黨”還瞄準了支付類APP。“打包黨”破解正版APP後，再修改App的付費連結參數，使用者支付的費用直接進入“打包黨”的口袋，完全切斷了開發人員的財路。
辛辛苦苦一整年，轉眼回到解放前！
三、安卓apk的檔案結構
AndroidManifest.xml：Android主設定檔，編譯過程中由文本格式轉化為二進位AXML檔案格式。
Classes.dex:java代碼編譯後產生的一種類似位元組碼的檔案。
res：資源檔，其中的.xml檔案在編譯過程中由文本格式轉化為二進位AXML檔案格式。
META-INF：簽名檔案。
lib: native代碼編譯後的so。
其他檔案夾：由開發人員自己添加的檔案
Android apk的核心邏輯主要存在於classes.dex中，通常破解者在進行破解和二次打包時，會對classes.dex和AndroidManifest.xml檔案進行操作，所以對這兩個檔案進行保護尤為重要。四、apk二次打包的四個步驟 1.反編譯 反編譯java：classes.dex反編譯成中間檔案(smali、jar)。
反編譯布局檔案：Axml檔案反編譯成xml檔案。
2.修改 修改smali檔案。
修改xml檔案。
3.重新編譯 修改後的smali編譯成classes.dex。
修改後的xml編譯成Axml。
4.重簽名
一款山寨版APP由此誕生!
五、Android APP 防破解進化史原始社會時期——代碼混淆
最早的應用保護當屬代碼混淆，Google官方發布的sdk中就包含ProGuard這種混淆工具。混淆工具會把你用java語言編寫的代碼的類名、變數名混淆為自己定義的格式，這樣可以增加破解者在破解時閱讀難度。但代碼混淆只是簡單的改變類名或者變數的名，只要能找dex，反編譯為smali或者java，花些時間還是可以輕鬆破解的。如果說不用混淆工具我們破解一個apk需要2兩天，那麼用了這個工具，破解者可能需要4天，只是時間成本增加了。
奴隸社會時期——自我校正 經過漫長的混淆時期，開發人員發現他們的應用還是照常被破解。於是新的保護方式又出現了——自我校正。
簡單說，自我校正就是在程式中加一些對自己應用的完整性校正，可以藉助簽名、或計算自己應用dex的md5值等等來完成。有些開發人員直接把校正功能加入到dex中，有些則是通過http協議請求相關服務來得到校正。有了這種校正，應用在被二次打包的時候會無法運行。
那這種方法的弊端是什嗎？舉一個有意思的例子。在懸崖的拐彎處都會有一個路標，用來正確指示方向。但如果有人故意搞破壞，把路標指示方向弄反，那開車的人被誤導後，順著錯誤的方向行駛，就會發生不幸的悲劇。
這個例子的意思是，電腦在執行指令的時候也是按照預先定義好的邏輯（開發人員寫的）去執行，然而如果破解者對開發人員校正的地方近進行了修改，那麼電腦也會按照新的邏輯執行，這種保護措施風險很大，所以也就逐漸沒落了。
封建社會時期——dex檔案變形 經曆了兩個時代，開發人員也逐漸提高了保護技能。於是很多做java出身的開發人員，在經過無數日夜的努力下搖身一變成為了c、c++專家。越來越多的邏輯被寫入到c層，並且所有的校正也被移到c層，混淆也同樣存在。同時，開發人員開始對dex檔案AndroidManifest檔案做變形處理，這樣做的好處是既能保證應用能正常運行，也能使一些反編譯工具如apktool在反編譯時間奔潰。但對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結構進行變形 一些第三方加固產品開始嘗試這種方式，他們的保護方案中可能抽取了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代碼邏輯複雜，很難達到定製，特別是讓它同時支援多種架構。
Android應用安全隱患現狀,安全防護進化史
