做自己的Android ROM，屏蔽对framework中的系统APK的签名检查

最新推荐文章于 2024-09-10 08:30:00 发布

zhao3546

最新推荐文章于 2024-09-10 08:30:00 发布

阅读量1.1w

点赞数 1

分类专栏： Android 文章标签： Android ROM 屏蔽系统APK签名检查

本文链接：https://blog.csdn.net/zhao_3546/article/details/11026705

版权

Android 专栏收录该内容

55 篇文章 0 订阅

订阅专栏

最近两天一直在尝试更新Android中的关键库以达到定制ROM的效果，中间比较曲折，记录下来供自己和大家参考。

因为我需要基于Android的原生代码做一定的修改，所以如果无法将我自己编译出的APK或Jar替换系统中的东西，则无法达成我的目标。

我的测试的机器：htc one 电信定制版（802d），Android版本：4.2.2；LG Nexus 4，Android版本：4.3。

测试第一步：

将手机root掉，以替换修改系统文件的权限。不同厂商的手机的root步骤不一样，自己上网搜索吧。

测试第二步：

使用我自己编译出来的SystemUI.apk，替换Nexus 4的SystemUI.apk，通过 adb logcat > 1.txt 查看日志，直接报下面的错；

W/PackageManager(  530): Signature mismatch for shared user : SharedUserSetting{41ea0bc8 android.uid.system/1000}

E/PackageManager(  530): Package com.android.systemui has no signatures that match those in shared user android.uid.system; ignoring!

签名有问题，根据这个关键字“has no signatures that match those”去搜索Android源代码，可以在PackageManagerService.java中找到如下函数：

    private boolean verifySignaturesLP(PackageSetting pkgSetting,
            PackageParser.Package pkg) {
        if (pkgSetting.signatures.mSignatures != null) {
            // Already existing package. Make sure signatures match
            if (compareSignatures(pkgSetting.signatures.mSignatures, pkg.mSignatures) !=
                PackageManager.SIGNATURE_MATCH) {
                    Slog.e(TAG, "Package " + pkg.packageName
                            + " signatures do not match the previously installed version; ignoring!");
                    mLastScanError = PackageManager.INSTALL_FAILED_UPDATE_INCOMPATIBLE;
                    return false;
                }
        }
        // Check for shared user signatures
        if (pkgSetting.sharedUser != null && pkgSetting.sharedUser.signatures.mSignatures != null) {
            if (compareSignatures(pkgSetting.sharedUser.signatures.mSignatures,
                    pkg.mSignatures) != PackageManager.SIGNATURE_MATCH) {
                Slog.e(TAG, "Package " + pkg.packageName
                        + " has no signatures that match those in shared user "
                        + pkgSetting.sharedUser.name + "; ignoring!");
                mLastScanError = PackageManager.INSTALL_FAILED_SHARED_USER_INCOMPATIBLE;
                return false;
            }
        }
        return true;
    }

直接替换，肯定是不行了，签名通不过，那我可否尝试将签名检查的代码给屏蔽掉？

测试第三步：

尝试屏蔽对系统级APK的签名检查，代码已经找到，在这个目录下：frameworks/base/services/java/com/android/server/pm。

进一步分析，services目录下的内容，最终会被编译成 services.jar，adb shell 后，在 /system/framework 下可以找到 services.jar。

root@android:/system/framework # ls servi*
ls servi*
services.jar

在 out/target/product/generic/dex_bootjars/system/framework 这个目录下可以找到 services.jar，

直接使用自己编译出来的services.jar去替换 /system/framework下的同名jar包，重启os后，好像报的这个错误：DexOpt: mismatch dep signature，

然后os一直处于死循环中，无法开机成功。

根据“DexOpt: mismatch dep signature”这个关键字搜索，在DexPrepare.cpp中有对应的检查：

if (memcmp(signature, ptr, kSHA1DigestLen) != 0) {  
    LOGI("DexOpt: mismatch dep signature for '%s'", cacheFileName);  
    goto bail;  
}

测试第四步：

既然第三步也不行，那我用自己编译出来的“libdvm.so” 将/system/lib下的同名文件更新掉，重启os后，还是类似的错误，签名摘要校验不过。

当前陷入了短时间的僵局，上网找了很多资料参考，大部分仅能参考，写得太不详细，直接我遇到了这个文档：《MIUI ROM定制教程》，

已经在我的百度网盘共享： http://pan.baidu.com/share/link?shareid=198381908&uk=4145338314

神一般的文档，将Android的系统框架，到刷机原理，再到一些刷机的具体细节，都写得非常清楚。

下面的过程是基于HTC ONE（802d）来测试的：

1、先找一个可刷机的ROM，我找到的是Nic_One_M7_802d_4.2.2_Devil_3.5_signed.zip，这个包可以刷机成功并且系统可用。

之前找的两个包可以刷机成功，但屏幕驱动似乎有问题，触屏无反应。

