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

android打包

以下是原理圖：

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

.dex 文件

resources.arsc

uncompiled resources

AndroidManifest.xml

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

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

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

具體打包流程圖：

android簽名

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

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

1、MANIFEST.MF

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

2、CERT.SF：

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

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

3、CERT.RSA

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

為何要這么來簽名

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

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

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

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

那么能不能繼續(xù)偽造數(shù)字簽名呢？不可能，因?yàn)闆]有數(shù)字證書對(duì)應(yīng)的私鑰。

所以，如果要重新打包后的應(yīng)用程序能再Android設(shè)備上安裝，必須對(duì)其進(jìn)行重簽名。

從上面的分析可以得出，只要修改了Apk中的任何內(nèi)容，就必須重新簽名，不然會(huì)提示安裝失敗，當(dāng)然這里不會(huì)分析，后面一篇文章會(huì)注重分析為何會(huì)提示安裝失敗。

最新評(píng)論