64

As we know, Android apps are written in Java. In Java, no matter what you do, it is impossible to protect compiled code from decompilation or reverse-engineering, as the Stack Overflow question How to lock compiled Java classes to prevent decompilation? suggests.

How would one go about protecting an app that contains algorithmic trade secrets from reverse-engineering?

By "how" I mean not only software techniques, but also other creative approaches.

Community
  • 1
  • 1
Android Eve
  • 14,864
  • 26
  • 71
  • 96
  • 4
    Android apps may be "written in Java" as source, but they are not *distributed* as Java bytecodes - they are distributed as DEX (Dalvik EXecutable) files. There are disassemblers for DEX files that produce "assembly-like" code, but as far as I know, there's no way to "de-compile" a DEX into Java source code. – Nate Dec 02 '10 at 16:10
  • 3
    Nate, this is a great comment and incredibly useful information. If this turns out to be a correct solution, post this as an answer, I will happily accept it as "the answer". In the meanwhile, I found the following thread which suggests that even DEX files can be decompiled into Java source code: http://stackoverflow.com/questions/1249973/decompiling-dex-into-java-sourcecode -- is this true? – Android Eve Dec 02 '10 at 17:00
  • Another relevant reference I stumbled upon: http://stackoverflow.com/questions/3122635/android-decompile-apk – Android Eve Apr 21 '11 at 12:39

10 Answers10

73

The first stop for me would be to optimise and obfuscate the code with ProGuard which is known to work with byte code targeted at Android's Dalvik VM (via Dex). It's a really great tool and can increase the difficulty of 'reversing' your code while shrinking your code's footprint (in some cases dramatically: a recent applet of mine went from about 600 KB down to about 50 KB).

Like others are saying, you will never get 100% security of your algorithm's details while its implementation is being distributed to clients. For that, you'd need to keep the code on your servers alone. Attempts to near 100% percent security for client code effectively amount to DRM and can make your client code fragile in the face of network outages and just generally frustrate (legitimate) users.

The Android developers blog has some useful articles on the matter of 'tamper resistant' Android apps (and they recommend the use of ProGuard as part of the overall approach).

With regards to 'creative' approaches: some developers employ debugger detection techniques to prevent run-time analysis and combine this with encryption of portions of binary code (to deter static analysis), but to be honest, a determined enough attacker can circumvent these, while it can cause legitimate user frustration as illustrated by the Windows KB article Games: Error Message: A Debugger Has Been Detected: Unload the Debugger and Try Again. My girlfriend's 'Learn to drive' DVD software will not run under VirtualBox for this reason, but she blames Linux of course!

OpenRCE and Wikipedia's article on obfuscated code may be good starting points if you want to look into this further. But be warned, you may lose more through over zealous use of these techniques frustrating your users than you would through loss of trade secrets by reverse engineering. Like Anton S says, maybe the most 'creative' approach lies with tweaking the business model rather than the technology.

The latest Android SDK update on 6th Dec 2010 (coinciding with Android 2.3 Gingerbread release):

Integrated ProGuard support: ProGuard is now packaged with the SDK Tools. Developers can now obfuscate their code as an integrated part of a release build.

Community
  • 1
  • 1
willjcroz
  • 2,106
  • 1
  • 25
  • 33
  • 1
    +1. This is the best answer I received so far. Thank you. Unless an even better answer is received, this will be the accepted answer. – Android Eve Dec 02 '10 at 17:41
14

If it's a possibility: remote procedure calls to a well-protected server (the server has the code you want to protect).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
jcomeau_ictx
  • 37,688
  • 6
  • 92
  • 107
  • My thoughts! +1! @Android Eve: You could use a secred authentication passphrase for connecting to your server. Even if somebody extracts this passphrase out of your code, nobody will be able to see how your calculations work. – jwueller Dec 02 '10 at 15:41
  • 1
    +1 for this idea. One huge drawback though: giving up the benefits of distributed processing. If the algorithm needs to serve hundreds of millions of people, then you need serious investment in a server farm. – Android Eve Dec 02 '10 at 15:42
  • I'd say forget the passphrase, because someone *will* extract it. as you said, it's a black box, people can see the results but not the code that produced them. thanks for the +1! – jcomeau_ictx Dec 02 '10 at 15:44
  • 1
    The passphrase is an additional layer of obfuscation. You do not need it, but it does not hurt either and makes it harder to use this service without using the app. – jwueller Dec 02 '10 at 15:47
  • @elusive: if that's your preference. it's hard to explain my philosophy in these little comment boxes so I won't try. – jcomeau_ictx Dec 02 '10 at 15:50
