Develop Reference

Drag & Drop app builder licensing. How do I make sure the source code won't be decompiled and re-used?

I'm working on a drag and drop app builder. The concept is simple: users can build their apps visually, then the app's settings get turned into a configuration file which will be used by the app to decide how to construct itself (which views should be shown, how should the navigation look like, etc.)
My main concern is once the users download the apk (or ipa) file, they can decompile it, change things in the configuration file and re-compile/re-sign it to be published as a brand new app.
I was thinking about putting part of the logic on server side but that would introduce me the following problems:
If 1000 people built and published an app with my software, and each app sends only 10,000 daily requests to my server, that's already 10,000,000 requests per day, which would be pretty expensive.
If my server is down for any reason, I will have a lot of angry users coming at me.
Got any ideas?

There is no exact way of stopping decompilation/reverse engineering process of android app or apk !
But there Some chances to reduce the scope of code visiblity after decompilation/reverse engineering process !
Here are some habits I am sharing
1) Put important code on a Server : You may rely on remote procedure calls to a well protected server. This reduces the chance of your codes being stolen as the code will always remain on the server and nothing other than the results can be seen.
2) Debugger Detection Techniques : Insted of using the hard coated values or string use some formula or encryption methods which can help to hide the actual values
3) Write important parts of code in C/C++ :You can also write the important parts of your code in C/C++ and add them as a compiled library. While it can be disassembled into assembly code, reverse engineering a large library from assembly is extremely time-consuming. Java is easier to decompile in comparison to C/C++.
These are some key habits which are be taken care by good developer , You should also check out this answer as well !

Huh, I knew it wasn't possible to stop the decompilation/reverse engineering process on any android app. But, I thought maybe everything was possible! Like, perhaps something has changed since then, but no. Basically, I use the same steps as Nisarg Jani described. But, you have to pay some special attention to the C++ code. Any mistake will destroy everything that you have built to that moment. So, if you use a no-code desktop app builder, you should be aware of those "tips and tricks." Besides that, you should keep in mind that without the C++ code, you won't be able to do anything.

secure native methods and api-key in android using ndk

i am using ndk and android studio to secure my api-key and it works now.
also i am trying dirty code to harden disassembling... .
but i can still decompile and see native methods in java classes.
also pre-built .so(shared object) files are available in apk and wil be used again!
Questions:
After releasing the apk, all hackers can see .so file and they can use custom settings in .mk file and program specific native methods like my class for extracting the api-key only. they call my functions related to api-key without knowing the implementation. am i eliminating something here?
is proguard necessary for this way ?

That's right, there is no way to prevent .so reuse by malicious agent. Therefore, your native API should never reveal secret information to the Java side. You can perform some validation in your native methods to check if the calling Java actually belongs to the legitimate APK.
On the other hand, don't underestimate another vulnerability of native code: your .so can be disassembled with relevant tools, and any protection may be torn off. There exist means of obfuscation and resilience to reverse engineering for native code, but the earning curve for them is much steeper than with ProGuard.
Still, it's worthwhile to at least not keep the api-key in plain text in your C++ code. Try yourself to run
strings libnative.so
(here libnative.so is the .so file extracted from your APK) and you may discover important information that is waiting to be stolen from your library, no sophisticated reverse engineering necessary.
As far as ProGuard is concerned, it does not add protection to the native methods you use. You cannot even obfuscate the class name and method name for a native method. (Well, it is possible, but very tricky, and there are no tools that can help with such setup).

You increase the time hackers will need to decompile and understand the .so file. Estimate how hard it is, and change the way your api authentification works from time to time. Doing so makes previous hacking attempt obsolete, even if they have been successful.
To clarify : put the api-key and the authentification process in the native methods. For instance, for an HTTPS api, send the uri, json content, usertoken, to a native method. Then in the native code, use these and the api-key and some hash functions to create a hash. And output that hash to the Java code to be send in the HTTP request. By doing so, it will be hard to guess the authentification recipe by simply monitoring entries and output. Attackers will have to decompile the native code.
Activate Proguard, compile, decompile, and see for yourself. On my opinion it does raise a good level of complexity for a very easy set up.

We have created a gradle plugin to hide keys in the Android NDK, you can check all the implementation on github : https://github.com/klaxit/hidden-secrets-gradle-plugin
The goal is to make it as hard as possible to reverse engineer keys. We encourage to add a custom encrypt algorithm then keys are stored in the NDK as hexadecimal arrays.
We would love to have feedbacks on our solution !

Is NDK an alternative to reduce reverse engineering?

I have given up trying to get Proguard to work on either Eclipse or Android Studio. The docs are arcane and whatever I try, the Proguard obfuscated apk blows. Also questions regarding Proguard don't get much attention on this forum.
Standard Android apk files are designed to almost invite reverse engineering and I'm looking for some ways to protect my code. Not all my code just some methods.
Before I started writing Android apps, I wrote apps in C and in C# and I'm familiar with both of those languages and actually prefer either of them to Java so I've recently been reading about the NDK.
Of course the NDK is about speed but I'm wondering if it also would help protect my code against reverse engineering and inspection from hackers. I understand that it is "compiled" code so I imagine that the source code would not be visible.
Am I barking up the right tree?
Thanks,
Dean

