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.
Related
We are considering releasing an internal app onto the play store to make updating and management a bit easier.
We are happy with the security on the app but are concerned about someone unpacking our signed app and gaining access to the source code which contains some api links we don't want shared publicly.
Can this be done? Is there more we can do to prevent it?
Signing your apk is required to prevent not authorized person to upload new apk to store. It's not about protecting your sources mostly. If you want more protection - use proguard or other tools to obfuscate your code. Small tutorial on proguard can be found here, for example: https://medium.com/#jonfinerty/beginner-to-proguard-b3327ff3a831
Recently Google has introduced security metadata that is added to every app uploaded into Google Play. We used to have a tampering protection that's calculating the app's signature (hash) in runtime and check if it's equal to hash that was calculated during the release. This worked fine for years, but now the GP is modifying the app's binary by adding the security metadata.
Is there a way to disable GP security metadata at all?
Is there a way to check (download) modified APK from the store without publishing it? It seems that apps in beta channels are not modified so this solution doesn't work.
There is no way to disable the Google Play security metadata.
You can't get it without publishing an app
APKs in alpha and beta channels are modified (or should be) but only if they were uploaded after the start date of the program (2018-06-19 12:00 UTC). However, the APK will have different metadata when it is in Beta to when it is in production.
Hashing solutions will continue to work, but not ones which hash the whole file. Alternatives you could consider include hashing the zip entries, or hashing the classes.dex files. These methods work successfully for other developers.
Another option which works if you occasionally have online access (which I assume you do if you are checking a hash) is to use the SafetyNet attestation API to check your app, and verify the signature offline on the server. Again, many big name developers use this successfully.
Not directly answering your questions, sorry, but posting anyway in case that helps you or anyone else in the same case: instead of checking the hash, have you considered verifying the signature of the APK? Apksig is an open source library and would allow you to achieve a similar result in a more robust way.
There's a good report here of a recent scam perpetrated through the Android market.
http://www.theregister.co.uk/2011/12/12/android_market_malware/
Someone copied some popular game .apk files off a rooted phone, decompiled them with smali, added code to make them use an expensive premium SMS service, re-signed them with his own key, and put them back in the Android market. Over 10K users downloaded them in the 24 hours before Google booted the apps from the market.
How can app developers protect against their work being stolen, modified, and remarketed in this way? I suppose you could match the MD5 hash of your app as it was when you shipped it (perhaps kept with your app in the google market, or on one of your servers), with the MD5 hash of the app as it is now. But we don't have tools for checking the MD5 hash of an .apk file, and the underlying files are not visible to app software.
Ensuring identity integrity of an app you run, surely, is a solved problem. What is the best practice?
This kind of black hat practice are impossible to avoid. Whatever you find, a lucky, ingenious, patient hacker will undo it.
You can nevertheless hope to work hard enough to make it harder for most hackers to easily break your protections. That's what people often call IT security btw :)
Fields to investigate are :
obfscation
CRCs and MD5 as you mentionned it
secure networked verification
a second app to check the first
a custom checking class loader (can you do that on android ?)
Not the be-all-to-end-all but there is ProGuard:
The ProGuard tool shrinks, optimizes, and obfuscates your code by
removing unused code and renaming classes, fields, and methods with
semantically obscure names. The result is a smaller sized .apk file
that is more difficult to reverse engineer. Because ProGuard makes
your application harder to reverse engineer.
If you are willing to spend some money then go for some professional help such as Arxan. We have used this in our enterprise level app. Basically it recompiles the .apk with its own encryption and creates a new apk which will enable you to know whether tampering was done with apk and other such instances. You may refer to this url : https://www.arxan.com/ for more details and do your research accordingly.
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).