⑴ 如何查看android應用簽名文件的信息
以下介紹查看自己的應用簽名及三方APK或系統APK簽名信息,包含其中的MD5、SHA1、SHA256值和簽名演算法等信息。
1、查看自己的應用簽名可以通過兩種方式查看(1) debug的apk通過Eclipse查看,如下圖:
可以查看簽名的MD5、SHA1、SHA256值及簽名演算法
⑵ android keystore 怎麼查看md5簽名
查看keystore簽名
1.定位到bin目錄
2.運行命令行
keytool -list -v -keystore C:\Users\Sinaan\Desktop\2.0開發\xiyilangpda.keystore -storepass Xiyilangpda.cc1
代表含義:
C:\Users\Sinaan\Desktop\2.0開發\xiyilangpda.keystore : keystore的絕對路徑
Xiyilangpda.cc : keystore的密鑰,注意不是alias。
3.查看生成簽名
MD5後面的一串去掉:,然後小寫就是你需要的keystore簽名。
⑶ 請問安卓端的什麼軟體能給tar包進行md5簽名
md5是校驗碼。不是簽名。比方說,一個視頻文件大小是12389M,一個可運行文件大小也是12389M,但後綴名被刪除了,那怎麼區別他們呢,這時候你用hash值軟體或者軟媒魔方的文件大師就可以看到用的md5值,盡管大小一模一樣但md5永遠不會一樣
⑷ Android中,apk文件的MD5值和apk簽名的MD5值 是一樣的嗎
不可以,簽名MD5隻是簽完名表現出來的數字,要有同樣的簽名必須要用同樣的「xxx.keystore」簽名文件。你拿到了「xxx.keystore」文件才行
⑸ android簽名是要md5值還是要sha1值
android簽名是要md5值
⑹ Android V1及V2簽名原理簡析
Android為了保證系統及應用的安全性,在安裝APK的時候需要校驗包的完整性,同時,對於覆蓋安裝的場景還要校驗新舊是否匹配,這兩者都是通過Android簽名機制來進行保證的,本文就簡單看下Android的簽名與校驗原理,分一下幾個部分分析下:
簽名是摘要與非對稱密鑰加密相相結合的產物,摘要就像內容的一個指紋信息,一旦內容被篡改,摘要就會改變,簽名是摘要的加密結果,摘要改變,簽名也會失效。Android APK簽名也是這個道理,如果APK簽名跟內容對應不起來,Android系統就認為APK內容被篡改了,從而拒絕安裝,以保證系統的安全性。目前Android有三種簽名V1、V2(N)、V3(P),本文只看前兩種V1跟V2,對於V3的輪密先不考慮。先看下只有V1簽名後APK的樣式:
再看下只有V2簽名的APK包樣式:
同時具有V1 V2簽名:
可以看到,如果只有V2簽名,那麼APK包內容幾乎是沒有改動的,META_INF中不會有新增文件,按Google官方文檔:在使用v2簽名方案進行簽名時,會在APK文件中插入一個APK簽名分塊,該分塊位於zip中央目錄部分之前並緊鄰該部分。在APK簽名分塊內, 簽名和簽名者身份信息會存儲在APK簽名方案v2分塊中,保證整個APK文件不可修改 ,如下圖:
而V1簽名是通過META-INF中的三個文件保證簽名及信息的完整性:
V1簽名是如何保證信息的完整性呢?V1簽名主要包含三部分內容,如果狹義上說簽名跟公鑰的話,僅僅在.rsa文件中,V1簽名的三個文件其實是一套機制,不能單單拿一個來說事,
如果對APK中的資源文件進行了替換,那麼該資源的摘要必定發生改變,如果沒有修改MANIFEST.MF中的信息,那麼在安裝時候V1校驗就會失敗,無法安裝,不過如果篡改文件的同時,也修改其MANIFEST.MF中的摘要值,那麼MANIFEST.MF校驗就可以繞過。
CERT.SF個人覺得有點像冗餘,更像對文件完整性的二次保證,同繞過MANIFEST.MF一樣,.SF校驗也很容易被繞過。
CERT.RSA與CERT.SF是相互對應的,兩者名字前綴必須一致,不知道算不算一個無聊的標准。看下CERT.RSA文件內容:
CERT.RSA文件裡面存儲了證書公鑰、過期日期、發行人、加密演算法等信息,根據公鑰及加密演算法,Android系統就能計算出CERT.SF的摘要信息,其嚴格的格式如下:
從CERT.RSA中,我們能獲的證書的指紋信息,在微信分享、第三方SDK申請的時候經常用到,其實就是公鑰+開發者信息的一個簽名:
除了CERT.RSA文件,其餘兩個簽名文件其實跟keystore沒什麼關系,主要是文件自身的摘要及二次摘要,用不同的keystore進行簽名,生成的MANIFEST.MF與CERT.SF都是一樣的,不同的只有CERT.RSA簽名文件。也就是說前兩者主要保證各個文件的完整性,CERT.RSA從整體上保證APK的來源及完整性,不過META_INF中的文件不在校驗范圍中,這也是V1的一個缺點。V2簽名又是如何保證信息的完整性呢?
前面說過V1簽名中文件的完整性很容易被繞過,可以理解 單個文件完整性校驗的意義並不是很大 ,安裝的時候反而耗時,不如採用更加簡單的便捷的校驗方式。V2簽名就不針對單個文件校驗了,而是 針對APK進行校驗 ,將APK分成1M的塊,對每個塊計算值摘要,之後針對所有摘要進行摘要,再利用摘要進行簽名。
也就是說,V2摘要簽名分兩級,第一級是對APK文件的1、3 、4 部分進行摘要,第二級是對第一級的摘要集合進行摘要,然後利用秘鑰進行簽名。安裝的時候,塊摘要可以並行處理,這樣可以提高校驗速度。
APK是先摘要,再簽名,先看下摘要的定義:Message Digest:摘要是對消息數據執行一個單向Hash,從而生成一個固定長度的Hash值,這個值就是消息摘要,至於常聽到的MD5、SHA1都是摘要演算法的一種。理論上說,摘要一定會有碰撞,但只要保證有限長度內碰撞率很低就可以,這樣就能利用摘要來保證消息的完整性,只要消息被篡改,摘要一定會發生改變。但是,如果消息跟摘要同時被修改,那就無從得知了。
而數字簽名是什麼呢(公鑰數字簽名),利用非對稱加密技術,通過私鑰對摘要進行加密,產生一個字元串,這個字元串+公鑰證書就可以看做消息的數字簽名,如RSA就是常用的非對稱加密演算法。在沒有私鑰的前提下,非對稱加密演算法能確保別人無法偽造簽名,因此數字簽名也是對發送者信息真實性的一個有效證明。不過由於Android的keystore證書是自簽名的,沒有第三方權威機構認證,用戶可以自行生成keystore,Android簽名方案無法保證APK不被二次簽名。
知道了摘要跟簽名的概念後,再來看看Android的簽名文件怎麼來的?如何影響原來APK包?通過sdk中的apksign來對一個APK進行簽名的命令如下:
其主要實現在 android/platform/tools/apksig 文件夾中,主體是ApkSigner.java的sign函數,函數比較長,分幾步分析
先來看這一步,ApkUtils.findZipSections,這個函數主要是解析APK文件,獲得ZIP格式的一些簡單信息,並返回一個ZipSections,
ZipSections包含了ZIP文件格式的一些信息,比如中央目錄信息、中央目錄結尾信息等,對比到zip文件格式如下:
獲取到 ZipSections之後,就可以進一步解析APK這個ZIP包,繼續走後面的簽名流程,
可以看到先進行了一個V2簽名的檢驗,這里是用來簽名,為什麼先檢驗了一次?第一次簽名的時候會直接走這個異常邏輯分支,重復簽名的時候才能獲到取之前的V2簽名,懷疑這里獲取V2簽名的目的應該是為了排除V2簽名,並獲取V2簽名以外的數據塊,因為簽名本身不能被算入到簽名中,之後會解析中央目錄區,構建一個DefaultApkSignerEngine用於簽名
先解析中央目錄區,獲取AndroidManifest文件,獲取minSdkVersion(影響簽名演算法),並構建DefaultApkSignerEngine,默認情況下V1 V2簽名都是打開的。
第五步與第六步的主要工作是:apk的預處理,包括目錄的一些排序之類的工作,應該是為了更高效處理簽名,預處理結束後,就開始簽名流程,首先做的是V1簽名(默認存在,除非主動關閉):
步驟7、8、9都可以看做是V1簽名的處理邏輯,主要在V1SchemeSigner中處理,其中包括創建META-INFO文件夾下的一些簽名文件,更新中央目錄、更新中央目錄結尾等,流程不復雜,不在贅述,簡單流程就是:
這里特殊提一下重復簽名的問題: 對一個已經V1簽名的APK再次V1簽名不會有任何問題 ,原理就是:再次簽名的時候,會排除之前的簽名文件。
可以看到目錄、META-INF文件夾下的文件、sf、rsa等結尾的文件都不會被V1簽名進行處理,所以這里不用擔心多次簽名的問題。接下來就是處理V2簽名。
V2SchemeSigner處理V2簽名,邏輯比較清晰,直接對V1簽名過的APK進行分塊摘要,再集合簽名,V2簽名不會改變之前V1簽名後的任何信息,簽名後,在中央目錄前添加V2簽名塊,並更新中央目錄結尾信息,因為V2簽名後,中央目錄的偏移會再次改變:
簽名校驗的過程可以看做簽名的逆向,只不過覆蓋安裝可能還要校驗公鑰及證書信息一致,否則覆蓋安裝會失敗。簽名校驗的入口在PackageManagerService的install里,安裝官方文檔,7.0以上的手機優先檢測V2簽名,如果V2簽名不存在,再校驗V1簽名,對於7.0以下的手機,不存在V2簽名校驗機制,只會校驗V1,所以,如果你的App的miniSdkVersion<24(N),那麼你的簽名方式必須內含V1簽名:
校驗流程就是簽名的逆向,了解簽名流程即可,本文不求甚解,有興趣自己去分析,只是額外提下覆蓋安裝,覆蓋安裝除了檢驗APK自己的完整性以外,還要校驗證書是否一致只有證書一致(同一個keystore簽名),才有可能覆蓋升級。覆蓋安裝同全新安裝相比較多了幾個校驗
這里只關心證書部分:
Android V1及V2簽名簽名原理簡析
僅供參考,歡迎指正
⑺ SMSSDK android發驗證碼返回錯誤碼489MD5錯誤
集成SMSSDK從3.3.0版本開始必須要在mob後台配置MD5簽名(md5是指Android端apk簽名文件(keystore)中的md5值)以下是MD5的使用規則:
1.md5碼限制只針對Android3.3.0以上的版本,Android3.3.0以前的版本或者iOS任何版本,在後台添加md5是不起作用的
2.md5簽名中不含「:」
3.md5目前不區分大小寫, 必須和自己的包里的md5一致
4.未審核或審核未通過,不影響20條測試
5.原先通過審核的包(同一個包名)升級sdk的話,目前沒有測試額度,必須填寫MD5並且審核通過才能使用
6.Android和iOS相同包名,只上傳了ios的話,就在ios包下設置MD5簽名並且審核通過才不影響Android包
7.同一個包名下最多可提交5個md5,只要請求的包中的md5與後台配置的任何一個md5匹配就行
8.如果是gradle集成的用戶,只有在重新打包的時候才會更新,不會影響線上版本 如果還有不清楚的地方 可以登陸MobTech官網咨詢
⑻ 在應用市場發布android應用安裝包提示參數(包簽名MD5跟現有的版本的簽名MD5不一致)
這種情況表示的是:
你之前有上傳過此程序的版本;
你現在是在更新此程序;
更新的apk用的簽名文件(keystore)跟之前的不一樣。
解決方法呢就是: 找到之前的keystore文件,簽名後再上傳。