APK打包流程及簽名安全機制該怎么理解

這篇文章將為大家詳細講解有關APK打包流程及簽名安全機制該怎么理解，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

0x00、今天我們聊什么

  今天我們聊些啥？許久不見，是該聊些啥了，話不多說，先來個五毛錢得，聊一聊胡小毛的Android逆向之路吧，當然，你們想知道的一定不是走了這么遠的路，那么我們開始看看他又Get到的新zishi吧（本文內容為MaoXH總結，喜大奔普，胡小毛的新id：MaoXH<毛小胡>）。

0x01、切入正題，apk文件結構

    切入正題，胡小毛在學習Android逆向的過程中又有所總結，先來看看apk文件結構：

    首先拿一款普通app講解，用zip壓縮文件打開會出現以下文件夾：

• Assets目錄用來存放需要打包到 Android 應用程序的靜態資源文件，例如圖片資源文件、JSON 配置文件、渠道配置文件、二進制數據文件、HTML5離線資源文件等。與res/raw 目錄不同的是，assets 目錄支持任意深度的子目錄，同時該目錄下面的文件不會生成資源ID。

• Lib目錄存放的是當前app所用得到的so動態鏈接庫文件，so文件就是利用底層的c、c++代碼實現的。

• META-INF目錄存放的是所用到的證書簽名文件，包括：MANIFEST.MF（摘要文件）、CERT.SF和CERT.RSA。其中MANIFEST.MF文件是對每個文件的SHA-256-Digest；CERT.SF是對每個文件的頭3行進行SHA-256-Digest；CERT.RSA這個文件保存了簽名和公鑰證書。

• Res目錄放應用的資源文件，包括圖片資源、字符串資源、顏色資源、尺寸資源等，這個目錄下面的資源都會出現在資源清單文件 R.java 的索引中。

• AndroidManifest.xml：Android項目的系統清單文件，Android應用的四大組件（Activity、Service、BroadcastReceiver和 ContentProvider ）均在此配置和聲明。

• classes.dex：應用程序的可執行文件。若APP有多個dex，是因為當前的方法數超過65535，進行了分包處理。如果未超過，則只有一個dex。Android的所有代碼都集中在此。可以通過反編譯工具dex2jar轉化成jar包，再通過jd-gui查看其代碼。

• resources.arsc：資源索引表，用來描述具有ID值的資源的配置信息。

0x02、開始正戲，apk打包流程

   看完了上面的apk的文件結構，我就要開始我們的正戲了，首先是“小二，上圖~，上長圖~”

放心，不是表情包

上圖就是一個apk包的細化打包流程，包含了每個細化過程可能會用到的工具，各位看官可多注意橘色標注字體部分。然后我們再看一下應用安裝涉及到的如下幾個目錄：

安裝過程具體表現為：

復制APK安裝包到data/app目錄下，解壓并掃描安裝包，把dex文件(Dalvik字節碼)保存到dalvik-cache目錄，并在data/data目錄下創建對應的應用數據目錄。

對應的卸載過程為：

刪除安裝過程中在上述三個目錄下創建的文件及目錄。

0x03、正戲ING，虛擬機

     有事好好說，沒事干啥提虛擬機啊，胡小毛也是搞得我暈頭轉向，莫慌，仔細瞧瞧，發現小毛得學習思路還是可圈可點得。上面提到得dalvik虛擬機，可能并未引起各位看官的注意力，所以這邊再多嘮叨一遍。

首先是java虛擬機，我們知道java語言有一個很重要的特性就是“跨平臺”可以做到“一次編譯，到處運行”的效果。怎樣才能有這樣的特性呢？主要就是依靠的java虛擬機（JVM）。當我們編寫好一個java程序之后如test.java。然后將其編譯為一個字節碼文件test.class。在java虛擬機上運行這個字節碼文件，java虛擬機就可以把字節碼文件解釋成具體平臺上的機器指令執行，而實現了java的跨平臺特性。

然后我們需要知道的是Android是基于Dalvik虛擬機(DVM)或art虛擬機(aot機制)的。Dalvik虛擬機主要應用于Android5.0及以前，而ART（Android Runtime）虛擬機是 Android 4.4 發布的，用來替換 Dalvik 虛擬機，Android 4.4 默認采用 DVM，但是可以選擇使用 ART。在 Android 5.0 版本中默認使用 ART，DVM 從此退出歷史舞臺。

具體可參考：https://www.jianshu.com/p/a37d3be0a341。

而JDM、DVM、ART之間的關系可參考下圖：

0x04、拓展知識，Android簽名機制

  還記得之前提到的META-INF目錄嗎？里面的簽名證書文件就是對apk進行簽名過程中生成，apk簽名過程可以總結如下：

 1、對Apk中的每個文件做一次算法(數據SHA1摘要+Base64編碼)，保存到MANIFEST.MF文件中，具體作法可以理解為程序遍歷APK包中的所有文件，對非目錄、非簽名文件的文件，逐個用SHA1生成摘要信息，再用Base64進行編碼后保存。基于此文件的安全機制可以進行文件完整性校驗：如果APK包的文件被修改，在APK安裝校驗時，被修改的文件與MANIFEST.MF的校驗信息不同，程序將無法正常安裝，同理CERT.SF和CERT.RSA文件同樣應用于apk的完整性校驗。    

MANIFEST.MF文件格式如下：

        2、對MANIFEST.MF整個文件做一次算法(數據SHA1摘要+Base64編碼)，存放到CERT.SF文件的頭屬性中，再對MANIFEST.MF文件中各個屬性塊做一次算法(數據SHA1摘要+Base64編碼)，存到到一個屬性塊中。

CERT.SF文件格式如下:       3、對CERT.SF文件做簽名，內容存檔到CERT.RSA中,所以CERT.RSA是一個加密文件，所以它長的很難看，不信的自己去看：

了解了上面apk的簽名過程，我們可以深入思考一下下面這段話（某大神原話）：

假如我們是一個非法者，想要篡改apk內容，我們怎么做呢？如果我們只把原文件改動了（比如加入了自己的病毒代碼），那么重新打包后系統就會認為文件的SHA1-Base64值和MF的不一致導致安裝失敗，既然這樣，那我們就改一下MF讓他們一致唄？如果只是這樣那么系統就會發現MF文件的內容的SHA1-Base64與SF不一致，還是會安裝失敗，既然這樣，那我們就改一下SF和MF一致唄？如果這么做了，系統就會發現RSA解密后的值和SF的SHA1不一致，安裝失敗。那么我們讓加密后的值和SF的SHA1一致就好了唄，但是呢，這個用來簽名加密的是私鑰，公鑰隨便玩，但是私鑰我們卻沒有，所以沒法做到一致。所以說上面的過程環環相扣，最后指向了RSA非對稱加密的保證。

最后我們必須要知道簽名機制只是保證了apk的完整性，具體是不是自己的apk包，系統并不知道，所以對于上面的通過apk簽名進行完整性校驗，攻擊者可以通過直接重簽名，讓所有的信息都一致就能繞過校驗，這樣重簽名后就可以安裝了。所以對于應用簽名是否被篡改，那就是另一門學問了……

關于APK打包流程及簽名安全機制該怎么理解就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。