Created
July 11, 2012 21:42
-
-
Save migueldeicaza/3093801 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| > in what way and how far someone can decompile our apps | |
| All software distributed can be decompiled. | |
| If you use C#, people can use C# decompilers. | |
| If you use Java, people can use Java compilers (in Android's case they can use a DEX decompiler, or a DEX to JVM and then a Java decompiler) | |
| If you use native code, they can use IDA Pro that turns native code into source code | |
| What you need to evaluate is what is your comfort level with how many people might want to get to the code. If you are guarding state-secrets, your best bet is to never ship the code in the first place. | |
| The general solution to prevent decompilation is to obfuscate the bytecode/IL. Android provides a `proguard` program which performs Dalvik obfuscation, and there are a number of commercial programs which will obfuscate .NET IL and produce output which will work with Mono for Android. At present Android's proguard tool cannot be used with Mono for Android, but the only types that proguard could operate on are Android Callable Wrappers, which don't contain much decompilable information: | |
| http://docs.xamarin.com/android/advanced_topics/architecture/android_callable_wrappers | |
| > Looking forward to your (reasssuring) reply ;-) | |
| Now we get to the meaningful interpretation. There is no reassuring reply; if someone wants it badly enough, they will get it. High-level languages, as provided by decompilers, are frequently not necessary; crackers will quite happily use disassemblers instead. There is very little protection against disassemblers. Just look at the past decade of Digital Rights Management (DRM) platforms, all of which are either unused or have cracks available. (For example, there are iTunes Fair Play crackers, Kindle eBook crackers, etc.) Software is slightly different, but only slightly: both software copy protection and DRM involve giving your customers both the key and the product, then hiding the key in an effort to keep it away from the customer. | |
| To prevent cracking, you either don't give the customer the key and the data (e.g. use lots of server-side processing and reduce your client capabilities as much as possible), or you "fly under the radar" and have an app that no one cares enough about to crack. (Server-side processing won't necessarily help either, it just moves the problem to protecting your servers, which can also be problematic; see the recent LinkedIn debacle in which they lost their password database.) | |
| Native apps can be disassembled with a variety of programs, and crackers regularly crack native software (e.g. games) without access to source code. Decompilation isn't necessary. | |
| Java apps can be disassembled into Java bytecode (see `javap -c`), and a great deal of information can be obtained just from viewing bytecode. | |
| Dalvik bytecode is no different: the Android SDK `dexdump -d` tool can be used to disassemble Dalvik bytecode. | |
| Mono fairs little better: assemblies are stored within the .apk, which is just a ZIP container. Anyone with access to the .apk can extract the contents, and disassemble the assemblies into IL using the .NET ildasm or Mono monodis tools. | |
| In summary, there is no silver bullet. The only 100% foolproof way to prevent cracking is to have no software. After that, you need to ask whether it's worth protecting the software (it might not), and if it is worth protecting, you need to determine how much you're willing to pay for that protection, monetarily and developmentally. Possible protections include obfuscation, server-side components/validation, encrypting and decrypting blobs and running them in memory, public key crypto cryptography... | |
| - Jon |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment