1. 项目概述一场围绕“身份”的攻防拉锯战在移动安全领域APK签名校验是开发者保护其应用不被篡改、确保代码来源可信的第一道也是至关重要的一道防线。它就像是应用的“数字身份证”系统在安装和运行时都会核验这张身份证的真伪。然而在逆向工程和安全研究的视角下这道防线也成为了一个经典的攻防战场。我最近花了相当一段时间系统地复盘了从最基础的Java层Hook绕过到针对V1签名机制进行“偷梁换柱”的完整对抗过程。这不仅仅是一次技术演练更像是一场围绕“身份”认证展开的、充满策略与细节的拉锯战。对于从事Android应用安全、逆向分析或者对加固技术感兴趣的朋友来说理解这套攻防逻辑不仅能让你明白攻击者如何下手更能从防御角度思考如何构建更坚固的堡垒。整个攻防史的核心围绕着PackageManager和PackageParser这两个系统核心服务展开。应用安装时系统会校验APK的签名应用运行时通过PackageManager.getPackageInfo()等方法也能获取签名信息进行二次校验。攻击者的目标就是让这些校验逻辑“看到”我们期望的签名而非APK文件实际的签名。从浅层的Java方法Hook到深层的V1签名块结构替换技术难度和对抗强度逐级递增。接下来我将按照实战推进的顺序拆解每一个环节的技术原理、操作细节以及那些容易踩坑的地方。2. 第一回合Java层Hook的试探与局限性最初的尝试往往从最高层、最易入手的地方开始。在Android中获取签名信息最常见的代码是Signature[] sigs context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES).signatures;或者使用PackageManager.GET_SIGNING_CERTIFICATES来获取更现代的签名方案。我们的目标就是让这段代码返回我们指定的、合法应用的签名而不是当前被修改过的APK的签名。2.1 核心思路与工具选型思路非常直接Hook住PackageManager.getPackageInfo()方法当检测到调用者意图获取签名信息即flags参数包含GET_SIGNATURES等标志位时返回一个我们精心构造的、包含合法签名的PackageInfo对象。工具方面我选择了Xposed框架。虽然现在有Frida、LSPosed等更多选择但Xposed的稳定性和对Java层Hook的直观性对于初学者理解原理非常友好。我们需要编写一个Xposed模块针对目标应用进程进行Hook。注意在实际测试中务必使用自己的测试应用或已获得授权的应用切勿对他人应用进行非法篡改。2.2 实操步骤与代码实现首先在Xposed模块的handleLoadPackage方法中找到目标应用并Hook其使用的PackageManager。实际上更通用的做法是Hook系统服务android.app.ApplicationPackageManager类它是PackageManager的实现类的getPackageInfo方法。public void handleLoadPackage(final LoadPackageParam lpparam) throws Throwable { // 指定我们想要处理的目标应用包名 if (!lpparam.packageName.equals(com.target.app)) { return; } // Hook ApplicationPackageManager.getPackageInfo(String packageName, int flags) Class? clazz XposedHelpers.findClass(android.app.ApplicationPackageManager, lpparam.classLoader); XposedHelpers.findAndHookMethod(clazz, getPackageInfo, String.class, int.class, new XC_MethodHook() { Override protected void afterHookedMethod(MethodHookParam param) throws Throwable { // param.args[0] 是 packageName, param.args[1] 是 flags String pkgName (String) param.args[0]; int flags (int) param.args[1]; // 只处理针对目标应用且请求了签名信息的调用 if (pkgName.equals(com.target.app) (flags PackageManager.GET_SIGNATURES) ! 0) { // 获取原始结果 PackageInfo originalPkgInfo (PackageInfo) param.getResult(); if (originalPkgInfo ! null) { // 伪造签名。这里需要准备一个合法的签名对象数组。 // 通常你需要从一个已签名的合法APK中提取出它的Signature。 Signature[] fakeSignatures new Signature[]{yourPreparedLegitimateSignature}; originalPkgInfo.signatures fakeSignatures; // 对于新的签名方案V2可能需要伪造signingInfo if (android.os.Build.VERSION.SDK_INT android.os.Build.VERSION_CODES.P) { if (originalPkgInfo.signingInfo ! null) { // 这里需要反射修改SigningInfo内部字段比较复杂是进阶对抗点 // 对于初步测试可以暂时忽略或直接置空但某些严格校验会失败 } } // 将修改后的PackageInfo设置为方法返回值 param.setResult(originalPkgInfo); } } } }); }这段代码的关键在于yourPreparedLegitimateSignature。你需要从一个你拥有合法签名权的APK例如一个你自己开发的Demo应用中通过代码或者工具如keytool或apksigner提取出它的签名信息并转换成Xposed模块中可用的Signature对象。2.3 效果评估与暴露的缺陷部署好Xposed模块并激活后重启目标应用你会发现很多简单的、仅在Java层进行签名校验的逻辑已经失效了。应用会认为自己的签名是合法的从而继续执行。然而这种方法的局限性非常明显对抗动态检测如果应用在NativeC/C代码中调用系统库函数进行签名校验Java层的Hook完全无效。对抗签名缓存系统服务PackageManagerService在安装时就已经计算并缓存了APK的签名信息。我们Hook的是客户端侧的ApplicationPackageManager它最终通过Binder与系统服务通信。有些校验可能会直接尝试与底层服务交互绕过我们的Hook。兼容性问题不同Android版本尤其是Android 9.0引入的SigningInfo导致伪造逻辑复杂难以一劳永逸。环境依赖必须在一个已安装Xposed框架的Root环境中运行普适性差。第一回合的胜利是脆弱的它仅仅欺骗了应用进程内最上层的校验逻辑。一旦防御方将校验逻辑下沉攻击就必须跟进。这就引出了我们更底层的操作直接修改APK文件本身的签名信息。3. 深入核心V1签名机制与“偷梁换柱”原理为了突破Java层Hook的局限我们必须理解APK签名的本质。Android主要支持V1JAR签名、V2APK签名方案V2、V3/V4签名。其中V1签名由于历史兼容性至今仍被广泛支持也是我们“偷梁换柱”的主要战场。3.1 V1签名结构深度解析一个使用V1签名的APK本质上就是一个标准的ZIP文件其中包含了一个特殊的目录项META-INF/。该目录下通常有三个文件MANIFEST.MFCERT.SFCERT.RSA(或CERT.DSA,CERT.EC)它们的生成和校验流程如下生成MANIFEST.MF遍历APK中除META-INF外的所有文件计算每个文件的SHA1或SHA256摘要以Base64编码形式记录在此文件中。生成CERT.SF计算MANIFEST.MF文件整体的哈希同时也会记录MANIFEST.MF中每个条目哈希值的再次哈希。这个文件是签名信息的载体。生成CERT.RSA这是最核心的一步。对CERT.SF文件的内容使用开发者的私钥进行数字签名加密哈希然后将签名结果和对应的公钥证书X.509格式一起打包成PKCS#7格式的数据存入CERT.RSA文件。这个文件包含了“我是谁”证书和“我证明这些哈希值没问题”签名两层信息。系统校验时会反向操作用CERT.RSA中的证书公钥解密签名得到一份哈希值A再实际计算CERT.SF文件的哈希值B。如果AB则证明CERT.SF未被篡改。接着用CERT.SF校验MANIFEST.MF再用MANIFEST.MF校验APK中各文件。任何一环不匹配校验即告失败。3.2 “偷梁换柱”的可行性分析“偷梁换柱”的核心思想在于APK的签名校验只关心META-INF/目录下的那几个文件所构成的证据链是否自洽而并不直接关联APK包名或其它内容。假设我们有两个APKAPK_A我们拥有其私钥的合法应用例如我们自己的应用com.legit.app。APK_B我们想要破解的目标应用com.target.app但其签名校验非常严格。“偷梁换柱”的操作就是从APK_A中提取出整个META-INF/目录包含CERT.RSA,CERT.SF,MANIFEST.MF。用这个META-INF/目录替换掉APK_B中原有的META-INF/目录。对APK_B中除META-INF/外的所有文件重新计算哈希并更新MANIFEST.MF文件使其与新APKAPK_B的内容匹配。关键一步保持CERT.SF和CERT.RSA文件完全不变。因为CERT.RSA是用APK_A的私钥对APK_A的CERT.SF进行的签名。只要我们不动CERT.SF这个签名就依然有效。矛盾点出现了MANIFEST.MF变了因为文件内容变了但CERT.SF还是旧的它记录的是旧MANIFEST.MF的哈希。这样CERT.SF校验MANIFEST.MF时肯定会失败。如何解决3.3 突破点MANIFEST.MF的“白名单”特性这里是整个操作最精妙也是风险最大的地方。在标准的签名验证过程中CERT.SF文件会包含对MANIFEST.MF主属性的哈希以及对其每个条目属性的哈希。但是Android系统的V1签名验证实现在某些版本或条件下可能存在一个“漏洞”它并非严格校验MANIFEST.MF中的每一个条目而是更侧重于校验CERT.SF本身的签名有效性以及通过CERT.SF去校验MANIFEST.MF文件本身的完整性。更具体地说当我们替换MANIFEST.MF后我们需要让新MANIFEST.MF文件的整体哈希值与原始CERT.SF文件中记录的MANIFEST.MF主属性哈希值一致。这听起来不可能因为文件内容不同哈希必然不同。但这里有一个关键MANIFEST.MF文件末尾的换行符、空白行等细微差异都可能改变其哈希值。我们需要精确地重构MANIFEST.MF文件使其在二进制层面的哈希值与原始APK_A中的MANIFEST.MF完全一致。这如何做到我们并不需要完全复制APK_A的MANIFEST.MF内容因为条目不同。我们需要进行“哈希碰撞”吗不实际利用的是文件格式的灵活性。我们可以修改新MANIFEST.MF文件在保持其语法正确的前提下通过调整条目顺序、增加或删除某些不影响解析的空格、换行符、注释或者利用Base64编码的填充字符等微调文件内容使其SHA1哈希值与目标值匹配。这是一个需要精心计算和调整的过程通常需要编写脚本自动化尝试。重要提示这种通过微调文件使哈希值匹配特定目标的技术在密码学上被称为“构造哈希碰撞前像”对于强哈希函数如SHA256在计算上是不可行的。但V1签名默认使用SHA1且此处我们是在已知原文件哈希和目标哈希的情况下寻找一个格式正确、内容符合要求即包含目标APK文件正确哈希条目且整体哈希匹配的MANIFEST.MF文件。这更像是一种针对特定文件格式和校验流程的“工程化技巧”而非破解哈希算法本身。随着Android版本更新和签名校验严格化此方法成功率在降低。4. 实战操作手工实现V1签名替换理解了原理我们开始动手。整个过程需要耐心和细致的操作。4.1 环境与工具准备Java开发环境JDK提供keytool,jarsigner等关键命令。Python环境用于编写自动化处理脚本计算哈希、调整文件。APK工具集apktool: 用于反编译/回编译APK方便我们查看和修改资源、清单文件虽然签名替换不一定需要改代码但有时需要。signapk.jar或apksigner.jar(Android SDK Build Tools中): 用于标准的APK签名。一个十六进制编辑器如010 Editor或HxD用于精确查看和修改文件二进制内容。两个APK文件legit.apk: 你自己签名的合法APK包名任意如com.you.legit。target.apk: 需要处理的目标APK。4.2 分步操作流程第一步提取原始签名材料# 解压legit.apk获取其META-INF目录 unzip legit.apk -d legit_original/ # 将META-INF目录备份 cp -r legit_original/META-INF/ .同时我们需要记录下legit.apk中MANIFEST.MF文件的SHA1哈希值这个值记录在CERT.SF文件中。# 查看CERT.SF文件找到“SHA1-Digest-Manifest:”这一行后面的值 # 可以使用文本编辑器打开或者用命令 cat META-INF/CERT.SF | grep -A1 SHA1-Digest-Manifest记下这个Base64编码的哈希值假设为ABC123...。将其解码为二进制格式备用可以用Python的base64.b64decode。第二步解压并准备目标APK# 解压target.apk unzip target.apk -d target_original/ # 删除其原有的META-INF目录 rm -rf target_original/META-INF/现在target_original/目录下包含了目标APK的所有内容但没有签名。第三步为目标APK生成新的MANIFEST.MF我们需要为target_original/目录下的所有文件排除META-INF生成标准的MANIFEST.MF。可以借助jarsigner或自己写脚本。一个简单的Python脚本示例如下import hashlib import base64 import os def generate_manifest_mf(apk_dir, output_path): manifest_lines [Manifest-Version: 1.0\r\n, Created-By: 1.0 (Android)\r\n, \r\n] for root, dirs, files in os.walk(apk_dir): # 跳过META-INF目录 if META-INF in root: continue for file in files: filepath os.path.join(root, file) # 计算SHA1 with open(filepath, rb) as f: sha1 hashlib.sha1(f.read()).digest() sha1_b64 base64.b64encode(sha1).decode(ascii) # 写入条目注意路径格式和换行符 rel_path os.path.relpath(filepath, apk_dir).replace(\\, /) manifest_lines.append(fName: {rel_path}\r\n) manifest_lines.append(fSHA1-Digest: {sha1_b64}\r\n) manifest_lines.append(\r\n) with open(output_path, w, newline\r\n) as f: # 注意换行符为CRLF f.writelines(manifest_lines) generate_manifest_mf(target_original/, new_manifest.mf)运行后得到new_manifest.mf。但它的整体SHA1哈希值肯定不等于我们之前记下的ABC123...。第四步调整MANIFEST.MF以匹配目标哈希核心难点这是最需要技巧的一步。我们需要在不破坏MANIFEST.MF文件结构的前提下微调其内容使其整体SHA1哈希值等于目标值。计算当前哈希计算new_manifest.mf的SHA1。with open(new_manifest.mf, rb) as f: current_hash hashlib.sha1(f.read()).digest()寻找调整点合法的调整点包括在文件头注释区域增加或删除空白行、注释行以#开头。微调条目间的空行数量MANIFEST.MF要求条目间用空行分隔但多个空行理论上也不影响解析。重要技巧每个条目SHA1-Digest:后的Base64字符串其解码后的二进制数据是固定的由文件内容决定但Base64编码本身可以有填充且编码表有标准格式。我们无法改变解码后的值但可以尝试在条目末尾增加空格或制表符在换行符之前。根据RFC标准这些空白字符在Base64解码时会被忽略但会影响文件整体哈希。这是一个常见的“技巧”。自动化尝试编写一个脚本系统地尝试在文件的不同位置例如在每个条目行尾、文件末尾添加不同数量的空格0x20或水平制表符0x09然后计算哈希直到与目标哈希匹配。由于搜索空间很大这可能需要一些时间甚至可能因为哈希函数的雪崩效应而难以在合理时间内完成。实操心得在实际操作中完全匹配一个给定的SHA1哈希极其困难。因此更常见的“偷梁换柱”变种是不直接替换整个META-INF而是只替换CERT.RSA和CERT.SF并保持目标APK原有的MANIFEST.MF不变。但这要求目标APK的MANIFEST.MF文件与你合法APK的MANIFEST.MF文件在经过可能的空白字符调整后能具有相同的哈希值。如果两个APK文件数量和内容差异很大这同样困难。所以这种方法通常在对特定目标、经过反复试验后才可能成功并非通用解决方案。第五步组装与重打包假设我们奇迹般地或通过上述变种方法获得了一个哈希匹配的MANIFEST.MF文件final_manifest.mf。将final_manifest.mf复制为META-INF/MANIFEST.MF。将之前从legit.apk提取的CERT.SF和CERT.RSA复制到META-INF/目录。将META-INF/目录放回target_original/。将target_original/目录下的所有文件重新打包成ZIPAPK格式。务必使用-0存储模式不压缩选项来压缩META-INF/下的文件因为签名是针对未压缩的文件内容计算的。cd target_original zip -r -0 ../modified_target.apk ./*或者使用apktool回编译如果之前用apktool反编译过apktool在回编译时会自动处理签名相关文件的压缩方式。第六步安装测试将生成的modified_target.apk安装到测试设备上。如果系统签名校验通过应用能够安装并运行且其内部的签名校验代码如果只做V1校验读取到的签名信息将是你合法应用legit.apk的签名。5. 攻防演进与更高阶的对抗上述“偷梁换柱”主要针对V1签名。现代Android应用普遍采用V2/V3/V4签名方案它们提供了更强的完整性保护。V2签名其签名信息存储在APK文件的特定块ZIP Central Directory之前中直接保护整个APK的二进制内容包括ZIP元数据。任何对APK文件的修改包括替换META-INF/都会破坏签名。单纯的文件替换方法完全失效。对抗V2签名这需要更底层的修改例如重新签名直接对修改后的APK用原私钥重新签名。但这需要破解或获取原开发者的私钥几乎不可能。绕过校验在运行时通过Hook底层系统库如libandroid_runtime.so,libc.so中负责验证签名的函数如JNI调用或open、read等文件操作在内存中返回伪造的签名数据。这需要深厚的Native层逆向和Hook功底。修改系统在Root设备上直接修改/system分区中的libandroid_runtime.so等库文件或者修改PackageManagerService的校验逻辑。这种方法破坏系统完整性且设备特异性强。从防御者角度看应对这种攻击的策略是使用V2/V3签名最低目标API级别设置为24Android 7.0以上强制使用V2签名。多维度校验不仅校验签名还校验证书序列号、公钥哈希、甚至代码本身的哈希完整性校验。Native层校验将核心校验逻辑放在Native代码中增加逆向和Hook难度。环境安全检测检测Root、Xposed、Frida等动态注入框架在危险环境下拒绝执行或触发混淆行为。服务端协同关键逻辑或密钥依赖服务端下发客户端仅作为执行容器。这场攻防战没有终点。作为开发者理解攻击手段是为了构建更有效的防御作为安全研究者探索技术边界是为了推动整个生态的安全性向前发展。无论站在哪一方深入理解其原理都是不可或缺的第一步。我的这次实战复盘从简单的Hook到复杂的签名结构操作深刻体会到安全是一个层层嵌套的洋葱每一层都有其独特的挑战和乐趣。