Is NDK an alternative to reduce reverse engineering?

Question

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

Answer 1

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".

Answer 2

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.