Develop Reference

Does ProGuard protect data in source code?

I am currently writing an Android library (AAR file) that will ship with a database (to be put in the asset/ folder of the app). The data in the database includes some sensitive data that I'd like to protect from the users of my library and database.
I've thought about encrypting the data and storing the decryption key in my library's source code. But of course this method is super unsafe, as anyone can decompile the source code and read the decryption key.
Then my colleague suggested doing the above and using ProGuard to obfuscate the source code, making it unintelligible for the decompiler to understand what and where the key is. Could this method work?

Proguard will obfuscate the code by giving random meaningless names to all method, classes and variables. Even of decompiled these are hard to understand without the mappings.txt file which will be only with you. Keep it safe for troubleshooting issues in production.
But the hard coded strings will still be seen when decompiled. You need to manipulate the string and store it as encrypted or something. Write a method to decrypt it before using.
Read more about proguard and it's advantages here.

No it will not protect your data (String literals, hard coded values etc). It will only obfuscate your code.
For storing cryptographic keys (in ur case your decryption key), KeyStore can be used.

Is ProGuard or JNI capable of protecting assets stored in Android apk file?

I've tried to package the apk with encrypted assets(image, text, etc.).
When it's run on Android the assets will be decrypted and then displayed (of course I hard-coded the decryption key in the source code).
I guess: as long as the source code is protected, then the decryption key will also be protected, which means the assets is finally protected?
Questions:
1. If ProGuard is used to obfuscate the apk, is the decryption key safe?
2. If I code the decryption key in JNI(C++) and let JNI do the decryption, is the decryption key safer?
I've also made 2 demo Android apps with encrypted assets that you can try hacking.
The first one uses obfuscated Java to decrypt the assets with AES key (hard-coded in Java):
https://drive.google.com/file/d/0B9O3ChlSQJL1dVZUZmFtWlRyMXc/edit?usp=sharing
The second one uses JNI to decrypt the assets with AES key (hard-coded in JNI):
https://drive.google.com/file/d/0B9O3ChlSQJL1UWU0VlprcXdVUjg/edit?usp=sharing
If you are able to get the original assets in the first demo, please let me know.
If you are able to get the original assets in the second demo, please also let me know.
Any suggestions about better solutions for assets protection are appreciated!

Without looking at your code, no amount of obfuscation is going to 100% hide an "in the clear" private key.

Protecting AES key in mobile App

I have read through a number of posts and resources regarding AES, CommonCryptor, salt and MAC in search of a solution to a problem I am facing with the release of my mobile software library. I would like to pass an encrypted string to my iPhone and Android App via HTML and JavaScript in a WebView using custom URL Scheme, with the string as a parameter. The HTML file will be created on my site and then distributed to users to store on their web servers.
From what I have read, I would encrypt the string in the HTML file using a key before distributing it to the user. Then the same key would be stored in the library and used to decrypt the string. But if someone decompiles my App they would then have the key and be able to decrypt the string stored in the distributed HTML file. I know that the library can be easily decompiled, but providing the string along with the code is really giving it away. And the real danger it that one could use the HTML files to trigger nefarious actions in a hacked version of my library.
I really don’t want to make a call to my site to get the key or salt and I am not sure that would offer any protection. Would a random salt stored along with the key in the library work?
I am willing to put in the time to research, code and test this, but first I would like to know if this is even feasible using AES, CommonCryptor, salt or MAC. If we solve it here, it will be available to all as the solution to this problem.
Thank You

Compile your own openssl and crypro static libraries and include those two static modules into your own native .so module. Don't use internal Android SSL.
Sore the key deep inside in some protected manner (simple solution is to use an array of floats with some non trivial hashing). Decipher the encrypted messages in the native code. Decide whenever the message is OK or not also inside the native code. Don't return to Java with plain boolean values.
Whenever a hacker wants to crack your code he has to decompile ~800K of native code.

How to make apk Secure. Protecting from Decompile

I am developing an application that has SQLite database to store personal information that must be protected. What are some ways of protecting these personal data? An APK can easily be de-compiled completely, so how can we secure an APK? Additionally, how can a database of a mobile application be protected?

