Application Signature Verification: How It Works, How to Disable It with Xposed, and Why You Shouldn’t
If you’ve ever tried to modify and reinstall a system application, you probably encountered application signature checks in one form or another. Either you removed the original app before proceeding, or you gave your modified APK another package name in order to get it to install without first removing the old application. And in either case, you also had to re-sign the application yourself in order to get it to install in the first place.
You can get around all of these behaviors by temporarily disabling application signature checks. But before we get into the metaphorical meat and potatoes of this article and tell you how to do so, it’s critical that we talk a little bit about application signature checks, what they do, and why you should never remove them in the vast majority of cases.
Android Signature Verification Basics
By default, the Android OS requires all applications to be signed in order to be installed. In very basic terms, this means that the application signature is used to identify the author of an application (i.e. verify its legitimacy), as well as establish trust relationships between applications with the same signature. With the former, you are assured (to a reasonable degree) that an application with a valid signature comes from the expected developers. And through the latter, applications signed with the same private key may run in the same process and share private data. Then when you install an application update, the Android OS checks this signature to make sure that: A) the APK has not been tampered in the time since it was signed, and B) the application’s certificate matches that of the currently installed version.
So how does all of this affect me in the real world? It’s simple, really. If you obtain an APK from outside of the Google Play Store and attempt to install it as an update to your currently installed app (read: same package name), the OS will attempt to validate the application’s certificate to make sure that it came from the same initial developers. If the certificate matches, the application install will proceed as planned, your application will retain its existing data, and all is gravy. If the signature is not valid (indicating that the APK has been tampered) or if the certificate does not match that of the original app, the installation will fail. And as stated earlier, the application certificate will only match if it is signed with the same private key used to sign the previous version. In other words, you can only install an application if it has a valid signature that matches the APK’s contents, and you can only install an update if its certificate also matches that found on the earlier version of the app.
[As a humorous aside in this otherwise dense article, there is one very public example in which a private application signing key was lost or compromised. I am of course referring to Google’s own Authenticator app, which received an update that changed its package name from com.google.android.apps.authenticator to com.google.android.apps.authenticator2 in an update about two years ago. Due to this change, all subsequent Authenticator app updates could only be issued under the new package name–with the new signature generated by the new private signing key.]
Why You May Wish to (Temporarily) Disable Signature Verification
Now, let’s take a look at a potential scenario in which we may wish to temporarily disable application signature verification. As mentioned at the start of this article, signature verification can be a bit of a headache when modifying existing system applications. If you install a modified version of a system application, you will be unable to sign the application with a valid and matching certificate. In cases like this, you would normally want to remove the existing application first, and then install the modified version as normal. You could also disable signature verification, but it’s better (and safer) to leave signature verification enabled and simply remove the old version so that the new one can install. This, however, can become a bit of an issue if the app you’re trying to replace has data that you’d rather not lose. There are certainly ways to preserve the data manually using root access and transplant it to the new version of the app, but users may also wish to simply disable signature verification temporarily and then resume checks afterwards. Alternatively as pointed out by XDA Senior Member mcbyte_it in the comments, this can also be useful in application development.
How to Do So
Up until now, disabling signature verification has been a horrible solution for pretty much any problem. This is because when doing so, you essentially throw away Android’s built in protection that makes sure that your applications haven’t been tampered with and that their updates come from the original developers. But now thanks to the magic of Xposed Framework, you can temporarily disable signature verification and re-enable it once you’re done installing your modified application. One such Xposed Module that can do precisely this was recently released by XDA Senior Member pyler, and it works as planned for all devices capable of running Xposed. This way when you wish to install a modified application update that has not been properly signed, you can simply enable the module, reboot, install the modified application update, disable the module, reboot, and be on your merry way.
Now that you know how to temporarily disable signature verification, it’s important to reiterate how important it is to leave signature verification enabled at all times, unless you have a very, very good reason to disable it. As such, you should only really use such a tool in order to apply application updates that you create yourself and when there are extenuating circumstances that require you to do so rather than simply uninstalling the old application first.
Be safe, and use this judiciously.
Want more posts like this delivered to your inbox? Enter your email to be subscribed to our newsletter.