Background:
I have an obfuscated C code. Obfuscation can only protect the algorithm logic, but cannot hide the variable values from dynamic analysis. I want to further hide some values (e.g., a char array) from memory debug.
Platform: mobile client-side (not related to remote server)
Assume I have a secret char array:
char secret[15] = {"hide this value"};
Is it possible to hide this value in this way:
for every element i, secret[i] = x1[i] XOR x2[i]
Only define and store char x1[ ] and char x2[ ] in the memory
When need to use secret[ ] every time, call x1[ ] XOR x2[ ]. So secret[ ] cannot be found through memory debug (dynamic analysis)
Or any other ways?
If an adversary has the ability to freely examine the working memory of your program, such as via a debugger, then within the program there are no secrets from them. In particular, encrypting data in memory is not a reliable safeguard because you have to decrypt it to use it, at which point it can be easily be intercepted. But also, the decryption key must be somewhere in memory, where your adversary can find it, thereby obtaining the ability to decrypt your in-memory encrypted data at will.
Obfuscating your code is not a reliable safeguard, either. It may slow down your adversary, but with skill and / or good tools, they will sort out what's what in time. In fact, supposing that you strip debugging symbols from the executable and do not provide source code, the only obfuscation that even is visible is external function and variable names (so don't bother obfuscating anything else).
Protect sensitive data by not putting it in unprivileged hands in the first place. If you deliver data to an untrustworthy device or program, then you should consider it compromised.
Anything you're discussing right now is just ways to obfuscate your data. If somebody wanted to debug or disassemble, they would clearly see what was happening and could find the key. Even without disassembly, seeing two strings, someone could XOR each character just out of curiosity. Given that, an XOR is still a good option and it keeps your data pretty obscure when both strings are unprintable. To further this, it would be interesting if you used a certain hash of a file or string to generate the key to XOR.
Now, given that, there are many resources on string obfuscation in binaries and in C that you can research.
Rather than obfuscation on its own, hashing or encryption could be used. This really depends on what the string/key is used for. If you are willing to comment more details, I can help out more.
Here are a few great resources:
- Stack Exchange: Protect Data Stored in Binary
- Binary/String Obfuscation in C
I've been trying to decompile and extract useful data from an APK for some time now. This data is stored in CSV files inside an "assets" folder. Unfortunately, the developers got smart, and have begun encrypting these CSVs starting in July. I've exhausted every way I know of to try and turn these files into readable versions of themselves without any success. But then, I realized, there are a few files in the assets folder that haven't changed since well before July—thus, I have both the decrypted and encrypted versions of these files. Using this knowledge, is it possible to predict the encryption pattern that all other files in the directory went through?
I'm fairly sure that it was encrypted bit-level, not byte-level since there are a lot of unknown characters (represented as special question marks) while trying to read these CSVs using Notepad/TextEdit/Atom in UTF-8 mode (or any other mode except UTF-16, really).
You're talking about a "known plain text" attack. No modern, widely used
method is vulnerable to this kind of attack, but many home grown encryption
methods are. Even with known text, you need to know or guess a lot about
the details of the encryption algorithm.
A better plan might be to hack the software that you know is doing the
decrypting, which must contain both the algorithm and the key.
You'd have better luck simply guessing based on the encrypted output. You'll need to familiarize yourself with characteristics of the output of algorithms and compare against what you see. This is probably a lot easier for hashes but you're talking about encryption. To answer your question though, it's unlikely that you're going to be able to use an unencrypted version of a file to break the encrypted one. You might try encrypting that file using different algorithms and comparing the results. That might give you the algo but could take longer.
Alternatively, here are some tools I found that might be able to automate the process for you...
https://code.google.com/archive/p/aligot/
https://bitbucket.org/daniel_plohmann/simplifire.idascope
https://www.aldeid.com/wiki/IDA-Pro/plugins/FindCrypt2
To crack it, you're also going to need to find the key that was used to encrypt it. Since it's a program that obvious must be decrypted to use, that key shouldn't be impossible to find. It's either in the apk or on a server somewhere in which case use wireshark but I'm guessing it's embedded.
They might be usig DexGuard or ProGuard. Here's a related post What methods are being used to protect this Android APK: Reflection? Encryption? How do I reverse engineer it and analyze it?
If it's ProGuard you might start with something like this: http://proguard.sourceforge.net/manual/retrace/examples.html
Here's some info on that: How to decode ProGuard's obfuscated code precisely?
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.
I had stumbled upon this simple question of what is the best way for me to open a database or use a service which is secured, in the sense, will work only when correct password is provided.
I have looked at SharedPreferences as a way of retrieving information,but i need to create an app which will store the password in the first case, which by itself means i need to write it on code somewhere or the other
Account Manager is yet another way i've considered.
Store the actual password in an AES encrypted format, in a file, or in an sqlite db. But that means the key will have to be in the code.
I would've thought that this is a fairly common problem that people face and i'm wondering how people solved it!
In my opinion you can encrypt your data using AES encryption. But the main problem is the key is not safe. APK can be decompiled. So there is a method to hide the key. Implantation is bit difficult. Use native coding (NDK). You can write your key in a C file and after compilation you get a .SO file. This file can be included in your project. Make a call from java to a C function and return the key. But another problem is the strings written in C is visible when you open the .SO file. So assign generate ascii code of your key and make a string using the ascii code in C.
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.