在 Android 應(yīng)用的安全體系中，簽名機(jī)制是保障 APK 完整性與可信來(lái)源的關(guān)鍵手段。越來(lái)越多的應(yīng)用（尤其是金融、電商類(lèi)）會(huì)在運(yùn)行時(shí)進(jìn)行簽名校驗(yàn)，以防止被篡改或二次打包。本篇文章將從簽名校驗(yàn)的原理出發(fā)，介紹常見(jiàn)的繞過(guò)方式，并分析開(kāi)發(fā)者與逆向工程師之間的“攻防博弈”。

一、Android 簽名校驗(yàn)原理

Android 系統(tǒng)要求每個(gè) APK 在安裝前都必須經(jīng)過(guò)簽名。簽名不僅保證了 APK 的完整性，還用于標(biāo)識(shí)開(kāi)發(fā)者的身份。在運(yùn)行時(shí)，應(yīng)用也可以自行校驗(yàn)簽名以檢測(cè)是否被篡改。校驗(yàn)流程通常涉及以下幾個(gè)核心環(huán)節(jié)：

1. 獲取 PackageInfo

應(yīng)用通過(guò) PackageManager.getPackageInfo() 方法獲取自身的 PackageInfo 對(duì)象，其中包含 signatures（Android 9 及以下）或 signingInfo（Android 9+）字段，用于反映 APK 的簽名信息。這個(gè)過(guò)程內(nèi)部依賴(lài) PackageParser 解析 APK 文件中的 META-INF 目錄下的 .RSA/.DSA 文件。

2. CREATOR 反序列化機(jī)制

在 Binder 跨進(jìn)程通信（如系統(tǒng)服務(wù)與應(yīng)用交互）過(guò)程中，PackageInfo 對(duì)象會(huì)通過(guò) Parcelable 接口進(jìn)行序列化與反序列化。具體是通過(guò) CREATOR.createFromParcel() 方法構(gòu)造 PackageInfo，其中簽名字段也被反序列化出來(lái)。

3. 底層文件操作

讀取 APK 或簽名文件通常涉及文件 I/O 操作，如 open、read 等，這些調(diào)用最終都依賴(lài)于 libc 層的系統(tǒng)函數(shù)。

4. 應(yīng)用層自定義校驗(yàn)

部分應(yīng)用在 Java 或 JNI 層主動(dòng)讀取簽名信息并與預(yù)設(shè)值進(jìn)行對(duì)比，達(dá)到校驗(yàn)簽名的目的。這種方式靈活性高、也更易被混淆或加殼保護(hù)。

二、簽名校驗(yàn)繞過(guò)的常見(jiàn)思路

在逆向分析或自動(dòng)化測(cè)試場(chǎng)景中，繞過(guò)簽名校驗(yàn)是必不可少的一步。以下是常見(jiàn)的繞過(guò)方法，按邏輯層次劃分：

1. 攔截 PackageInfo 簽名信息

• 目標(biāo)：篡改 getPackageInfo() 返回的簽名字段。
• 實(shí)現(xiàn)思路：利用 Xposed、Frida 等框架 hook PackageManager.getPackageInfo() 方法，返回自定義 PackageInfo 對(duì)象，并偽造簽名字段（如 MD5、SHA1）。
• 適用場(chǎng)景：Java 層簽名校驗(yàn)邏輯。

2. 替換 CREATOR 構(gòu)造器

• 目標(biāo)：控制 Binder 通信中 PackageInfo 的反序列化過(guò)程。
• 實(shí)現(xiàn)思路：替換 PackageInfo.CREATOR，在 createFromParcel() 中構(gòu)造偽造簽名對(duì)象，從而影響系統(tǒng)服務(wù)下發(fā)的數(shù)據(jù)。
• 適用場(chǎng)景：跨進(jìn)程通信校驗(yàn)（如通過(guò) ActivityManagerService 獲取簽名）。

3. 重定向文件 I/O

• 目標(biāo)：篡改簽名文件內(nèi)容。
• 實(shí)現(xiàn)思路：Hook libc 層的 open() 或 read() 函數(shù)，在訪(fǎng)問(wèn) META-INF/ 簽名文件時(shí)返回偽造內(nèi)容。Frida、ptrace、或 preload SO 層劫持是常見(jiàn)方式。
• 適用場(chǎng)景：JNI 或底層校驗(yàn) APK 文件內(nèi)容的邏輯。