7

Make it so cheap to bother and don't build your business model on top of secrets that are executed on the client side. In other words, don't share your secrets.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Anton S
  • 12,750
  • 2
  • 35
  • 37
  • 6
    Anton, I didn't mean copy or piracy protection against users. The app would most likely be offered for free. I meant reverse-engineering by some corporations... – Android Eve Dec 02 '10 at 15:40
  • The same applies to Root Detection. You will be trying to control "the user that controls control", including the api calls that you rely on to know "Who has root access?". – Awi Jul 20 '18 at 13:50
5

It is impossible to protect any client side code from reverse engineering. You can just use more or less efficient ways of obfuscating your code. And optimized x86 assembler happens to be a pretty good obfuscation.

So if you have algorithmic secrets put them on the server-side.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • Optimized x86 assembler on an *Android* device? How? – Android Eve Dec 02 '10 at 15:44
  • 3
    That was just a general remark about x86 being harder to reverse than java bytecode, but still possible. And afaik it is possible to ship native code with your android programs(ARM I'd guess), but I'm not sure it's a good idea. – CodesInChaos Dec 02 '10 at 15:47
  • Are you referring to the NDK? I wouldn't mind using my mother tongue (C++) on the Android, but my understanding is that the NDK is limited for a very specific low-level system programming. – Android Eve Dec 02 '10 at 15:51
3

How to lock compiled Java Classes to prevent decompilation

You can't. Any scheme can be defeated by someone with sufficient skills, time and motivation.

(Incidentally, this also applies to software that is compiled to binary. The only difference is in the amount of effort involved in decompiling.)

My question is how one would go about protecting an app that contains algorithmic trade secrets from reverse-engineering?

Simply don't install the app on the user's phone. Or (more usefully), run the code that contains the trade secrets on a remote (properly secured) server.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
2

You can't protect your application completely, as there will always be someone who will crack it...

However you could hinder them doing this by making your application free, or at least dirt cheap so people won't be bothered.

Alternative, try to keep your Android application "dumb", as in keep all the secretive business logic on a backend server, and just have you app display data using some form of exposed service.

Jimmy
  • 16,123
  • 39
  • 133
  • 213
1

No matter what you do, maybe at least you can make it very hard to decompile, but: If something gets executed/calculated in a program, the information about the algorithm has to be there, and there will always be a possibility to find out how to get that (enough skill and motivation on you opponents side assumed). Always.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
oezi
  • 51,017
  • 10
  • 98
  • 115
0

You want a creative approach, here's one.

What is the main program on phones that haven't been decompiled today? Radio firmwares. Why? It doesn't run on the ARM chipset of the phone but instead on a separate Qualcomm Hexagon that is more and more present in smartphones. It's not x86, it's not ARM, it uses a Qualcomm proprietary architecture and instructions.

  • Java decompilation is easy.

  • ARM decompilation is more difficult (Hex-Rays Decompiler licences start at 1129 USD... and the mix between thumb code and standard ARM code in binaries is a pain) => you could try compiling with the Android NDK.

  • There is currently no Hexagon decompilers! And QDSP specifications are not publicly available, even pirated versions.

Question is, can an independant software vendor use the Hexagon firmware included in the mass-market phones? It seems to be the direction Qualcomm takes. Check out their website and the SnapDragon products.

NB: I'm not pro-Qualcomm nor pro-closed-source. But this thread appeals to this kind of solution.

KrisWebDev
  • 9,342
  • 4
  • 39
  • 59
  • 1
    You don't need decompilation for reverse engineering, disassembly is sufficient. And i found the hexagon disassembly to be quite readable. – Willem Hengeveld Sep 01 '14 at 07:36
0

You can't 100% secure you android code from reverse engineering. If you want to secure some key then you can take help from integrating server that give you encrypted key while calling web service and use that key into your code.

Muhammad Noman
  • 1,842
  • 19
  • 14
0

I have my algorithm on a server and I invoke that service from my smartphone app. A perpetrator can reverse engineer my smartphone app to see my protocol with my server. I can protect my algorithm but I can not protect against unauthorized use of my service. I have to accept this reality without a solution. I have to be content that as long as I am making money with my own service, then I have to live with the potential of others siphoning my service.

David
  • 36
  • 2