Failed to collect certificates from /system/app/Bluetooth/Bluetooth.apk using APK Signature Scheme v3

[3038843920]

My operation is as follows:

1. Extract /system/app/Bluetooth. apk from the rooted pixel first generation AOSP Android 10 system (command: adb pull/system/app/Bluetooth. apk.)
2. Decompilation: Java jar \APKEditor-1.3.9.jar d -dex -f -i . \Bluetooth.apk
3. Compile back: Java jar \APKEditor-1.3.9.jar b -f -i . \Bluetooth_decompile_xml
4. Coverage push back: adb push \Bluetooth_decompile_xml_out.apk /system/app/Bluetooth.apk
5. System restart: adb reboot
6. View logs and filter PackageManager: 1971-09-22 07:57:34.519 944-944 PackageManager system_server I /system/app/Bluetooth changed; collecting certs 1971-09-22 07:57:34.525 944-944 PackageManager system_server W Failed to scan /system/app/Bluetooth: Failed to collect certificates from /system/app/Bluetooth/Bluetooth.apk using APK Signature Scheme v3

Question: I have checked the AOSP source code and found android.util.apk There is an exception thrown in ApksignatureVerifier.verify: throw new PackageParserException(INSTALL_PARSE_FAILED_NO_CERTIFICATES, "Failed to collect certificates from " + apkPath + " using APK Signature Scheme v3", e); come from: http://aospxref.com/android-10.0.0_r47/xref/frameworks/base/core/java/android/util/apk/ApkSignatureVerifier.java#103

My question: I have tested that if the signature is completely consistent, simply using adb push to replace the original system app with a modified one with the same signature but inconsistent signatures can still be used normally I would like to ask if this is due to insufficient processing of V3 signatures in the project, or is it related to the Mismatch in zip data descriptors issue mentioned in the issue? Is there any way to handle it directly?

[REAndroid]

• "Signature restore" function on APKEditor is not same as signing apk, it just places V2 & V3 signing blocks on zip structure. Here is general structure of signed apk: [Local File Headers] [V2 signing block] [V3 signing block] [Central Entry headers] [End block]
  • V2 & V3 blocks contains certificate and SHA digest of [Local File Headers] (which is lost during any modding), in order to conclude the apk is signed a system must do SHA digest of [Local File Headers] in android this done by SignatureVerifier

• Apps/services like google sign-in first sends the apk to SignatureVerifier then trusts the certificate on V2/V3. So you need to disable SignatureVerifier

BTW: Since Bluetooth.apk is a system app you can sign with any of your key

[3038843920]

Thank you very much for your reply. Initially, I tried to directly sign and overwrite the installation, but due to the configuration of android: sharedUserId="android. uid. Bluetooth" in AndroidMainfest.xml of Bluetooth.apk, the value of this sharedUserId property needs to maintain the same signature as other apps with the same UID. I checked the AOSP source code and found the "com. android. server. pm. permission. PermissionManagerial Service. rantSignaturePermission" function (from: http://aospxref.com/android-10.0.0_r47/xref/frameworks/base/services/core/java/com/android/server/pm/permission/PermissionManagerService.java?r=&mo=81167&fi=1660#1660 ）Verified, which resulted in me being stuck in the boot logo interface after performing the operation of "directly pushing the second signed apk file and restarting the system". Therefore, I analyzed the function and found that changing "ro.controlle_privapp_permissions=enforce" to "ro.controlle_privapp_permissions=disable" in "/vendor/build. prop" would solve the verification problem. However, when I restarted the system to turn on Bluetooth, the app still failed to start. Through the "logcat" log, I found that there may be some issues with SELinx (logcat exception output: "SELinx: Could not set context for/data/data/com. android. Bluetooth: Permission denied"). However, I am not very familiar with the issue of SELinx and do not know how to proceed. Additionally, my production environment is not very convenient for installing framework software and modules such as Magisk and Apatch. Therefore, I wanted to try to find a solution to modify the app while retaining its original signature. Finally, I found your article on Google and after trying it out, I discovered the problem mentioned at the beginning. In addition, I have used a closed source app called "MT Manager"(link:https://mt2.cn/) before. Initially, I used its latest version to modify the app but did not re sign it. However, I found that it still failed. After checking through "logcat", I discovered that the signature was incorrect. However, after trying it out, I used the 2.15.0 version of the "MT Manager" app to modify the app without re signing it. I found that there was no need to modify the system properties and the app could be replaced directly to run successfully. I thought about and tried the above operations for about a week, and finally, in a situation where there was nothing I could do, I sent you my initial question. Thank you very much for your answer.

Finally, I would like to ask you another question. Do you know of any recommended open source projects or solutions that can almost perfectly achieve the operation of modifying an app without re signing and keeping the app's signature unchanged?

Finally, thank you very much for your response. Looking forward to your answer

[REAndroid]

However, after trying it out, I used the 2.15.0 version of the "MT Manager" app to modify the app without re signing it. I found that there was no need to modify the system properties and the app could be replaced directly to run successfully.

Sorry hard to believe this, can you drop both apks (original and modified) here ?

I checked the AOSP source code and found the "com. android. server. pm. permission. PermissionManagerial Service. grantSignaturePermission"

How about modifying PermissionManagerial class so that grantSignaturePermission returns true for your specific package, e.g

private boolean grantSignaturePermission(String perm, PackageParser.Package pkg,
              BasePermission bp, PermissionsState origPermissions) {
              boolean oemPermission = bp.isOEM();
  if(pkg.packageName.equals("com.android.bluetooth")){
    return true;
  }
  .....

Finally, I would like to ask you another question. Do you know of any recommended open source projects or solutions that can almost perfectly achieve the operation of modifying an app without re signing and keeping the app's signature unchanged?

I don't think it exist at all. As I tried to explain above, V2 & V3 blocks contains SHA-256 digest against certificates. So any change on the file results different SHA digest.

V2 blocks had some weakness but closed by V3, but if you discovered any logic for tampering signature blocks APKEditor is very suitable to implement.