I read an article about reverse engineering, there is a way to reverse engineer through a proxy, how can my app not use any proxies?
CodePudding user response：
You should know about Flutter's/Dart code obfuscation, which makes the code very very hard to understand by humans, so it's very very hard to reverse engineer it, A from the official Flutter website:
Code obfuscation is the process of modifying an app’s binary to make it harder for humans to understand. Obfuscation hides function and class names in your compiled Dart code, making it difficult for an attacker to reverse engineer your proprietary app.
Code obfuscation is supported only for Android/IOS, and not supported for Windows, Linux, and the web.
when building a release of your app, you can pass the --obfuscate flag to activate it:
flutter build apk --obfuscate
Read More From this:
CodePudding user response：
Your Problem
I read an article about reverse engineering, there is a way to reverse engineer through a proxy, how can my app not use any proxies?
What you can reverse engineer through a "proxy" it's how the App is communicating with the API's it uses, and the correct definition for this is a Manipulator in the Middle (MitM) attack:
The Manipulator-in-the middle attack (MITM) intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.
The MITM attack is very effective because of the nature of the http protocol and data transfer which are all ASCII based. In this way, it’s possible to view and interview within the http protocol and also in the data transferred. So, for example, it’s possible to capture a session cookie reading the http header, but it’s also possible to change an amount of money transaction inside the application context
Reverse engineering can be done statically or at runtime, and a lot of open source tools exist to make it easy. No matter how well protected its your mobile app binary against static reverse engineering it will be possible to perform dynamic reverse engineering while the app it's running, even when the app uses Runtime Application Self Protection (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.
A lot of open source tools exist to defeat RASP, being the most notorious one 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.
Statically Reverse Engineering
Some open source tools exist to make this task very simple, being my favourite the MobSF, and in order for you to understand how reverse engineering is easy with this tool I invite you to read the 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.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
How to MitM attack an API
In a series of articles about Mobile API Security I wrote an article that illustrates how you can do one - How to MitM Attack the API of an Android App:
Performing a MitM attack against an HTTPS channel requires the capability for the attacker to be able to add the proxy server Certificate Authority (CA) into the Trust Store of the device running the mobile app and a popular approach is to manually upload the CA to the device, but this comes with some challenges, that may require to root the device and/or repackage the mobile app.
An easier way exists, and in this article I will show how to use an Android Emulator with a writable file system that will allow us to install the proxy certificate directly into the system trusted store, without the need to root the emulator or make changes in the mobile app.
Implementing Certificate Pinning
how can my app not use any proxies?
I believe that you are asking here is how can I prevent MitM attack on my app, and that can be achieved with the use of certificate pinning, that basically pins your app to certificates used by the API's that talks with. In other words your app will only talk with an API if it presents the correct certificate during the TLS handshake.
I wrote an article on how you can implement certificate pinning on your app, that uses certificate pinning via the Android network security config file. Learn how to implement it on this step by step tutorial for Android - Securing HTTPS with Certificate Pinning:
In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.
In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.
If you are on iOS you are also covered, you just need to use the same Mobile Certificate Pinning Generator tool used on the article, which requires us to fill a form with the domains we want to pin and then copy the generated configuration to your iOS app.
But be aware that certificate pinning can be bypassed.
Bypassing Certificate Pinning
Certificate pinning can be bypassed by decompiling the app and resigning it without the pinning implementation or by simply hook an instrumentation framework (Frida or others) at runtime to bypass the pining check, that you can see being done in the article How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Possible Solutions
how can my app not use any proxies?
Giving the context of my answer against all the possible attacks on your mobile app, that by the way isn't an exhaustive list, what you may be looking for it's what can you do to defend against them all.
Remember that security is about of adding as many layers as possible and as you can afford, and this isn't exclusive to software development, it's being used for centuries in medieval castles and prisons. The goal its to make it as time consuming as possible to defeat and to require an increased level of resources and skills set as the attacker progresses to the next layer of defence.
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
From all the recommendations suggested the most effective one will be the implementation of a Mobile App Attestation solution, that will allow the API server to have a very high degree of confidence that the request is indeed from what it expects, an unmodified version of the mobile app that isn't under attack.
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
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.