android驗證簽名

Ⅰ Android APP的簽名

Android APP的簽名

Android項目以它的包名作為唯一的標識，如果在同一部手機上安裝兩個包名相同的APP，後者就會覆蓋前面安裝的應用。為了避免Android APP被隨意覆蓋，Android要求對APP進行簽名。下面介紹對APP進行簽名的步驟

1、選擇builder菜單下的Generate Signed APK

2、彈出簽名向導對話框

3、在該對話框中選擇數字證書，如果沒有數字證書，可以點擊Create new按鈕，創建數字證書如下圖所示：

4、輸入證書的存儲路徑及文件名稱，密碼，有效年份，發布人員的姓名，單位，所在城市，省份，國家等信息，後點擊OK按鈕，如下圖所示，系統會自動帶入密碼

5、點擊Next選擇簽名後的安裝包存放路徑，構建類型，點擊finish完成安裝包的構建

注意：

v2是Android 7.0中引入了簽名版本，v1是jar Signature來自JDK，只勾選v1簽名並不會影響什麼，但是在7.0上不會使用更安全的驗證方式，只勾選V2簽名7.0以下會直接安裝完顯示未安裝，7.0以上則使用了V2的方式驗證，為了保證兼容性，可以同時勾選V1和V2。
在Debug調試版本中，默認會調用調試用的簽名證書debug.keystore，該證書默認存放在C:\Users<你的用戶名>.android下。
包名和簽名都相同的APP才可以覆蓋安裝

Ⅱ 如何判斷 Android 應用的 Apk 簽名是否一致

