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
Related
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.
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.
I am developing an android app and I am planning to publish it (paid app). I have heard that it is very easy to pirate Android apps (much easier than iphone). I was wondering from your experience or what you know, how can increase the security of my app? I know that I can never get it 100% secured but I want to make it harder for people to pirate it or distribute it illegally
Any ideas, experiences, comments you can share?
I released a free anti-malware app for Android, and making sure nobody hacked it was essential to its success. The biggest threats agains an app on the Android Market include leaked source code, copied/distributed paid apps, and re-keying. I explain each below and way to solve them.
Firstly, this paper describes how to reverse-engineer an Android application by unpacking the compiled code and viewing the source code. You will not be able to block this from happening to your app. Period. Someone with a will can always view your sourcecode if they get a copy of your apk (easily available on a rooted phone). The good news is that you can obfuscate the important pieces of your code making it harder to reverse engineer. Proguard is a tool provided by Android that lets you obfuscate (make harder to read) your code during packaging. In order to prevent your important code from being read, however, you will need to move all vulnerable methods or variables to a file that is not an Activity, Service, or BroadcastReceiver. For full facts, read the documentation.
To protect agains illegally copy and distribution of your application, Google Play provides some licensing options. Unfortunately, LVL is also not entirely secure. A detailed HOW-TO for how to crack it (pre-Google Play) is available here.
Lastly, the paper linked above, as well as numerous scholarly articles and online blogs describe how, once the source code (or even obfuscated source code) is leaked, once can merely add some of their own, malicious code, resign the app, and publish it on the Android Market. The good news here is that, unless your android license key password is easily guessable, or if you give it out to someone else, the attacker will not be able to publish an application with the same license key. This not only protects you from blame, but it will also make it so that malicious application cannot access data available through your original application (such as SharedPreferences).
All in all, the best way to really secure your application from piracy is to correctly configure and use Proguard, Google Play Licensure, and to sign you final apk with a very secure license key.
You could add tamper checks combined with obfuscation to alert user/disable functionality /report to server if the app has been pirated. I use DexGuard for hardened obfuscation.
Tamper checks
Installer app - Use package manager to ensure the installing app is the play/amazon app store
Emulator check - Check system properties for telltale signs the app is being run on emulator which outside of dev could indicate attack/tampering
Debuggable check - Use package manager to check the debuggable flag, this should be off in product so could indicate attack/tampering
Signing certificate check - Use package manager to verify the app is signed with your developer certificate (this would be broken if someone unpacked and repacked/resigned the app)
update: Since answering this question, I've written a more detailed article on tamper detection.
Have a look at the Google Play licensing framework.
http://developer.android.com/guide/market/licensing/index.html
This is your best choice.
Google Play Licensing is a network-based service that lets an
application query a trusted Google Play licensing server to determine
whether the application is licensed to the current device user. The
licensing service is based on the capability of the Google Play
licensing server to determine whether a given user is licensed to use
a given application. Google Play considers a user to be licensed if
the user is a recorded purchaser of the application.
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).