How to avoid reverse engineering of an APK file?

Question

I am developing a payment processing app for Android, and I want to prevent a hacker from accessing any resources, assets or source code from the APK file.

If someone changes the .apk extension to .zip then they can unzip it and easily access all the app's resources and assets, and using dex2jar and a Java decompiler, they can also access the source code. It's very easy to reverse engineer an Android APK file - for more details see Stack Overflow question Reverse engineering from an APK file to a project.

I have used the Proguard tool provided with the Android SDK. When I reverse engineer an APK file generated using a signed keystore and Proguard, I get obfuscated code.

However, the names of Android components remain unchanged and some code, like key-values used in the app, remains unchanged. As per Proguard documentation the tool can't obfuscate components mentioned in the Manifest file.

Now my questions are:

1. How can I completely prevent reverse engineering of an Android APK? Is this possible?
2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?
3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

Answer 1

The main question here is that can the dex files be decompiled and the answer is they can be "sort of". There are disassemblers like dedexer and smali.

ProGuard, properly configured, will obfuscate your code. DexGuard which is a commercial extended version of ProGuard, may help a bit more. However, your code can still be converted into smali and developers with reverse-engineering experience will be able to figure out what you are doing from the smali.

Maybe choose a good license and enforce it by the law in best possible way.

Answer 2

There is no way to completely avoid reverse engineering of an APK. To protect application assets, resources, you can use encryption.

• Encryption will make harder to use it without decryption.choosing some strong encryption algorithm will make cracking harder.
• Adding some spoof code into your main logic to make more harder for cracking.
• If you can write your critical logic in any native language and that surely make harder for decompile.
• Using any third party security frameworks like Quixxi

Answer 3

 1. How can I completely avoid reverse engineering of an Android APK? Is this possible?

This isn't possible

 2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

When somebody change a .apk extension to .zip, then after unzipping, someone can easily get all resources (except Manifest.xml), but with APKtool one can get the real content of the manifest file too. Again, a no.

 3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

Again, no, but you can prevent upto some level, that is,

• Download a resource from the Web and do some encryption process
• Use a pre-compiled native library (C, C++, JNI, NDK)
• Always perform some hashing (MD5/SHA keys or any other logic)

Even with Smali, people can play with your code. All in all, it's not POSSIBLE.

Answer 4

 1. How can I completely avoid reverse engineering of an Android APK? Is this possible?

That is impossible

 2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

Developers can take steps such as using tools like ProGuard to obfuscate their code, but up until now, it has been quite difficult to completely prevent someone from decompiling an app.

It's a really great tool and can increase the difficulty of 'reversing' your code whilst shrinking your code's footprint.

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.

 3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

While researching, I came to know about HoseDex2Jar. This tool will protect your code from decompiling, but it seems not to be possible to protect your code completely.

Some of helpful links, you can refer to them.

• Proguard, Android, and the Licensing Server
• Securing Android LVL Applications
• Stack Overflow question Is it really impossible to protect Android apps from reverse engineering?
• Stack Overflow question How to prevent reverse engineering of an Android APK file to secure code?

Answer 5

Agreed with @Muhammad Saqib here: https://stackoverflow.com/a/46183706/2496464

And @Mumair give a good starting steps: https://stackoverflow.com/a/35411378/474330

It is always safe to assume that everything you distribute to your user's device, belong to the user. Plain and simple. You may be able to use the latest tools and procedure to encrypt your intellectual properties but there is no way to prevent a determined person from 'studying' your system. And even if the current technology may make it difficult for them to gain unwanted access, there might be some easy way tomorrow, or even just the next hour!

Thus, here comes the equation:

When it comes to money, we always assume that client is untrusted.

Even in as simple as an in-game economy. (Especially in games! There are more 'sophisticated' users there and loopholes spread in seconds!)

How do we stay safe?

Most, if not all, of our key processing systems (and database of course) located on the server side. And between the client and server, lies encrypted communications, validations, etc. That is the idea of thin client.

Answer 6

when they have the app on their phone, they have full access to memory of it. so if u want to prevent it from being hacked, you could try to make it so that u cant just get the static memory address directly by using a debugger. they could do a stack buffer overflow if they have somewhere to write and they have a limit. so try to make it so when they write something, if u have to have a limit, if they send in more chars than limit, if (input > limit) then ignore, so they cant put assembly code there.