Is It Really Impossible to Protect Android Apps from Reverse Engineering

Is it really impossible to protect Android apps from reverse engineering?

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.

How to avoid reverse engineering of an APK file

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

AFAIK, there is not any trick for complete avoidance of reverse engineering.

And also very well said by @inazaruk: Whatever you do to your code, a potential attacker is able to change it in any way she or he finds it feasible. You basically can't protect your application from being modified. And any protection you put in there can be disabled/removed.

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?

You can do different tricks to make hacking harder though. For example, use obfuscation (if it's Java code). This usually slows down reverse engineering significantly.

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?

As everyone says, and as you probably know, there's no 100% security. But the place to start for Android, that Google has built in, is ProGuard. If you have the option of including shared libraries, you can include the needed code in C++ to verify file sizes, integration,
etc. If you need to add an external native library to your APK's library folder on every build,
then you can use it by the below suggestion.

Put the library in the native library path which defaults to "libs" in
your project folder. If you built the native code for the 'armeabi' target then put it
under libs/armeabi. If it was built with armeabi-v7a then put it under
libs/armeabi-v7a.

<project>/libs/armeabi/libstuff.so

Somebody is reverse engineering my app. Should I afraid of stealing? Is it legal?

Yes, you should definitely kick off the process. If this is uploaded to the Play Store, it's an unlawful event as they will be stealing your IAP's.

If you can prove that they are using your code, it's a copyright violation and you should visit the guide at https://support.google.com/legal/answer/3110420 and follow the steps to report this right away.

How to protect Flutter app from reverse engineering

I am trying to develop a payment application using Flutter, is there any way to protect my application API's and Tokens or make app reverse engineering proof.

If you are looking for bulletproof solutions in the sense they are 100% effective in preventing reverse engineering a mobile app binary to extract tokens or secrets from it then I have to tell you that unfortunately, this is not possible to achieve, but you can make it harder... How hard it will depend on the effort and resources you are willing to put in or required by law for your use case.

In the other hand protecting mobile API's from being accessed from others then a genuine instance of your mobile app it is possible to achieve with a very high degree of confidence.

How easy can it be to extract an API key from a Mobile APP?

Reverse engineering a mobile app binary to extract an API token from it is very easy with the plethora of Open-Source tools out there, as I demo in my article How to Extract an API key from a Mobile App with Static Binary Analysis:

The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.

Alternatively, a Man in the Middle(MitM) attack can be used to extract the same API key, and for this, we also have Open-Source tools, like mitmproxy that I demo in my article Steal that Api Key with a Man in the Middle Attack:

In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.

Defending against Reverse Engineering

Reverse engineering is a huge topic and you can learn more about the techniques used in reverse engineering by reading the markdown file 0x04c-Tampering-and-Reverse-Engineering.md in the Github repo for the OWASP Mobile Security Testing Guide(MSTG).

You cannot make the mobile app 100% reverse engineering proof, but you can have a lot of hardening code techniques to make it more difficult and/or use some runtime self-protection mechanisms, aka RASP:

Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.

You can read some of the possible anti-reversing defences in the OWASP MSTG repository:

Android - 0x05j-Testing-Resiliency-Against-Reverse-Engineering.md
iOS - https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md

So, these are all approaches that make decisions in the client-side, thus prone to be bypassed by using instrumentation frameworks, like Frida:

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

Am I telling you that is worthless to use them? No, by the contrary you should add as many layers of defences as you can afford, just like how castles from the past centuries were doing to protect against the enemy breaching the outer layers of defence.

The Difference Between WHO and WHAT is Accessing the API Server

Before I dive into how you can defend your API server I would like to first clear a misconception that usually I find among developers of any seniority, that is about the difference between who and what is accessing an API server.

I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An API Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

So think about the who as the user your API server will be able to Authenticate and Authorize access to the data and think about the what as the software making that request in behalf of the user.

Lockdown the API server to the Mobile App

So, anything that runs on the client-side and needs some secret to access an API server can be abused in different ways and you can learn more on this series of articles about Mobile API Security Techniques. This articles will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed.

To solve the problem of what is accessing your mobile app you need to use one or all the solutions mentioned in the series of articles about Mobile API Security Techniques that I mentioned above and accepted that they can only make unauthorized access to your API server harder to bypass but not impossible.

A better approach can be employed by using a Mobile App Attestation solution that will enable the API server to know with a very high degree of confidence that only responds to requests from a genuine mobile app. I recommend you to read this answer I gave to the question How to secure an API REST for mobile app? that goes in more detail about it.

Do You Want To Go The Extra Mile?

In any response to a security question, I always like to reference the excellent work from the OWASP foundation.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.