4. 替換 Application 類(lèi)

• 目標(biāo)：繞過(guò)應(yīng)用初始化流程中的簽名校驗(yàn)邏輯。
• 實(shí)現(xiàn)思路：修改 AndroidManifest.xml 中聲明的 Application 類(lèi)或 AppComponentFactory，注入自定義邏輯，避開(kāi)原始簽名校驗(yàn)。
• 適用場(chǎng)景：加固或殼中初始化簽名校驗(yàn)邏輯。

5. 系統(tǒng)調(diào)用級(jí)別攔截（高級(jí)）

• 目標(biāo)：偽造從內(nèi)核返回的文件內(nèi)容。
• 實(shí)現(xiàn)思路：通過(guò) inline hook 或內(nèi)核模塊攔截 SVC 指令，直接修改 sys_open、sys_read 返回值，實(shí)現(xiàn)更底層的繞過(guò)。
• 適用場(chǎng)景：高版本 Android，繞過(guò) SELinux 或反調(diào)試限制。

三、檢測(cè)與反檢測(cè)的攻防對(duì)抗

在簽名校驗(yàn)繞過(guò)普及的同時(shí)，開(kāi)發(fā)者也在不斷強(qiáng)化檢測(cè)機(jī)制。逆向工程師需要應(yīng)對(duì)如下檢測(cè)手段并設(shè)計(jì)反制策略：

1. CREATOR 檢測(cè)

• 檢測(cè)方式：校驗(yàn) PackageInfo.CREATOR 是否為系統(tǒng)原生類(lèi)。
• 繞過(guò)策略：hook 檢測(cè)邏輯，返回偽造但合法的 CREATOR 實(shí)例；或在 JNI 層使用 native 方法偽裝。

2. Application 類(lèi)校驗(yàn)

• 檢測(cè)方式：校驗(yàn) Application 實(shí)例是否為期望的類(lèi)名，或是否被替換為無(wú)效對(duì)象。
• 繞過(guò)策略：在反射層或 LoadedApk 中修改 mApplication 實(shí)例，使其符合預(yù)期。

3. 文件完整性檢測(cè)

• 檢測(cè)方式：讀取 APK 中 META-INF 文件、比對(duì) CRC32 或簽名摘要。
• 繞過(guò)策略：在文件系統(tǒng)層攔截讀取操作，提供偽造文件內(nèi)容，或 Patch 校驗(yàn)邏輯代碼。

4. 內(nèi)存校驗(yàn)與 Dex 完整性驗(yàn)證

• 檢測(cè)方式：比對(duì) ClassLoader 加載的 Dex 內(nèi)容與磁盤(pán)內(nèi)容是否一致。
• 繞過(guò)策略：修改內(nèi)存中的 Dex 數(shù)據(jù)，或 Hook 校驗(yàn)函數(shù)返回原始值。

5. AppComponentFactory 檢測(cè)

• 檢測(cè)方式：檢測(cè) AppComponentFactory 的初始化流程與實(shí)際調(diào)用棧。
• 繞過(guò)策略：構(gòu)造偽造工廠(chǎng)類(lèi)、重寫(xiě)其創(chuàng)建組件邏輯，確保行為與原始一致。

四、總結(jié)

簽名校驗(yàn)作為 Android 安全體系的第一道防線(xiàn)，其重要性不言而喻。但隨著逆向技術(shù)的發(fā)展，簽名校驗(yàn)也逐漸演變?yōu)橐粓?chǎng)攻防博弈。開(kāi)發(fā)者需要構(gòu)建多層次、多維度的校驗(yàn)體系；而逆向工程師則需靈活運(yùn)用 Java Hook、Native Hook、甚至系統(tǒng)層手段進(jìn)行繞過(guò)。

無(wú)論你是開(kāi)發(fā)者，還是逆向工程師，理解簽名校驗(yàn)的原理與繞過(guò)方式，都是提升安全能力與分析技巧的必要一步。

到此這篇關(guān)于A(yíng)ndroid 簽名校驗(yàn)與繞過(guò)思路詳解的文章就介紹到這了,更多相關(guān)Android 簽名校驗(yàn)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論