故事的开始

明天老大急冲冲的跑过来说:xx,你帮我看看这手机咋回事,忽然开不了机。

我心想:我最近也没提过代码,应该不是我的问题吧。(甩锅~.~)

把电脑插上手机后,我看到上面这段报错始终在loop

12-31 16:08:49.603 21899 21899 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: main12-31 16:08:49.603 21899 21899 E AndroidRuntime: java.lang.IllegalStateException: Signature|privileged permissions not in privapp-permissions whitelist: {com.xxx.xxx.xxxxx (/data/app/~~BR9Kz0rmscIpqqvqBf8jwg==/com.xxx.xxx.xxxxx-fLGzzHKkZaTB5_DLxgo_Fg==): android.permission.BACKUP, com.xxx.xxx.xxxxx (/data/app/~~BR9Kz0rmscIpqqvqBf8jwg==/com.xxx.xxx.xxxxx-fLGzzHKkZaTB5_DLxgo_Fg==): android.permission.UPDATE_DEVICE_STATS}12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.server.pm.permission.PermissionManagerService.systemReady(PermissionManagerService.java:4688)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.server.pm.permission.PermissionManagerService.access$500(PermissionManagerService.java:181)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.server.pm.permission.PermissionManagerService$PermissionManagerServiceInternalImpl.systemReady(PermissionManagerService.java:4771)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.server.pm.PackageManagerService.systemReady(PackageManagerService.java:22183)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.server.SystemServer.startOtherServices(SystemServer.java:2305)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.server.SystemServer.run(SystemServer.java:624)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.server.SystemServer.main(SystemServer.java:440)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at java.lang.reflect.Method.invoke(Native Method)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)12-31 16:08:49.603 21899 21899 E AndroidRuntime:  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

看完之后我立马答复:老大,这个我晓得,肯定是零碎利用组的同学遗记在privapp-permissions-platform.xml文件上面加权限申明了。

老大:不会呀,这个手机我始终在用,前面忽然就变成这样了。

此刻的我一脸懵逼:还有如此神奇之事。故事的开始便是这样,接下来我就开始考察这个神奇的景象。

万恶之源

《众 所 周 知》

手机开机会查看priv-app的权限是否和/etc/permissions/privapp-permissions-platform.xml(有可能在别的文件夹下,例如vendor/etc/permissions,也有可能叫其余名字,因为只有xml的节点是对的就行,pm中的SystemConfig会对这类文件夹的所有xml进行扫描)所申明的权限是否一样,不一样则无奈开机,就会始终loop下面的crash。

先从log中的PermissionManagerService#systemReady办法动手

