As a follow-up to this question, I am trying to figure out what stops Google from modifying our apps that it signs and distributes. Regardless of whether we distribute an APK or an App Bundle, the App Signing service strips away whatever signature that we have and Google signs the APKs that it distributes. In the case of the App Bundle, this will result in several APKs, akin to what bundletool generates.
But since an APK is just a ZIP archive with compiled code and resources, it seems as though Google could modify that as they see fit before signing, including adding or replacing code.
Google has stated:
we don’t modify and distribute your application code without your knowledge and approval
and:
As stated before, Play will not modify the functionality of your application without your knowledge and approval.
Notably, Google used "don't" and "will not"... as opposed to "can't" and "cannot". In fact, in the same post, we see:
For apps uploaded as app bundles, we will improve this security by introducing what is called a source stamp. This source metadata is inserted into the app’s manifest by bundletool.
So, we know of at least one modification, albeit to metadata.
Plus,
the Amazon AppStore for Android modifies APKs before re-signing them:
Regardless of whether you choose to apply Amazon DRM, Amazon wraps your app with code that enables the app to communicate with the Amazon Appstore client to collect analytics, evaluate and enforce program policies, and share aggregated information with you. Your app will always communicate with the Amazon Appstore client when it starts, even if you choose not to apply DRM.
Amazon removes your signature and re-signs your app with an Amazon signature that is unique to you, does not change, and is the same for all apps in your account.
Amazon has been doing this sort of thing for a decade.
It seems as though Google should have the same technical capability as does Amazon.
So, is there anything that I am missing that prevents Google from adding to or modifying the code in APKs that it re-signs and distributes?
Google doesn't just have the capability to modify .apk files uploaded to it's Google Play signing program- they already are.
Granted, this is at the moment a minor change and certainly a non-malicious one; but it remains an actual change of your .apk. They add
<meta-data
android:name="com.android.vending.derived.apk.id"
android:value="1" />
to the AndroidManifest.xml
Below is a comparison that I made in 2018 while researching this topic. It has the apk before upload (signed with upload key), and the apk as downloaded from Google Play with Google play signing enabled.
As you can see from this graphic; there's only two changes- the old signing (upload key) was removed, and replaced with Google signing. And also the AndroidManifest.xml was slightly appended (with the meta-data mentioned above)
I'll also point out this Google IO video from 2017 where they're introducing Google Play signing: https://www.youtube.com/watch?v=5tdGAP927dk&feature=youtu.be. From 11:25 in they're talking about something called "App signing + optimizations". The idea was that they could optimize apks for you, and generate sub-apks.
This was something that you could enable on a per-apk basis within Google Play. Today of course, you'll find no mention of any of this in any documentation, other than in this video- That's because they later came up with app bundles and essentially moved all this work into that. So, this is mostly relevant because the question was "What Stops Google From Modifying Our APKs That It Signs Via the App Signing Service?", and this shows that even specifically for .apk files they can; they intended to; and they were.
As others have pointed out; whoever has the signing keys and access to the Google Play account for the given app- can upload any .apk or .aab containing anything; as long as the packageName remains the same, and versionCode is incremented by one. The same applies of course to Google when Google Play signing is enabled. If they wanted, they could change, remove or add to any and all parts of the application.
It's worth keeping in mind that while yes; Google could modify everything and anything within the Google Play signed .apk file(s), those modifications aren't necessarily evil or with a bad intent. Whether for optimization purposes, compatibility or hot-fixing; there are plenty of reasons Google could or would modify the uploaded apk and justify those modifications. And they wouldn't necessarily warn the developers about this; nor would developers necessarily react to a discovery of this with an outcry.
I do believe that we're very unlikely to see Google perform purposely malicious content changes to uploaded apps, mostly for business, reputation and ethical risks outlined well in the other answers here already. I just can't picture this being a valuable attack vector for Google that outweighs the rather heavy cost-risk, and considering the other, often stronger vectors available to them.
Lastly, I'll mention integrity checks as one way this would be discovered. There are several solutions in this space that goes further than signature checks to verify the integrity of the app. Whether app developers roll their own, or use an off-the-shelves solution- these checks typically run during runtime on device to verify the integrity of the apk; comparing against records taken during compile-time or near compile-time. Modifications performed to the apk during transit does get picked up by this, including whatever change Google Play might do.
Disclaimer: I work for a app-security company that performs such integrity checks (any many other checks and verifications) on the apps that we protect. We've had to map out and account for all changes Google Play might do to an app both for regular apk files and app bundles- so we can distinguish between Google Play doing optimizations and a malicious actor repackaging the app.
At some point, the processor needs to be able to read the instructions in your app to know what it’s supposed to do. The operating system itself needs to know what to do with your app.
Ignoring how an app is packaged for a moment, for the aforementioned reasons, it seems to me there is no technical reason why your app cannot be modified by Google or any technical entity that has the knowledge and resources to do so. Let me explain further why:
It doesn’t matter how the app is packaged - the moment the operating system loads the app, you know what the app does. If the operating system did not know how to handle an app, the app would be useless.
You can try to obfuscate it, the way some popular worms tried to hide their purpose, but it really just delays the inevitable. People have been disassembling and decompiling software right from the beginning, that’s why many licenses used to explicitly prohibit disassembly.
Knowing this, it should be apparent that if “Google” wanted to modify your app they could, because even if the package is obfuscated, when the app is ultimately executing you could see what its doing then, document it, and then modify the app as required. They also have all the technical skills and resources to do so.
Let’s step back for a moment:
The purpose of signing something with a signature, is so that one can determine if the copy of the app they have received is authentic - in this case, if the app that an end user has received matches what is on the play store. The purpose being to ensure the copy you have is the same as the one distributed to other users.
You’re asking if there is a technical reason why Google cannot modify the app - no there isn’t. You’ve mentioned yourself that an apk is just a zip file. If your app was signed by yourself, and that same signature was included in the copy of the app that the end user received, then the end user could verify if Google had tampered with your app. But if your signature is stripped, then the user is left with having to trust Google.
Your question is interesting, because it made me think of something else : I guess the context in which you asked your question was “would Google be able to modify the app before distribution”. With modern devices becoming increasingly powerful, what’s to stop the operating system (since a manufacturer can customise their version of android), from modifying the app after distribution, or in future, on the fly while it executes?
I’m leaving this paper here below:
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
The reason being it seems this will always be a perennial question, as it’s impossible for human beings to single handedly verify every piece of software in the kind of systems we use today.
I also find it a bit funny that people think that just because source code is available for an app, that it means they can trust the app which is actually running on their device - unless they’ve gone through the trouble of actually examining the app on their device, it technically is possible that the app running on their device is not the same as the source code describes - it could have been modified by both the developer themselves, or the store distributing the app for malicious or accidental reasons.
But trust has to begin somewhere 🤷♂️. In future, with Quantum Computing, maybe the way we do things will change. But again, there are so few of us who actually understand how every piece of a system works, we will still have to place our trust somewhere. Even if we understand something, having the resources to verify it is another matter as well...
so what stops Google from modifying it?
Do they really need to? It’s the developers which create value for Google Play by creating and submitting their apps.
Would you trust Google if they modified your app without your permission? How would it affect your perception of them as a company, since privacy is already a major issue.
In the event that a modification of theirs causes your app to behave incorrectly and cause damage to a customer, yourself or some third party entity, who will be held liable?
The above are just some of the reasons to think about when considering if Google will modify your app. It’s a can of worms. In the end, it boils down to cost-benefit & risk-reward analysis. What would they modify your app for, and is it worth any risk of repercussions?
In summation, there is no technical reason why they can’t. Why they don’t / won’t boils down to their business motivations and model. There is nothing to say why they will or won’t in future. But there is no reason to arbitrarily modify an app - there has to be a valid business reason which results in some kind of gain.
Simple answer: Google can, if they want to. In a digital signature scheme the signer has complete capability of modifying the document prior to signing.
Why they won't: Because developer can easily detect it, and the payload which is of most importance - the classes*.dex, actually containing the code - can easily be decompiled by interested third parties (or the app creator) to figure out any added code. (Adding code into JNI libraries is even less likely). To clarify, the detection by the developer is as easy as unzipping the APK and comparing its contents to what the developer submitted.
The impact of adding code to an app without notifying the developer would likely cause quite a backlash if discovered. Of course, at any further date Google could decide to change their terms of use, migrate from DEX to LLVM bitcode, or do something else, which might change this behavior.
Clarification: It is true, that Google could in theory ship modified apps only to certain targets, but once again it suffices that one such incident be detected (maybe by a concerned app-user mailing his or her APK to the developer?) for the implications to be far reaching for Google.
This, btw, holds true for Apple as well, being the signer of all App-Store apps. In the Apple case it's even more of a question, since apps may get recompiled by Apple (from BitCode to to the underlying ARMv8 variant), and apps deploy encrypted by FairPlay, which makes it virtually impossible to decrypt the app outside a jailbroken device.
As an anecdote, you could wonder if a malicious device vendor couldn't change dex2oat (the on-device compiler) to inject arbitrary code when the app is installed and compiled on the device itself. This would be much harder to detect, since on a non rooted device there would not be an easy way to access the compiled art/oat files of the app. But then, malicious vendors can also directly modify the Android frameworks, as well.
Apologies for potential anachronism here.
When you say
the App Signing service strips away whatever signature that we have
are you sure this is what it does? One could imagine an alternative scheme, which could achieve everything noted in other answers / comments as actually occurring:
Assume that the dev has uploaded their artefacts (let's say as an .obb) and signed it using their upload key. Google appends its additional metadata (think of it as a kind of diff file) and re-signs the resulting expanded payload. On receipt at the device, android checks that the payload it has received was correctly signed by Google (which it was), removes (but keeps) the metadata Google added, then checks the remaining payload (the dev's .obb) against the dev's signature. If that checks out, which it presumably will, it applies the change implicit in the added metadata to the original .obb
That .obb becomes the artifact which android installs. It isn't what the dev uploaded.
Google hasn't stripped the dev's upload signature, they've just added extra payload in a way which doesn't invalidate the original signature, then added some more payload and a signature of their own.
I'm not saying this is what they are doing, just that this is what they might be doing. You would be able to detect this once you had downloaded the payload and installed it on a device. Could it be made to happen or not according to which device the download was sent to? I expect that wouldn't be hard. And in that case, you wouldn't be able to detect it unless you had access to a device which had been targetted for the modification. It would be very difficult to detect the modification process while it was occurring. You could tell the difference between a modified payload and an unmodified payload immediately on receipt at the device because the presence or absence of the metadata "diff" would change the file size.
I don't know whether bundletool could support such a scheme. I guess that's where you could look for clues.
They may just be stripping the dev's upload signature and replacing it with their own. The only protection against signature stripping comes from checks done by the receiver.
When it comes down to it, you cannot trust any crypto scheme if you might consider the receiving endpoint to be compromised. Whether the payload is encrypted (which in this case it isn't) or merely signed, if the endpoint is not going to enforce the scheme, the sender and the user are both potentially exposed.
Technically, in this case, the crypto on the endpoint is in the control of the device manufacturer, although it is questionable whether they would actually exercise that control against the will or interests of the OS provider - Google - assuming that manufacturers even check these things.
I'm attempting to reverse engineer an android app called HeartTrace in order to pull sensor data at a higher frequency. I decompiled, adjusted the parameters, and recompiled the APK. However, the app no longer connects to Google Fit API. Does the API require a new signature from Google before recompiling? If not, what is the issue? Thanks!
As mentioned in Sign Your App,
Android requires that all APKs be digitally signed with a certificate before they can be installed.
Therefore, you need to digitally sign the app again using these two options:
use the same key which can be found in .keystore file if the app has already been published in apps store, or
generate a new key to be used in signing in
However, if you opt to use a new key, don't forget to check Signing Considerations.
I highly recommend going through the given documentation wherein these are being discussed in complete details:
describes how to sign your APKs, including creating and storing your certificate,
signing different build configurations using different certificates, and
configuring the build process to sign your APKs automatically.
And for additional information, this tutorial on Google Fit for Android: Reading Sensor Data and solution given in this SO post - Google maps does not work after resigning an apk which is related to decompiling an Android app might also help.
Looking to improved the security of my Android app to flag if the .apk has been extracted, modified, repacked and resigned. Here's article from Zdnet noting the issue link1.
The concern is if the app is targeted by hackers they could add malicious code and upload to an alternate app store and dupe users in to downloading it.
So I'm thinking code to verify a checksum of the apk or signing certificate?
I appreciate the app code could be repacked and any security code removed, but it does increase the difficulty of repacking it, maybe enough for them to try another app.
[update]I know the Google Play store licensing module offers something similar but I'm looking for something for non paid apps and other/non marketplaces.
I ended up using Dexguard (paid obfuscator for Android). It offers a module that preforms apk verification. It is simple to implement and offers better than average protection.
Here's the code to do the check:
dexguard.util.TamperDetection.checkApk(context)
The main issue is where to store the checksum of the apk to verify against given that it could to be replaced. The dexguard way is to check it locally but using other features like class/string encryption and api hiding obscure this call.
Here are some of the articles that could help you out.
Retrieving APK signature during runtime.
Self checking an APK signature.
How to check APK signature.
Use the Google licensing service It will connect with the play store to make sure the user purchased the app every few days. (you can set the amount) Also loook at ProGuard. It strips all the class, method, and variable names out of your code making it really hard to understand once its decompiled.
Amazon's documentation is surprising lacking in information about the submitting binary process. From what I can tell, you submit an unsigned binary and they wrap it in their own code and produce a signed apk?
This leaves several questions:
Does the Amazon App Store perform a zipalign for you?
If you have your app in the Android Market (Google's) already, is it recommended to use the same package name or a different one? Does it make any difference?
I also saw elsewhere, that they offer the option to download the apk they prepare and sign it with your own key. Is it recommended to take this and then sign it with the same key you are using in the Android Market? Does it make any difference?
Are there any other considerations or pitfalls that one should know before diving into this process?
Yes. Amazon wraps your binary with code specific to their appstore that allows them to collect analytics data and enforce DRM. The app will be repackaged after that.
You should use the same package name. The Amazon distribution agreement currently has a number of provisos; e.g., that your app is not priced lower on another app store. They also do occasional checks to see whether the version of your app on the market is up to date. These checks are primarily done using the package name; changing the package name of your app could easily be viewed by them as a means to evade the terms of the agreement.
No. There may be good reasons why one would want to do this, but none that I can think of. By default, Amazon signs your apk with a signature that is specific to your Amazon developer account.
Other:
Read this. In particular, ensure that the app links correctly to the Amazon app store and not the Android market, or others. I don't have inside data, but I'd wager a fair amount that the vast majority of submissions that Amazon turn down fall afoul of that requirement.
Edit: Point 2 is no longer correct; see comment below.
Here is the reply I received from the amazon mobile app distribution team for a question concerning whether to submit signed or unsigned apk's:
"You can submit signed, or unsigned binaries to the store - we will then apply our signature to your app in either case. If you need to sign your app with a known signature (if you are using Facebook authorization for example) you can choose to upload your app using our self signing process (you will need to ask us for this to be enabled for you)."
The most straight forward way to submit an app is to export your signed apk from Eclipse (all zip aligned are ready to go), then upload via the Distribution Portal using our DRM and signature.
For the latest update of my app I just took the same signed apk I previously released to google play, and it worked well.
I have only published two little applications that sell almost nothing, but both got aproved and I followed exactly the same procedure I follow for publishing on the Android Market: I just exported the signed .apk from eclipse and also used the same package name. So far I have no problems, so I guess it's ok.
You should zipalign during every build, as a matter of practice.
I use the same exact build process for Amazon as I do before publishing to Google. Only difference is an Interface's variable to determine the market link (at build time, if/else is compiled out).
I have an app on the Android Market, and recently I was made aware that another publisher had uploaded it under a different name, and was giving it away for free.
I've never uploaded an apk that wasn't signed correctly in the official Google manner. What I'd like to know is, is code signing intended to prevent this kind of thing happening?
Can someone remove the license and add their own? Is this easy to do?
They'd have to do more than just take your APK and upload it under their account. The namespace which you create is unique to your application. So, at a minimum they've reverse engineered some of your code.
As long as somebody is able to pull your apk off of their device and re-package it, nothing can really stop them from uploading it to the market on their own. Report it to Google and you may want to look into using the licensing service.
There is nothing preventing someone from doing this. All code signing does is ensure your application has not been modified from the version you published. i.e. a modified version cannot be installed on top of an unmodified version. If your app has simply been republished without modification, it is no different from your own version. Only the distribution source has changed.
You will need to implement some kind of licensing to prevent piracy. Android code signing is not like iOS code signing (where apps on the store as actually signed by Apple, not just you).