Basically, there are 5 methods to protect your APK being cracking/ reversing/ repackaging:
1. Isolate Java Program
The easiest way is to make users unable to access to the Java Class program. This is the most fundamental way, and it has a variety of specific ways to achieve this. For example, developers can place the key Java Class on the server, clients acquire services by access relevant interfaces of the server rather than access to the Class file directly. So there is no way for hackers to decompile Class files. Currently, there are more and more standards and protocols services provided through interfaces, such as HTTP, Web Service, RPC, etc. But there are lots of applications are not suitable for this protection. For example, Java programs in stand-alone programs are unable to isolate.
2. Encrypt Class Files
To prevent Class files from being decompiled directly, many developers will encrypt some key Class files, such as registration number, serial number management and other related classes. Before using these encrypted classes, the program needs to decrypt these classes first, then loading these classes into JVM. These classes can be decrypted by hardware, or software.
Developers often loading cryptographic classes through a customed ClassLoader class (Applet does not support customed ClassLoader because of security). Customed ClassLoader will find cryptographic classes first, then decrypt them. And finally loading the decrypted classes to JVM. Customed ClassLoader is a very important class in this protect method. Because it itself is not encrypted, it may be the first target of a hacker. If the relevant decryption key and algorithm have been overcome, then the encrypted classes can easily be decrypted.
3. Convert to Native Codes
Convert program to native codes is also an effective way to prevent decompilation. Because native codes are often difficult to be decompiled. Developers can convert the entire application to native codes, or they can also convert only key modules. If just convert key part of the modules, it will need JNI technology to call when Java programs are using these modules. It abandoned Java's cross-platform feature when using this mothod to protect Java programs. For different platforms, we need to maintain different versions of the native codes, which will increase software support and maintenance workload. But for some key modules, sometimes this solution is often necessary. In order to guarantee these native codes will not be modified or replaced, developers often need to digitally sign these codes. Before using these native codes, developers often need to authenticate these local codes to ensure that these codes have not changed by hackers. If the signature check is passed, then developers can call relevant JNI methods.
4. Code Obfuscation
Code obfuscation is to re-organize and process Class file, making the treated codes accomplish the same function (semantics) with the untreated codes. But the obfuscated codes are difficult to be decompiled, i.e., the decompiled codes are very difficult to understand, therefore decompile staffs are hard to understand the really semantics. Theoretically, if hackers have enough time, obfuscated codes may still be cracked. Even some people are developing de-obfuscate tool. But from the actual situation, since the diversified development of obfuscation, the mature of obfuscation theory, obfuscated Java codes can well prevent decompilation.
5. Online Encryption
APK Protect was an online encryption website for APK, but activity has apparently been discontinued since 2013 or so. It provided Java codes and C++ codes protection to achieve anti-debugging and decompile effects.
I originally suggested you use this last method for it could save you more time. Based on my experience, it was very simple to operate and it wouldn't take long time.

With Jellybean this has now become a possibility.
$ openssl enc -aes-128-cbc -K 000102030405060708090A0B0C0D0E0F
-iv 000102030405060708090A0B0C0D0E0F -in my-app.apk -out my-app-enc.apk
$ adb install --algo 'AES/CBC/PKCS5Padding' --key 000102030405060708090A0B0C0D0E0F
--iv 000102030405060708090A0B0C0D0E0F my-app-enc.apk
pkg: /data/local/tmp/my-app-enc.apk
Success
Please read the following blog post for further details

If this is secret information that must not fall into the hands of your users, you cannot secure it. It is fundamentally impossible to put information on a device (code or data), and have your application access it, but not allow someone with the device to have access to that information.
Encrypting the information is pointless from a security point of view, because your application has to contain whatever is needed to decrypt it in order to use it, and a sufficiently motivated attacker can always extract that and decrypt it on their own.
All you can do is make it more annoying and time consuming to get access to that information, which only helps if there's not really that much of a need to keep it secret. This is what using proguard to obfuscate your .apk file can do.

Have you considered sqlite encryption? See this thread - sqlite encryption for android
As for protecting your .apk, try obfuscating your code using proguard. See http://developer.android.com/guide/developing/tools/proguard.html

You can try 'Anti Decompiler(Android)Trial'
https://play.google.com/store/apps/details?id=com.tth.AntilDecompilerTrial
It makes something Proguard doesn't:
Hide all const values (string, character), you will never see clear text like "my key", "my val"... in your apk file
Obfuscate file name, which is referenced in AndroidManifest.xml
Add fake code to your source code. Event the powerful decompilers likes: dex2jar, jd-gui,... can't reverse exactly your apk file. Most of functions will show with comment 'Error'.
=====
After transforming, if you give someone your source project, it will be nearly impossible to read and understand.
This solution doesn't exclude Proguard, You can combine them together. (function, field Obfuscation of Proguard is better than Obfuscation features of this solution)

