I'm wondering about the impact on the Android KeyChain if an attacker manages to root the device. Can anyone shed some light on this? Could you also make the distinction between hardware-backed (f.i. devices like the Nexus 4) and non-hardware backed credential storage?
How much of a role does the passcode strength play in such cases?
In addition, I would be most grateful for sources where I can verify this information.
Thank you.
Here:
https://source.android.com/devices/tech/security/index.html
I believe this guys have a better and more concrete response to your question.
But hey, if you want my 10 cents... Android is "secure enough". A rooted device only means a user can retrieve otherwise blocked content and files from its device and run processes with full control, but it does not means it can simply see KeyChain in clear text pair values.
Even if you do have the skills to retrieve the key and break its codification (that actually could take weeks, or months, or more time then one would spend), it is way to much trouble to root a bazzillion devices out there.
If your phone is rooted, then the hacker will manage to USE the keys in the hardware store
He will not manage to COPY them.
Since USING the keys is really what a hacker wants to do, it does mean that your security is absolutely compromised if the device is rooted.
Related
Long story:
My clients want to let a third-party company test my App.
Because I have never heard about this company before, I want to make my App not copyable/data-accessible, in case they try to copy my program or do strange stuff.
In few words, I give them a smartphone with the App already installed and usable, but that's it, they can't do anything more than test it normally like a casual user. Or a way to ask them a password if they try to access to sensible data.
Is there a way to do it?
Short story: I need to make my App not copyable and its data inaccessible from others.
I hope my explantion was exhaustive :)
Thank you all!
A determined hacker will defeat any sort of copy protection you put in place. But what you can do is put enough barriers in place to make their return on investment not worth the time and effort.
Without investing too heavy in security components or investing in a trusted security platform, here are some dirt simple things you can put do in a special one-off build of your app.
Tie this particular build of your app to something specific to the phone you are sharing with them. If the phone's serial number doesn't match, it doesn't work. See this on getting a serial number of an Android device.
If there are data files beyond the program's compiled code that you are trying to protect that is plaintext or not in a custom binary format, simply encrypt it. Decrypt at runtime. Perhaps the password/key is based on the serial number of the device or other nonce unique to the phone. That way, they can't copy data and program to another phone and have it work.
Put a timebomb in place. That is, after a specific date, the app just doesn't work.
On startup, your app accesses a website and downloads a URL. Based on the contents of the URL, the app shuts off.
All of these mechanisms can be defeated by someone that really wants to copy your app or get at your files. But it's sufficient to ward off the casual hacker and to buy time while your app is relevant.
Use licensing options provided by Play Store and Tools like Proguard can make it difficult
You can try StarForce Android Protection that prevents hacking and copying. They offer a month for free. It can be enough for testing. Or just ask for prolongation of trial period if you need.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'am writing some small security report about Android devices in general related to accessing information from RAM.
Main condition is that device initially is non-rooted.
Use case:
User opens 3rd-party app, enters some password in password field. After that the device is lost with this running application. Source code of this application shows that this password information available in RAM while application is up and running. For example in class AllMyAppPasswords in public String myPassword. Now is the question about possible way to access this password info (correct me if I am wrong):
The way to access this pwd is to dump the memory.
For memory dump I need to have device to be rooted.
In order to root the device I need to unlock bootloader.
To achieve unlock bootloader and root operations it is requires that device needs to be rebooted at least once.
After device is rebooted the information about password is gone from RAM
Conclusion: It is not possible to get password residing in RAM memory from app if device is non-rooted. Is it correct?
Update to use case:
We assume that user just un-boxed new device and 100% sure that it is not rooted and not contain any keylogger apps. So user just installed my app, entered password, and application uses this password internally during run-time for periodically connecting the server (password only RAM, never stored on disk). So, visually there is nothing left in Edit text fields, info about password only in application memory for internal use, of course it is not possible just to read password text from the screen. Now user lost his phone. Should user concern about someone who found his phone can get this password info from RAM?
While not being a hands-on insider in this area, I will claim that I'm certainly interested above average, and here are my thoughts. Not meaning to say you don't potentially already know this, though.
Yes, Linux protects process memory from other regular users (with root not being a regular user).
I don't see why in the scenario you describe, the person who finds the phone would not simply bring the app in question to the foreground and have all confidetial information displayed, because your scenario already assumes that whoever finds the device can successfully unlock it, and that the app is still running.
I am however suspecting (inspired by your hypothetical AllMyAppPasswords class) that you are intending to build an argument similar to the following: If my "password safe" app starts and identifies that the device is not rooted, a reboot is required to change this fact, and since on a non-rooted device there is no way to access my app's memory, holding decrypted confidential information in RAM is safe. If this is along the lines of your intended rationale, I'd like to point your attention to the following aspects.
It is relatively easy to reverse engineer your code from your APK even if you apply a byte code obfuscator. This is especially true if someone out there decides that confidential information held in your app's memory is important enough for them. This means that everyone can relatively easy figure what to look for, once they gain access.
There are security holes both in Linux and in Java Virtual Machines, and the update strategy of the Android device vendors is not exactly transparent in this respect. In other words, there may be a way, direct or by combination of bugs, to either execute code in root context or with the user ID of your app even if the phone is not rooted.
Ways to root phones may change once your app has been published, so you may not be able to reliably identify a rooted phone.
Any encrypted data and the key must solely exist on a trusted server, or otherwise people will simply extract the key from your app and access the encrypted data stored on the Android device (if any) instead of trying to access app RAM.
All bets are off if someone has an Android device which allows for an in-circuit debugger to be connected, which would then theoretically allow for direct memory access without any software being aware of this. I'm not sure about the exact prerequisites for such a scenario and I also don't know which precautions individual manufacturers take in this respect.
I have somewhat widened the scope of your original question, but maybe there's still something useful in it for you. Even when sticking to your question word by word, I believe the security hole point really hurts, besides the fact that I'm unaware of any reliable (fully doubt-free, now and in future) way to identify a rooted device.
Direct hardware access may be out of scope for the security level you aim at or not, but I seem to recall that I read something about this recently.
i've seen apps like Cerberus which can survive hard reset of phone. I want to add similar functionality in my app that has security features such as anti theft. So my question is: How to create a app that will survive hard reset to preserve some data that might be even used for further purposes, How can i prevent my app from hard reset of device?
I went through the .zip file from one of the app which is used to flash the app to the ROM but it didn't clear my doubts , can anyone clear the idea about how it can be done
Thanks in advance!
You can only do this if you have root permissions by moving the APK to /system/app. SuperSu, etc. offer this as an in-app feature. If you really want reliable 'security features' though, the app(s) should be part of the firmware, anything else is snake oil.
Why not store some data in a file on the SD card? You can simply retrieve this later and phone reset should not affect this. /sdcard is not wiped in a factory reset AFAIK.
See:
http://www.androidcentral.com/android-z-f-factory-reset
https://android.stackexchange.com/questions/33082/does-a-factory-reset-on-a-galaxy-nexus-wipe-the-virtual-sd-card-directory
I would like to know how it is possible to protect an Android application from illegal copies not going through the Android market.
I know I can protect the code against reverse-engineering using ProGuard.
I am wondering if there is a good solution to avoid anyone to copy the apk file to another device and install the app. Since I will have full control of all the devices where the application will be installed (it is a company internal app), would it be possible to link the app to the device serial number? In that case the app will run only on those devices which serial number is in a list of allowed ones.
I am not looking for hyper security, I just want to keep the casual pirate away. I understand a professional hacker would hack it anyway if he wanted to.
Any suggestion??
Many Thanks
You could use a whitelist of IMEI numbers and quit the application with an error if the number is not in the list.
It is possible to access the IMEI through TelephonyManager. You need the READ_PHONE_STATE permission for that.
Please also have a look at How to programmatically get the devices IMEI/ESN in Android
I was wondering what the most effective way of preventing people from stealing my application (downloading a copy of the .apk online rather than buying it).
I've spent a lot of time on one in particular (Droidbox) and won't be releasing Sync until I can guarantee that the people who are providing illegal copies of the pro version aren't able to.
Anyone implemented this? I've tried checking my package signature verses an the signature of an unsigned copy but it appears to be the same - perhaps I'm doing something incorrectly here. I'm unsure whether people actually distribute the signed .apk in which case I don't think signature validation would work to begin with...
Please note, this question is specific to Android Marketplace Applications - the difference being, application delivery is out of my hands and I have no way of linking between a legitimate purchase and an illegal download.
Now there is the new Google App Licensing available. For deeper information read about it in the android developer blog.
A short summary: Google provides a library that makes a inter process call to the market client on the phone. The market client will then ask the google servers if the signed in user has purchased the app and forward this answer to you. There should be a public key in you developer profile that you need to encrypt the connection to the google server to prevent spoofing of answers. You also provide a application and device unique id with the query to make it impossible to forward approved queries to another device and build something like an licensing proxy with one bought copy forwarding the IS LICENSED answers to other devices.
At the moment this service looks secure enough to protect even the more valuable apps in the market. I will give it a try and maybe come back and leave some more informations after I used it a little bit.
If your app is really popular like an EA game or something this wan't stop users from hacking it. To hack the app somebody has to buy it, then unzip the apk, and edit the bytecode of your app to think that the market send a correct answer. The new byte code can be packed into another apk and can be installed on every phone that allows side loading.
To make this harder you can always try to obfuscate your apk and make your bytecode hard to understand.
There is a single, useful connection between an application buyer and the developer through the marketplace, the forwarding email address provided by google to contact the buyer.
Utilizing the integration callback setting to send buy information to your own server, you can use PHP to send a unique identifier (registration code) to the buy via email (real time as the callback is shipped from google during a purchase. The user then uses this email to register their software using the unique identifier that is then linked to their android ID (or google account username) and the software is "activated" and guaranteed to be legitimate.
Obvious Questions
Why is this a suitable solution when it requires the user to read email? Our market are those people who are capable of buying an application using an android device. By using an android device, it is implied that the user has a google account which implies they know how to use email.
How do I use the email with the unique identifier with my application? Create a content handler in your application that handles something like "myactivator://uniqueid-or-something" which causes your application to communicate to your internal server that keeps tabs on activations. Embed this as a link in the email that the user can click on.
How should I generate the unique identifer? I'm going to use the email somehow - I'm fairly confident google has already made it unique enough to disallow any feasible method of contact information selling.
What about people who have already purchased the software? A lot of options here - none ideal or terrible.
Send emails to all previous buyers
Allow users to activate by typing in their order number (can be obtained by logging into checkout.google.com.
Why bother?
Because some of us put a lot of time into applications and saying "you should just accept pirating" is a slap in the face.
The people that are lax enough to use pirated copies of your application to access their DropBox are probably using their DropBox for piracy anyway. Forget those people. Let them go. Yes, it's a huge number of people I bet, but let's face it, those people were never going to pay you anything anyway. Focus on the parts that you can control, and forget the rest.
Focus on the Android users that use DropBox for their work, for their businesses, for their own code, for their finance, for their thesis, and/or for their private family pictures. 95% of those people, that have something of value in their DropBox, and that want it kept private, are going to want to buy your application (assuming it's good enough for them).
Let me use this analogy:
When it comes to hiring a locksmith to put a lock on your home, do you hire the guy that looks the part and takes $150 an hour, or do you hire the shady guy that is willing to sell you a stolen lock to put on your front door?
Release your own illegal copy in the best known forums and have it disable itself after a week and showing a message like
Thanks for stealing... I make my living with programming this app. The x Dollar won't hurt you and I could by my next meal and go on making great updates for you.
I think this is the only thing that you can do about it. People will always find a way to copy your app and all countermeasures will only disturb the users that paid for the app.
The people copying your app aren't your customers and they never will be. Just see their use of the program as a kind of viral marketing. At least they are talking about your app and maybe some of their friends will then buy the app.
General shareware advice here - license the software to the individual. i.e. provide a license key that is personalized to their username. They'll be much less likely to distribute a key if it's got their name on it. You can probably automate the backend fulfillment of the order, to provide custom keys. Have your "Pro" version operate in trial mode until the name/key are entered.
Don't leave your computers so that someone can steal your applications from there.
Or wait.. Did you meant you don't want others to copy your software? Then.. not publishing it in the first place is likely your best option.
A bit related link: http://news.cnet.com/8301-27076_3-20003120-248.html
You neither have any mechanism to estimate amount of illegally copied software. Enjoy your attempts from stopping the rain even though entities bigger than you have attempted and failed.
There is a new tool in the wild that seems to good to be true:
Automatic Application Licensing from Keyes Lab.
I haven't tried it yet but if this works it sound like something you want to use in your high priced android apps.
If anybody tested it leave a comment or edit my answer with personal feedback.
I have the same issue. I recently found a number of my paid apps available for free download on this site: https://dlandroid.com/
I asked them to remove my app APKs, but I'm sure there are many other similar sites. Presumably they have a rooted phone which gets one valid copy of the app from Google Play, then uploads it onto their web site to distribute to all and sundry for free.
You could spend endless amounts of time ensuring that there are no pirated copies of your apps on the web, or implementing complex piracy protection measures, which would most likely make things less convenient for your genuine paid users. But I guess in the end, you have to be prepared to make a trade-off and accept that a certain level of loss is inevitable, and hope that most people are honest and get your app through the proper channels rather than risk malware infection by going to dodgy sites like this.