Android應用的發布形式apk中包含的簽名加密方法除了RSA還有DSA，所以不能只從apk中提取常見的META-INF/CERT.RSA，第一步應該是檢查apk中具體的簽名文件是什麼。
FILE="yourapp.apk"
cert_XSA=`jar tf $FILE | grep SA`
此時得到的cert_XSA可能是META-INF/*.RSA或者META-INF/*.DSA。

接下來從apk中提取具體的簽名文件。
jar xf $FILE $cert_XSA
此時會在當前目錄得到cert_XSA文件。

然後對於得到的簽名文件，提取其中簽名的MD5值
keytool -printcert -file $cert_XSA | grep MD5 > "$FILE.certMD5"
這時候yourapp.certMD5這個文件中就保存了yourapp.apkk中的簽名MD5值。

最後比較兩個app的簽名可以用diff
FILE1="yourapp1.apk"
FILE2="yourapp2.apk"
# ...
# ... 經過上述步驟得到$FILE1.certMD5和$FILE2.certMD5
# ...
certMD5_diff=`diff $FILE1.certMD5 $FILE2.certMD5`
if [ "$certMD5_diff" = "" ]; then
echo "$FILE1.certMD5 == $FILE2.certMD5"
fi
若輸出yourapp1.apk.certMD5 == yourapp2.apk.certMD5那麼這兩個應用的簽名就一致。

Ⅲ 安卓 自動簽名 以及如何驗證一個apk包是用你的簽名文件簽名的

## 使用自動簽名的方法

1. 創建或者修改 ~/.gradle/gradle.properties

2. 在gradle.properties 文件中增加鏈寬乎下面的內容.(具體內巧棚容需要根據實際來更改)

STORE_PASSWORD=xysys

KEY_ALIAS=xxsasd

KEY_PASSWORD=988asdf

3. 這樣每次build的時候，總是用keystore來簽名，不會用生成的debug來簽名了

## 使用命令行來構建APK

進入項目最高層目錄,找到 gradlew. 執行下面的命令來構建所有類型的APK，自動使用官方簽名

## 驗證簽名是官方簽名

1. 使用keytool 獲取apk包的指紋

例如：

2. 查看keystore的棚悉指紋

apk的簽名指紋跟keystore中的指紋一致表明該包是用keystore來簽名的。

注意：若java版本是7之前的，需要先把apk解壓，

來看包的指紋。

Ⅳ Android簽名機制之簽名文件和數字證書的作用

Android簽名機制目的是確保app的可靠通信，其一，要確定消息的來源確實是其申明

的那個人；其二，要保證信息在傳遞的過程中不被第三方篡改，即使被篡改了，也可以

發覺出來。

所謂數字簽名，就是為了解決這兩個問題而產生的，它是對非對稱加密技術與數字摘要

技術的一個具體的應用。

對於消息的發送者來說，先要生成一對公私鑰對，將公鑰給消息的接收者。

如果消息的發送者有一天想給消息接收者發消息，在發送的信息中，除了要包含原始的

消息外，還要加上另外一段消息。這段消息通過如下兩步生成：

1）對要發送的原始消息提取消息摘要；

2）對提取的信息摘要用自己的私鑰加密。

通過這兩步得出的消息，就是所謂的原始信息的數字簽名。

而對於信息的接收者來說，他所收到的信息，將包含兩個部分，一是原始的消息內容，

二是附加的那段數字簽名。他將通過以下三步來驗證消息的真偽：

1）對原始消息部分提取消息摘要，注意這里使用的消息摘要演算法要和發送方使用的一致；

2）對附加上的那段數字簽名，使用預先得到的公鑰解密；

3）比較前兩步所得到的兩段消息是否一致。如果一致，則表明消息確實是期望的發送者

發的，且內容沒有被篡改過；相反，如果不一致，則表明傳送的過程中一定出了問題，

消息不可信。

通過這種所謂的數字簽名技術，確實可以有效解決可靠通信的問題。如果原始消息在傳

送的過程中被篡改了，那麼在消息接收者那裡，對被篡改的消息提取的摘要肯定和原始

的不一樣。並且，由於篡改者沒有消息發送方的私鑰，即使他可以重新算出被篡改消息

的摘要，也不能偽造出數字簽名。

那麼數字簽名呢？

綜上所述，數字簽名其實就是只有信息的發送者才能產生的別人無法偽造的一段數字

串，這段數字串同時也是對信息的發送者發送信息真實性的一個有效證明。

不知道大家有沒有注意，前面講的這種數字簽名方法，有一個前提，就是消息的接收者

必須要事先得到正確的公鑰。如果一開始公鑰就被別人篡改了，那壞人就會被你當成好

人，而真正的消息發送者給你發的消息會被你視作無效的。而且，很多時候根本就不具

備事先溝通公鑰的信息通道。那麼如何保證公鑰的安全可信呢？這就要靠數字證書來解

決了。

所謂數字證書，一般包含以下一些內容：

證書的發布機構（Issuer）

證書的有效期（Validity）

消息發送方的公鑰

證書所有者（Subject）

數字簽名所使用的演算法

數字簽名

可以看出，數字證書其實也用到了數字簽名技術。只不過要簽名的內容是消息發送方的

公鑰，以及一些其它信息。但與普通數字簽名不同的是，數字證書中簽名者不是隨隨便

便一個普通的機構，而是要有一定公信力的機構。這就好像你的大學畢業證書上簽名的

一般都是德高望重的校長一樣。一般來說，這些有公信力機構的根證書已經在設備出廠

前預先安裝到了你的設備上了。所以，數字證書可以保證數字證書里的公鑰確實是這個

證書的所有者的，或者證書可以用來確認對方的身份。數字證書主要是用來解決公鑰的

安全發放問題。

綜上所述，總結一下，數字簽名和簽名驗證的大體流程如下圖所示：

引用鏈接： https://www.cnblogs.com/dacainiao/p/5842987.html

Ⅳ 如何對android的apk簽名進行驗證

方法/步驟

1
菜單菜單鍵，鍵入cmd命令進入命令模式。如圖：

2
命令模式中，進入JDK的安裝目錄的Bin子目錄下。（我的JDK安裝在E盤，所以先進入E盤，然後再進入JDK安裝目錄）

3
通過keytool.exe 工具來創建keystore庫.
輸入以下命令：
keytool -genkeypair -alias - mydemo.keystore -keyalg RSA -validity 100
-keystore mydemo.keystore
命令說明如下：
-genkeypair ：指定生成數字證實
-alias ：指定生成數字證書的別名
-keyalg：指定生成數字證書的演算法 這里如RSA演算法
-validity：指定生成數字證書的有效期
-keystore ：指定生成數字證書的存儲路徑。 （這里默認在keytool.exe 目錄下）
回車 出現如圖互動式界面 輸入數字證書費密碼 作者 公司等詳細信息
如圖 ：

4
完成後，keystore庫創建完成，你可以在指定的保存目錄下找到 如圖：

5
使用jarsigner命令對未簽名的APK安裝包進行簽名。使用JDK安裝目錄下bin子目錄下的jarsigner.exe工具來進行簽名。
然後把未簽名的apk也拷貝到此目錄。如圖：

6
使用如下命令進行簽名：
jarsigner -verbose -keystore mydemo.keystore -signedjar
-Note.apk Notes.apk mydemo.keystore
以上命令的說明：
-verbose：指定生成詳細輸出
-keystore：指定數字證書存儲路徑
-signedjar：該選項的三個參數為 簽名後的apk包 未簽名的apk包 數字證書別名
注意有效期哦。

7
簽名後的apk 如圖：

8
sdk目錄下tool目錄下使用zipalign.exe工具優化APK安裝包。
將已經簽名的apk包放在zipalign.exe同目錄下 如圖：

9
使用如下命令：
zipalign -f -v 4 -Note.apk -Notes.apk
命令說明：
-f ：指定強制覆蓋已有文件
-v 指定生成詳細輸出
4：指定檔案整理基於的位元組數 一般是4 也有基於32位的。
-Note.apk :優化前APK
-Notes.apk 優化後的APK

10
運行命令後，在該目錄下生成一個-Notes.apk,這個就是優化過的APK安裝包
，該安裝包可以對外發布。
如圖：
如果能對你有幫助，希望你能收藏和支持。

http://jingyan..com/article/3c48dd3491d91fe10be358f4.html

Ⅵ android 系統簽名

也有提到怎麼單獨給一個apk簽名，這里補充一下android的簽名許可權控制機制。

android的標准簽名key有：

     testkey

     media

    latform

    hared

    以上的四種，可以在源碼的/build/target/proct/security裡面看到對應的密鑰，其中shared.pk8代表私鑰，shared.x509.pem公鑰，一定是成對出現的。

    其中testkey是作為android編譯的時候默認的簽名key，如果系統中的apk的android.mk中沒有設置LOCAL_CERTIFICATE的值，就默認使用testkey。

   而如果設置成：

   LOCAL_CERTIFICATE := platform

    就代表使用platform來簽名，這樣的話這個apk就擁有了和system相同的簽名，因為系統級別的簽名也是使用的platform來簽名，此時使用android:sharedUserId="android.uid.system"才有用！

     在/build/target/proct/security目錄下有個README，裡面有說怎麼製作這些key以及使用問題（android4.2）：

     從上面可以看出來在源碼下的/development/tools目錄下有個make_key的腳本，通過傳入兩個參數就可以生成一對簽名用的key。

    其中第一個為key的名字，一般都默認成android本身有的，因為很多地方都默認使用了這些名字，我們自定義的話只需要對第二個參數動手腳，定義如下：

    C ---> Country Name (2 letter code) ST ---> State or Province Name (full name) L ---> Locality Name (eg, city) O ---> Organization Name (eg, company) OU ---> Organizational Unit Name (eg, section) CN ---> Common Name (eg, your name or your server』s hostname) emailAddress ---> Contact email addre

    另外在使用上面的make_key腳本生成key的過程中會提示輸入password，我的處理是不輸入，直接enter，不要密碼！後面解釋，用自定義的key替換/security下面的。

    可以看到android源碼裡面的key使用的第二個參數就是上面README裡面的，是公開的，所以要release版本的系統的話，肯定要有自己的簽名key才能起到一個安全控製作用。

    在上面提到如果apk中的編譯選項LOCAL_CERTIFICATE沒有設置的話，就會使用默認的testkey作為簽名key，我們可以修改成自己想要的key，按照上面的步驟製作一個releasekey，修改android配置在/build/core/config.mk中定義變數：

在主makefile文件裡面：

ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/proct/security/releasekey)

  BUILD_VERSION_TAGS += release-key

這樣的話默認的所有簽名將會使用releasekey。

修改完之後就要編譯了，如果上面的這些key在製作的時候輸入了password就會出現如下錯誤：

我在網上找到了合理的解釋：

其實會出現這個錯誤的最根本的原因是多線程的問題。在編譯的時候為了加速一般都會執行make -jxxx，這樣本來需要手動輸入密碼的時候，由於其它線程的運行，就會導致影響當前的輸入終端，所以就會導緻密碼無法輸入的情況！

再編譯完成之後也可以在build.prop中查看到變數：

這樣處理了之後編譯出來的都是簽名過的了，系統才算是release版本

我發現我這樣處理之後，整個系統的算是全部按照我的要求簽名了。

網上看到還有另外的簽名release辦法，但是應該是針對另外的版本的，借用學習一下：

make -j4 PRODUCT-proct_mol-user dist

這個怎麼跟平時的編譯不一樣,後面多了兩個參數PRODUCT-proct_mol-user 和 dist. 編譯完成之後回在源碼/out/dist/目錄內生成個proct_mol-target_files開頭的zip文件.這就是我們需要進行簽名的文件系統.

我的proct_mol 是full_gotechcn,後面加「-user」代表的是最終用戶版本，關於這個命名以及proct_mol等可參考http://blog.csdn.net/jscese/article/details/23931159

編譯出需要簽名的zip壓縮包之後，就是利用/security下面的准備的key進行簽名了：

./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/security  out/dist/full_gotechcn-target_files.zip   out/dist/signed_target_files.zi

簽名目標文件 輸出成signed_target_files.zi

如果出現某些apk出錯，可以通過在full_gotechcn-target_files.zip前面加參數"-e =" 來過濾這些apk.

然後再通過image的腳本生成imag的zip文件，這種方式不適用與我目前的工程源碼，沒有做過多驗證！

Android簽名機制可劃分為兩部分：（1）ROM簽名機制；（2）第三方APK簽名機制。

Android APK實際上是一個jar包，而jar包又是一個zip包。APK包的簽名實際上使用的是jar包的簽名機制：在zip中添加一個META的子目錄，其中存放簽名信息；而簽名方法是為zip包中的每個文件計算其HASH值，得到簽名文件(*.sf)，然後對簽名文件(.sf)進行簽名並把簽名保存在簽名塊文件(*.dsa)中。

在編譯Android源碼生成ROM的過程中，會使用build/target/proct/security目錄中的4個key（media, platform, shared, testkey）來對apk進行簽名。其中，*.pk8是二進制形式（DER）的私鑰，*.x509.pem是對應的X509公鑰證書（BASE64編碼）。build/target/proct/security目錄中的這幾個默認key是沒有密碼保護的，只能用於debug版本的ROM。

要生成Release版本的ROM，可先生成TargetFiles，再使用帶密碼的key對TargetFiles重新簽名，最後由重簽名的TargetFiles來生成最終的ROM。

可以使用Android源碼樹中自帶的工具「development/tools/make_key」來生成帶密碼的RSA公私鑰對（實際上是通過openssl來生成的）: $ development/tools/make_key media 『/C=CN/ST=Sichuan/L=Cheng/O=MyOrg/OU=MyDepartment/CN=MyName』 上面的命令將生成一個二進制形式（DER）的私鑰文件「media.pk8」和一個對應的X509公鑰證書文件「media.x509.pem」。其中，/C表示「Country Code」，/ST表示「State or Province」，/L表示「City or Locality」，/O表示「Organization」，/OU表示「Organizational Unit」，/CN表示「Name」。前面的命令生成的RSA公鑰的e值為3，可以修改development/tools/make_key腳本來使用F4 (0×10001)作為e值（openssl genrsa的-3參數改為-f4）。

也可以使用JDK中的keytool來生成公私鑰對，第三方APK簽名一般都是通過keytool來生成公私鑰對的。

可以使用openssl x509命令來查看公鑰證書的詳細信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout

還可以使用JDK中的keytool來查看公鑰證書內容，但其輸出內容沒有openssl x509全面： $ keytool -printcert -v -file media.x509.pem

有了key之後，可以使用工具「build/tools/releasetools/sign_target_files」來對TargetFiles重新簽名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目錄中需要有四個key（media, platform, shared, releasekey）。注意：這里的releasekey將代替默認的testkey（請參考build/tools/releasetools/sign_target_files腳本實現），也就是說，如果某個apk的Android.mk文件中的LOCAL_CERTIFICATE為testkey，那麼在生成TargetFiles時是使用的build/target/proct/security/testkey來簽名的，這里重新簽名時將使用new_keys_dir/releasekey來簽名。

uild/tools/releasetools/sign_target_files_apks是通過host/linux-x86/framework/signapk.jar來完成簽名的。也可以直接使用host/linux-x86/framework/signapk.jar來對某個apk進行簽名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，」-w」表示還對整個apk包(zip包）進行簽名，並把簽名放在zip包的comment中。

對於第三方應用開發者而言，對APK簽名相對要簡單得多。第三方應用開發一般採用JDK中的keytool和jarsigner來完成簽名密鑰的管理和APK的簽名。

使用keytool來生成存儲有公私鑰對的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000

查看生成的密鑰信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （註：獲取Base64格式的公鑰證書，RFC 1421）

導出公鑰證書： $ keytool -export -keystore mystore -alias mykey -file my.der （註：二進制格式公鑰證書，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （註：Base64格式公鑰證書，PEM）

對APK進行簽名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey

驗證簽名： $ jarsigner -verify -verbose -certs my_application.apk

在進行Android二次開發時，有時需要把build/target/proct/security下面的公私鑰對轉換為keystore的形式，可以參考這篇文章：把Android源碼中的密碼對轉換為keystore的方法。

Ⅶ Android | 他山之石，可以攻玉！一篇文章看懂 v1/v2/v3 簽名機制

這篇文章的內容會涉及以下前置 / 相關知識，貼心的我都幫你准備好了，請享用~

數字簽名（Digital Signature）也叫作數字指紋（Digital Fingerprint），它是消息摘要演算法和非對稱加密演算法的結合體，能夠驗證數據的完整性，並且認證數據的來源 。

數據簽名演算法的模型分為兩個主要階段：

需要注意的是，Android 目前不對應用證書進行 CA 認證，應用可以由第三方（OEM、運營商、其他應用市場）簽名，也可以自行簽名。

應用 APK 其實是一種特殊的 Zip 壓縮包，無法避免惡意破解者解壓 / 反編譯修改內容，針對這個問題有何解決方案呢？他山之石，可以攻玉 ——數字簽名演算法。應用簽名正是數字簽名演算法的應用場景之一，與其他應用場景類似，目的無非是：

Android 平台上運行的每個應用都必須有開發者的簽名。在安裝應用時，軟體包管理器會驗證 APK 是否已經過適當簽名，安裝程序會拒絕沒有獲得簽名就嘗試安裝的應用。

軟體包管理器在安裝應用前會驗證應用摘要，如果破解者修改了 apk 里的內容，那麼摘要就不再匹配，驗證失敗（驗證流程見下文方案）。

截止至 Android 11，Android 支持以下三種應用簽名方案：

為了提高兼容性，必須按照 v1、v2、v3 的先後順序採用簽名方案，低版本平台會忽略高版本的簽名方案在 APK 中添加的額外數據。

v1 簽名方案是基於 Jar 的簽名。

首先，我們先來分析其簽名產物。 v1 簽名後會增加 META-INF 文件夾 ，其中會有如下三個文件。考慮到使用不同的證書和簽名方式，得到的文件名可能不同，因此你只要留意文件的後綴即可：

v1 簽名流程如下：

MANIFEST.MF（Message Digest File，摘要文件）

*.SF（Signature File，簽名文件）

驗證流程可以分為驗證簽名和驗證完整性兩個步驟：

驗證簽名步驟：

如果上述簽名驗證結果正確，才會驗證完整性：

以上任何步驟驗證失敗，則整個 APK 驗證失敗。

為了解決這些問題，Android 7.0 中引入了 APK 簽名方案 v2。

v2 簽名方案是一種 全文件簽名方案 ，該方案能夠發現對 APK 的受保護部分進行的所有更改，相對於 v1 簽名方案驗證速度更快，完整性覆蓋范圍更廣。

在分析 v2 簽名方案之前，我們先簡單了解一下 Zip 文件格式：

首先，我們先來分析其簽名產物。v2 簽名後會在 「條目內容區」和「中央目錄區」之間插入「APK 簽名分塊（APK Signing Block）」 。

從左到右邊，我們定義為區塊 1~4。

相對與 v1 簽名方案，v2 簽名方案不再以文件為單位計算摘要了，而是以 1 MB 為單位將文件拆分為多個連續的塊（chunk），每個分區的最後一個塊可能會小於 1 MB。

v2 簽名流程如下：

驗證流程可以分為驗證簽名和驗證完整性兩個步驟：

簽名方案 v3 支持密鑰輪換，應用能夠在 APK 更新過程中更改其簽名密鑰。

【累了，後面先不寫了...】

這一節，我們介紹基於 Android 應用簽名機制的衍生應用場景。

在 v1 方案中， MANIFEST.MF 和 *.SF 這兩個文件會記錄大量的文件名和文件摘要。如果 apk 中文件數很多，而且文件名很長，那麼這兩個文件會變得很大。使用 AndResGuard 工具，可以將文件名轉換為短路徑文件名，從而減少這兩個文件的大小。

在實際生產中，往往需要生成多個渠道的 APK 包，傳統的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，這一類多渠道打包方案的缺點是耗時嚴重。隨著 Android 應用簽名方案的演進，演變出了不同的多渠道打包方案：

在 v1 方案中，我們提到了完整性校驗不覆蓋到 META-INF 文件夾的問題。有些多渠道打包方案就是利用了這個問題，在 META-INF 文件夾下添加空文件， 用空文件的名稱來作為渠道的唯一標識 ，就可以節省打包的時間，提高打渠道包的速度。

除了添加空文件的方法，還可以向 APK 添加 Zip Comment 來生成多渠道包（APK 本身就是特殊的 Zip 包）。

在 v2 簽名方案中，幾乎整個 APK 都納入保護范圍，如果向 APK 添加空文件或 Zip Comment 的話，在安裝時會報以下錯誤：

新背景下的多渠道打包方案，則是利用了 APK 簽名分塊（區塊 2）不受保護 & 欄位可擴展的特點 ，向區塊中添加多渠道信息（ID-Value），例如 美團多渠道打包方案 Walle 。