You may read my post at: http://www.androidpit.com/en/android/forum/thread/567093/An-Analysis-of-Android-APK-Protect-Shell-APKProtect. The APK added with protect shell of APK Protect is seems unable decompile. I mean, the encrypt method is very advanced. Even a master hacker need long time to crack it.

If it is the database that contains sensitive data you can encrypt the values of several columns or the full database like mentioned in the other answer and make sure that the password is not stored on the device but has to be entered by the user on accessing the data.
If there are pieces of code you need to protect there's really no good way of securing it. All you can for a limited amount of use-cases is to create a dependency to an online service and secure the server. But for a lot of applications this would not be an option.

First, make apk that can never be modified and used. I do it by temper detection from the server. I use root check emulator check. Then on the important activity, it checks root and emulator on every oncreate and on resume, deletes important data on onpause, Great. Now encrypt data and place license to server, use SSL server. It app can not be modified and run, everything is safe for ever. Well, how to avoid decompiler and online tamper detection. I do placing a huge code to generate some sample string from apk file, and compare it with an apk copy placed on the server. I have converted apk file to string. Just enjoy.

encrypt data in SharedPreferences

Im currently developing a framework for oAuth 1 and 2 access to webservices and my question is, how do i store sensitive data like an oAuth access key in a secure way?
the problem with this keys is that some platforms like twitter use a permanent key and if someone would get access to this key he could do whatever he wants with the users twitter account..
so is it possible to automatically encrypt the data before it is stored in the shared preferences? Or is there a better way/place to store very important data?
UPDATE - ALSO READ: What is the most appropriate way to store user settings in Android application

You can also have a look at this class I made for doing exactly this: https://github.com/sveinungkb/encrypted-userprefs
It uses AES instead of the deprecated and weak DES used in the other suggestion.

1). How to encrypt?
On Android the encryption is done via Java Cryptography Architecture (JCA). Mainly it is the javax.crypto.* package.
JCA Reference Guide
Here is an example of JCA API usage (AES alrorithm in particular).
2). Where to store?
Encryption API manipulates with byte arrays (not strings). This means you can use SharedPreferences, but you'll need to apply Base-64 encoding on the encrypted byte array before putting it into SharedPreferences (otherwise XML parser will fail to read the shared preferences file). Then to read you will need to use Base-64 decoding. Note that by default most Android OS versions do not have a built in Base-64 API (see UPDATE section). So to remove this Base-64 overhead I would recommend just to store your bytes in a private file.
UPDATE: Since API Level 8, the API has android.util.Base64.

I would recommend using Facebook Conceal for encryption on Android almost every time - it's a fast Android library that makes some really sane decisions and leaves you with a few, simple interfaces for actually doing the work.
Bonus! I have recently pieced together the puzzle of how you can use it from Xamarin - see my article on securing your C# app's data using conceal for more information.

You should take a look at Slink.
I came to realize that most of the SharedPreferences encryption tools use encryption for each action you make, meaning that each key-value pair is saved only after both key and value been encrypted, separately. This creates a big performance overhead.
So I searched for a library that will give me a more efficient encryption process and I found Slink. Slink uses Facbook's Conceal library to save the entire map of objects as a whole, making it the most efficient and fast SharedPreferences encryption solution. It also uses common Android's SharedPreferences interfaces, which makes the usage extremely easy and almost seamless.
Disclaimer: I'm part of the development team developing this library.

See duplicate: Obfuscate/Encrypt SharedPreferences file possible?
Hi, I've created a SharedPreferences implementation using AES
encryiption. The project is a maven module. If you need one, take a
look. https://github.com/kovmarci86/android-secure-preferences

Try using our https://github.com/BottleRocketStudios/Android-Vault Vault component. It will use Android's Keystore (on supported devices) or an Obfuscation technique to encrypt values in a SharedPreference file and implements the SharedPreference interface, so it is largely a drop-in replacement.

new encryption introduce by facebook - conceal Encryption.. easy to use
https://github.com/afiqiqmal/ConcealSharedPreference-Android

This article on codeproject contains a nice wrapper for the shared prefs. However the class name SecurePreferences is misleading something like ObfuscatedPreferences would be more appropriate.

There is an Android Library that uses Facebook Conceal to encrypt data.
https://github.com/rtoshiro/SecureSharedPreferences
Maven Central:
compile 'com.github.rtoshiro.securesharedpreferences:securesharedpreferences:1.0.+'

You can encrypt the data in preferences and keep the encryption key in the Android Keystore system. This way your encryption key would also be safe.
You can look into a library doing this
https://github.com/ophio/secure-preferences