I have created an Android library and I would like to protect the library code from reverse engineering. To my understanding, I could either use obfuscation (i.e use proguard) or create an Android Library without the source code. Also I have read some posts that recommend to use both approaches. What is the best approach to use and potential limitations? Is there any other solution you recommend?
Thanks,
Lupe
You should use both, but I guess it won't be enough. Managed languages are very easy to decompile. Android code seems to be even easier to reverse enginner, because of use of built-in libraries. You cannot obfuscate system libraries, so with calls to system libraries your code becomes more and more obvious.
For me you have two ways of dealing with the problem:
rewrite your library in C. Compiled languages are much safer.
rely on the law. Nobody can use your library or its parts when it's officially protected by law as your intellectual property.
Related
I would like to build a library that is used for applications. The library is not free. I intend to code it by using C++, and compile into binary files which my clients can import to their Android applications (written by Java/Kotlin).
This is just my roughly idea, I haven't done any similar thing previously.
Could someone who used to do same thing before guide me the best practice for this kind of library?
At the end of the day, if you give someone binaries, they will be able to reverse engineer it to some extent no matter what you do. With that said, there are a few things you can do to make reverse engineering really hard.
First, you'll only want to provide C++ headers for your user (that don't expose implementation details). Then, you'll distribute the actual .dll or .so compiled binary, of which they can only access the assembly code. A great example of this strategy I've seen is Porcupine, who only distributes headers.
You can look into code obfuscation, but this probably isn't worth it for C++. If you have Java parts to the library though, this could help.
Set a restrictive license on your library, most well-intended developers would rather find an alternative library upon seeing your non-open source license rather than wasting time stealing it and reverse engineering it. Porcupine also has a licensing system (and the library will expire without a valid license). So you could look into that as well.
Does your library have to be local? Can some parts be hidden behind an API that your users could call instead?
Only distribute your library to paying customers (do not provide headers, binaries, or anything to non-subscribers).
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.
I've been working on a writing a game for Android. Until now I've been using Java instead of the NDK, but I've decided to port my code to C++ (for performance, memory management and industry standards reasons).
Porting my application shouldn't be a problem (I've written my fair share of C++ applications), but I've been using RoboGuice as a dependency injection framework because otherwise my object graph would become too complex rather quickly.
I've been looking around, but I haven't found any resources about using a dependency injection framework in combination with the Android NDK.
Can someone tell me if there any such franeworks available. If so, which one would you recommend?
If you have a C++11 compiler for Android you could use several frameworks (I wrote Infectorpp) but there are others available. You should note that DI is quite limited in C++ due to the lack of reflection so you should make some compromises as not everything you did in RoboGuice would still be possible.
By doing a quick search seems that C++11 is possible on Android. I don't have an Android device and still not needed to emulate it, but if you have any feedback it will be wellcome (private message here or support ticket on google code is enough), the library is headers only so no special build stuff is required for it, apart enabling c++11 on your compiler wich is just one extra option by command line. If that will works good on Android then it will be definitely good also for PC. (Do not misunderstand please, I'm using it heavily, but seems very few people is interested in DI in C++ and so I get very little feedback)
There was also a nice framework cpp-resolver: a little awkard to use because you explicitly register factory functions for injecting ALL parameters, but very scalable, especially for server applications.. (decouple object lifetime management and works with plain old C++).
The most complete framework is probably wallaroo
If you search something really easy to use Infectorpp is a good choice
If you need control over lifetime (mostly servers): Cpp-resolver is perfect
If you need exotic features and configuration files: wallaroo
As side note, run-time configuration is possible also with frameworks that do not explicitly support it:
You just need a Factory that istantiate a different type based on a configuration file you could read through a class that you add as dependency to factories (Probably you don't need to know that since you were already using DI frameworks, but still good to know for occasional readers)
I have an Android project, and I want to protect the APK file because I found it very easy to decompile. With a little research, I found ProGuard, but I don't know how to use it to protect my app.
how about trying ProGuard yourself? a really good explanation could be found over here: http://proguard.sourceforge.net/index.html#manual/index.html
I use quixxi, it is much simpler and more efficient than Proguard.
You can also try whitecryption, have no experience with it though.
Technically you don't protect the file against decompilation but you simply make it harder to understand your decompiled code/logic
the first tool you can use to immediately increase the difficulty in reading the decompiled code is ProGuard, which you can activate directly in Android Studio
ProGuard provides obfuscation for free and is super nice but not necessarily enough to guarantee the right level of security. Check this link to understand the practical difference in the code readability of the sample code [original code, code after proguard only and code after professional tool]
some other good tips are described here. In particular if the level of security required is very tight [fintech, healthcare, etc.] I strongly suggest you to consider paid solutions like DexGuard, Quixxi, Arxan just to say a few. The advantage with them is that they can automate most of the best practices, leaving you only with the duty to take care about functionalities [i.e. without thinking about security practices]. Which means faster and safer delivery
As far as I understand it is necessary for people using Scala for Android applications to bundle the Scala classes they used with their application.
Considering this adds hundreds of kilobytes to each Scala app redundantly, would it be possible to build a Scala library which can be delivered over the market, so app writers can just depend on that library instead of bundling it themselves?
You'd probably be better off using something like Proguard. See here for someone's instructions on how to do this.
Third party shared libraries are not currently supported. They can introduce a lot of issues that then end up being visible to the user (see: DLL hell), so in many cases the disadvantages of a traditional shared library model may out-weight the benefits.
If you need well-grounded maven project for Android with Scala, android-scala-test would help you. It provides all of the complex setup out-of-the-box, including Scala compiler, Proguard, Signing, etc.
Further, android-scala-common will guide you to write more concise Android program in Scala.