private void systemReady() {    mSystemReady = true;    // 万恶之源    if (mPrivappPermissionsViolations != null) {        throw new IllegalStateException("Signature|privileged permissions not in "                                        + "privapp-permissions whitelist: " + mPrivappPermissionsViolations);    }    // ...}

只有mPrivappPermissionsViolations这个数组中有数据,咱们就永远无奈开机,看看这个数组是怎么填充的。

private boolean grantSignaturePermission(String perm, AndroidPackage pkg,            PackageSetting pkgSetting, BasePermission bp, PermissionsState origPermissions) {  // ...        if (!privappPermissionsDisable && privilegedPermission && pkg.isPrivileged()                && !platformPackage && platformPermission) {            if (!hasPrivappWhitelistEntry(perm, pkg)) {                if (!mSystemReady                        && !pkgSetting.getPkgState().isUpdatedSystemApp()) {                    ApexManager apexMgr = ApexManager.getInstance();                    String apexContainingPkg = apexMgr.getActiveApexPackageNameContainingPackage(                            pkg);                    if (apexContainingPkg == null || apexMgr.isFactory(                            apexMgr.getPackageInfo(apexContainingPkg, MATCH_ACTIVE_PACKAGE))) {                        // ... 进行和xml申明的权限进行比照... 发现在黑名单找到这个perm的或者在白名单找不到这个perm                        // 一律加到开机防火墙(我本人想的名字0.0)中                        if (permissionViolation) {                            Slog.w(TAG, "Privileged permission " + perm + " for package "                                    + pkg.getPackageName() + " (" + pkg.getCodePath()                                    + ") not in privapp-permissions whitelist");                            if (RoSystemProperties.CONTROL_PRIVAPP_PERMISSIONS_ENFORCE) {                                if (mPrivappPermissionsViolations == null) {                                    mPrivappPermissionsViolations = new ArraySet<>();                                }                                mPrivappPermissionsViolations.add(                                        pkg.getPackageName() + " (" + pkg.getCodePath() + "): "                                                + perm);                            }                        } else {                            return false;                        }                    }             // ....                          }                }            }        }}

看完这里,我有一个疑难,一个一般的App怎么会有如此大的影响(小身材大力量?),能够看到下面各种条件判断能力走到这个校检权限申明的码块里。而这其中的一个条件引起了我的留神---pkg.isPrivileged(),这个为true则阐明这是一个priv-app,而priv-app个别都是内置在零碎内作为系统软件,还能在内部装置?(可能是我见识太少了 丢人~~)。

与之关联的是一个scanFlag叫SCAN_AS_PRIVILEGED,这个在开机扫描的时候就常常应用,对一个指定的零碎外部门路scan的时候加上SCAN_AS_PRIVILEGED,这个门路上面所有的包都是priv-app。果不其然,当我找这个flag的应用时候,发现PMS的其余中央也会给一个包附上这个flag,就在PMS#adjustScanFlags办法中。

// 对和priv-app进行sharedUser的利用也要像priv-app一样扫描final boolean skipVendorPrivilegeScan = ((scanFlags & SCAN_AS_VENDOR) != 0)    && getVendorPartitionVersion() < 28;if (((scanFlags & SCAN_AS_PRIVILEGED) == 0)    && !pkg.isPrivileged()    && (pkg.getSharedUserId() != null)    && !skipVendorPrivilegeScan) {    SharedUserSetting sharedUserSetting = null;    try {        sharedUserSetting = mSettings.getSharedUserLPw(pkg.getSharedUserId(), 0,                                                       0, false);    } catch (PackageManagerException ignore) {    }    if (sharedUserSetting != null && sharedUserSetting.isPrivileged()) {        // 豁免应用平台密钥签名的SharedUsers。        // TODO(b / 72378145)修复此豁免。        // 强制签名应用程序像其余priv-apps一样将其特权许可列入白名单。        synchronized (mLock) {            PackageSetting platformPkgSetting = mSettings.mPackages.get("android");            if ((compareSignatures(platformPkgSetting.signatures.mSigningDetails.signatures,                                   pkg.getSigningDetails().signatures)                 != PackageManager.SIGNATURE_MATCH)) {                scanFlags |= SCAN_AS_PRIVILEGED;            }        }    }}

而在PMS#adjustScanFlags办法中,给和priv-app sharedUser的利用 append 上SCAN_AS_PRIVILEGED,让其也要强制退出到开机查看的白名单列表,所以google这是成心而为之。既然作为一个priv-app,开机查看权限也就成了天经地义了。所以咱们为priv-app预置到零碎的时候,要确定该priv-app有没有其余的sharedUserId利用,如果有的话,也要在权限白名单privapp-permissions-platform.xml中申明这个没有预置到零碎的App申请的权限,否则装上去之后重启会造成loop crash。

为什么SharedUser的利用可能共享权限

《 众 所 周 知》 * 2

所有查看权限的最初步骤都是通过调用PackageSettings中的getPermissionsState()获取App的权限获取状态,代码如下:

@Overridepublic PermissionsState getPermissionsState() {    return (sharedUser != null)        ? sharedUser.getPermissionsState()        : super.getPermissionsState();}

如果Package的PackageSettings的sharedUser不为空,则默认用sharedUser的权限。所以SharedUser的利用能相互共享大家已有的权限,且一个权限授予了,在这个SharedUser的其余包都会默认授予这个权限。做零碎利用的同学可能比拟理解,只有在manifest.xml中申明android:sharedUserId="android.uid.system",就能获取并应用其余同属于android.uid.systemSharedUser组的其余权限。

SharedUser怎么被赋值到PackageSettings上 咱们先来看看PMS#scanPackageNewLI办法中的这个中央,也就值sharedUser赋值的中央。

SharedUserSetting sharedUserSetting = null;if (parsedPackage.getSharedUserId() != null) {    // SIDE EFFECTS; may potentially allocate a new shared user    sharedUserSetting = mSettings.getSharedUserLPw(parsedPackage.getSharedUserId(),                                                   0 /*pkgFlags*/, 0 /*pkgPrivateFlags*/, true /*create*/);    if (DEBUG_PACKAGE_SCANNING) {        if ((parseFlags & PackageParser.PARSE_CHATTY) != 0)            Log.d(TAG, "Shared UserID " + parsedPackage.getSharedUserId()                  + " (uid=" + sharedUserSetting.userId + "):"                  + " packages=" + sharedUserSetting.packages);    }}

咱们能够看到这里依据parsedPackage.getSharedUserId这个String类型的SharedUserId,就去pm.Settings中寻找属于这个package的SharedUserSetting了,也没有校验这个包的sharedUserId是否合乎某些条件,例如签名之类的条件。

直到最初的PMS#commitPackageSettings(长久化PackageSettings到packages.xml文件中,安装包数据不再发生变化步骤),也没有对这个SharedUserSetting进行从新赋值,所以到这步我感觉应该是SharedUserId的问题。机智的我把想法就放在了这个SharedUserId的赋值流程下面了,一通查找之下,我找到了SharedUserId赋值的中央:ParsingPackageUtils#parseSharedUser

private static ParseResult<ParsingPackage> parseSharedUser(ParseInput input,                                     ParsingPackage pkg, TypedArray sa) {                                                                 String str = nonConfigString(0, R.styleable.AndroidManifest_sharedUserId, sa);                           if (TextUtils.isEmpty(str)) {                                                                                return input.success(pkg);                                                                           }                                                                                                                                                                                                                 if (!"android".equals(pkg.getPackageName())) {                                                               ParseResult<?> nameResult = validateName(input, str, true, true);                                        if (nameResult.isError()) {                                                                                  return input.error(PackageManager.INSTALL_PARSE_FAILED_BAD_SHARED_USER_ID,                                       "<manifest> specifies bad sharedUserId name \"" + str + "\": "                                                   + nameResult.getErrorMessage());                                                     }                                                                                                    }                                                                                                                                                                                                                 return input.success(pkg                                                                                         .setSharedUserId(str.intern())                                                                           .setSharedUserLabel(resId(R.styleable.AndroidManifest_sharedUserLabel, sa)));                } 

下面这段代码很简略,大略的意思就是读取R.styleable.AndroidManifest_sharedUserId这个attribute中的内容,而后间接给它赋值到这个String类型的SharedUserId下面,也没有做合规查看。这时候不禁就有个疑难了,那我岂不是轻易申明一个android:sharedUserId="xxx"就能获取到SharedUser的其余权限?这时候我关上了测试的test demo,给它加上android:sharedUserId属性,但没有胜利装置胜利,且报了INSTALL_FAILED_SHARED_USER_INCOMPATIBLE异样,往PMS那么一搜,啪的一下,很快就找到辣(但其实是找错了 因为报错不是在PMS中产生)。因为找错了的起因,我把装置的堆栈打了进去,发现报错其实是在PackageManagerServiceUtils#verifySignatures。

先把堆栈打进去

verifySignatures:689, PackageManagerServiceUtils (com.android.server.pm)reconcilePackagesLocked:16947, PackageManagerService (com.android.server.pm)installPackagesLI:17373, PackageManagerService (com.android.server.pm)installPackagesTracedLI:16696, PackageManagerService (com.android.server.pm)lambda$processInstallRequestsAsync$22$PackageManagerService:14802, PackageManagerService (com.android.server.pm)run:-1, -$$Lambda$PackageManagerService$9znobjOH7ab0F1jsW2oFdNipS-8 (com.android.server.pm)handleCallback:938, Handler (android.os)dispatchMessage:99, Handler (android.os)loop:223, Looper (android.os)run:67, HandlerThread (android.os)run:44, ServiceThread (com.android.server)

这也很合乎逻辑,SharedUser中的其余包:你说你是我兄弟,那你就是我兄弟?拿你的签名跟我的比照一下,一样的才算我兄弟。毕竟在包治理中,一个包的签名相当于这个包的DNA了,只有通过同一个x509.pem和.pk8文件签名的apk的签名才会雷同。

能够看到这里校验签名不匹配间接抛出了throw new PackageManagerException,终止装置流程,基本不给你装置胜利的机会。所以并不需要置空SharedUserSetting或者SharedUserId,只有装置胜利的Package且它们的SharedUserSetting不为空,都是非法的。

/** * Verifies that signatures match. * @returns {@code true} if the compat signatures were matched; otherwise, {@code false}. * @throws PackageManagerException if the signatures did not match. */public static boolean verifySignatures(PackageSetting pkgSetting,                                       PackageSetting disabledPkgSetting, PackageParser.SigningDetails parsedSignatures,                                       boolean compareCompat, boolean compareRecover)    throws PackageManagerException {    final String packageName = pkgSetting.name;    boolean compatMatch = false;    // ...    // 查看是否匹配SharedUser的签名    if (pkgSetting.getSharedUser() != null        && pkgSetting.getSharedUser().signatures.mSigningDetails        != PackageParser.SigningDetails.UNKNOWN) {        // 曾经存在的软件包。确保签名匹配。在签订证书轮换的状况下,        // 带有较新证书的软件包必须与较旧版本的sharedUserId保持一致。        // 咱们查看是否新软件包是由较旧的证书签名的,能够应用以后的sharedUser签名,        // 还是由较新的证书签名,以及是否与现有的签名证书作为sharedUser签名,则能够。        boolean match =            parsedSignatures.checkCapability(            pkgSetting.getSharedUser().signatures.mSigningDetails,            PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID)            || pkgSetting.getSharedUser().signatures.mSigningDetails.checkCapability(            parsedSignatures,            PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID);        // 如果sharedUserId性能查看失败,        // 则可能是因为这是sharedUserId中到目前为止惟一的包,        // 并且继承被更新以回绝继承中先前密钥的sharedUserId性能。        if (!match && pkgSetting.getSharedUser().packages.size() == 1            && pkgSetting.getSharedUser().packages.valueAt(0).name.equals(packageName)) {            match = true;        }        if (!match && compareCompat) {            match = matchSignaturesCompat(                packageName, pkgSetting.getSharedUser().signatures, parsedSignatures);        }        if (!match && compareRecover) {            match =                matchSignaturesRecover(packageName,                                       pkgSetting.getSharedUser().signatures.mSigningDetails,                                       parsedSignatures,                                       PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID)                || matchSignaturesRecover(packageName,                                          parsedSignatures,                                          pkgSetting.getSharedUser().signatures.mSigningDetails,                                          PackageParser.SigningDetails.CertCapabilities.SHARED_USER_ID);            compatMatch |= match;        }        // 不配对 则抛异样 装置失败        if (!match) {            throw new PackageManagerException(INSTALL_FAILED_SHARED_USER_INCOMPATIBLE,                                              "Package " + packageName                                              + " has no signatures that match those in shared user "                                              + pkgSetting.getSharedUser().name + "; ignoring!");        }        // ...    }    return compatMatch;}

最初

请大家留神好手机备份和软件起源的确认,如果有其余手机厂商“修复”了这个问题能够在评论区告知,AndroidQ和R都会存在这个问题,至于后面的版本就没一一确认了。我曾经用这个apk搞坏了一台Google Pixel(泪目),普通用户大略也只能复原出厂设置了,高级用户能够用串口关上USB调试,而后把这个包卸载掉。

我的库存,须要的小伙伴请点击我的GitHub收费支付