(愛加密系列教程十八) Android安全分析挑戰：運行時篡改Dalvik字節碼

移動互聯網已是一種趨勢，僅2012年就有450億應用程序下載量。伴隨着移動互聯網的火爆，衆多攻擊者也被吸引到這個平臺，移動平臺惡意軟件呈現爆炸式增加態勢。與PC平臺不一樣的是，PC平臺有大量的反病毒包和惡意軟件分析工具，而新興的移動互聯網卻缺少強大的分析工具和技術。這些工具和技術將是保持移動互聯網遠離惡意軟件和惡意應用程序的關鍵。它們通常來自於學術界和安全界的研究人員，可是它們都有必定的缺陷，並不適合全部的狀況，加入安全社區能夠幫助咱們學習和發展android應用的分析方法。

1、介紹
首先介紹一下移動應用程序的分析方法和背景。咱們能夠採用不少工具來對應用程序進行分析，Android應用程序的分析通常都是基於APK文件，APK文件表明了一個應用程序。
它存儲瞭如下內容：

一、程序邏輯：dex字節碼和so本地庫。
       二、元數據信息：AndroidManifest.xml文件。
       三、資源文件：圖像或其餘類型數據。


 分析工具通常採用如下兩種應用分析方法：  

      一、靜態分析：該方式收集有關應用程序的信息，但程序代碼不執行。
      二、動態分析：該方式執行應用程序，同時收集應用運行行爲。


  這兩種分析技術都各有利弊，在Android逆向分析領域，許多工具都是基於靜態分析技術，也有用於動態分析的沙箱系統，但受限於動態分析系統的交互靈活性，分析師每每在那些部分須要動態分析上沒有足夠的控制力。在逆向工程過程當中，分析人員一旦肯定了感興趣的應用程序部分，它們更側重於使用靜態分析工具。問題是如何找到那些部分呢？靜態分析技術的另外一個主要缺點是不知道什麼被真正執行和程序上下文在某特定點的執行是否有效。當咱們假定應用程序代碼在運行過程當中不會改變時，分析工做將是十分容易的，咱們能夠經過分析apk文件來識別程序代碼邏輯，混淆的應用程序會給分析人員帶來必定的挑戰。隨着運行時篡改Dalvik字節碼的講解，咱們將暴露這些基於代碼流分析的工具的限制和問題。

  咱們將在接下來的部分描述一下應用程序的基本組成部分，並指出重要的運行時組件。這將使咱們更容易明白當運行crackme時發生了什麼事情。以後，咱們將講述用於欺騙靜態分析工具所採用的主要技術。最後咱們會進入crackme挑戰的細節。

2、應用程序執行的上下文

應用程序的生命週期開始於zygote進程的fork方法，由於它已經預先加載了Android框架，因此應用程序沒必要再花時間加載這些基礎類，同時這也能夠有效下降總體的內存開銷。在新的進程下降權限以後，它加載了apk文件中的classes.dex文件，該文件包含了可被Dalvik虛擬機（DVM）解釋執行的Dalvik字節碼，表明了應用程序邏輯。此外，應用程序還帶有能夠在運行時動態加載的Native庫。由於Dalvik虛擬機和Native庫運行在同一進程中，所以它們具備相同的權限。一個典型的（縮短的）應用程序的內存佈局如圖1所示。

圖1典型的APP內存佈局

咱們能夠看到，Android框架和共享庫及dex文件同樣被映射到咱們的進程。咱們的dex文件字節碼被映射爲只讀。

3、篡改技術

回到靜態分析工具的話題，若是Dalvik字節碼在運行時不能改變的話，靜態分析工具將能很好的工做。由於咱們能夠直接從APK文件中提取的出和運行時相匹配的字節碼。你可能會說這種假設是成立的，由於dex文件映射爲只讀，因此Dalvik指令集是不可以修改的字節碼自己的。有限的Dalvik指令集使咱們不可以篡改程序字節碼，但咱們能夠利用捆綁在APK文件中的本地庫。本地代碼和DVM運行在相同的較低水平，如圖2：

圖2 本地代碼和DVM在同一級別的操做

本地代碼是可以任意操做本身進程上下文內存的，所以咱們能夠經過本地代碼覆蓋已加載Dalvik字節碼。可是classes.dex被映射爲只讀。這意味着，若是咱們修改該段內存，內核將會殺掉咱們的進程，所以在實際篡改咱們的應用程序的字節碼以前，咱們必須從新映射該段內存爲可寫。以後，咱們就能夠寫咱們的新字節碼到咱們的應用程序。若是程序調用咱們篡改過的方法，那麼將執行新的字節碼。沒有進一步修改應用程序或DVM的必要。經過這種方法，咱們發現「字節碼在運行時不能修改」的假設也不是絕對的。只關注classes.dex文件的靜態分析工具沒有考慮到這種狀況，這樣的工具就必須改進以應對這種狀況。可使用靜態和動態分析的組合來克服這種限制，但這樣的複雜的分析系統是不常見的。

3、示例-Crackme

爲了說明咱們前面所討論的一些問題，咱們決定建立一個案例研究「challenge」的應用程序「crackme」，它使用惡意軟件使用的混淆技術進行了處理。您可使用任何分析技術和工具，並弄清楚它是如何工做的。找到正確的密碼，輸入到上面的文本框中。點擊按鈕，查看是否獲得了正確的答案。這將顯示按鈕下面的文字。



 您能夠在這裏下載crackme的apk文件的副本：https://github.com/blueboxsecurity/DalvikBytecodeTampering/raw/master/delta.apk

中止閱讀，若是你打算接受挑戰。下面是挑戰的答案 -----

首先咱們開始分析Action類，這是咱們的應用程序的Activity的入口，按鈕會觸發verify（）方法。在這裏，咱們第一次獲取TextField中的輸入的文本，並把它轉換成一個String。這個String對象並非java.lang.String類的一個實例而是咱們本身的實現。在構造函數中，咱們使用第二種方法改變字符串。結果將被儲存在私有的區域，和Action類的硬編碼在一塊。若是密碼相同，將被用於顯示在屏幕上的消息的加密。

 可是String類內所使用的改變文本方法的方法，或者更準確地說，這種方法的字節碼，將永遠不會被執行。當應用程序啓動後，在Action的靜態類的構造函數中，這個方法的字節碼已經被替換掉了。在這裏，咱們加載本地庫'libnet.so'和執行READMEM（）函數。在這個庫中，咱們獲取一個指針從堆棧到咱們的映射的dex文件，並嘗試找到文件的開頭。這能夠很容易地經過正向搜索內存頁，直到咱們發現dex文件的magic byte。如今咱們能夠從dex文件的開頭解析頭文件。當咱們解析dex文件時，咱們能夠找到的咱們要篡改方法的地址。但正如前面提到的，咱們首先要從新映射內存爲可寫。這可使用mprotect（）函數實現。以後，咱們就能夠覆蓋原來的字節碼，並經過從本機代碼到類的初始化的返回來完成。類初始化已經結束，Activity在Android設備上彈出。如今，當咱們按下按鈕時，咱們執行的是新的字節碼，而不是原來dex的字節碼。

在此向你介紹一款：自動化App安全檢測平臺（http://safe.ijiami.cn），一鍵上傳，方便快捷，能夠幫助開發者找出本身APP所存在的漏洞和薄弱環節，幫助能夠幫助本身進行APP加殼加密保護。

更多內容，期待您的探索，請關注愛加密，讓您精彩不斷！

愛加密官方地址：http://www.ijiami.cn/