Threats / 02 Dynamic analysis and tampering

In server mode, attackers can specify how they’d like to instrument an app using Frida. 

The first option is spawn. With spawn, instead of hijacking the target app or process directly, Frida first hijacks the parent process of all apps (i.e. Zygote on Android, launchd on iOS) using the mechanism described above. And finally it spawns the target app based on its identifier (ID).

The second option is attach, which instructs Frida to hijack the target app directly and performs the same mechanism as described above. 

Spawning the app with Frida naturally allows for earlier instrumentation. This is usually preferable for the attacker because it gives them access to any sensitive operations the app performs on launch. This includes any related to protection mechanisms, such as unpacking encrypted code and running RASP checks).

However, attaching to the process may be equally useful, depending on the adversary’s goals. Let’s say that the target app unpacks encrypted code incrementally (i.e. on demand, whenever the code needs to be made accessible to the operating system) and Frida has some issues in discovering all of them. If the attacker wants to see and instrument all of those decrypted code, they can just attach later at some point.

Gadget mode, on the other hand, involves direct injection of a Frida library or framework into the application package. It’s therefore a form of binary modification, as covered in the Decompilation and Modification page. Attackers download the Frida agent library, decompile your app, inject the library and write some code to ensure the app loads this library on runtime. They then re-compile, re-sign, and install this new version of the app on their device. When the app is launched, provided that Frida is loaded as early as possible, it will perform the same operations as in server mode - creating a native thread to open up the socket and pausing the app’s execution until it can successfully communicate with Frida through that socket.

So, what’s the difference between server mode and gadget mode from an attacker’s perspective?

The main advantage of gadget mode - i.e. of injecting the Frida agent library - is that an attacker can perform instrumentation without the need for a rooted or jailbroken device. This is especially advantageous if the attacker intends to run the modified app on other users’ devices.

On the other hand, operating in server mode - specifically with spawn - allows for earlier and deeper instrumentation. Because Frida has already hijacked the parent process, it can instrument system functions as well as user-defined functions (or the code that you write) which will be executed early, such as in application or library constructors. And another benefit for the attacker is that there is no need to tamper with the application binary, which may be a more labour-intensive process.

Fortunately, from a security perspective, there are mitigations against all of these modes. We’ll explore these later on this page.

The key difference between dynamic binary instrumentation and debugging is how they take control of the app and how they perform their work. Dynamic binary instrumentation (DBI) toolkits will seem to be a natural part of the target application or process because they reside in that app’s memory space. So, DBI frameworks essentially operate from within the target application itself.

Debuggers are mainly external processes which simply attach to the target app or process and then transmit signals from the outside to control the target app’s execution.

This makes dynamic binary instrumentation frameworks stealthier and harder to detect than debuggers. Android, for example, offers a security feature called Security-Enhanced Linux which is basically a sandboxing or access control system for every app or process in the device. Debuggers often require this feature to be disabled, so this is a clear indicator of a debugging attempt. 

DBI frameworks such as Frida are also able to perform early instrumentation due to its app spawning functionality - something that debuggers usually don’t have. This is why DBI toolkits are generally more useful to security researchers and bad actors than debuggers are. However, debuggers still have their own advantages. For example, debuggers can easily deal with multi-thread apps and are often shipped as part of the mobile app development SDK, which means they are particularly convenient to use and keep up-to-date.

One of the most important aspects of dynamic tampering is being able to inspect and modify the behavior of an application. This can be achieved via function hooking or tracing. By using a dynamic binary instrumentation toolkit like Frida or a debugger like LLDB, bad actors can intercept any user-defined functions. That is the functions that you create in your mobile app, as well as system library functions loaded into it. Once a function is intercepted, bad actors can then modify its arguments and return values or patch its implementation in-memory.

Dynamic binary instrumentation toolkits like Frida rely on a bridge or agent library that resides in the same memory space or region occupied by your mobile application. Debuggers can also attach to your app and access its memory layout through the relevant system API like ptrace. This means that DBI frameworks and debuggers have the same comprehensive access to every bit of data in your application’s memory layout. Bad actors can therefore use DBI toolkits like Frida or debuggers to explore your app’s memory. By doing so they can locate the address of a particular function to investigate, or they can simply dump the entire memory layout for further analysis later.

Mobile application binaries are often hardened (through obfuscation and encryption), making life more difficult for reverse engineers and security researchers. This makes reverse engineering by means of decompilation considerably slower and in some cases impossible. Dynamic instrumentation toolkits like Frida offer a more efficient alternative. Frida provides functionality like Instruction API which can be used to dynamically disassemble the code of a function or a particular memory address.

Bad actors may be able to extract sensitive information from your app at runtime thanks to dynamic binary instrumentation toolkits like Frida or debuggers like LLDB. For example, as described above, both Frida and debuggers are able to access your memory layout. Imagine you forgot to remove sensitive information of your app such as API keys or access tokens to your servers and cryptographic keys from the memory. The attacker could then use Frida or debugger to spot and retrieve that information from the memory for further attacks. For example, using your own API keys or access tokens as a way to compromise your backend.

Mobile applications often contain proprietary algorithms, data formats, or protocols to provide functionality to their users. Unsurprisingly, adversaries may try to reverse-engineer a competitor’s mobile app to understand its inner workings and extract any useful information from it that might give them an edge. Attackers can use Frida to discover and hook all the user-defined functions and decompile the code on the fly. From there, they can further locate which function or code block contains proprietary information.

Tools like Frida and debuggers (e.g. GDB/LLDB) are also ideal for gamers who want to cheat the system and gain an unfair advantage. They can use either or both to explore your mobile game’s memory layout to locate the address of a function or a game variable they’re targeting. This might be a player’s health, power, movement, or in-game credits. Once they’ve found it, they can easily modify its value to their heart’s content.

As mentioned above, for Android the system will allow a debugger to attach to an app’s process if the app has the android:debuggable="true" attribute in its AndroidManifest.xml. iOS apps must have the <key>get-task-allow</key> set to <true/> in their Entitlements. Both of these options should therefore be set to false. Given the security risks of allowing an app to be debugged, both Google Play and the App Store enforce this as a requirement before uploading an app for distribution. Nevertheless, it’s important to be aware of the importance of these flags, especially for apps that are distributed directly to users.

Encryption may be helpful against some forms of dynamic analysis and tampering, but code needs to be decrypted before it can run. This is one of the reasons why it’s crucial to combine protections against both static and dynamic forms of attack. Still, obfuscation and code virtualization can make dynamic reverse engineering considerably more difficult. And as we explain elsewhere in this guide, encryption can be an effective way to guarantee code and app integrity, therefore preventing binary modification exploits based on using Frida in Gadget mode.

To be able to use Frida in server mode, or to attach a debugger to an app that doesn’t explicitly allow debugging, attackers will need escalated privileges: a rooted or jailbroken device. So, checking whether the device on which your app is running is rooted or not can help prevent instrumentation or debugging.