2、将原有包中的services.jar转成smali文件，通过 baksmali-1.4.2.jar 进行将 jar中的dex文件转成smali文件，将PackageManagerService.smali中的verifySignaturesLP函数的实现给修改掉，然后再使用smali-1.4.2.jar将反编译出的包含smali文件的目录转成dex文件，使用winrar打开services.jar，将新生成的classes.dex覆盖jar包中的classes.dex，将这个新jar包替换原ROM zip包中的同名文件。

再使用“土豆ROM工具箱” 将新ROM zip包重新签名下，再进行刷机。

经过几分钟的等待后，系统可用，并且使用我自己编译出的 SystemUI.apk 直接覆盖 /system/framework/ 下的同名文件，也不会再报签名错误，只是无法正常运行，无法正常运行的原因是：HTC定制过此apk，将原生的代码作了很多修改，同时加入htc自己实现的代码。

为了进一步验证，我将HTC系统原生的 SystemUI.apk 复制我的电脑上，使用“土豆ROM工具箱”将其重新签名，然后再替换原生 SystemUI.apk，HTC手机也是可以正常运行的。

终于成功将系统APK签名验证这步给屏蔽了，这样我就可以基于此ROM做很多其它想做的事件了。

进一步的验证和测试：

下载一份Nexus 4原生的可刷机的4.2.2的ROM，直接使用自己编译的services.jar替换原ROM中的同名文件，刷机成功后，完全可以正常使用。

再使用自己编译出来的SystemUI.apk替换系统的同名文件，一样也可以正常运行。基于支持Android原生系统的机器进行验证和扩展，直接修改源码重新编译替换系统原文件即可，非常方便。

smali-1.4.2.jar、baksmali-1.4.2.jar的使用命令参考：

C:\Users\zhao3546\Desktop\Android\Android_framework_4.2>java -jar smali-1.4.2.jar -h
usage: java -jar smali.jar [options] [--] [<smali-file>|folder]*
assembles a set of smali files into a dex file
 -?,--help                      prints the help message then exits. Specify
                                twice for debug options
 -a,--api-level <API_LEVEL>     The numeric api-level of the file to generate,
                                e.g. 14 for ICS. If not specified, it defaults
                                to 14 (ICS).
 -o,--output <FILE>             the name of the dex file that will be written.
                                The default is out.dex
 -v,--version                   prints the version then exits
 -x,--allow-odex-instructions   allow odex instructions to be compiled into the
                                dex file. Only a few instructions are supported
                                - the ones that can exist in a dead code path
                                and not cause dalvik to reject the class


C:\Users\zhao3546\Desktop\Android\Android_framework_4.2>java -jar baksmali-1.4.2.jar -h
usage: java -jar baksmali.jar [options] <dex-file>
disassembles and/or dumps a dex file
 -?,--help                                  prints the help message then exits.
                                            Specify twice for debug options
 -a,--api-level <API_LEVEL>                 The numeric api-level of the file
                                            being disassembled. If not
                                            specified, it defaults to 14 (ICS).
 -b,--no-debug-info                         don't write out debug info (.local,
                                            .param, .line, etc.)
 -c,--bootclasspath <BOOTCLASSPATH>         the bootclasspath jars to use, for
                                            analysis. Defaults to
                                            core.jar:ext.jar:framework.jar:andro
                                            id.policy.jar:services.jar. If the
                                            value begins with a :, it will be
                                            appended to the default
                                            bootclasspath instead of replacing
                                            it
 -d,--bootclasspath-dir <DIR>               the base folder to look for the
                                            bootclasspath files in. Defaults to
                                            the current directory
 -f,--code-offsets                          add comments to the disassembly
                                            containing the code offset for each
                                            address
 -l,--use-locals                            output the .locals directive with
                                            the number of non-parameter
                                            registers, rather than the .register
                                            directive with the total number of
                                            register
 -m,--no-accessor-comments                  don't output helper comments for
                                            synthetic accessors
 -o,--output <DIR>                          the directory where the disassembled
                                            files will be placed. The default is
                                            out
 -p,--no-parameter-registers                use the v<n> syntax instead of the
                                            p<n> syntax for registers mapped to
                                            method parameters
 -r,--register-info <REGISTER_INFO_TYPES>   print the specificed type(s) of
                                            register information for each
                                            instruction. "ARGS,DEST" is the
                                            default if no types are specified.
                                            Valid values are:
                                            ALL: all pre- and post-instruction
                                            registers.
                                            ALLPRE: all pre-instruction
                                            registers
                                            ALLPOST: all post-instruction
                                            registers
                                            ARGS: any pre-instruction registers
                                            used as arguments to the instruction
                                            DEST: the post-instruction
                                            destination register, if any
                                            MERGE: Any pre-instruction register
                                            has been merged from more than 1
                                            different post-instruction register
                                            from its predecessors
                                            FULLMERGE: For each register that
                                            would be printed by MERGE, also show
                                            the incoming register types that
                                            were merged
 -s,--sequential-labels                     create label names using a
                                            sequential numbering scheme per
                                            label type, rather than using the
                                            bytecode address
 -v,--version                               prints the version then exits
 -x,--deodex                                deodex the given odex file. This
                                            option is ignored if the input file
                                            is not an odex file