Will Verduzco · Jun 16, 2014 at 12:00 am

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 something on the XDA Portal? Send us a tip!

Will Verduzco

willverduzco is an editor on XDA-Developers, the largest community for Android users. Will Verduzco is the Portal Administrator for the XDA-Developers Portal. He has been addicted to mobile technology since the HTC Wizard. But starting with the Nexus One, his gadget love affair shifted to Google's little green robot. He is also a Johns Hopkins University graduate in neuroscience and is now currently studying to become a physician. View willverduzco's posts and articles here.
Mario Tomás Serrafero · Apr 18, 2015 at 10:00 am · 4 comments

Open War for Open Android: Antitrust for Cyanogen?

Android and openness is something we talk about all the time, but the recent developments in the industry point towards inherent flaws with this very premise. Be it from bloggers, political institutions or corporations, Android is seemingly not open enough. The “War on Openness” is ironically becoming an open war, where many players are increasing their stakes and scope to try and land a bigger hold - or at the very least, restrict Google’s - on what is the world’s...

XDA NEWS
Emil Kako · Apr 17, 2015 at 01:22 pm · 3 comments

What Do You Do with All of Your Old Photos?

Smartphone cameras have advanced so tremendously over the past few years that they have almost completely replaced point and shoot digital cameras for the most of us. Furthermore, since our smartphones are always with us, the majority of us end up taking tons of photos throughout the lifespan of our devices. But what happens to all the old photos you take? Do you store them on an external hard-drive or keep them backed up to an online cloud service like Flickr? Let us know what your favorite way of storing old photos is and why.

DISCUSS
Faiz Malkani · Apr 17, 2015 at 01:04 pm · 1 comment

Diving into the April 2015 Material Design Update

Before the release of Android 5.0 Lollipop, the Holo Design guidelines served as the official reference for Android design, right from IceCream Sandwich to KitKat. However, updates to the guidelines were few and far between, leading to a lack of synchronization between Android design and current UI/UX trends. Google seems to have learned from their mistake the last time around, and earlier this week, a significant update was released for the Material Design guidelines, marking the second revision in less...

XDA NEWS
Share This