4

Seems that one of my company's successful apps has been repackaged as a torjan and distributed on 3rd parties markets (outside of google play). I'm looking for a robust solution that will protect our apps from such issues in the future.

So far I've seen:

But neither seem to deliver a comprehensive solution.

Any ideas anyone?

Zvi
  • 237
  • 3
  • 8
  • 3
    By definition, what you want is impossible, on any OS. Anyone can take any app, reverse-engineer it, add in malware, and distribute the result. Obfuscation (e.g., ProGuard for Android apps) can slow things down, as can various other tricks (e.g., http://www.develop-online.net/blog/349/How-Android-developers-can-fight-piracy-bots-and-malware). But all they will do is slow things down, making it less likely somebody will fully scratch their itch to hack your app. Nothing can stop it outright. – CommonsWare Aug 18 '12 at 17:47
  • @CommonsWare - Of course that there is no solution that protects 100% of the cases. Problem is that today it's extremely easy to take an application, change some of the code and repackage it as a real app. On the PC you can find many off-the-shelf products that make the process much harder. I'm looking for a solution that will works well against 80% of the "crackers" attempting to modify my app. Something similar to [armadillo](http://www.woodmann.com/crackz/Packers.htm#armadillo) for android – Zvi Aug 18 '12 at 17:56
  • Any "comprehensive solution" is a magnet for those who can (and will) comprehensively break it. There were several cracks for various versions of Armadillo *on the very page that you linked to*. A search of the Internet shows various SoftwarePassport (the new name for Armadillo, apparently) cracks, and even free downloads of SoftwarePassport itself -- not exactly a testament to its defensive ability. This is one area that if you want it done right (or as right as it can get), you have to do it yourself, so that there is no existing off-the-shelf crack for your solution. – CommonsWare Aug 18 '12 at 18:41
  • @CommonsWare - I disagree. I don't know how well you know this space (packers, protectors and reversing), but breaking the latest versions of armadillo was extremely difficult. Usually you could find cracks for earlier versions, but finding one for the newest was not easy. On most cases, people were able to create a crack for an app manually, but removing the armadillo automatically was much harder. On the mobile space, were an app cost 0.99$ crackers might not find it that cost-effective. – Zvi Aug 18 '12 at 19:51
  • Building your own solution is costly if you want to create something that is hard to crack. If you are not willing to heavily invest, and/or if you don't have the team, you would probably create a very weak protector. – Zvi Aug 18 '12 at 19:52
  • Our business developed about 90 apps, all of those use quixxi. http://quixxi.com/ – Giuseppe May 04 '16 at 20:07

2 Answers2

1

I think you are looking at it from wrong perspective. Not sure about your exact case but normally the repackaged apps aren't "Reverse Engineered". i.e. the malware guy has little concern about the internals of your app. Trojan can be appended simply at the entry point of your application in which case the trojan would execute and then proceed to run your application. In such case obfuscation will not do anything except slow your application down.

sharjeel
  • 5,825
  • 7
  • 34
  • 49
  • I'm not looking for a good obfuscation. I'm looking for a protector - a software that modifies the original apps and adds a protection layer that prevents (up to a certain extent) modifications and repackaging. – Zvi Feb 18 '13 at 11:19
0

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 (http://www.apkprotect.com/) is an online encryption website for APK. It provides Java codes and C++ codes protection to achieve anti-debugging and decompile effects. The operation process is simple and easy.

I suggest you use this last method for it can save you more time. I've tried. It is very simple to operate and it won't take long time.

user2563366
  • 27
  • 1