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

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

0x00、今天我們聊什么

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

0x01、切入正題，apk文件結(jié)構(gòu)

    切入正題，胡小毛在學(xué)習(xí)Android逆向的過程中又有所總結(jié)，先來看看apk文件結(jié)構(gòu)：

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

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

• Lib目錄存放的是當(dāng)前app所用得到的so動態(tài)鏈接庫文件，so文件就是利用底層的c、c++代碼實(shí)現(xiàn)的。

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

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

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

• classes.dex：應(yīng)用程序的可執(zhí)行文件。若APP有多個dex，是因?yàn)楫?dāng)前的方法數(shù)超過65535，進(jìn)行了分包處理。如果未超過，則只有一個dex。Android的所有代碼都集中在此。可以通過反編譯工具dex2jar轉(zhuǎn)化成jar包，再通過jd-gui查看其代碼。

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

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

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

放心，不是表情包

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

安裝過程具體表現(xiàn)為：

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

對應(yīng)的卸載過程為：

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

0x03、正戲ING，虛擬機(jī)

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

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

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

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

而JDM、DVM、ART之間的關(guān)系可參考下圖：

0x04、拓展知識，Android簽名機(jī)制

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

 1、對Apk中的每個文件做一次算法(數(shù)據(jù)SHA1摘要+Base64編碼)，保存到MANIFEST.MF文件中，具體作法可以理解為程序遍歷APK包中的所有文件，對非目錄、非簽名文件的文件，逐個用SHA1生成摘要信息，再用Base64進(jìn)行編碼后保存?；诖宋募陌踩珯C(jī)制可以進(jìn)行文件完整性校驗(yàn)：如果APK包的文件被修改，在APK安裝校驗(yàn)時，被修改的文件與MANIFEST.MF的校驗(yàn)信息不同，程序?qū)o法正常安裝，同理CERT.SF和CERT.RSA文件同樣應(yīng)用于apk的完整性校驗(yàn)。    

MANIFEST.MF文件格式如下：

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

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

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

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

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

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