實戰(zhàn)android打包和簽名

更新時間：2017年12月07日 15:20:28 作者：威威dett

本篇文章給大家通過實例講解了如何對android項目打包和簽名，并把用到的文件和流程做了注視，需要的朋友參考一下吧。

小編在之前給大家介紹過很多android項目打包的經(jīng)驗，本篇內(nèi)容我們通過一個項目實例來給大家講解android每一步打包和簽名的過程。

android打包

以下是原理圖：

這里寫圖片描述

由android的項目經(jīng)過編譯和打包，形成了:

.dex 文件

resources.arsc

uncompiled resources

AndroidManifest.xml

解壓了一個普通的apk文件，解壓出來的文件如下：

這里寫圖片描述

classes.dex 是.dex文件。resources.arsc是resources resources文件。AndroidManifest.xml是AndroidManifest.xml文件。res是uncompiled resources。META-INF是簽名文件夾。

其中resources.arsc相等于是資源文件的索引，方便查找資源文件

具體打包流程圖：

這里寫圖片描述

android簽名

android簽名后文件中多了個META-INF其中有三個文件：

這里寫圖片描述

下面分析一下3個文件的具體如何生成的apksinger：

1、MANIFEST.MF

逐一遍歷里面的所有條目，如果是目錄或者三個文件(MANIFEST.MF,CERT.RSA,CERT.SF)就跳過，如果是一個文件，就用SHA1（或者SHA256）消息摘要算法提取出該文件的摘要然后進行BASE64編碼后，作為“SHA1-Digest”屬性的值寫入到MANIFEST.MF文件中的一個塊中。該塊有一個“Name”屬性，其值就是該文件在apk包中的路徑。

2、CERT.SF：

1》計算這個MANIFEST.MF文件的整體SHA1值，再經(jīng)過BASE64編碼后，記錄在CERT.SF主屬性塊（在文件頭上）的“SHA1-Digest-Manifest”屬性值值下

2》逐條計算MANIFEST.MF文件中每一個塊的SHA1，并經(jīng)過BASE64編碼后，記錄在CERT.SF中的同名塊中，屬性的名字是“SHA1-Digest

3、CERT.RSA

這里會把之前生成的 CERT.SF文件，用私鑰計算出簽名, 然后將簽名以及包含公鑰信息的數(shù)字證書一同寫入 CERT.RSA 中保存。CERT.RSA是一個滿足PKCS7格式的文件。

為何要這么來簽名

上面我們就介紹了簽名apk之后的三個文件的詳細內(nèi)容，那么下面來總結一下，Android中為何要用這種方式進行加密簽名，這種方加密是不是最安全的呢？下面我們來分析一下，如果apk文件被篡改后會發(fā)生什么。

首先，如果你改變了apk包中的任何文件，那么在apk安裝校驗時，改變后的文件摘要信息與MANIFEST.MF的檢驗信息不同，于是驗證失敗，程序就不能成功安裝。

其次，如果你對更改的過的文件相應的算出新的摘要值，然后更改MANIFEST.MF文件里面對應的屬性值，那么必定與CERT.SF文件中算出的摘要值不一樣，照樣驗證失敗。

最后，如果你還不死心，繼續(xù)計算MANIFEST.MF的摘要值，相應的更改CERT.SF里面的值，那么數(shù)字簽名值必定與CERT.RSA文件中記錄的不一樣，還是失敗。

那么能不能繼續(xù)偽造數(shù)字簽名呢？不可能，因為沒有數(shù)字證書對應的私鑰。

所以，如果要重新打包后的應用程序能再Android設備上安裝，必須對其進行重簽名。