This depends on what kind of protection you are looking for. If that is a revolutionary algorithm that will allow you do some very popular task much much faster than it takes today, then your code will be reverse engineered, no matter how you obfuscate it; you need patent protection. If you want to hide some unfriendly behavior (like spying on your users), it will be discovered. So don't do it. If you want to protect some protocol of client-server communication, it may be subject to easy attack elsewhere.
But in some cases going C++ does really help; it may be easier to distribute a monolithic shared library "black box" than to deal with Java API. I don't think obfuscation can work on code that you sell as library.
When we were selling a huge communication SDK, we followed this approach, and all our Java code was simply open to customers (part was intended to be changed/customized, but some classes carried a warning in the header "Please don't modify this class, there is very high chance that the product will not work properly if you mess with it".

Native C code is harder to decompile but it can be decompiled easily using the right tools.
Especially if you only develop small parts in C and then communicate with it using JNI which is a clear interface, anybody who decompiles your app can also use it. Who needs to know how your code works if you can simply execute it?
Conclusion: native code can be harder to decompile. But usually the only difference is that you need different tools and you need more knowledge & practice to decompile. Also modifying something is usually more complex.

Just implementing some methods in NDK alone will not likely help a lot. However, the resistance to reverse engineering can be improved if you also apply obfuscation and even run-time protection techniques to your NDK code. A simply web search gives a list of free tools. You could also work with commercial solution providers like Arxan. In addition, the level of obfuscation can generally be improved if you put more logic of your app in native code.

Yes if you use the NDK you can make it very difficult to reverse engineer your code and it is unlikely anybody would try.

Saving constant values securely

I am working on a Android application related to secure data communication. I am using a few constant values in my application, and am saving them in constant.java class. I don't want these values to be reverse engineered, but even though I am using ProGuard for Android, for experts it's easy to reverse the code. These constants are very secure. I can use properties file or any file in res folder but this approach is not at all secure.
Can anybody can tell me how to proceed? Is there any file format I can save my constants or prevent properties file from reverse engineered. Is there any option such as saving it in .py python file format and reading it from Android code?

It is fundamentally impossible to securely store secret constants on a device, since hackers can reverse engineer them through static and dynamic analysis. You can only make it a bit more difficult, by obfuscating the values:
Compute them with some algorithm, instead of storing them literally. Even a trivial algorithm may increase the time needed to extract the constants.
Distribute the components of the values throughout the code.
Use native code. It is generally more difficult to reverse engineer, at least if the code and its API are sufficiently large and complex.
Maybe look into whitebox cryptography, which tries to weave constant keys into the implementations of cryptographic algorithms, in such a way that the constant keys can't be extracted. This is still the realm of research and high-end commercial solutions.
You might get some ideas that you can apply yourself from my presentation and from Scott Alexander-Bown's presentation at Droidcon in London.
You can also use a commercial obfuscator like the extended version of ProGuard, DexGuard, to harden code for you, with techniques like string encryption and class encryption.
How effective the protection is depends on the time and effort that you can invest, on the value of your product, on the time and effort that hackers are willing to spend, on their expertise, etc.
Similar question: Best Practice for storing private API keys in Android
(I am the developer of ProGuard and DexGuard)

The answer is Dont do it!. Secret constants are never secret. You should always assume your opponent is smart enough to reconstruct what you've hidden behind your smokescreen.
And anyway, you don't need to do it. For secure communications, instead use a public key infrastructure. Heres roughly how this works.
Your server generates a private and public key, and then you include the public key with your apps installation. It doesn't matter if the attacker finds this. All it allows is for your app to securely send a message to the server, and ONLY the server can decrypt it because only they have the private key.
So first thing your app should do is generate private and public key. Use whatever secure storage locker your OS provides to keep the private key safe. Its not invulnerable, but it's a damn lot more secure than anything you'll come up with. And then send the public key to your server.
Now you can securely send messages to the server using the servers public key, and the server can securely send messages to you using your public key.
Don't try reinventing the wheel here. Security researchers with serious qualifications in hard math and comp sci spend lifetimes coming up with these systems, and if you blow your implentation you leave it open for hackers to break in and steal your stuff. Use a widely trusted off the shelf PKI encryption library like OpenSSL and keep abreast of whatever source of security alerts covers that library.

Android apps reverse engineering

Is there any way to protect an Android applications source code from reverse engineering, as explain in this post: http://blog.darrylsite.com/?p=23 ?

Hm, you are linking to an article in French...
Anyway, using ProGuard should make reverse engineering more difficult, although it can't prevent it completely: Dalvik bytecode contains sufficient clues about an application's structure. Obfuscation (as performed by ProGuard) makes this harder to understand, but given sufficient effort, one will still be able to figure out what is going on.

Your two tools will be code obfuscation and server side-processing.
For the first, obfuscating, the Android team encourages the use of Proguard..
The second is to do your sensitive processing on a server and set up good licensing model. This makes it so the user doesn't have access to even your compiled code. They only get the results of the code and in order to run it you can use licensing to verify they are a valid user. For more information about licensing on Android see Licensing.

Did you take a look at ProGuard?