Unlock the secrets of mobile security! In this insightful podcast, Devyany Vij (Senior Product Security Engineer @ Tide), Oleksandr Leushchenko @olexale (Google GDE, Engineer Manager @ Tide), and Tomáš Soukal (Senior Mobile Security Dev, Product Owner at Talsec) dive deep into the differences and unique capabilities of the Android Keystore and iOS Keychain—two essential tools every app developer should understand.

Discover how each platform protects sensitive data like encryption keys and passwords, what makes them secure, and how their access controls and hardware integrations work behind the scenes. Whether you’re building for Android, iOS, or both, you’ll get practical tips and clear explanations to help you choose the right approach for your next project. Perfect for developers who want to level up their app security knowledge—don’t miss it!

Big thanks to Majid Hajian @mhadaily (Azure & AI advocate @ Microsoft, Dart & Flutter community leader) for help with the production of this podcast

🔐 Level Up Your Game’s Security with freeRASP for Unity

In today’s mobile landscape, securing your game isn’t just about protecting profits—it’s about preserving your players’ trust and ensuring fair gameplay. Whether you’re an indie developer or a full-blown game studio, runtime threats like app tampering, emulators, rooting, and unauthorized modifications are real dangers that can undermine your game’s performance and credibility.

That’s where freeRASP for Unity (Android + iOS) comes in.

🎮 Designed with Unity Devs in Mind

Talsec’s freeRASP solution is now natively available for Unity—a game-changer for developers targeting Android and iOS platforms. This early-release plugin empowers teams to effortlessly integrate robust runtime threat detection directly into their Unity-based games.

⚙️ Easy Integration, Powerful Protection

The official Unity plugin streamlines the setup process:

• 📦 Drag-and-drop installation via .unitypackage

• 🔐 Custom configuration for Android (via certificate hashes and package names) and iOS (using team identifiers and bundle IDs)

• 🔁 Real-time threat detection callbacks integrated into your Game.cs or entry-point logic

This makes it simple to respond to threats like:

• Emulator use

• VPN or system proxy tunneling

• Rooting or jailbreaking

• Debugging and hooking attempts

• Tampering, screen recording, or app repackaging

With built-in detection callbacks, you can proactively respond to these threats by triggering in-game behaviors or alerts that protect your app integrity.

🚀 Why It Matters for Game Developers

While Unity makes multiplatform publishing easier than ever, it also exposes your game to a wide surface area of potential exploits. Mobile cheaters and malicious actors often use rooted devices, simulators, or altered app binaries to bypass normal game logic or manipulate in-game currencies.

freeRASP gives you the armor your game deserves, acting like a security co-pilot as your players navigate your game world.

💡 Ready to Fortify Your Game?

Visit the to get started with installation, configuration, and callback integration. There’s no need to compromise between performance and protection—freeRASP for Unity delivers both.

Talos, a remarkable figure in Greek mythology, was a giant bronze automaton, crafted either by Hephaestus or Daedalus. His sole duty was to protect the island of Crete, tirelessly patrolling its shores. Circling the island three times a day, Talos would hurl stones at approaching ships to fend off intruders, symbolizing unwavering vigilance and defense.

In essence, Talos embodies constant protection — just like Talsec’s approach to security.

Happy Cybersecurity Month — stay vigilant, stay secure!

Elevating SDK Stability with Advanced Crash Reporting

At Talsec, we are committed to delivering top-tier security SDKs, ensuring both reliability and seamless integration. To further enhance our quality assurance, we explored various crash-tracking solutions and successfully implemented a proof-of-concept (PoC) using PLCrashReporter – a lightweight and efficient crash-reporting framework.

Why Crash Tracking Matters

As our SDK portfolio grows – with offerings like , RASP+, and custom client adaptations – ensuring stability across different versions is a top priority. Introducing automated crash tracking empowers us to proactively address issues, minimize downtime, and enhance the overall developer experience.

Beyond stability, security and data privacy are core concerns for both us and our clients. Many third-party crash-tracking services collect and store crash data in ways that may not align with strict security policies. By opting for a custom implementation with PLCrashReporter, we ensure that crash data is handled entirely within our security guidelines, giving clients complete control over how and where their data is stored and transmitted.

Evaluating the Market: 3rd-Party Crash-Tracking Solutions

We assessed leading crash-tracking services based on framework size, ease of integration, and self-hosting capabilities. Here’s how they compare:

• Sentry: Robust and open-source, but complex and premium-priced. (Framework size: ~20MB)

• Bugsnag: Slightly lighter but lacks self-hosting. (Framework size: ~10MB)

• Firebase Crashlytics: Closed-source and requires the full Firebase SDK, making it bulky. (Framework size: 100+MB; Oh wow, Google, seriously?)

• Datadog: Primarily server-focused with intricate setup requirements. (Framework size: ~21MB)

While these services offer advanced features, they come with added complexity, costs, and potential privacy concerns. Many do not clearly document how crash reports are stored prior to submission, leaving uncertainty around data security between the moment of a crash and when the report reaches the server.

The Power of PLCrashReporter

To maintain efficiency and independence, we turned to PLCrashReporter – a lightweight, open-source crash-reporting framework for iOS/macOS. Key benefits include:

• Compact footprint (4.2MB framework size)

• Zero operational costs

• Complete control over data collection and reporting

• Open source nature enables secure on-device storage of crash data until transmission, reducing exposure risks

By integrating PLCrashReporter, we ensure that all crash data remains securely stored until it is explicitly sent to the designated endpoint. This provides an additional layer of security rarely addressed in third-party solutions, aligning with the highest standards of data privacy and compliance.

Seamless Integration & Compatibility Insights

We rigorously tested PLCrashReporter alongside common crash-reporting services to ensure compatibility:

• Sentry (8.43.0): Fully compatible, with seamless integration.

• Bugsnag (6.31.0): No issues, though some VPNs may block communication.

• Firebase Crashlytics (11.7.0): Works but logs a non-critical warning.

• Datadog (2.23.0): Conflict due to Datadog’s internal use of PLCrashReporter. A customized approach may resolve this.

Next Steps & Optimization

With our PoC validated, we are now focused on refining the integration by:

1. Ensuring flawless coexistence with third-party crash reporters

2. Optimizing data collection for more actionable privacy-focused crash insights

3. Enhancing security mechanisms for even stronger data protection

Join the Conversation

We’re eager to collaborate with the developer community! If you have expertise in PLCrashReporter implementation, multi-SDK crash management, or advanced analytics integration, we’d love to hear from you.

Let’s build a smarter, more resilient crash-reporting ecosystem – together! Stay tuned for more updates on our progress.

Overview of "RASP techniques not implemented" weakness

RASP (Runtime Application Self-Protection) encompasses techniques such as root or jailbreak detection, unauthorised code or code execution, malware detection, system state, data logging and data flow. It provides a systematic, organised management approach to securing mobile applications in real time from potential threats.

These techniques:

• Ensure that the application flow remains secure and untampered at all times.

• Enable applications to detect and trigger responses to threats, such as:

  • Warning the user.

  • Killing the app.

  • Locking access to certain features.

Without RASP implementation, applications remain vulnerable to attacks during runtime. RASP techniques assure that the app continuously monitors both its own state and the device environment to detect threats like malware, root, or integrity issues.

Additional benefits of implementing these techniques might include:

• Independent decoupled protection updates.

• Remote configuration of security rules.

• Threat intelligence gathering.

• Fast security incident remediation.

• Providing data for security analysis.

Speed and timing of checks is also important and crucial for response times and ensuring no gaps in detection rounds, with control timing checking sensitive steps in the app. Incorporating RASP into an app ensures continuous protection from threats, ultimately minimising risk and improving overall security.

Modes of Introduction

Mobile app security and user security can be disrupted in various scenarios, including:

• The application does not comprehensively process information and fails to account for system weaknesses or its own vulnerabilities, potentially leading to breached environment integrity.

• Direct reactions to detected threads are not properly executed or integrated into the application’s business logic.

• Security rules cannot be effectively defined based on discovered weaknesses, as this approach lacks the broader perspective needed to address all potential threats and ensure comprehensive protection.

Impact

• Loss of Control and Monitoring: One of the key advantages of RASP is the ability to continuously control and monitor the mobile app’s state and the device environment in real-time. Without these features, the application may fail to detect or respond to unauthorised modifications, malware presence, or tampering attempts.

• Missed Threat Intelligence: Without continuous monitoring, security checks, and data logging, we lose a critical overview of potential threats, making it harder to identify emerging attack patterns and respond to malicious activities effectively.

• Loss of Manageability and Updateability of Detection Techniques: Without RASP, applications lose the ability to update security rulesets, reset policies/settings, and adjust risk scoring in older or already released apps.

Mitigation

• To enhance the security of your mobile application, implement detection mechanisms that continuously monitor the app's state and device environment.

• Implement response actions for detected threats to mitigate potential risks, such as:

  • Killing the app,

  • Warning the user,

  • Logging information about potential risks to the database.

• Use third-party solutions, which specialise in threat detection and real-time security monitoring (e.g. ).

How to test "RASP techniques not implemented"

RASP (Runtime Application Self-Protection) is designed to monitor and protect the application during runtime by detecting and responding to threats in real-time. The test verifies if the application can identify and react to malicious modifications, such as code tampering, root or jailbreak environment, and attempts to bypass security mechanisms. It also checks if the application has the ability to protect sensitive data and prevent unauthorised access to critical operations or features.

By conducting this test, we ensure that the app is capable of defending against runtime attacks and maintaining its integrity even in compromised environments. If RASP techniques are not implemented or are improperly configured, the app may be vulnerable to various security threats, including data breaches, unauthorised access, and malicious modifications.

Steps

1. Ensure that all security checks and protection mechanisms expected from RASP are present and enabled with the application. To test the RASP policy that the app enforces, a written copy of the policy must be provided. The policy should define available checks and their enforcement. For example:

   • Root detection.

   • Screen lock enforcement.

   • Code integrity checks.

   • Detection of dynamic analysis.

2. Based on the previous step, attempt to simulate threats to test if the application reacts as expected. This can involve various scenarios such as:

   • Launching the mobile application on a rooted device.

   • Launching the mobile application on a device without a screen lock enabled.

   • Attempting to repackage the application and launching it.

   • Launching the application in an emulator.

3. Verify that the application properly detects and responds to potential threats. There are various scenarios in which a mobile application can respond to these threats, such as:

   • Killing the app.

   • Warning the user about the detected threat.

   • Logging information about potential risks to a database or SIEM.

Observation

The output depends on the specific reactions set up for the mobile application. The results should demonstrate the app’s behaviour when a threat is detected or triggered, for example:

• Application is terminated.

• Application displays a warning message.

• Application sends information to a database or SIEM. Testers should ensure that the collected threat intelligence data are rich enough.

Evaluation

The test case fails if the mobile application does not react as expected to the detected threats.

written by Martin Žigrai, Tomáš Soukal

System VPNs may be used to mask illicit activities, evade compliance controls, or access services from unauthorized regions.

Detecting a running VPN service on mobile devices is critical for security-sensitive applications, as it can indicate potential privacy and security risks. VPNs can obscure the user’s actual IP address and route data through servers potentially under external control, which might interfere with geographical restrictions and bypass network security settings intended to protect data integrity and confidentiality.

Such anonymizing features could be exploited to mask illicit activities, evade compliance controls, or access services from unauthorized regions. FreeRASP checks whether the system VPN is enabled.

Featured AppSec Collections

Latest Articles

Articles by our team members and guest experts (become one of them) that explore practical mobile security and threat defense topics for the developer community.

Did you know that you can remove plugins dynamically from a Flutter app on Android?

During the implementation of a new feature on freeRASP (more about it ), we noticed that unregistering of plugins is possible using the class. While it may seem unimportant, we decided to push the limits and explore potential attack vectors tthat could lead to the complete disabling of plugins from an external source. As a result, we conducted a small check of the plugin architecture security on Flutter. During this investigation, we discovered what we consider to be a serious problem.

Malicious plugin can remove other plugins at runtime

In Flutter, the class plays a crucial role in managing plugins. The generated GeneratedPluginRegistrant class utilizes it to register plugins, which are then executed during startup. However, you have the flexibility to create your own plugins, acquire plugin instances, and even unregister plugins if needed. Therefore you can create plugin which removes other plugins:

If you have a class reference available, you can also selectively remove specific plugins:

This can even be also achieved directly from your app’s MainActivity on Android (which extends FlutterActivity) without the need for malicious plugin. By leveraging a bit of reverse engineering and code injection (similar to what we discussed in our ), you can achieve this:

How can you secure your app?

You can follow these measures if you want to make sure, that your code is protected againsts such attacks:

🔒 Opt for reputable plugins — Choose well-maintained plugins with a considerable number of likes and positive user feedback.

🔒 Inspect the plugin’s source code — Take a closer look at the codebase for any suspicious lines or potential vulnerabilities.

🔒 Always obfuscate your application — Apply obfuscation techniques to make your app less readable and more obscure.

How do we secure our solution?

We faced the same issue at Talsec (link), while trying to hack our own products + and which are critical security components and should have maximum resilience. Finding at least a partial solution was very important to us. In our RASP solution, (coincidentally) solves this problem.

RASP (Runtime Application Self Protection) Security technique that actively defends application by real-time controlling the security state of the device, integrity of the OS and App.

For context, AppiCrypt is an app attestation tool that protects your API by generating a cryptogram — information about the security state of the device, which is then used in the request header. The backend then checks the cryptogram to determine whether the device is compromised and decides whether to allow or deny the request.

Since the plugin cannot generate a cryptogram (CryptogramFailureException is thrown due to the PlatformExceptionthrown by MethodChannel), the app can be considered untrustworthy. Without a cryptogram, you cannot make network requests backed by AppiCrypt.

Therefore, as a security measure, we can also add:

🔒 Dynamically validate plugin functionality — If the plugin throws a PlatformException, it can indicate that it is unable to communicate with the native side.

While it won’t directly tell you that the plugin has been disconnected, it can give a hint that something unusual is going on.

Stay safe and code with confidence! 💪

Written by Jaroslav Novotný — Flutter developer

Flutter is a beautiful framework for building pretty and natively compiled mobile, web, and desktop applications. Thanks to its simplicity and developer-friendly way of building applications, it’s gaining popularity around the world. However, with great power comes great responsibility. As unlikely as it seems, Flutter applications face the same issues as their native siblings — security attacks.

Should I care about security?

The answer is yes, you should. Security engineering should always be your first step. The moment you take your development more seriously, security becomes your top concern. Whether you develop a simple attendance app or a demanding health, FinTech, or automotive application, you shouldn’t make any concessions in security, especially if you deal with personal data and/or finance transactions.

But I have heard Flutter apps aren’t susceptible to attacks or what?

You could argue that reverse engineering of Flutter apps is not being done very often, and even if it is done, it’s complicated to get something. Your production build is compiled without debugging symbols, and compiled apps are usually harder to crack. Well, that’s true, for now. But first of all, this approach is nothing short of a hide and seek game — you will be caught, and time is playing against you. And second of all, complicated does not mean impossible.

Based on our experience, the following attacks are already possible:

• App repackaging and cloning

• Re-publishing of tampered apps

• Running the App in compromised OS environments (rooted/jailbroken OS, hooking app during runtime, emulators)

• Overlay and Cloak&Dagger attacks

• Misuse of Accessibility Services

• Stealing of hard-coded secrets

A common sign of intrusion on mobile devices is the presence of a root user. A root can do pretty much anything in the system. If we let our Flutter application work normally on a rooted device, we expose it to a possible attack/security breach just because the device’s state is compromised.

Applications need shields and swords to defend themselves — they need RASP (Runtime Application Self-Protection).

In Talsec, we noticed that RASP solutions at that time were not in good condition. We decided to do it our own way. And that’s how freeRASP was born — created to protect Flutter applications conveniently.

How does freeRASP for Flutter differ from its native siblings?

Cross-platform development frameworks, in general, suffer when platform-specific problems need to be solved. Sacrificing security to be able to do cross-platform development is a no-go. We already had experience with both native Android and iOS platform protection. The only question was how to do it for Flutter.

Luckily, in Flutter, you can expose native APIs. If you want to expose native API or implement a platform-specific library, you have to do the implementation for each platform separately. This means you have to understand the specifics of each platform — from low-level coding to system architecture specifics. You have to write a glue code between the native and Flutter side and some API to reuse implementation in other projects. Finally, you have to do tons of testing and verification. In a nutshell — long, cumbersome and exhausting process.

We decided to overcome this gap for you — we created freeRASP for Flutter. Our team did all the work you would typically need to do and shipped it to a pub.dev.

What was the result?

This had many positive effects:

• made Flutter safer for everyone

• contributing to the Flutter community by adding a plugin to pub.dev, which led to…

• getting closer with the Flutter community so that we can listen to any opinion and making our product even better

We wanted to make Flutter safer because we saw its potential. The fast world needs fast development — that’s what Flutter does perfectly well. We also want to help Flutter grow so that more people can appreciate its advantages and raise awareness about security between Flutter developers. freeRASP is a real game-changer. The developer gets a nice and tidy plugin, and the user receives a secure application.

Okay, but how do I use it in my app?

Implementation of freeRASP for Flutter is pretty simple. After initial importing, you just set up some initial configuration and callbacks. And that’s it!

From now on, freeRASP has your back covered and makes reports for you, so you have an overview of your application security. Make sure you accept an email confirmation request from the system to be able to receive these reports.

Example of security report

This example presents a mid-sized FinTech app:

You can find freeRASP for Flutter plugin on pub.dev. There is also a step-by-step guide to help you with implementation. If you like our plugin, don’t forget to give it a like.

Summary

Security is essential, even though we tend to forget about it when it comes to cross-platform applications. freeRASP provides a plugin for Flutter that solves this problem, and it’s easy to use. So what are you waiting for?

Useful links

If you want to know more about freeRASP, don’t forget to bookmark these links:

• Medium — article about freeRASP’s features

• GitHub repository — main repository containing all necessary information

• pub.dev — Flutter plugin

• About freeRASP in general: https://medium.com/geekculture/freerasp-in-app-protection-sdk-and-app-security-monitoring-service-de12d8e49400

written by Jaroslav, Flutter developer at Talsec

In an increasingly interconnected world, the need for robust application security has never been more critical. Capacitor, with its remarkable ability to build cross-platform apps using web technologies, empowers developers to create stunning applications with ease. However, as the capabilities of our apps grow, so does the importance of safeguarding them against a myriad of potential threats.

With a native runtime such as Capacitor, it is fairly easy to turn any web app into native apps for both Android and iOS. You can quickly use the native APIs and access common device functionality, which is awesome, but at the same time, it adds another level of complexity because when you access native APIs, you are imposing yourself to native security issues as well. And trust me, you don’t want to underestimate these challenges.

As a practical example, consider one of the most common security concerns: reverse engineering. Mobile apps are typically distributed in formats like APK (for Android), AAB (Android App Bundles), or IPA (for iOS). These distribution files contain bundled JavaScript code essential for the application’s functionality.

Despite attempts to obfuscate the code through minification and adhering to industry standards like OWASP MASVS (Mobile Application Security Verification Standard), a person with the necessary knowledge can still extract your code with relative ease. There are even utilities like JSTool that can effectively reverse the minification and reveal the original code, potentially exposing sensitive keys and API calls. Afterwards, it’s all in the hands of the attacker.

Successful attacks like these may lead to loss of revenue, exposure of sensitive data, damage to the brand and reputation or leaked intellectual property. And that’s where we want to help you.

What is freeRASP?

Talsec freeRASP is a freemium mobile security SDK designed to make app protection straightforward and accessible. It offers robust protection against a range of threats and is supported on both Android and iOS platforms. freeRASP also provides customized modules for a number of multi-platform tools, now including Capacitor.

From a developer’s perspective, freeRASP acts as an additional protective layer, simplifying the handling of certain attack vectors. This allows you to focus on other critical aspects of your app while safeguarding your users. freeRASP can detect and inform you about various attack scenarios, including reverse engineering, repackaging, cloning attempts, and much more.

Join us as we explore how freeRASP integrates with Capacitor, helping you defend your apps against attacks and vulnerabilities, and ultimately, ensuring your users’ safety. Say hello to enhanced security and peace of mind for your Capacitor apps — let’s dive in.

Why Do You Need RASP?

Mobile app security is a complex challenge that goes beyond traditional security measures like encryption and certificate pinning. Attackers constantly seek vulnerabilities in your app that may not be immediately obvious. A single security breach can have severe consequences for your reputation and user trust.

The need for Runtime Application Self-Protection (RASP) solutions has grown significantly with the rise of mobile technologies. While there are several security libraries available, freeRASP stands out by offering comprehensive protection across various attack vectors.

Based on our experience, a selection of the most common attacks include:

• App repackaging and cloning

• Re-publishing of tampered apps

• Running the App in compromised OS environments (rooted/jailbroken OS, hooking app during runtime, emulators)

freeRASP is designed to detect and mitigate these types of attacks, providing an extra layer of defense against evolving threats.

Integrating freeRASP with Capacitor

Now, let’s dive into the process of integrating freeRASP with the Capacitor platform. You can always find up-to-date integration manual along with detailed description of configuration in our GitHub Integration Guide.

Step 1: Install the Plugin

To get started, install the capacitor-freerasp plugin:

$ npm install capacitor-freerasp
$ npx cap sync

Step 2: Set Up Dependencies

For Android, ensure that your project’s minimum SDK level is set to 23. Update your variables.gradle file accordingly:

ext {
    minSdkVersion 23
    compileSdkVersion 33
    // ...
}

Step 3: Setup Configuration and Callbacks

Import freeRASP in your app’s entry point file:

import { startFreeRASP } from 'capacitor-freerasp';

Configure freeRASP by providing the necessary settings. You’ll need to specify configuration for both Android and iOS, as well as common configuration options. Here’s a sample configuration:

const config = {
  androidConfig: {
    packageName: 'com.yourapp.package',
    certificateHashes: ['yourSigningCertificateHashBase64'],
    supportedAlternativeStores: ['storeOne', 'storeTwo'],
  },
  iosConfig: {
    appBundleId: 'com.yourapp.bundle',
    appTeamId: 'yourTeamID',
  },
  watcherMail: '[email protected]',
  isProd: true,
};

Additional Note About Obfuscation

To enhance security, consider obfuscating your app’s code. Obfuscation makes it harder for attackers to reverse engineer your app and disrupt freeRASP’s operations. You can enable code minification and obfuscation for Android in your build.gradle file:

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

Security Report

With this weekly summary, you get insights into your app’s security state, including detected threats and device characteristics. By keeping an eye on these reports, you can proactively address security issues before they become too severe and make your app even safer for users. If you are curious how such report looks like, take a look at the screenshot below 👇.

Commercial Versions (RASP+ and More)

While freeRASP offers a robust free version, Talsec also provides commercial versions like RASP+ with advanced features and support. These versions offer additional protection, including API protection, App Integrity Cryptogram (AppiCrypt®), security hardening, and more.

RASP+ allows easy-to-implement API protection and App Integrity verification on the backend to prevent API abuse from:

• Bruteforce attacks

• Botnets

• API abuse by App impersonation

• Session-hijacking

• DDoS

It is a unified solution that works across all mobile platforms without dependency on external web services (i.e., without extra latency, an additional point of failure, and maintenance costs).

Learn more about commercial features at talsec.app.

Finally, stay protected before it’s too late 😎

If you read through the whole article, thank you. Maybe now it’s time to check out freeRASP. It’s free, so there’s nothing to lose and who knows, maybe it will save you from a couple of sleepless nights.

We’d be happy to read your thoughts in the comments below 👇 or in one of our GitHub repos 📄.

Written by Tomas Psota, developer @ Talsec

While there are multiple options when it comes to choosing a library that implements secure storage in React Native, it is crucial to ensure that the data are stored properly and ideally without any known vulnerabilities. At Talsec, we made an effort to go through the most popular packages, so you can get an image of what is on offer.

This article assumes you are familiar with:

• How data storage works on native platforms

• Android Keystore, Keychain and how they are used

How to approach secure storage challenges?

Recently, the Talsec team started to support React Native by providing the freeRASP and RASP+ SDKs. We are currently exploring ways how we could go even further and are considering to add a secure storage solution that would follow the latest security standards. In order to proceed, we evaluated the existing secure storage options within React Native and seek input from the community to understand your expectations regarding this feature.

We would love to share our findings so far with a brief description of various secure storage packages available for React Native, along with their benefits and potential vulnerabilities:

1. react-native-keychain

• ✅ Pros: This is a popular package that securely stores sensitive information using the Keychain on iOS and the Keystore on Android. It encrypts data and provides secure storage for confidential data.

• ⛔️ Cons: While react-native-keychain provides secure storage, it is not immune to all vulnerabilities. The package stores sensitive information, e.g. username and password in clear text in the keychain file, and you can find several concerning issues that are open on GitHub, mentioning that the data from iOS keychain can be retrieved. On top of that, it can only store username/password combination.

2. react-native-encrypted-storage

• ✅ Pros: react-native-encrypted-storage is another third-party library that offers secure storage for sensitive data. It uses EncryptedSharedPreferences on Android and Keychain on iOS, encrypts data using AES-256 encryption, providing an extra layer of security.

• ⛔️ Cons: There are some memory leaks detected by Xcode profiler and Keychain is not cleared when your app is uninstalled on iOS — this issue, however, is well documented and can be fixed.

3. rn-secure-storage

• ✅ Pros: rn-secure-storage encrypts data using AES-256 encryption and securely stores it on the device. Plus, it can store any [key, value] pair.

• ⛔️ Cons: The implementation uses secure-preferences package to store the data, which is nowadays deprecated and it is encouraged to use EncryptedSharedPreferences from androidx.security instead.

4. react-native-async-storage

Okay, this package doesn’t implement any kind of secure storage and is not intended to store any sensitive data. However, it is still a popular solution for data storage in React Native, prompting us to mention it in this article as well.

• ✅ Pros: Offers a simple asynchronous storage. It is built on top of the original React Native’s AsyncStorage and provides a convenient API for storing and retrieving data.

• ⛔️ Cons: The package requires devs to handle encryption of the data on their own, as it stores data in plain text, making it vulnerable to unauthorized access if the device is compromised. We would suggest to avoid using AsyncStorage for sensitive information like passwords or authentication tokens.

Problems with Hardware-Backed Keystores

Although many devices offer hardware-backed keystores, there is a significant number that lacks it. Moreover, certain devices, particularly those running on Android, face challenges with hardware-backed keystores due to manufacturer-provided software. These implementations either fail to function properly or resort to software-backed alternatives. I suggest checking out the list of public resources related to Trusted Execution Environment (TEE). This resource compilation provides valuable information on reverse-engineering techniques and strategies for achieving trusted code execution on ARM devices.

Another important consideration is that although hardware-backed keystores may provide better protection against key extraction, they are still susceptible to runtime attacks, just like software-backed keystores. During runtime, attackers can still access encrypted data stored in the keystore using rooted devices, a repackaged or tampered app, or hooking frameworks.

Therefore, we have concluded that the most effective approach which will mitigate the risk of runtime attacks is a combination of secure storage with RASP-based solution.

Boosting Software-Backed Keystore with RASP

By integrating a software-backed keystore into the RASP (Runtime Application Self-Protection) solutions, we can address two critical aspects simultaneously:

1. Reliability: The enhanced RASP solution will offer a dependable keystore mechanism that does not rely on secure hardware. This ensures the integrity and protection of cryptographic keys, even on devices that lack hardware-backed security features.

2. Security: While the keystore itself remains vulnerable to threats like root access and runtime hooks, a closely integrated keystore within RASP can mitigate these risks. It can dynamically determine whether to store or retrieve data based on the current security state of the device.

Through the integration of a software-backed keystore, the enhanced RASP solution provides a comprehensive and reliable approach to data protection, overcoming limitations related to hardware availability and compromised devices.

That’s it!

We hope this summary helps you make an informed decision when considering a secure storage option for your React Native project. But also, we’d be happy to hear your opinion. Would you use a software-based secure storage SDK for React Native that utilizes a hardcoded obscured encryption key?

Please share your experiences, suggestions, and any other secure storage tips. Let’s discuss in the comments below! 👇

Happy coding.

written by Tomas Psota, developer at Talsec

https://talsec.app | [email protected]

Introduction

Ever wondered how your Android phone can tell if that Instagram app you're about to install is the genuine application, or just a sneaky clone repackaged by a hacker with malicious intent? That's where APK signatures come in – they're the digital gatekeepers of the Android app world! Think of them as a high-tech, unforgeable seal of authenticity stamped on every app, verifying its true origin and guaranteeing the code hasn't been illicitly altered since the developer signed off on it. This critical verification happens every time you install or update an app, acting as an invisible shield that ensures the software you're running is legitimate and safe.

How does the Android signature verification work?

Android apk sign verification has mainly two steps:

1. Signing

When development is complete, the developer signs the app using a private key. This process generates a digital signature of the app's contents and embeds the developer's public key certificate within the APK file.

2. Verification

This process is performed by the Android OS on the device before the installation of an app.

1. First, the Android package manager calculates a cryptographic hash of the APK's contents.

2. Next, it extracts the developer's public key certificate from the APK and uses it to decrypt the digital signature. This decryption reveals the original hash of the app as calculated by the developer.

3. Finally, the hash calculated on the device is compared to the developer's original hash . If they match, it confirms that the APK's contents have not been tampered with since it was signed.

To prevent anyone from bypassing this verification mechanism, Android utilizes several signature schemes. The primary difference between them is how they sign the application and store the resulting data inside the APK:

• v1 (JAR Signing): This original scheme individually signed each file within the APK and stored the signature data inside the META-INF/ directory (e.g., MANIFEST.MF`, `CERT.SF ). This method was computationally slow and had a critical flaw: it did not verify the entire APK file. Sections like the ZIP metadata were left unsigned, creating an attack vector where malicious code could be injected into the APK without invalidating the signature.

• v2 Scheme: Introduced in Android 7.0, this scheme verifies the entire APK file as a single blob. The signature is stored in a dedicated APK Signing Block, located just before the ZIP Central Directory . This approach is significantly faster and closes the vulnerabilities present in the v1 scheme. However, this scheme did not originally support signing key rotation, meaning a developer could not change their signing key without breaking updates for their app.

• v3 Scheme: Introduced in Android 9.0, this scheme is very similar to v2 but adds support for signing key rotation . It includes an attribute in the APK Signing Block that holds a history of signing certificates. This allows developers to change their app's signing key while enabling the app to be verified using either the new or older keys, ensuring seamless updates.

• v4 Scheme: This scheme was introduced to support streaming installs, allowing for parts of an app to be used before the entire APK is downloaded. For v4 signing, a Merkle hash tree of the APK's contents is calculated, and its root hash is stored in a separate file named .apk.idsig . This allows for the incremental verification of individual blocks of the file as they are streamed to the device.

Vulnerabilities related to Android Signatures

The methods employed by ApkSignatureKiller are the modern versions of critical vulnerabilities of Android signature verification process.

1. The famous Master-Key vulnerability: This critical vulnerability exploited a discrepancy in how Android handled ZIP archives . An attacker could include two files with the same name within an APK. The package installer would process one file when verifying the signature, while the Dalvik/ART runtime would execute the other, malicious file. This allowed an attacker to inject and execute arbitrary code within a validly signed application, effectively bypassing the v1 signature check.

2. The Janus vulnerability: This vulnerability specifically targeted the v1 signature scheme. An attacker could prepend a malicious DEX file to the beginning of a legitimate, signed APK file. Because the v1 signature verifier would check the integrity of the ZIP entries but ignore the header of the file, it would still validate the application as authentic. However, the Android runtime would see the malicious DEX file at the start and execute its code, effectively running a malicious payload while the app appeared legitimate. This is simlar to the methods used to bypass v1 signature scheme by the apkSignatureKiller application .

The ApkSignatureKiller

The infamous ApkSignatureKiller application actively bypasses Android's entire signature verification system. This capability is frequently exploited to tamper with critical applications, such as banking apps, which are then used on a device, creating a major security headache for developers who rely on signature checks to ensure app integrity.

Let us take an example of an Android app signed by v1 signature scheme named victimApp2 :

We can also check which signature schemes are verified inside a fully built apk using apksigner tool. This shows that the apk has been signed using the v1 signature scheme.

Now let's try to install the apk inside the Android emulator with < Android 7.0 to ensure that we are able to install apk with just v1 signature scheme. With v1 scheme enabled we are easily allowed to install the apk on the device.

Now let's try the same with the unsigned apk on the same device. This tells us that the apk is unsigned and cannot be verified. The device also denies to download the unsigned application.

Here enters the ApkSignatureKiller who changes everything. Now let's just hook and modify our signed installed application using the ApkSignatureKiller. For this we have to push our signed application into the directory that can be accessed by the ApkSignatureKiller app just like the external storage directory.

• Let's open our evil app

• Now just choose the signed app from the external directory and then press the Hook button.

• Press Install and guess what we are able to install the app with the killed signature verification mechanism.

• We can also verify if our new app has been actually modified or not.

This shows that an unsigned, tampered application can be installed on a device without being detected by Android's security mechanisms. It proves that by using this method, it's possible to alter an app, recompile it, and install it without a valid signature, leaving the app's contents completely vulnerable.

To keep this article straightforward and easy to understand, I have used a simple demo application and focused on bypassing only the v1 signature scheme. However, it is crucial to understand that modern versions of ApkSignatureKiller and similar tools, are capable of bypassing the much more secure signature schemes. This makes them some of the most dangerous tools in the hands of attackers today.

Working of ApkSignatureKiller

But some of you with inquisitive minds might wonder: How does this tool actually work? How is it able to bypass the signature verification on an Android device ? 🙁

To bypass the signature check, the tool doesn't just remove the signature; it employs a more deceptive technique. It injects its own malicious code into the target application by hooking the specific part of the Android framework responsible for verifying an app's integrity. This injected code then intercepts the verification process and falsely reports to the system that the APK is still securely signed, even though its original signature has been stripped and its contents have been altered.

• These are the methods used by it to hook the application and remove its signature file.

• It basically hooks the classes like PackageManager or ContextImpl that are generally used during reflection that helps in signature verification of the Android application.

• Then it uses this above method to replace the application with new application that does not have any signature verification mechanism and will always be verified by the Android signature verifier no matter how much the apk is tampered.

• It hooks the code that fetches the signature file for verification and instead modifies the method to return true or verified always.

Why is it so crucial ?

Think of your Android device as a car and its signature verification system as a sophisticated car alarm. As long as the alarm is active, a thief cannot steal the stereo without setting it off.

However, a tool like ApkSignatureKiller acts as a master key that doesn't just break the window but cleverly disables the entire alarm system. Once the alarm is off, the thief can freely open the doors, steal the stereo, or even swap out the engine parts without anyone knowing.

This is precisely why signature verification is so crucial for an Android app. Without it, anyone could tamper with an app's contents, recompile it, and distribute their own modified version . Imagine the consequences: someone could unlock Spotify Premium for free, use cheats in a game like Clash of Clans, or, far more dangerously, bypass security measures in banking applications to authorize fraudulent transactions.

ApkSignatureKiller threatens the very foundation of Android's application security model. Despite continuous efforts to harden the platform, this tool often succeeds in its malicious goals.

But luckily, as developers, we are not helpless. There are concrete steps we can take to safeguard our applications against such attacks:

How to prevent tampering attacks with Talsec RASP+? [2 Months Free Trial!]

Talsec's RASP+ (Runtime App Self-Protection) offers a multi-layered defense to shield mobile apps from tampering and malicious tools like ApkSignatureKiller. These tools are built to bypass Android's fundamental security measure: verifying an app's digital signature. By disabling this check, an attacker can modify a legitimate app, inject malicious code, and then repackage it.

RASP protects against that with:

• Signature and Certificate Verification: Unlike system-level checks that can be intercepted or disabled, RASP operates within the application itself. It continuously validates the app’s signature and signing certificate hash, making tampering significantly more difficult.

• Code and Resource Integrity Checks: RASP doesn’t stop at verifying signatures—it actively monitors the application’s code and resources. If the app has been decompiled, modified, or augmented with malicious code, RASP flags and responds to these unauthorized changes.

• Real-time Threat Response: When RASP detects a threat, it triggers a callback function—giving developers full control over how their app responds. Once integrated, you can implement callbacks such as onRootDetected, onDebuggerDetected, onEmulatorDetected, and more. These powerful tools let you tailor defensive actions: show custom alerts, limit app functionality, or shut down the app entirely if the environment is compromised.

The onTamperDetected callback plays a crucial role in identifying and responding to signature verification issues within the application. This powerful layer of security is easy to integrate—any developer can add it in just minutes. With Runtime Application Self-Protection (RASP), strengthening your app's defenses has never been simpler.

Try it for free for 2 months and experience how effortlessly you can boost your app’s protection; check out https://talsec.app to request the trial.

written by Akshit Singh

"For Your Eyes Only" Principle

Ever felt embarrassed after accidentally leaking your account balance, private messages, or personal photos and videos? As app developers, we’re often tasked with preventing such privacy breaches. Fortunately, implementing the right countermeasures is simpler than you think—and I’ll show you how.

For Your Eyes Only isn’t just a catchy phrase—it’s rooted in espionage history and made famous by the 1981 James Bond film. Originally used to label highly classified documents intended solely for authorized eyes, it perfectly captures the essence of protecting user data in mobile apps. When it comes to your users’ sensitive information, it truly should be for their eyes only.

Let’s explore a few common mobile app scenarios where you might want to enhance privacy and security:

• Hide Everything: Protect highly sensitive content like health reports, password screens, account balances, recent transactions, and browsing history.

• View, But Don’t Share: In galleries, stories, and dating apps, guard against unauthorized sharing by blocking screenshots and screen recording.

• Leakage Awareness: Notify users if someone takes a screenshot of their stories, reels, or other ephemeral content.

• Combat Social Engineering & Phishing: Block remote access tools like TeamViewer or AnyDesk to prevent attackers from stealing data or tricking users in phishing scams.

• Penetration Testing Defense: Skilled testers often use remote access tools to demonstrate data leakage vulnerabilities—make this an impossible win by securing against RAT exploits. Check MASWE-0055 OWASP Mobile Security Standard requirement.

RASP Solution

At Talsec, we set out to solve this problem elegantly by introducing three simple methods to tackle it effectively. You will find them both in the freeRASP and RASP+ on all supported platforms (Android, Flutter, React Native, Capacitor, Cordova, iOS).

1. blockScreenCapture

2. onScreenshotDetected

3. onScreenRecordingDetected

Blocking / Unblocking Screen Capture

Talsec provides comprehensive protection against all listed categories of screen capture apps, ensuring your app’s content remains secure. All previosly listed categories can be blocked, with the screen appearing black in screenshots, recordings, or casting.

To easily implement this protection, simply use the Talsec.blockScreenCapture(this, true) method within your application.

public class DemoApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        // Talsec initialization code
        // ...

        // Register a callback to listen to activity lifecycle events
        registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
            @Override
            public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle bundle) {
                // Block (true) or unblock (false) screen capturing
                Talsec.blockScreenCapture(activity, true);
            }
            // ...
        });
    }
}

Result

The protected application will display as a blank (black) screen in screenshots, screen recordings, screen casting, or when accessed through remote access tools like TeamViewer.

Screenshot Detection Integration

Screenshot Detection can be integrated by implementing onStart() and onStop() in the Activity class. Talsec is notified about the screenshot through Talsec.onScreenshotDetected(). This is returned to the application via the onScreenshotDetected() callback and processed further in the SDK.

Our RASP provides convenient callback method:

override fun onScreenshotDetected() {
    // your custom logic here
}

To integrate it you will need to integrate it into your Activity:

Screenshot Detection requires target Android SDK at least 34 (Android 14, API Level 34, Upside Down Cake).

[AndroidManifest.xml]
<uses-permission android:name="android.permission.DETECT_SCREEN_CAPTURE" />

[MainActivity.kt]
class MainActivity : ComponentActivity() {
    private lateinit var screenCaptureCallback: ScreenCaptureCallback

    override fun onCreate(savedInstanceState: Bundle?) { … }

    override fun onStart() {
        super.onStart()
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
            screenCaptureCallback = ScreenCaptureCallback {
                Talsec.onScreenshotDetected()
            }
            registerScreenCaptureCallback(mainExecutor, screenCaptureCallback)
        }
    }

    override fun onStop() {
        super.onStop()
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE && screenCaptureCallback != null) {
            unregisterScreenCaptureCallback(screenCaptureCallback)
        }
    }
}

Screen Recording Detection Integration

Screen Recording can be integrated by implementing onStart() and onStop() in the Activity class. Talsec is notified about the screenshot through Talsec.onScreenRecordingDetected(). This is returned to the application via the onScreenRecordingDetected() callback and processed further in the SDK.

Our RASP provides convenient callback method:

override fun onScreenRecordingDetected() {
    // your custom logic here
}

To integrate it you will need to integrate it into your Activity:

Screen Recording Detection requires target Android SDK at least 35 (Android 15, API Level 35, Vanilla Ice Cream).

[AndroidManifest.xml]
<uses-permission android:name="android.permission.DETECT_SCREEN_RECORDING" />

[MainActivity.kt]
import android.view.WindowManager.SCREEN_RECORDING_STATE_VISIBLE
import java.util.function.Consumer

class MainActivity : ComponentActivity() {
    private val screenRecordCallback = Consumer<Int> { state ->
        if (state == SCREEN_RECORDING_STATE_VISIBLE) {
            Talsec.onScreenRecordingDetected();
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) { … }

    override fun onStart() {
        super.onStart()
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            val initialState =
                windowManager.addScreenRecordingCallback(mainExecutor, screenRecordCallback)
            screenRecordCallback.accept(initialState)
        }
    }

    override fun onStop() {
        super.onStop()
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            windowManager.removeScreenRecordingCallback(screenRecordCallback)
        }
    }
}

Free and Business Approaches to Prevent Screen Capture Threats

To effectively block all screen capture threats, both free and business approaches can be used depending on your security needs. For those seeking a cost-effective solution, and offer foundational protection. These tools can block basic screen capture threats while incorporating malware detection technologies to uncover Remote Access Tools (RATs) by searching for package names and risky permissions. This provides a robust initial layer of security without the need for a premium plan.

For businesses looking to implement more complex, customizable security solution RASP+ provides advanced features that go beyond simple threat detection. With built-in reactions, MalwareDetection, Overlay Detection, and Accessibility Services Misuse Detection, businesses can create a comprehensive defense strategy. Additionally, incidents such as screenshots and screen recording attempts are recorded in logging data, enabling thorough tracking.

written by Tomáš Soukal

This article will delve into the concept of obfuscation, explore its different types, and articulate Talsec's philosophy on its application. We believe in a balanced and pragmatic approach, prioritizing the most developer experience, app performance, exploitability of attack techniques while minimizing potential drawbacks and considering cost efficiency, to ensure both security and the smooth business operation of your mobile applications.

Understanding the Fundamentals of Obfuscation

The primary goal of mobile app obfuscation is to render the application's code more difficult for an attacker to understand after it has been decompiled. Think of it as scrambling the blueprint of your application, making it significantly harder for someone to decipher its structure, logic, and sensitive information. While obfuscation doesn't make your application completely impenetrable – a determined attacker with enough time and resources might eventually succeed – it drastically increases the effort and expertise required, often making the attack economically unviable.

It's crucial to understand that obfuscation primarily focuses on hindering static analysis – the examination, understanding or tampering of the application's code at build time. Runtime attacks, where malicious actors attempt to manipulate the application while it's running, require a different set of defenses, which is where RASP technologies like those offered by Talsec come into play.

Obfuscation and RASP are complementary security layers, working in tandem to provide comprehensive protection.

Deconstructing Obfuscation: Three Key Types

The concept of obfuscation can be broadly categorized into three distinct types, each targeting different aspects of the application's code:

A) Name Obfuscation for Classes, Methods, and Fields

This type of obfuscation focuses on renaming the classes, interfaces, methods, and fields within the application's code to meaningless and often short identifiers. Instead of descriptive names like UserManager, authenticateUser, or userPassword, these elements might be renamed to something like a, b, or c.

Key Concepts

• Renaming: The core mechanism involves replacing meaningful names with arbitrary strings.

• Reduced Readability: This significantly hinders an attacker's ability to understand the purpose and functionality of different code components simply by examining their names. It breaks the semantic link between the code and its intended behavior.

• Limited Complexity: Name obfuscation is generally the least complex type of obfuscation to implement and has minimal impact on the application's performance or stability.

• Generic Applicability: This technique is indispensable and straightforward, as it is a complimentary compiler feature that yields a significant security advantage.

Example

Consider a class responsible for handling user sessions:

Copy

public class UserSessionManager {
    private String loggedInUsername;
    private boolean isLoggedIn;

    public boolean authenticateUser(String username, String password) {
        // Authentication logic
    }

    public String getLoggedInUsername() {
        return loggedInUsername;
    }
}

After class name obfuscation, this might become:

Copy

public class a {
    private String b;
    private boolean c;

    public boolean d(String e, String f) {
        // Authentication logic
    }

    public String g() {
        return b;
    }
}

While the underlying logic remains the same, the renamed elements provide no clues to an attacker about the class's purpose or the functionality of its methods and fields.

Talsec offers a feature to ensure that this basic obfuscation technique is applied and trigger the security threat control if this was skipped at build time.

B) String Obfuscation

String obfuscation focuses on concealing string literals embedded within the application's code. These strings can often reveal sensitive information, such as API keys, Certificates, URLs, error messages, or even business logic. By obfuscating these strings, you prevent attackers from easily extracting valuable insights or identifying critical parts of your application.

Key Concepts

• Encoding and Encryption: String obfuscation typically involves encoding or encrypting the string literals within the application.

• Runtime Decoding/Decryption: The original strings are reconstructed at runtime, only when they are actually needed by the application.

• Increased Analysis Difficulty: Attackers cannot simply search for specific keywords within the decompiled code to uncover sensitive information. They need to understand the obfuscation algorithm and potentially reverse-engineer the decoding/decryption process.

Example

Consider the following code snippet containing an API key:

Copy

String apiKey = "YOUR_SUPER_SECRET_API_KEY";
String apiUrl = "https://api.example.com/data";
After string obfuscation, this might look like:
Java
String apiKey = new String(Base64.getDecoder().decode("WU9VX1NVUEVSX1NFQ1JFVF9BUElfS0VZ"));
String apiUrl = new String(Base64.getDecoder().decode("aHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vZGF0YQ=="));

An attacker examining the decompiled code would see seemingly random strings, requiring them to identify and reverse the Base64 decoding to uncover the actual API key and URL. More sophisticated techniques involving encryption would further complicate this process. Talsec provides a Secure Vault feature to address this need with high level data protection.

C) Control-Flow Obfuscation

Control-flow obfuscation aims to make the application's control flow – the order in which instructions are executed – more complex and difficult to follow. This is achieved by introducing artificial complexity, such as:

Key Concepts

• Opaque Predicates: Inserting conditional statements whose outcome is always known at runtime but is difficult for an attacker to determine statically. This creates "dead code" paths that complicate analysis.

• Bogus Code Insertion: Injecting code that has no functional impact on the application's behavior but serves to confuse and mislead attackers.

• Branching and Jumps: Replacing straightforward sequential execution with a web of conditional and unconditional jumps, making it harder to trace the logical flow.

• Exception Handling Abuse: Using exception handling mechanisms in non-standard ways to alter the control flow.

• State Machine Transformation: Converting linear code sections into complex state machines, obscuring the original logic.

Control-flow obfuscation might transform this into a more convoluted structure involving opaque predicates and unnecessary jumps, making it harder to understand the simple conditional logic.

Talsec's Perspective: A Pragmatic Approach to Obfuscation

At Talsec, we firmly believe that a layered security approach is the most effective way to protect mobile applications. Obfuscation is a crucial component of this strategy, acting as a vital deterrent against static analysis. However, we also recognize the trade-offs associated with different obfuscation techniques.

Our Stance on Obfuscation Types

• Class Name Obfuscation and String Obfuscation: Must-Haves for Sensitive Apps: We consider both class name and string obfuscation as essential baseline security measures for any application handling sensitive data or implementing critical business logic. The relatively low overhead and significant increase in analysis difficulty make them highly valuable in hindering casual attackers and raising the cost for more sophisticated ones. Implementing these techniques should be a standard practice in your mobile app development lifecycle.

• Control-Flow Obfuscation: Reserved for Algorithm Protection: While control-flow obfuscation can offer a higher degree of protection against reverse engineering of specific algorithms, we believe its application should be carefully considered and generally reserved for scenarios where the application's core algorithm itself is a significant intellectual property asset.

The Challenges of Control-Flow Obfuscation

We acknowledge that control-flow obfuscation can introduce several complexities and potential issues:

• Increased Integration Complexity: Integrating and configuring control-flow obfuscation tools can be more challenging compared to class and string obfuscation.

• Potential for Non-Deterministic Bugs: The transformations applied by control-flow obfuscation can sometimes introduce subtle and hard-to-debug issues that may not manifest consistently.

• Performance Impact: The added complexity in the control flow can potentially lead to performance overhead, impacting the application's responsiveness and battery consumption.

• App Store Review Issues: Aggressive control-flow obfuscation techniques can sometimes be flagged by app store review processes due to the significant code modifications they introduce.

Our Recommendation for Algorithm Protection

If your application's core algorithm is a critical asset that requires a higher level of protection than class and string obfuscation can provide, we recommend a more targeted approach:

• Isolate Sensitive Code: Move the algorithm's implementation to code written in a lower-level language like C or C++.

• Separate Obfuscation: Apply robust obfuscation techniques specifically designed for C/C++ code to this isolated module.

• Minimize Impact: By isolating the sensitive code, you limit the potential negative impacts of complex obfuscation on the main application codebase, reducing integration challenges, performance concerns, and the risk of introducing widespread bugs.

Talsec's Commitment to Comprehensive Security

While Talsec doesn't directly provide control-flow obfuscation for the main application code due to the aforementioned complexities, we are committed to offering our partners a holistic security solution.

We can recommend and facilitate integration with reliable third-party tools that specialize in obfuscation enabling you to effectively protect your most critical algorithms without compromising the stability and maintainability of your primary application code.

Conclusion

Obfuscation is an indispensable tool in the mobile app security arsenal. By making your application's code significantly harder to understand, you deter attackers and protect your intellectual property and sensitive data.

Talsec advocates for a pragmatic approach, emphasizing the crucial role of class name and string obfuscation as fundamental security layers for all sensitive applications. While acknowledging the potential benefits of control-flow obfuscation for specific algorithm protection, we recommend a targeted strategy involving isolating sensitive code in C/C++ and applying specialized obfuscation tools to minimize risks and ensure a robust and stable application.

At Talsec, we are dedicated to providing you with the tools and knowledge necessary to build secure and resilient mobile applications. By understanding the nuances of obfuscation and adopting a layered security products RASP, App Hardening, Malware Detection, AppiCrypt and carefully chosen obfuscation techniques, you can significantly enhance your application's defenses against the ever-evolving threat landscape.

It is predicted that there will be whopping . With great power comes great responsibility, and every experienced software developer should thrive to follow security standards to ensure that their app is secured against cyber criminals. Technologies like RASP (Runtime Application Self-Protection) are made to shield your app against attacks that occur in the runtime. In this article, we’ll show you a RASP-based security library for your React Native app which can detect a wide range of potential attacks and vulnerabilities.

But it is unlikely that someone is going to mess with my app…

Well, statistically yes. But reality is quite different. When your app is republished or the data of your users are compromised, it’s too late to think about security. Your reputation is now weakened. You are that ‘one in a million’ person that was unfortunate enough. However, if you found this article, then you most likely want to find out how to make your app more secure. And this is a great starting point!

Just to give you an example, one of the most common security risks is reverse engineering. React Native apps are shipped as APK, AAB, or IPA files with the JavaScript code that is bundled with the application. This code can be, with a small effort of a person that knows what he is doing, easily extracted. Although the code is minified, there are utilities like that make it possible to unminify them and reveal your sensitive keys or API calls.

With a hybrid platform like React Native, the development of your application may cost less resources and time. That’s great! Unfortunately, you still have to solve platform-specific problems and focus on security on both iOS and Android. In addition to that, hybrid platforms may introduce new security flaws with adding more complexity to how your app is executed. And you don’t want to ignore them. If you want to keep your app safe, you can follow industry standards, such as .

Our contribution to React Native community

When we started to think about extending our support to React Native at Talsec, we already had with protection for native Android and iOS apps, as well as other frameworks like Cordova and Flutter. The only challenging part was to understand how to create the bridge between native code and JavaScript, which would expose the freeRASP to the consumer, so you don’t have to spend your time messing around with native modules, testing and verification. We did all of this for you and are proud to introduce .

What is freeRASP?

freeRASP is a mobile in-app protection and security monitoring plugin. It aims to cover the main aspects of RASP (Runtime App Self Protection) and application shielding, enabling the app to defend itself against threats. It allows mobile applications to check the security state of the environment they run within, actively counteract attack attempts, and control the integrity of the app.

From the developer’s point of view, freeRASP serves as an extra protection layer that helps you to handle certain attack vectors with ease, while you can aim your focus on other areas. You are also protecting the users of your app as freeRASP is able to detect and take actions if the app is being executed on a rooted or jailbroken device, whether the app is tampered, etc.

freeRASP is designed to combat many significant attack vectors, thus creating an obstacle that prevents your app from intrusion. This gives you a real advantage against other apps which do not protect themselves in any way.

So far so good, but how do I use it?

It’s quite simple, actually. Just follow the 4-step tutorial below. .

Step 1: Install the package

You can add freeRASP the same way as you would with any other package. The plugin is installed via your favorite package manager. With yarn, for example, you can do it like this:

Furthermore, for Android apps you need to modify android/build.gradle to add our maven repository containing freeRASP. iOS requires Pods to run our plugin. Find out more .

Step 2: Configure the freeRASP

This is a place where you set up required fields (package name, signing certificate hashes, bundleId, teamId), which will help freeRASP to detect threats correctly. Don’t forget to add also your email address so you don’t miss your regular security report (more on that later). The configuration might look like this:

Step 3: Set up threat reactions

After a threat is detected, freeRASP fires an event that is consumed by your app. With freeRASP, it’s the developer’s responsibility to configure what should happen after such event is registered. You can for example kill the application, notify the user that a threat has been detected or just ignore the threat. It’s all in your hands. Just create an object that has threat name as a key and function as a value, like it is shown in the example below:

Step 4: Start the freeRASP

Good, all setup is done! The last missing part is to start looking for threats. We provide a custom hook that handles all required logic for you, as is registering and unregistering of the listeners. The hook is a part of the freeRASP package and needs to be imported:

Now pass your config and threat reactions to the imported hook:

The hook will now initialize freeRASP with your configuration and start to look for threats. That’s it!

Additional information

There are the dev and release versions of the library. The dev version should be used only during the development process of the application as it disables some of the checks (e.g. if you would implement killing of the application on the debugger callback). In other cases, you always want to use the release version. On Android, it is handled automatically, whereas, on iOS, the step is a matter of adding a pre-built script into the run phases and embedding a symlink to the correct framework. Do not worry, it is quite easy ;)

freeRASP is available to everyone, free of charge. However, it uses a bridge between JavaScript and native code, which is essentially an additional place that could be exploited. We are able to remove this redundant communication while still keeping your app safe. You can read more in the Enterprise Services section down below.

Example of a security report

This example presents a report of a mid-sized FinTech app:

Summary

The demand for secured apps nowadays is already high and will only increase in the future. Therefore developers should thrive for secure solutions. freeRASP is a tool that can help you to achieve this task. With all its security checks, it can be your good friend and keep you out of trouble. freeRASP is a powerful tool that gives you freedom of choice in how you set up the reactions to detected incidents. What’s more, it is available as a package, which makes the integration pretty straightforward. Don’t forget, freeRASP is available free of charge, why don’t you try it then?

written by Tomas Psota, developer at Talsec

| | Read also |

At Talsec, we believe apps should have the option to detect risky environments, including suspicious malware, to ensure no sensitive information is leaked. Let us introduce our advanced in-app malware protection!

https://docs.talsec.app/freemalwaredetection

Active protection against:

• Known malware

• Ongoing malware campaigns

• Counterfeit app clones

• Tapjacking

• Accessibility Screen readers

• Other potentially risky apps

Malware detection capabilities include:

• Scanning the device for blocklisted apps

• Identifying apps installed from untrusted app stores

• Detecting side-loaded apps from unverified sources

• Apps requiring risky permissions

Reporting and logging:

• Any unwanted findings are reported back to the app

• All findings are logged for further analysis and tracking

https://docs.talsec.app/freemalwaredetection

Written by Tomáš Soukal — Security Consultant

Introduction

In today’s mobile app ecosystem, ensuring your app is secure from piracy, tampering, and sideloading is more important than ever. With unofficial app stores and third-party platforms on the rise, developers face the risk of their apps being stolen, modified, or misused, often leading to revenue loss, security breaches, and reputation damage. One simple but effective measure to safeguard your app is enforcing install source restrictions, ensuring it only runs if downloaded from official stores like Google Play or the Apple App Store. This article explores how you can implement these checks and why it’s crucial for app security.

How Unauthorized Installs Lead to Vulnerabilities

Distributing an app through unofficial channels opens the door to numerous security threats, many of which could have devastating consequences for both the developer and users. Unauthorized installs can lead to significant breaches in security for several reasons:

1. Tampered versions of the app

2. Lack of official updates and security patches

3. Data leaks and privacy concerns

4. Exploits for ads or in-app purchases

5. Gateway for broader attacks

One common scenario is that the app being installed has been tampered in order to skip verifications of some kind or in order to add malicious code to it. As an example, an attacker can use apktool to decompile the apk:

This gives back a smali version of the app that can be changed later on. Think of smali code like an assembly-like language that is a low-level representation of the compiled Java code. That can be modified by maybe adding a key logger function of some sort.

Than is as simple as repacking the app with

and then resign the apk

This high-level example shows how dangerous it can be to install an app like this for both developer and user. Users who unknowingly download these tampered versions may be exposed to malware, spyware, or data-stealing mechanisms that compromise their personal information. This type of unauthorized access could include reading sensitive files, intercepting user data, or even hijacking user accounts. Developers can be harmed both in terms of their reputation and earnings. Modified app versions may disable ads, unlock premium features for free, or provide unauthorized access to paid content.

How to Check to Install Sources in Your Mobile App

One basic strategy is to check the install source every time the user launches the app and react accordingly.

Let’s see a quick and easy example using Flutter. Keep in mind that we will write some native code for Android and iOS, so you can use the same code if your app is native only or if you want to use it in any other framework.

So first of all, let’s create a new Flutter project with flutter create check_install_source. You can remove the main.dart file entirely and replace it with the following, starting with the necessary imports and the classi main declaration:

Then we can create a MyApp class

In the actual MyAppState we can implement a simple build method and the initState :

Now let’s add a new method called _checkInstallSource in the initState

So that we can implement it as following:

What’s happening here is that we are calling specific native function using flutter’s method channels () so that we can perform some action in the native side. Of course we are catching exceptions that may occur.

When we call getInstallerPackageName **Android method we will ask what the install source is. In this case we are checking against com.android.vending that’s the Google Play Store but you can also check plenty of other alternative stores like Samsung Galaxy Store com.sec.android.app.samsungapps.

On the other hand, when calling validateAppStoreReceipt iOS method we are checking that an App Store receipt is present. Even on free apps, Apple attach a receipt file to verify the authenticity of the executable. Of course just checking if the receipt is there or not could not be enough so you can perform additional verification or send receipt to your server for validation ().

Now, before checking kotlin and swift code, let’s see what we can do with those informations and let’s implement the _showErrorAndExit() method.

Keep in mind that’s just an example to alert the user. Exiting an app with exit(0) it’s not usually recommended because Apple may reject your app when submitting it to the AppStore.

Now open the MainActivity.kt file in Android folder and swap the content with necessary import first:

and than change the MainActivity class as following:

In this chunk of code we are implementing Flutter method channel in Android counterpart, getting ready to listen for the same method getInstallerPackageName that we implemented in Dart. Using packageManager we can get the installer package name and pass it back to Dart.

We can move to iOS folder opening AppDelegate.swift and adding imports:

We can proceed editing didFinishLaunchingWithOptions method to let Swift know what method need to be respond to:

Last step is to implement the isValidAppStoreReceipt() method in the AppDelegate class:

Your app should now be able to check the install source and force exit if it’s an unofficial source (in this example).

Additional Security Measures

Even if you have verified the install source of an app this is just the initial stage of ensuring that only genuine and authorized versions are installed, developers still need to undertake other steps to ensure that their apps are safe. Here are some effective strategies and tools that developers can leverage to enhance security.

Code Obfuscation

Code obfuscation remains one of the easiest ways by which one can protect his or her application. Consumer objectives can be achieved using tools such as ProGuard for Android or LLVM Obfuscator for iOS because such tools distort code within the app, making it impossible for an attacker to understand what the app does. While renaming classes, methods, and variables, the work of an attacker significantly becomes more complex, depriving him even an attempt to begin to decompile and adjust the internal functioning of the application.

Another interesting project worth checking out is, that’s based on

dProtect an Android bytecode obfuscator based on Proguard O-MVLL is an obfuscator based on LLVM that uses the new LLVM pass manager, -fpass-plugin to perform native code obfuscation

Runtime Protection and Jailbreak/Root Detection

One must recognize when an app is running in an environment such as a jailbroken iPhone or iPad or a rooted Android device. These devices usually eliminate crucial security components, thus rendering them prone to hacking. There is always the possibility of root and jailbreak detection, so existing applications cannot run within these breeches.

Integrating Security Tools: freeRASP by Talsec

freeRASP (Runtime Application Self-Protection) () refers to an all-inclusive security solution whereby your mobile application can be monitored in real-time. It goes beyond basic checks like jailbreak or root detection by offering a full suite of security features, including:

Integrity Check: Identifies the state or level of modification of the app in order to determine if it has been modified in anyway. Debugging Detection: Recognizes whether in a specific app it is currently being debugged, or, for instance, during reverse engineering. Repackaging Protection: They also shield users against other attackers altering and repackaging their applications. Anti-Hooking: Intercepts and protects against such tool as Frida from injecting their code into the app during its execution. With the help of freeRASP, developers can prevent complex threats, including tampering, reverse engineering, and runtime manipulation. The application is free of charge and comes with powerful addressing security options compared to other powerful addressing security options that can easily be incorporated into existing mobile applications.

Conclusion

It is, therefore, important to consider multiple levels of security when developing applications for the current mobile environment. Verifying install sources is a good start, but by using tools such as freeRASP, runtime protections, and server-side checks, developers can offer a much safer environment for the applications. This shields the users from such applications and possible data leakage and your brand and business from the possible repercussions of a malicious app.

Highly recognized freeRASP SDK providing app protection and threat monitoring for mobile devices arrived in the Cordova ecosystem! This article will help you understand runtime application self-protection, explore freeRASP capabilities, and shield your app against threats!

The popularity of the hybrid app development

The popularity of hybrid platforms continues to grow, and companies have adopted them widely. They allow developers the possibility of writing the code once and reusing it on both Android and iOS native platforms. Often, the development of such apps costs less time and resources. Nowadays, there are many popular hybrid platforms (e.g., Flutter, React Native, Ionic, Cordova, or Xamarin).

Hybrid app security and freeRASP

Cross-platform development frameworks, in general, suffer when native platform-specific problems need to be solved and security has to be handled. In addition, hybrid platforms can introduce more specific issues. Sacrificing security to be able to do cross-platform development is a no-go.

“What should the developers do?”

First of all, ensure that the applications follow the standards for mobile app security () for the native parts. Besides security requirements for the architecture, data storage, or network communication, the application should be secured with advanced security solutions such as runtime application self-protection (RASP) to protect against tampering, distribution via an unofficial way or the app being run in a compromised environment.

“But developing such solutions is quite expensive, right?”

Right, it is pretty expensive to develop it in-house. Luckily, there are companies which can handle the problem for you. Moreover, there are !

“What does freeRASP have to do with all of this?”

In the past, we have observed a strong growth in the popularity of Flutter and chose it as our first contact with cross-platform development. We apps and developed a , which has been a great success and the developers’ feedback vastly improved our product.

Since releasing a freeRASP for Flutter, there have been a number of developers asking whether we can support other platforms. While some of them have successfully integrated the native versions with some of the frameworks, there were problems using it with the Cordova framework. We decided to take a closer look and develop an easy-to-integrate plugin to make Cordova developers’ lives easier. And that’s how was born!

freeRASP for Cordova

freeRASP for Cordova is a mobile in-app protection and security monitoring plugin. It aims to cover the main aspects of RASP (Runtime App Self Protection) and application shielding.

It is designed to combat:

• Reverse engineering attempts (debugging, running in emulators, hooking)

• Re-publishing or tampering with the apps

• Running an application in a compromised OS environment (root/jailbreak)

• Malware, fraudsters, and cybercriminal activities

“How can I use it?”

It is as easy as doing a minor prerequisite and adding a plugin to the application. Then you rely on freeRASP to protect your app. You can handle any threat that will be detected (e.g. attached debugger to the app) on your own, for example, by killing the application.

As Talsec uses Kotlin and Swift for the implementation of the native side, there is a minor prerequisite which must be done before adding the plugin.

• Kotlin must be enabled, and the version must be set up in the config.xml file

• A swift support plugin must be added

After that, you can easily add the plugin to your application. After initial importing, you set up an initial configuration (package name, signing certificate hash, bundleId, teamId) to have freeRASP detect some of the threats correctly. You also need to provide a mail address to which will be sent.

Next, you define a threat listener function, in which you can handle the detected threats as you wish, for example, killing the application, notifying the user that a threat has been detected or just ignoring the threat. The threat listener:

freeRASP can be started after the Cordova initialization is completed. The initialization should be done inside the onDeviceReady function in index.js:

As the last step, you need to differentiate the dev and release versions of the library. The dev version is designed not to complicate the development process of the application (e.g. if you would implement killing of the application on the debugger callback). It disables some of the detections. On Android, it is handled automatically, whereas, on iOS, the step is a matter of adding a pre-built script into the run phases and embedding a symlink to the correct framework. Do not worry, it is quite easy ;)

How does it work under the hood?

freeRASP for Cordova is composed of freeRASP and counterparts.

Android

It contains a Gradle file, which contains the dependency for the Android freeRASP repository.

It also contains a TalsecPlugin.kt file, which provides the API to the freeRASP for communication with Cordova. It parses the configuration input given from index.js, registers the threat listener and starts the detection. If any threat occurs, it sends a message back to the index.js to the threatListener function. If any error or incorrect input occurs, it sends back an error message to the index.js.

iOS

It contains built binaries (both Debug and Release versions) of the freeRASP iOS library.

It also contains a bridging header for the Objective-C -> Swift bridge. The TalsecPlugin.swift file is similar to the Android’s TalsecPlugin.kt. Moreover, it uses a static object to preserve the state of the delegate given by Cordova for sending messages.

The iOS version also contains an after_plugin_add script to create a symlink to one of the built binaries (default is Debug) at the correct place. You guessed it right! This is the symlink used in the integration step, which is recreated after changing the Debug <-> Release build of the application.

Cordova

It contains a simple Promise, which passes the configuration from index.js to respective native implementations and returns back a success or error message.

Customisation, demo application and distribution

The plugin is designed to be used easily without the modification of the native parts. The reactions to threats can be modified in the index.js easily in the threat listener, and configuration is also passed from index.js.

However, you can set up the configuration, threat listener and initialisation also from the native parts and not interact with index.js at all, for example, if you would prefer using a “native way” of killing the application.

We have prepared a which integrates the plugin. It shows the state of the threats with simple visualisation: green: OK, red: NOK (a threat happened). The threat listener is implemented in index.js. If a threat is detected, it changes the backgroundColor of the element corresponding to a given threat to red colour.

Except for the , the plugin is also distributed via NPMJS:

Next steps

Security is essential, even though we tend to forget about it when it comes to hybrid platform applications. However, the freeRASP solution is not bulletproof.

In the freeRASP, it’s up to the developer to implement the reaction for the individual threats (e.g., root, debug, simulator, device binding), and because each developer can implement their own logic for detected threats (e.g., step-up authentication, business logic flow modification, killing the application), we need to provide API for the callback, so they can implement their own logic.

The javascript part of the application tends to be more vulnerable to manipulation/injection/tampering, and it would be better to start Talsec in the native part of the code. However, even the reaction on the native side can be easily modified or stripped by an experienced attacker.

We have multiple solutions (pre-configured custom build SDK, in-SDK reactions and killing mechanism, AppiCrypt) in our business solution, preventing precisely those types of attacks. To check out what is the difference between freeRASP and Business RASP+, see this page:

written by Matúš Šikyňa, Developer at Talsec

| | Read also |

Flutter has gained significant traction within FinTech, underscoring the crucial need for robust security measures. The platform’s popularity attracts attention from both app developers and cybercriminals. Flutter’s strong security posture, evidenced by fewer reported vulnerabilities and CVEs, makes it a solid choice for developing sensitive apps.

Flutter Built-in Security

Flutter is more resilient to decompilation than native apps. Its binary packaging offers better protection of code and hardcoded data, although the number of Flutter-specific reverse engineering tools is increasing rapidly, continually broadening the potential threat landscape (e.g., reFlutter, flutter-spy, blutter).

Common Vulnerabilities

Despite its advantages, Flutter apps are not immune to common vulnerabilities:

• Privileged Access Issues: Rooting and jailbreak concerns remain prevalent.

• Dynamic Attacks: Techniques such as hooking frameworks (e.g., Frida, Xposed) pose significant risks.

• App Cloning and Repackaging: Unauthorized duplication of apps is a persistent threat.

• TLS Pinning Bypass: Critical for defending against man-in-the-middle attacks.

• Session Hijacking and App Impersonation: Compromise user sessions and mimic legitimate apps.

• Malware: Leveraging app permissions (accessibility misuse, screen sharing, keyloggers, SMS OTP interceptors, etc.) for malicious activities.

Developer Awareness

Flutter developers must stay informed about security threats and evolving attack vectors across all supported platforms. This demands n-depth expertise and continuous learning, making app security a specialized area within software development.

Essential Security Hardening Measures

In the financial sector, regulators mandate the adoption of a range of security techniques, which can be categorized into three primary areas:

1. Runtime Application Self-Protection (RASP): Implement client-side measures to monitor and react to integrity and environment compromises.

2. API Protection: Safeguard against app impersonation using tools like Firebase App Check, attestation services, or API protection SDKs such as AppiCrypt.

3. Anti-Malware: Detects and mitigates risks posed by malicious apps on client devices.

Basic controls can often be implemented using freemium or community-supported tools. However, advanced enterprise-grade protection typically requires custom development or commercial security solutions.

Advances in Mobile Security Tools for Flutter

The proliferation of app-to-API end-to-end protection solutions (such as App Attestation, AppiCrypt, and AppCheck) is effectively countering the escalating threats from mobileoriented API abuse. These threats encompass App impersonation techniques such as botnets, password enumeration scripts, data scraping, promotional abuse, fake registrations, and phishing campaigns.

However, due to Flutter’s compiled nature, Static Application Security Testing (SAST) tools have not yet reached the level of sophistication seen in native applications. This presents a challenge in maintaining security parity with other platforms. Conversely, the advent of Software Bill of Materials (SBOM) analysis has simplified the examination of third-party dependencies, thus enhancing the thoroughness and effectiveness of security assessments.

Overall, while there are still areas needing improvement, the strides made in mobile security tools for Flutter demonstrate significant potential in safeguarding against complex and evolving threats.

Budget Considerations

App issuers should allocate 20% to 25% of development and maintenance budgets to security features. It’s crucial to recognize that due to the dynamic nature of attack vectors and operating system updates, ongoing maintenance costs for security features may be significantly higher than initially estimated.

Conclusion

Proactive security measures are not just beneficial but essential for app protection in today’s dynamic threat environment. Ensuring comprehensive security requires both strategic investment and dedicated expertise.

Written by Sergiy Yakymchuk (CEO at Talsec)

Let's dive into Akshit Singh's insights on how Frida works, the risks it poses to mobile apps, and why effective Frida detection is crucial. This article highlights Talsec’s freeRASP as the #1 RASP solution by popularity, showcasing its advanced Frida-server detection and other security features that provide a robust defense against app tampering, ensuring real-time protection and resilience.

Introduction

In today's mobile security landscape, protecting applications is a constant cat-and-mouse game between defenders and attackers. Dynamic instrumentation tools like Frida have become a favourite weapon for adversaries, allowing them to hook into application processes, bypass security mechanisms, extract sensitive data, and manipulate runtime behavior . In response, developers implement Frida detection techniques like checking for suspicious libraries, unusual system calls, process injections, etc. However both sides continuously adapt to the methods of the other side and just start thinking about how to outsmart the other. This makes engineers dig deep to depths of working of these tools and overtake the other side.

Well, today we are going to dig deep inside such a tool that can tamper with any app's working and manipulate its code, giving the attackers an unfair advantage.

What is Frida?

Frida is a powerful dynamic instrumentation toolkit designed for cross-platform applications, supporting Android, iOS, Windows, Linux, and macOS. It allows developers, security researchers, and reverse engineers to analyze, modify, and manipulate applications at runtime. By injecting scripts into a running process, Frida enables real-time introspection of an application's internal functions, memory structures, and API calls. This makes it a valuable tool for debugging, security testing, and reverse engineering. With Frida, one can hook into functions, alter their behavior, or even bypass security mechanisms —all without modifying the application's original binary.

Here is a small script to demonstrate how frida works and hooks the application:

Java.perform(function() {
var TargetClass = Java.use('com.example.app.TargetClass');

    TargetClass.targetMethod.implementation = function(arg1, arg2) {
        console.log("[*] targetMethod called with args: " + arg1 + ", " + arg2);
        var result = this.targetMethod(arg1, arg2);
        console.log("[*] targetMethod returned: " + result);
        return result;
    };
});

This script hooks the targetMethod of the class TargetClass and prints out its arguments and the result whenever it is called inside the application with package name - com.example.app .

Using Frida

There are two ways to use Frida on an application on a device:

• Patching an application to use Frida:

  • Decompile the application using apktool .

  • The target application has to be patched by moving the right version of frida-gadget inside the application as libfrida-gadget.so .

  • The decompiled app has to be aligned and signed again correctly using zipalign and jarsigner .

  • Now whenever the application runs it will be able to connect to the frida client running on a remote system.

• Using frida-server

  • It is important to remember that this method might appear easier and simpler than the patching method but it only works in rooted devices.

  • Move the right version of frida-server into the device and execute the binary.

  • Connect to the frida-server through your local system using the frida command.

And voila you are ready to change the app without changing it :D

There are plenty of other tools that can be used for dynamic instrumentation of apps just like frida and they are too able to inject scripts into them during runtime. But what makes Frida unique is its integration with popular programming languages like Python and JavaScript, enabling powerful and flexible instrumentation:

Here are some examples of using frida in python:

• This is the script that helps us to hook a function target_function() inside the native library libnative-lib.so embedded inside the application com.target.app :

import frida

# Payload
jscode = """
Interceptor.attach(Module.findExportByName("libnative-lib.so", "target_function"), {
    onEnter: function(args) {
        console.log("[*] Hooked target_function!");
        console.log("Arg[0]: " + args[0].toInt32());
        console.log("Arg[1]: " + args[1].readUtf8String());
        
        args[0] = ptr(1337);  // Change integer argument
        args[1].writeUtf8String("Hacked!");  // Change string argument
    },
    onLeave: function(retval) {
        console.log("Original return value: " + retval.toInt32());
        retval.replace(42); //Changing the return value
    }
});
"""
device = frida.get_usb_device()
session = device.attach("com.target.app") 
script = session.create_script(jscode)
script.load()

• This is similar to hooking a java method inside the application during runtime but instead of attaching through the classes we use interceptors to be able to load the native non-static methods first and then hook them.

• The similar code can be written in js:

const frida = require('frida');

async function main() {
    const device = await frida.getUsbDevice();
    const session = await device.attach("com.target.app");
    const scriptCode = `
        Interceptor.attach(Module.findExportByName("libnative-lib.so", "target_function"), {
            onEnter: function(args) {
                console.log("[*] Hooked function called!");
                console.log("Arg[0]: " + args[0].toInt32());
            }
        });
    `;

    const script = await session.createScript(scriptCode);
    script.message.connect(message => console.log(message));
    await script.load();

    console.log("[+] Hook installed!");
}
main();

These dependencies of frida in languages like Python and JS make frida more powerful and efficient and even more compatible to be integrated with other advanced tools.

The power of Frida

Frida can be used to tamper with various functions inside the app in runtime also allowing us to bypass many checks and protections like Root checks, SSL pinning and Emulator checks.

Bypassing Root checks

Below is an example of one of the script that can be used to bypass root check in a library named JailMonkey that intends to detect rooted devices:

Java.perform(() => {
    try {
        const klass = Java.use("com.gantix.JailMonkey.JailMonkeyModule");
        const hashmap_klass = Java.use("java.util.HashMap");
        const false_obj = Java.use("java.lang.Boolean").FALSE.value;

        klass.getConstants.implementation = function () {
            var h = hashmap_klass.$new();
            h.put("isJailBroken", false_obj);
            h.put("hookDetected", false_obj);
            h.put("canMockLocation", false_obj);
            h.put("isOnExternalStorage", false_obj);
            h.put("AdbEnabled", false_obj);
            return h;
        };
    } catch (error) {
        console.error("An error occurred:", error);
    }
});

The above script hooks into the main class of the module and changes the implementation of the getConstants function to acquire the values of all the final detection variables as false. So it actually does not matter whether it detects root or not. It will show it as false as its final variables values are changed.

Bypassing emulator checks

https://codeshare.frida.re/@fdciabdul/frida-multiple-bypass

The above script has a function that is able to bypass emulator checks in various security modules by setting up fake device names, brand names, product names and other fake values inside the device properties to throw the detector off.

Bypassing SSL pinning:

https://codeshare.frida.re/@sowdust/universal-android-ssl-pinning-bypass-2

The above script is the smaller and more specific version of the SSL pinning bypass script that is effective in the Android Conscrypt security provider module. It hooks the TrustManagerImpl class and returns a null array instead of the array that the method should have returned to do SSL pinning encryption.

Developments in Frida

Frida was developed by Ole André V. Ravnås . Being the most used and famous tool in the field of mobile reverse engineering and security research, Frida has undergone many feature additions as well as upgrades that has improved the tool furthermore.

• frida-rust : https://github.com/frida/frida-rust

  • This is a prominent improvement by the frida community that has solved the problem of VM spawning overhead.

  • Whenever we try to load a script into the target application or try to inject some code using Frida then it has to first spawn a js v8 engine and then execute the script inside it. This creates a large overhead that makes script execution very slower and the execution of large scripts very longer and memory extensive.

  • frida-rust on the other hand does'nt have the problem of spawning any VM engine as it maintains a persistent session with the application and can communicate with the C APIs directly, increasing its speed many times compared to before.

• Updates in frida-server

  • There are many scripts that are out there claiming to be able to detect frida-server running on the device by communicating with it using its protocol.

  • Maybe this is the reason that frida-server implementation was updated. It can now run on any port instead of a default port and its method of communication was changed making frida-server undetectable again. But is it really undetectable??

Frida CodeShare

https://codeshare.frida.re

Frida CodeShare is a community-driven platform where security researchers and developers share ready-to-use Frida scripts for various purposes, including reverse engineering, penetration testing, and debugging. The platform hosts a vast collection of scripts that help automate tasks such as bypassing root detection, decrypting network traffic, intercepting function calls, and modifying app behavior at runtime.

Scripts like Universal Android SSL pinning bypass, aesinfo and ObjC method observer (objective-C method hooking) are available on this site.

• The Universal Android SSL pinning bypass

https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida

This script automates the process of pushing the Burpsuite certificate as a custom certificate on the device to be able to proxy the requests made by the target application.

It does this by making a custom Keystore and TrustManager so that the app does not verify the SSL certificate it is using.

• aesinfo

https://codeshare.frida.re/@dzonerzy/aesinfo

This script is able to detect the AES encryption in any application by hooking into the cryptographic classes of Java like: Cipher,SecretKeySpec,IvParameterSpec to gather the info regarding the Key, IV and the Ciphertext fed into the methods of these classes and then changes the implementation of the doFinal method that is responsible for the encryption/decryption of the ciphertext.

Tools based on Frida

Runtime Mobile Security tool

https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security

• It automatically detects the connected devices and the packages inside them helping the user to just interact with drop down menus and use default scripts to tamper with the apps.

• This is a web interface tool that is user-friendly and has a number of frida scripts that can be used by just a click.

• It makes filtering and scripting much easier as compared to using frida command line tool.

Medusa

https://github.com/medusajs/medusa

Medusa is an advanced Frida-based wrapper tool designed for dynamic instrumentation of mobile applications.

• It has stored database of useful frida scripts that can be executed just by executing a command.

  • It not only parses or enumerates the important files of an Android package but it also identify common attack vectors inside it.

  • Its Python-based design makes it more user-friendly and easy to work with.

Objection

https://github.com/sensepost/objection

• This is also a wrapper of frida tool that makes it easier to execute scripts like bypassing SSL pinning or anti-root checks and even makes it easier to patch the applications by embedding libfrida-gadget.so inside the app.

  • It is a command-line tool that works without root access or jailbreaking the target app's device, helping us to perform penetration testing and malware analysis.

• These are some general commands of using objection:

  • objection patchapk --source target.apk is to patch the target application to use frida in it.

  • android bypass root bypasses antiroot checks on the app.

  • android sslpinning disable bypasses ssl pinning on the device.

  • android sharedpreferences get dumps all the stored credentials in the target app.

freeRASP Protection

https://www.talsec.app/freerasp-in-app-protection-security-talsec

freeRASP is #1 RASP by popularity - free Runtime Application Self-Protection solution for all Android and iOS apps. Whether it is rooting, hooking, emulating, tampering or any other malicious practice inside the device that may harm the application, nothing can beat the RASP technology used by freeRASP.

Just try to integrate freeRASP into one of your application using https://docs.talsec.app/freerasp and use the methods like onRootDetected or onHookDetected to check your device in just a few moments.

Frida detection with freeRASP

Patching an application using Objection or frida-Gadget can be a complex process, as it requires resigning and correctly aligning the app.

On the other hand, running frida-server and interacting with the app through it is a much easier approach. This is why most users, including attackers, prefer using Frida-server on a rooted device to instrument applications.

Detecting frida-server is challenging because it allows communication on any port , and its recent updates have introduced new communication methods, making detection even more difficult.

However, frida-server isn't completely undetectable . Talsec's RASP (Runtime Application Self-Protection) technology is designed to spot it, no matter which port or communication method it uses. Also it doesn't just stop there—it also blocks attackers from using other tricks, like Objection patches, to manipulate the app.

This makes it a reliable defense against attackers using Frida, Objection, Medusa, and other hooking tools to compromise apps.

Conclusion

Frida is a powerful tool for dynamic instrumentation, allowing real-time analysis and modification of applications across multiple platforms. While invaluable for security researchers and developers, its capabilities can also be exploited by malicious actors to bypass restrictions, manipulate runtime behavior, and compromise app security. Without robust protection, applications remain vulnerable to these sophisticated attacks.

This is where Talsec's freeRASP becomes essential. With cutting-edge security features like Frida-server detection, Emulator detection, Root detection, and Developer Mode detection, freeRASP acts as a proactive defense layer, shielding applications from unauthorized tampering and advanced threats. By leveraging RASP (Runtime Application Self-Protection) technology, freeRASP ensures that your app remains secure, resilient, and protected in real time—making it a necessity, not an option.

Trusted by developers worldwide, freeRASP is the #1 RASP solution by popularity, setting the standard for in-app protection.

Introduction

In the area of mobile application security, the development of new techniques is a constant game of cat and mouse. Developers work tirelessly to implement new methods of identifying and mitigating the risks associated with rooted devices, while attackers continually develop more sophisticated tools to bypass these safeguards. In this article, we will explore what rooting is, outline basic root detection techniques, and show you how to effectively test your implementation.

Rooting: What It Is And How It Affects Mobile Security

Rooting is the process of gaining privileged control over an Android device, allowing users to bypass system restrictions and obtain full administrative privileges. This process enables the installation of specialized apps, modification of system settings, or running commands that are otherwise restricted in the default user environment.

On the one hand, these capabilities enhance control over the device, providing users with greater flexibility and customization options. On the other hand, rooting introduces significant security risks, as it can expose the system to unauthorized access, malicious activity, or potential vulnerabilities.

In the context of root detection testing, rooting presents a serious challenge as it disables or bypasses many of the operating system’s built-in mechanisms. Therefore, detecting signs of rooting is crucial for maintaining device integrity and preventing vulnerabilities that could be exploited by attackers.

Shut the Mouse Hole: Stop Attackers with Root Detection

As outlined in the previous section, Android devices with root access are significantly more exposed to mobile malware, privilege escalation exploits, and persistent system compromise due to the lack of enforced security boundaries. These rooted environments often become attractive entry points for attackers, allowing them to gain unauthorized access not only to sensitive user data but also for other components of the mobile ecosystem.

Given these significant risks, it is essential to implement reliable root access detection that can effectively identify compromised devices before serious security breaches occur. Root detection is the first line of defense against these threats and should be an integral part of the security architecture of any application.

However, root detection is not a simple task. As rooting techniques evolve, so do the methods for bypassing detection. Root bypass techniques have become increasingly sophisticated, making it necessary to implement multi-layered root detection mechanisms. Relying on a single method of detection is not sufficient, as attackers often find ways to circumvent basic checks.

Common Root Detection Techniques

There are several common techniques used to identify rooted devices, each targeting a specific characteristic or modification that typically occurs when a device is compromised. By combining these techniques, it is possible to create a more robust method for detecting rooted devices, helping to reduce the security risks posed by compromised devices.

File-based detection

Rooting often leaves behind characteristic traces in the file system, and by probing for these artifacts, it’s possible to identify compromised devices. These artifacts may include binaries, configuration files, or directories commonly associated with rooting tools.

One of the most recognizable indicators is the presence of the su binary, which is typically used to grant superuser privileges to applications. This binary may be located in several paths depending on the rooting method or tool used, such as:

• /system/bin/su

• /system/xbin/su

• /sbin/su

• /data/local/su

• /data/local/xbin/su

Some devices may also contain utility binaries like busybox, which provides a suite of Unix tools often included in rooted environments:

• /system/xbin/busybox

• /system/bin/busybox

Root management apps, such as SuperSU or Magisk, may install APKs and daemon scripts to maintain root access. These files can also be detected at known locations:

• /system/app/Superuser.apk

• /system/etc/init.d/99SuperSUDaemon

• /system/xbin/daemonsu

• /dev/com.koushikdutta.superuser.daemon/

Implementing a scan for these files can serve as a basic yet effective first layer of root detection.

Process-based detection

Some root detection techniques focus on monitoring and interacting with processes that are commonly associated with root access. Root management tools typically rely on binaries like su to elevate privileges, or sh to execute scripts with root permissions. By attempting to invoke these processes at runtime, it’s possible to detect their presence and functionality, even if their files are hidden or obfuscated.

Package-based detection

Rooted devices often rely on specialized apps to manage superuser access and maintain elevated privileges. These root management tools, such as Magisk, SuperSU, or older solutions like Superuser.

Android provides APIs to query all installed packages using the PackageManager. By comparing package names against a known list of popular root-related apps, it’s possible to detect the presence of these tools on the device.

Some commonly used package names include:

• eu.chainfire.supersu

• com.noshufou.android.su

• com.koushikdutta.superuser

• com.zachspong.temprootremovejb

• com.ramdroid.appquarantine

• com.topjohnwu.magisk

System property-based detection

Custom or tampered Android builds often leave identifiable traces in system properties. These builds may originate from user-modified ROMs or developer-compiled firmware images and frequently bypass standard security mechanisms. Detecting such modifications can help determine if a device is running a non-standard and potentially insecure, operating system.

One common technique involves inspecting the Build.TAGS property. Another indicator is the absence of Google’s Over-The-Air (OTA) update certificates.

Static Analysis for Root Traces

One approach to determine whether an application includes root detection mechanisms is to perform a static analysis. This technique enables the examination of the application’s code without requiring execution. It also helps identify embedded root detection logic, such as techniques outlined in the section Common Root Detection Techniques.

This method is particularly useful during security assessments, where it’s important to understand how thoroughly an application protects itself against rooted environments. The following steps outline how to perform static analysis to detect common root detection implementations:

1. Check for root detection indicators

• Apps may check for the presence of files commonly associated with rooted devices (e.g., /system/xbin/su, /data/data/com.superuser.android.id) or for root management apps (e.g., SuperSU, Magisk).

• Run a static analysis tool such as MobSF or Apktool on the app binary to look for common root detection checks.

1. Non-standard system behavior detection

• Check if the app monitors processes that shouldn't normally be running, such as su or sh, which are typically associated with root management tools.

• Reviewing the app's smali or assembler code can reveal whether the app checks for or interacts with such processes.

1. System properties modification detection

• Apps may monitor system properties (e.g., ro.debuggable, ro.secure) for changes, adding another layer to the root detection process.

1. Critical system directories modification detection

• Check if the app attempts to modify files or settings in critical system directories, such as /data or /system, which should remain immutable on unrooted devices.

As a result of this analysis, one should be able to observe whether the application contains any of these typical root detection patterns. If such mechanisms are present and clearly target known indicators of root access, it can be concluded that the app implements root detection properly.

It’s important to note that static analysis has limitations and may not reveal all root detection logic, especially if it is obfuscated or implemented using unconventional techniques.

Dynamic Detection of Root Access

Another approach to determine whether an application includes root detection mechanisms is to perform dynamic analysis. This technique involves observing the application’s behaviour at runtime while it operates on a potentially rooted device. It allows testers to understand how the application interacts with the system and whether it performs any real-time checks for root-related indicators.

This method is particularly useful during runtime security assessments, where the goal is to verify if the application can detect and respond to signs of root access under realistic conditions. The following steps outline how to perform dynamic analysis to detect runtime root detection behaviour:

1. Monitor Application Behaviour

• Use tools like strace or similar utilities to trace how the app checks for root access. Look for interactions with the system, such as attempts to open su, check running processes, or read root-specific files. This analysis helps uncover how the app performs root detection and may reveal potential weaknesses.

1. Bypassing Root Detection Mechanisms

• Run a dynamic analysis tool such as Objection to attempt automated root detection bypass. Use commands to manipulate root checks and observe whether the app still correctly detects root access or if its security mechanisms can be bypassed.

As a result of this analysis, one should be able to determine whether the application performs root detection at runtime and how resilient it is to bypass techniques. If the application actively checks for root indicators and responds appropriately, even under attempts to tamper with its logic, it can be considered to have a well-implemented runtime root detection mechanism. However, if no signs of root detection are observed, or if the application’s checks are easily bypassed, it suggests that the implementation may be incomplete or ineffective.

A Hands-On Demo

This section demonstrates how root detection logic present in an Android application can be verified via static analysis using Semgrep. The test is performed on a class containing basic root detection techniques.

In real-world scenarios, security engineers often work with Android applications where the original source code is not available. However, static analysis can still be performed by reconstructing the code using reverse engineering tools like jadx or apktool. These tools allow analysts to obtain Java or Smali code from an APK file.

For the purposes of this hands-on example, we’ll assume the source code is already available (or has been successfully reconstructed) and focus on the static analysis part.

Let’s take a look at a simple class that contains basic root detection logic:

Before we begin, make sure you have Semgrep installed. You can install it using:

pip install semgrep

or , if you’re using macOS:

brew install semgrep

If you’re working with code reconstructed from APK (e.g., RootDetection_reversed.java obtained via jadx), you can run Semgrep on the reversed Java file instead of the original Kotlin source.

Here’s an example of a Semgrep rule that identifies common patterns used in root checks:

You can run Semgrep with this rule:

semgrep -c root-detection.yml RootDetection_reversed.java

When executed, Semgrep will provide results similar to this:

Conclusion

To conclude, implementing effective root detection techniques is crucial for maintaining mobile security and protecting users from potential threats posed by compromised devices. As rooting methods evolve, developers must employ multi-layered detection strategies to stay ahead of attackers who seek to bypass security measures. Combining file-based, process-based, package-based, system property-based, and dynamic detection techniques can create a robust defense against rooting-related risks.

For industry-leading root detection, explore and , which provide advanced security features to safeguard mobile applications from threats.

For additional terminology and security insights about rooting, jailbreaking and hooking, visit the .

John is the creator of a popular app BetterVision, for the blind and visually impaired. There is a good reason for the over 100K installations John’s creation has achieved. BetterVision can turn a phone’s camera into a powerful assistant easing a daily routine for disabled users worldwide. With success, however, soon came difficulties. John’s app suffered a cloning attack, and his In-App purchases got stolen.

At , we specialize in in-app security. We build RASP (Runtime Application Self-Protection) tools to protect apps against hacking — which, unfortunately, is growing in popularity. In this article, we interviewed Business Owner and senior Android developer John Smith whose app BetterVision got hacked. The interviewee has requested anonymity. We deliberately changed his name to “John Smith” and his brand name to “BetterVision”.

1. Do not release without protections in-place

2. Perform sensitive operations server-side whenever possible

3. Prevent reverse-engineering

4. Monitor user groups and APK mirroring sites to detect malicious clones

5. Warn users against using fake clones

My five tips are:

Using time-saving drop-in solutions like Talsec and not messing up security basics pays off. Otherwise, you have to accept losing some percentage of purchases due to hacked clones and take it into account — also financially. I remember an Android security survey that suggested that most apps lack even the most basic obfuscation.

It can sound silly, but the thing is that when you have to choose between delivering functionality and improving security, you should select the first and reckon with the risk. I have heard of companies focused on security so much that they could not develop the functionality needed for business.

To wrap it, what would you recommend to other developers? What five tips would you give to yourself looking back?

My Firebase catches something already, but I would appreciate Talsec’s monitoring as it is more advanced. It would be great to see the collected statistics.

What do you think about Talsec’s Security Monitoring service and threat visualization dashboard?

I had the warning screen displayed in hacked clones that exited the application only to realize users of clones began complaining and giving bad reviews. So, I later reverted it as it wasn’t worth it. However, I believe it’s good to have hidden logging, which can’t be disabled by a hacker easily. That’s what I finally ended up with. The hacked clones still report to my monitoring service as hackers apparently don’t care about that.

Did you apply any mechanism to warn users against using a hacked clone? Did you forcibly terminate the app?

Yes, it would be necessary to add a lot of arbitrary fake reflection calls so that the important ones will be hidden between them. These could also serve as a kind of honey-pot. I would appreciate a plugin that would perform this transformation automatically.

Agreed. The reflection is easily spotted in the code. Do you have any solution in mind?

Obfuscation is of great importance in hiding inner business logic. You can combine obfuscation with the reflection API to hide system calls. Hackers often head for them as these are usually placed close to sensitive operations. With reflection, you turn these calls into strings that are consequently obfuscated. Hackers will not be able to locate them using static analysis. Unfortunately, hackers are aware of this technique, and if you use it only on a few occasions, they can easily guess its meaning.

Do you have some specific protection tips?

It’s a cat-and-mouse game. Hackers always find your protections, so you are forced to evolve your knowledge and update your app. For example, I spread those checks into many places in the app, so they are more likely to forget something untouched.

As I said, the first choice for me was the PiracyChecker as Talsec was not a thing back then. I have learned a lot from experienced Android developers on advanced forums. Things like decentralizing security checks, hiding secrets in a native code, rooting and tampering protection.

What countermeasures did you apply? Where did you learn about possible techniques? Did you get stuck?

The common issue of established RASP libraries is that bypass for the majority of them is already publicly available. I feel the Talsec has a slight edge in this manner, at least for now.

I didn’t have the necessary knowledge at that time. I have added the popular PiracyChecker library (note: Talsec didn’t exist at that time), but hackers still could circumvent it. As I have learned more about protecting Android apps, I have added many protections myself later. Alas, the iOS version of my app still needs to enhance the protection, which falls behind the Android one.

Did you consider products like Talsec RASP or freeRASP?

RASP made by does come as a complete toolbox of security enhancements. Reverse engineering protection can protect your app with many invisible traps that give hackers a hard time. Malware detection, tapjacking prevention, E2E Encryption, mutual TLS setup, online client integrity checks (Attestation), On-line Risk Scoring, API protection, Strong Customer Authentication, embeddable security dashboard, and much more are covered in our enterprise security. for a private meeting!

It’s common to use native code for hiding valuable parts of an application as its decompilation of binary is a much more demanding task. I hide logging and security checks in various places. There’s a high probability a hacker will miss some parts, and you will be able to track malicious activities. A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.

In theory, the best protection should be layered and spread all around the app. What layers and tricks do you recommend?

Not necessarily; you can change a Proguard’s dictionary. The unfortunate side effect is that Google Play’s review process becomes more time-consuming. The regular one-day review process takes up to 10 days if you change the dictionary, as Google Play scanning is more thorough in such cases. If I need to push hotfixes quickly, I stick with the same dictionary as my previous build.

Is obfuscation the same for all builds?

Finally, strip out any debugging lines. Popular library has one crucial weakness regarding that. Although your Timber tree won’t log in the production build, your debugging code is still in place. A hacker can just turn debugging on for the app, and the logging will be visible again. Creating your logging scheme is also beneficial. Debug and verbose logs are dropped in production, informational logs are written into the local log, and finally, warnings and more severe events are logged to Firebase.

I highly recommend the string obfuscator . It only takes a single annotation @Obfuscate above the class, and you are good to go.

I remember having issues with code obfuscation. In some cases, older versions of Proguard (code obfuscator) obfuscated method parameters but created annotations with original names above them. I haven’t noticed such issues with R8, which ships with Android Studio nowadays.

Could you share any technical insights?

“A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.”

The Mitigation: How to build a wall

For example, there was a guy from India who even added his own payment system and he charged half the price of the original. He even went to great lengths in protection and used a DexGuard to protect it. We got a hold of his WhatsApp and phone number. We unsuccessfully tried to sue him, but he was out of our legal reach.

Although they don’t usually want to talk to us, there was a white-hat guy who appreciated our work and gave us a few hints as to what we might do better. Apart from that, they only care about adding their own ads and other nasty things.

Did you contact hackers directly? What was their motivation?

Hackers are still active and create new clones. They can often release a clone just a few days after our updates. Unfortunately, we don’t have any way to disable those cracked versions.

Do users still use the hacked version, or did you disable it somehow?

There were also videos on YouTube that contained links to clones. Reporting to Google (Content ID claim) worked well. Google took down the incriminated video within a day. Reporting links to Google Drive with hacked versions was also successful.

Yes. The community was very supportive. Community members send us links to hacked versions. Fans are also sending in recordings of communications with the attackers. We’re tracking it, and we have a whole database full of it.

It seems you like to accommodate the community.

A common tool used for hacking is the app called Lucky Patcher. So I added a detection which caused the app to stop if the user had it installed. It turned out that many people have Lucky Patcher installed, and after an avalanche of complaints by angry users, I reverted this detection.

The first versions contained only basic functionality. In retrospect, I have to say that launching the app without protection was a big mistake. It was only in response to the hacking that the first protection was added, which was a signature check. This stopped cloners and amateurs from using automated repackaging tools for a while. A little later, I also added the string obfuscation.

Could you tell us more about your fight with hackers?

If you find out that you have four times more users on Google Play than on the AppStore and your profits are four times less, something is fishy. Sideloading of cracked apps, simplicity of rooting, and APK modifications are significant drawbacks of the Android platform. iOS protects both users and developers better against such malicious activities. A profitability perspective is much better as users are better used to paying for apps.

Although we haven’t done the math, the financial losses are significant. Because hackers may have disabled the in-app tracking, the actual number of installed cracked clones cannot be determined. Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.

It was a terrible feeling considering I used to develop it in my spare time for almost no profit initially. The application fee was only enough to cover the costs. Later, we invested a fair amount of money for performant Amazon servers used for machine learning.

What were the consequences and the financial impacts of this hacking?

I think that some users were resourceful and hacked the app themselves by removing Google Play Billing Library in-app purchases. As long as they were doing it for their own use, I didn’t even mind.

Users themselves reported finding illegal copies, which started popping up on Telegram and WhatsApp groups. Anyone could grab those APKs and install them. Paid users were upset.

When was the first time you noticed something was not alright?

“Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.”

The Hack: BetterVision got caught naked

We immediately had positive feedback from users after the release. We were amazed that users even switched from a competing app to us. We made it into newspapers and TV in the homeland thanks to great help from local organizations. We recruited ambassadors from the ranks of users in foreign regions.

Getting early-stage traction was surprisingly easy thanks to the strong disabled communities in which our app quickly gained attention. Users recommended the app to each other, especially coaches for disabled people, who took the initiative and spread the word among clients.

How did you acquire your first users?

Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.

Finally, ease of use and accessibility required offline operation because users don’t always and everywhere have a good network connection. One of the cornerstones and our know-how are computer vision models using machine learning. These have to be a static part of the application since users might have issues if they were hosted on the cloud. It is one of the misconceptions many developers have. They believe they can secure everything by putting it server-side. Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.

The idea wasn’t novel as there already were similar solutions by renowned companies. We kicked off with only basic features at the beginning focusing on accessibility. Not only we thoroughly tested eyes-free usage in the app but also accompanying web and brochures. I regularly tested it myself, covering my eyes with my hand.

The idea came from a disabled friend. Together we realized this is a widespread issue which many disabled people face. Similar solutions already existed but were insufficient (school projects) or with poor accessibility optimizations.

BetterVision is a unique app in its category, right? What inspired you to make it? Could you tell us more about its early development?

The idea came from a disabled friend. Together we realized this is a widespread issue which many disabled people face. Similar solutions already existed but were insufficient (school projects) or with poor accessibility optimizations.

The idea wasn’t novel as there already were similar solutions by renowned companies. We kicked off with only basic features at the beginning focusing on accessibility. Not only we thoroughly tested eyes-free usage in the app but also accompanying web and brochures. I regularly tested it myself, covering my eyes with my hand.

Finally, ease of use and accessibility required offline operation because users don’t always and everywhere have a good network connection. One of the cornerstones and our know-how are computer vision models using machine learning. These have to be a static part of the application since users might have issues if they were hosted on the cloud. It is one of the misconceptions many developers have. They believe they can secure everything by putting it server-side. Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.

Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.

How did you acquire your first users?

Getting early-stage traction was surprisingly easy thanks to the strong disabled communities in which our app quickly gained attention. Users recommended the app to each other, especially coaches for disabled people, who took the initiative and spread the word among clients.

We immediately had positive feedback from users after the release. We were amazed that users even switched from a competing app to us. We made it into newspapers and TV in the homeland thanks to great help from local organizations. We recruited ambassadors from the ranks of users in foreign regions.

The Hack: BetterVision got caught naked

“Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.”

When was the first time you noticed something was not alright?

Users themselves reported finding illegal copies, which started popping up on Telegram and WhatsApp groups. Anyone could grab those APKs and install them. Paid users were upset.

I think that some users were resourceful and hacked the app themselves by removing Google Play Billing Library in-app purchases. As long as they were doing it for their own use, I didn’t even mind.

What were the consequences and the financial impacts of this hacking?

It was a terrible feeling considering I used to develop it in my spare time for almost no profit initially. The application fee was only enough to cover the costs. Later, we invested a fair amount of money for performant Amazon servers used for machine learning.

Although we haven’t done the math, the financial losses are significant. Because hackers may have disabled the in-app tracking, the actual number of installed cracked clones cannot be determined. Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.

If you find out that you have four times more users on Google Play than on the AppStore and your profits are four times less, something is fishy. Sideloading of cracked apps, simplicity of rooting, and APK modifications are significant drawbacks of the Android platform. iOS protects both users and developers better against such malicious activities. A profitability perspective is much better as users are better used to paying for apps.

Could you tell us more about your fight with hackers?

The first versions contained only basic functionality. In retrospect, I have to say that launching the app without protection was a big mistake. It was only in response to the hacking that the first protection was added, which was a signature check. This stopped cloners and amateurs from using automated repackaging tools for a while. A little later, I also added the string obfuscation.

A common tool used for hacking is the app called Lucky Patcher. So I added a detection which caused the app to stop if the user had it installed. It turned out that many people have Lucky Patcher installed, and after an avalanche of complaints by angry users, I reverted this detection.

It seems you like to accommodate the community.

Yes. The community was very supportive. Community members send us links to hacked versions. Fans are also sending in recordings of communications with the attackers. We’re tracking it, and we have a whole database full of it.

There were also videos on YouTube that contained links to clones. Reporting to Google (Content ID claim) worked well. Google took down the incriminated video within a day. Reporting links to Google Drive with hacked versions was also successful.

Do users still use the hacked version, or did you disable it somehow?

Hackers are still active and create new clones. They can often release a clone just a few days after our updates. Unfortunately, we don’t have any way to disable those cracked versions.

Did you contact hackers directly? What was their motivation?

Although they don’t usually want to talk to us, there was a white-hat guy who appreciated our work and gave us a few hints as to what we might do better. Apart from that, they only care about adding their own ads and other nasty things.

For example, there was a guy from India who even added his own payment system and he charged half the price of the original. He even went to great lengths in protection and used a DexGuard to protect it. We got a hold of his WhatsApp and phone number. We unsuccessfully tried to sue him, but he was out of our legal reach.

The Mitigation: How to build a wall

“A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.”

Could you share any technical insights?

I remember having issues with code obfuscation. In some cases, older versions of Proguard (code obfuscator) obfuscated method parameters but created annotations with original names above them. I haven’t noticed such issues with R8, which ships with Android Studio nowadays.

I highly recommend the string obfuscator . It only takes a single annotation @Obfuscate above the class, and you are good to go.

Finally, strip out any debugging lines. Popular library has one crucial weakness regarding that. Although your Timber tree won’t log in the production build, your debugging code is still in place. A hacker can just turn debugging on for the app, and the logging will be visible again. Creating your logging scheme is also beneficial. Debug and verbose logs are dropped in production, informational logs are written into the local log, and finally, warnings and more severe events are logged to Firebase.

Is obfuscation the same for all builds?

Not necessarily; you can change a Proguard’s dictionary. The unfortunate side effect is that Google Play’s review process becomes more time-consuming. The regular one-day review process takes up to 10 days if you change the dictionary, as Google Play scanning is more thorough in such cases. If I need to push hotfixes quickly, I stick with the same dictionary as my previous build.

In theory, the best protection should be layered and spread all around the app. What layers and tricks do you recommend?

It’s common to use native code for hiding valuable parts of an application as its decompilation of binary is a much more demanding task. I hide logging and security checks in various places. There’s a high probability a hacker will miss some parts, and you will be able to track malicious activities. A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.

RASP made by does come as a complete toolbox of security enhancements. Reverse engineering protection can protect your app with many invisible traps that give hackers a hard time. Malware detection, tapjacking prevention, E2E Encryption, mutual TLS setup, online client integrity checks (Attestation), On-line Risk Scoring, API protection, Strong Customer Authentication, embeddable security dashboard, and much more are covered in our enterprise security. for a private meeting!

Did you consider products like Talsec RASP or freeRASP?

I didn’t have the necessary knowledge at that time. I have added the popular PiracyChecker library (note: Talsec didn’t exist at that time), but hackers still could circumvent it. As I have learned more about protecting Android apps, I have added many protections myself later. Alas, the iOS version of my app still needs to enhance the protection, which falls behind the Android one.

The common issue of established RASP libraries is that bypass for the majority of them is already publicly available. I feel the Talsec has a slight edge in this manner, at least for now.

What countermeasures did you apply? Where did you learn about possible techniques? Did you get stuck?

As I said, the first choice for me was the PiracyChecker as Talsec was not a thing back then. I have learned a lot from experienced Android developers on advanced forums. Things like decentralizing security checks, hiding secrets in a native code, rooting and tampering protection.

It’s a cat-and-mouse game. Hackers always find your protections, so you are forced to evolve your knowledge and update your app. For example, I spread those checks into many places in the app, so they are more likely to forget something untouched.

Do you have some specific protection tips?

Obfuscation is of great importance in hiding inner business logic. You can combine obfuscation with the reflection API to hide system calls. Hackers often head for them as these are usually placed close to sensitive operations. With reflection, you turn these calls into strings that are consequently obfuscated. Hackers will not be able to locate them using static analysis. Unfortunately, hackers are aware of this technique, and if you use it only on a few occasions, they can easily guess its meaning. Agreed. The reflection is easily spotted in the code. Do you have any solution in mind?

Yes, it would be necessary to add a lot of arbitrary fake reflection calls so that the important ones will be hidden between them. These could also serve as a kind of honey-pot. I would appreciate a plugin that would perform this transformation automatically.

Did you apply any mechanism to warn users against using a hacked clone? Did you forcibly terminate the app?

I had the warning screen displayed in hacked clones that exited the application only to realize users of clones began complaining and giving bad reviews. So, I later reverted it as it wasn’t worth it. However, I believe it’s good to have hidden logging, which can’t be disabled by a hacker easily. That’s what I finally ended up with. The hacked clones still report to my monitoring service as hackers apparently don’t care about that.

What do you think about Talsec’s Security Monitoring service and threat visualization dashboard?

My Firebase catches something already, but I would appreciate Talsec’s monitoring as it is more advanced. It would be great to see the collected statistics.

To wrap it, what would you recommend to other developers? What five tips would you give to yourself looking back?

It can sound silly, but the thing is that when you have to choose between delivering functionality and improving security, you should select the first and reckon with the risk. I have heard of companies focused on security so much that they could not develop the functionality needed for business.

Using time-saving drop-in solutions like Talsec and not messing up security basics pays off. Otherwise, you have to accept losing some percentage of purchases due to hacked clones and take it into account — also financially. I remember an Android security survey that suggested that most apps lack even the most basic obfuscation.

My five tips are:

1. Do not release without protections in-place

2. Perform sensitive operations server-side whenever possible

3. Prevent reverse-engineering

4. Monitor user groups and APK mirroring sites to detect malicious clones

5. Warn users against using fake clones

written by Tomáš Soukal, Mobile Dev and Security Consultant at Talsec

OWASP Mobile Application Security guides all phases of mobile app development and testing. The Verification Standard and the Testing Guide will provide you with a security standard and a baseline for mobile app security verification curated by a community dedicated to improving software security. Put in the right RASP suite to get the best passive and active security mix.

Part 1 () ↓

• Disassemble app.

• Extract its secrets.

Part 2 (this article) ↓

• Make a fake clone.

• Check every transmitted JSON.

• Inject code.

Part 3 () ↓

• Steal authentication tokens.

• and attack the API.

How to make a fake clone, aka “repackaging attack.”

To create a fake or “cloned” version of an Android app using , you first need to decompile the original app using the apktool d command. This would extract the contents of the app, including its resources, manifest file, and compiled code, into a directory on your computer. Next, you need to make the desired modifications to the app, such as changing its name, icon, or functionality. Once the modifications are complete, you can use the apktool b command to rebuild the app into a new APK file. This APK file would contain the modified version of the app, which you could then install on an Android device.

While you could fiddle with Flutter’s binary libapp.so file, I would just inject code into MainActivity.smali file, which is present in every Flutter Android app. The code used in this file is called smali. You can modify it as you wish. This can be misused to add a custom Activity, paywall, ads, or for credential harvesting. An adversary may be able to load native library containing reusable malware code. In my experience, the injection of hidden malicious native code is actually quite common.

Let’s make some code injections

This is the MainActivy.smali file in a stock Flutter app after being disassembled with apktool:

Example 1: Hello World

This code is a simple ‘Hello, world!’ string written into log.

Example 2: Open browser intent to a malicious website

This code will prompt a user to open the adversary-controlled phishing page.

Don’t reinvent the wheel and follow the standard

Let’s change the side and assume you want to protect your app against such attacks instead. I have great news! There is a standard for that. It’s called OWASP Mobile Application Security (OWASP MAS) which can guide you. It is a comprehensive guide for mobile app security with actionable solutions for many problems.

I should now advise you to visit the OWASP MAS using the link below. But it would also mean I would lose your attention. If you promise that you will return here, you can click it:

MAS Verification Standard (MASVS) will help you to understand something called security levels (L1 Standard Security, L2 Defense-in-Depth, R Resiliency). It will also introduce you to respective categories and their requirements:

MAS Testing Guide (MASTG) holds platform-specific detailed content about all security techniques. Unfortunately, it is targeted at iOS and Android devs and is less beneficial to Flutter devs.

MAS Checklist is a sheet used to check all requirements one by one to ensure nothing was left.

Check every transmitted JSON

JSON attacks, also known as JSON injection, refer to a type of backend web application vulnerability that occurs when user-supplied data is passed through a JSON parser without proper validation or sanitization. This can allow an attacker to inject malicious code into the JSON data, which can then be executed by the application.

To make a JSON attack, an attacker would need to craft a malicious payload that is designed to exploit the vulnerability in the target application. This payload could be included in an HTTP request, hidden in a file, or delivered through some other means. Once the payload is delivered to the application, it would be parsed by the JSON parser and executed, potentially allowing the attacker to gain unauthorized access or perform other malicious actions.

To protect against these types of attacks, it’s important to implement proper input validation and sanitization, as well as keep backend web applications up to date with the latest security patches. Another method to mitigate the JSON injection attack is to ensure that API call comes from a legit client and not crafted by an attacker who may have valid authentication token. Talsec provides the technology to verify client-side legitimacy and integrity. In comparison with the similar Firebase AppCheck technology the can do this with every API call.

Let’s catch some JSON’s!

I will use the tool to break into an app and intercept it’s JSONs. The hacked app will reveal the content of its network traffic in the Burp proxy.

I have chosen an arbitrary automotive app featured on the Flutter homepage. Just imagine that hackers would have discovered a vulnerability in such an app, allowing them to open the car’s trunk remotely. Such scenarios are actively researched nowadays and serve as a reminder of the importance of regularly updating software and maintaining strong security measures to protect against hackers.

Seeing the capabilities of this app makes me wonder what would happen if someone could exploit it. Remote unlock, car horn, remote cameras, car location and other super-sensitive operations can be invoked within this app.

To inspect traffic using the Burp Interceptor proxy, you first need to set up on your computer and configure your testing device to use the Burp proxy. Once Burp is set up, you can use the Interceptor tab to view and manage incoming and outgoing traffic. The Interceptor tab displays a list of requests and responses, along with details such as the URL, method, headers, and payload.

I downloaded the app from my testing device to my computer and reFluttered it:

At this moment, I am able to inspect every request, uncover hidden advertising campaigns, and so on. In general, this opens access to data like:

• API architecture

• Source URLs

• HTTP headers

• Bearer tokens

• Transmitted data (i.e., JSON)

Shields up! Runtime Application Self-Protection

A plethora of threats can be solved by a potent runtime application self-protection (RASP) library. There are various free solutions, but I have chosen the since it covers most areas, and I also contributed to this library.

Key features are the detection and prevention of root/jailbreak (e.g., unc0ver, check1rain), hooking framework (e.g., Frida, Shadow), untrusted installation method, and App/Device (un)binding.

Speaking of OWASP MAS levels, you would mostly be interested in RASP if your app should be compliant with R-level oriented on resiliency aspects. Actually, many devs integrate freeRASP as a future-proof solution to stay ahead even before their app truly needs R-level. This is something I am really proud of.

I prepared a small demo below showing freeRASP’s checks triggered on a rooted emulator. However, you can process the threat flags as you need. From my experience, the most common way is to show a dialog to warn the user about a tampered app or device and forbid any sensitive operations. I also wrote about freeRASP in this previously.

Actionable steps for app owners

1. Find out which security level (e.g., L1+R) is recommended for your app:

2. Try out freeRASP to get fundamental RASP features into your app:

Thank you for reading the second part of this guide. It’s always great to have an interested and engaged reader, and I appreciate your time and attention. I hope the information I’ve provided has been useful and informative! Thank you again for joining me on this journey.

Part 3 of this series will be available soon. Subscribe to Talsec and maybe try to crack-open some Flutter app in the meantime!

written by Tomáš Soukal, Security Consultant at Talsec

Revolutionizing Mobile Security: AI-Powered Device Risk Summary

For banking applications, fintech platforms, and any app where sensitive operations occur, preventing mobile fraud is critical. The challenge is to implement robust security without creating friction for the user. Imagine preventing fraudulent transfers or account takeovers with a seamless, user-empowering flow. This powerful, dynamic approach is the future of mobile security, moving beyond static defense to an interactive shield that helps, not just hinders.

What if you could not only detect a critical threat on a user's device but also guide them to fix it and complete their action securely, all within moments? At Talsec, we're thrilled to unveil a groundbreaking new capability that does just that. Let's walk you through a real-world scenario to demonstrate the power of our advanced security, culminating in our new AI Device Risk Summary.

The Scenario

Imagine a user is excited to buy a new pair of shoes from your e-commerce mobile application. They have found the perfect pair, added them to the cart, and are ready to check out. However, there's a hidden problem: their device is infected with malware.

Step 1: The Initial Purchase Attempt

The user proceeds to the payment page, ready to enter their card details. Instantly, Talsec's in-app security kicks in as an automatic background security step-up.

Step 2: Intelligent Security Check and Risk Assessment

Here's where the magic begins. While the input fields for the user's sensitive card information are temporarily disabled, Talsec performs a comprehensive device security scan in the background. The result? A high-risk score is returned, confirming that critical threats are present on the device, making it unsafe to proceed with an EMV payment transaction.

Step 3: AI-Powered Risk Summary and Crystal-Clear Guidance

This is the game-changer. Rather than leaving the user confused and likely to abandon their cart, your app now presents them with Talsec's AI Device Risk Summary. This user-friendly interface clearly explains the problem.

• Threat Report: A concise report informs the user that a specific threat has been found. In this case, it’s dangerous "SMS Forwarder" malware – a type of spyware that can intercept one-time passwords and other sensitive information sent via text message.

• Remediation Steps: The summary provides simple, actionable guidance, instructing the user on how to locate and uninstall the malicious application from their device.

Step 4: From Threat to Trust

The user follows the straightforward instructions and successfully removes the SMS Forwarder malware. They are now confident that their device is clean and their information is safe.

Step 5: A Secure Second Attempt and a Successful Transaction

The user returns to your app and attempts the purchase again. This time, the Talsec security check runs and delivers a vastly improved, low-risk score. The system recognizes that the threat has been neutralized.

The sensitive card detail fields are now enabled. The user confidently enters their payment information, completes the EMV transaction, and their purchase is successful.

From Friction to Empowerment

This entire process turns a potentially disastrous security incident into a positive user experience. You have not just prevented fraud; you have empowered your user to secure their own device, building trust and loyalty in your brand.

Would you like to protect your app with our new AI Device Risk Summary and transform your users' security experience?

Contact us to get more information about this awesome new feature! Visit and request a demo.

Cybersecurity has been a global problem for several decades. However, we are still in a phase where the exponential growth of security exploits leads to significant financial losses for businesses and individuals.

The size of the cybersecurity market was $3.5 billion in 2004. It is approaching $150 billion in 2021 and is expected to reach USD 352.25 billion by 2026. Regardless of such tremendous investments in this domain, the overall situation with security seems to be getting worse. So why isn’t the vast number of available technical solutions solving the cybersecurity problem?

What is wrong with Cybersecurity?

Ifwe ask an average technologically-minded manager in the security sector, we will get a simple answer. It is due to the low adoption of various brilliant tech solutions available on the market. Maybe… But isn’t this an over-simplified approach?

Suppose we want to radically improve cybersecurity and create a solution to gain mass user adoption. How would we get there? We must elaborate on the subject from different perspectives and go beyond the pure engineering view of security. Why?

One of the obstacles is that engineering-minded people tend to project the confusion in the problem statement onto users and explain the low adoption of security solutions by users’ ‘immaturity.’ On top of that, engineers quite often fall into an observation bias called the streetlight effect.

It is common for engineers to narrow the problem domain to a smaller segment that is more “comfortable” for research. They usually frame a problem, having in mind an “elegant” solution based on a “known” or “proven” technical framework. Meanwhile, the “core issue” may remain in the dark.

Technically minded people hate unclarity and vague problem statements. And it makes sense; we have to admit that otherwise, it is much harder to estimate and commit to the time needed for implementing the solution.

To tackle these problem statement misconceptions, we need to understand the difference between objective security issues and how users experience or perceive these problems. Remember the famous quote by Einstein “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” Generally speaking, we can’t just leave the problem statement fully defined by engineering-minded people. We need to make sure that we address the root problems in the security domain and verify if the selected methods are relevant.

The best approach to combat biases and go to the core of the issue is philosophizing. For example, let’s take a closer look at security through the eyes of mobile app users.

Security, Freedom, and Safety

Usually, the word “security” has a positive connotation for engineers. A good solution is a secure solution. Isn’t it so, dear CTOs?

While users often have ambivalent feelings about security, most have just run into too many unpleasant situations due to security measures. Have you ever blocked your payment card by incorrectly typing your PIN several times? Then you probably know how annoying security measures can be.

The core reason that security evokes negative feelings is that security, by definition, implies some limitations on freedom or privacy. It is especially true if an external party has imposed such limits out of our direct control.

NB: We may not realize it but people are quite used to being limited in freedom for the sake of security. For example, most of us were limited in our activities by our parents protecting us from the dangers of the external world. Another example is luggage scans in airports that somewhat intrude on our feelings of privacy.

There is often a “good reason” behind these limits, and it is communicated to users as a tradeoff between security needs and user convenience. But still, we often feel that it is unbalanced and doesn’t work how it should.

NB: Just think for a while how many potentially good online and offline services you have stopped using just because of annoying security measures.

The notion of safety is very close in meaning to security. But safety is subjective, i.e., a person can feel secure, in contrast to security, which is presumed to be a generic and objective concept. This difference explains why safety is perceived much more positively. The conditions leading to feeling safe are individual. Individual safety conditions may even contradict security conditions. And vice versa, security measures can conflict with and harm the feeling of safety. For some people, safety would mean accepting a certain comfortable level of insecurity, taking risks, and relying on self-protection skills. For others, it would mean the delegation of security to a trusted party and sacrificing some portion of personal freedom and privacy.

There is an essential implication in the subjective quality of safety. When we feel safe, it doesn’t necessarily mean we are objectively secure, and threats are absent.

Let’s sum up and list a few conclusions we have come to by now:

Security is not equal to safety; security measures are generic while the conditions of feeling safe are individual;

Security measures could harm the feeling of individual safety when an external entity manages it. In this case, security limits the users’ freedom and privacy that can go beyond the individual comfort zone.

Practically, users desire individual safety but may not have the full picture about security threats;

Engineers usually push generic security but have limited visibility into individual safety preferences and how security measures may impact them;

Both users’ and engineering’s views are influential and should be bridged and reconciled. Though, it is much easier said than done.

Social Contract in the Apps world

Many bright minds and philosophers have tackled the Freedom and Security dilemma from the ancient Greeks till modern times. The concept of the social contract was introduced and elaborated on in the 17th-18th century (Thomas Hobbes, John Locke, Jean-Jacques Rousseau). The social contract is an unwritten rule or agreement within the society that is supposed to balance and regulate the level of acceptable compromise between personal freedom and limitations for security provided by institutions, the state, or ruling classes.

In democratic states, citizens should influence this contract through the election process. Let’s assume for now that this mechanism works fine, and we have some control over the contract… I know some of you might say: it’s imperfect, it has a time lag, it is vulnerable to populism, but it still works, and we’ve got no better mechanism so far.

But what about social contracts in our digital life? We also delegate security to some external entities (consciously or not), don’t we?

Let’s use metaphoric language to highlight the parallels and differences between digital and real-life security in a simple thought experiment.

Though experiment about imaginary Apps world

Let’s imagine people living in the digital world like a historical real-time strategy computer game, where every person is a “natural Intellect-driven” game unit. People are surrounded by wild nature and the circumstances of a middle-age period of human history. A very insecure place to live, isn’t it?

The people organized themselves and came up with a collective defense by creating fortresses in towns and dedicated security institutions. These institutions (like states) provided security services to citizens by building fortifications to protect them from enemies while limiting their freedom by introducing rules and taboos.

NB: Keep in mind that such security institutions always had a tendency to misuse the power of the function that they were delegated (security geeks would call this a bug in the system that leads to “elevation of privilege” due to an issue in the “segregation of rights”)

Initially, citizens could go straight to the marketplace. Now they are forced to go through the main gates, pass through some identity verification process, pay taxes, and so on.

Now let’s upgrade this imaginary world, and let’s say these people live in a Mobile Apps World, where every fortress-town is an App.

NB: It is actually not an oversaturated metaphor since people spend 80% of their average online time in Apps.

In reality, Apps are designed to be executed under the supervision of an operating system in a sandbox environment and isolated from other Apps and processes. In our imaginary App world, the operating system is like a state that governs the fortress towns (Apps).

The same as in real life, the protection of the basic set of citizens’ rights is regulated by such states (operating systems). But the actual level of security inside the fortress (App) is still designed by the fortress owners (App publishers). Let’s call them governors.

NB: There would be two dominant states with quite a different regime in our App world: the iOS Kingdom and Androidian Union.

Inhabitants of such a world can quickly jump over from one fortress to another within the state. They can sell products in the marketplace of eBay, keep their fortune in the Revolut fort, and fall asleep on the dirty streets of YouTube. Just like us.

Safety first not a security

In our imaginary App world, the fortress governors must take security very seriously since it is a matter of life and death in assumed middle-age conditions. Also, they are forced to take their citizens’ safety feelings even more seriously because it directly impacts the growth of the population, which is crucial for the economic success of the fortress-town.

Thus, the more financial resources a town has, the better security measures it can afford. So there is a positive feedback loop from users’ safety feelings to security. It doesn’t work vice versa. More severe security conditions harm the population growth, limiting freedom or causing too much discomfort. This is why it is always “safety first” in our imaginary App world in contrast to “security first” that we are pretty used to in our lives.

This also explains why governors can’t fully delegate the balance between security, freedom, and comfort to their subordinates (neither the army nor merchants ). It is an existential question for a given App that is just too important to be delegated. It is directly linked to the mission and economic model of the App fortress.

NB: Thus in the real world the safety strategy should form the “right” balance between freedom, security, and comfort for a given App. Top management shall define or at least arbitrate it. It can’t fully delegate it to marketing-minded or tech-minded subordinates.

Evidence of security 👁️

These imaginary people of the App world have an advantage over us. They can visually observe the security system of fortresses that they consider entering. They can assess the security of the fortress app by a visual evaluation of the walls, gates, towers, or soldiers’ weapons and armor. These town citizens have the luxury of having an evident reason to trust the fortress app. And these citizens can easily guess how responsible and capable the owner of this town is in terms of security.

NB: In the real world, we usually lack clarity on how an app is secured. We only rely on the app review process of the marketplaces and trust in the given brand. This makes a strong link between trust in the brand and individual safety perception of the App.

Real-world App issuers rarely go the extra mile of guiding users through the security benefits of the app and user safety best practices. So users intuitively extrapolate the overall app UX quality to its security. As a result, any glitch in the App harms the feeling of safety just because users expect that security is at the same or worse level of quality as UX. The visual communication of security features, tips, and warnings could detach the perception of security from the rest of the functionalities. This aspect would be an independent factor of comparison with the competitors in the user’s eyes.

NB: The critical advantage of communicating and visualizing the state of App security is that it can help to bridge the gap between the personal feeling of safety and the actual state of user protection.

Security warnings and tips can be presented to only those users that have flaws in their device protection according to in-App protection controls.

NB: In-App protection is a mobile security technology that allows mobile applications to check the security state of the environment that it runs within, actively counteract attack attempts, and control the integrity of the App. Such technology is also called RASP (Runtime App Self Protection) or App-Shielding.

Let’s take a brief look at the Android security statistics collected from 400K devices of mBanking users (in EU countries). To get a general feeling of what percentage of users would deserve some security-related guidance, i.e., they have some fundamental security issues.

• About 21% of users ignore the Screen Lock functionality. It exposes users to the risk of misuse of Apps and data breaches if the device is lost, stolen, or used by kids.

• About 38% of users don’t use biometrics (like fingerprint scan), while only 12% (48K out of 400K) don’t have this feature available in their device; biometrics is much safer than a password or PIN. Incidentally, using a biometric lock doesn’t mean that data shared with any app or the device’s backend.

• 1112 users of 400K (0.28% have Rooted devices.). It means that the App integrity and its isolation sandbox can be compromised either through malware or by the user himself.

• 381 devices ran the App in a debugger mode, and 151 devices ran an emulator. These all are signals of a reverse engineering attack if they are not in the hands of a legal development team.

• 226 app instances have signs of app tampering (can indicate that the App was cloned, tampered, republished by an attacker, and a clone was installed).

Develop self-defense skills of users 🛡

Our imaginary governors know very well that an efficient defense should include more elements on top of the army and fortifications. Army and walls can probably protect from brute force attacks by barbarians, but it is much less efficient against traitors (aka fraudulent users in the real world), and can’t help against diseases caused by viruses (aka malware).

Fortress app owners could also realize that involving citizens in security affairs would increase the resilience of the town to large-scale problems while making the citizens more loyal and personally engaged.

That is why in the imaginary App world, governors should be very creative with educational activities, training, or performances explaining critical safety practices like how to detect scams and fraudsters, recognize suspicious activities of strangers, and hygiene rules to prevent epidemics.

So what I am pointing out is that businesses will implement user cybersecurity education and its visualization as an integral part of both the Security Journey and user loyalty programs soon.

NB: Some might say I don’t feel like educating my users about cybersecurity. Yes, it is quite a common view. I guess it was the same attitude among airline management before 1984. Since then, the pre-flight safety briefing has become mandatory and we are all quite used to watching the cabin crew demo every time we are about to take off.

Easiness to report an attack 🆘🕭

Every fortress owner in our imaginary world would need to get alarm messages in case an enemy army approaches his fortress. None of the governors would dare to underestimate this subject. It should be easy for citizens to send a signal, “We are under attack!”. That is why alarm bells are placed on every screen square of the app fortress .

In our real-life FinTech apps, it is bizarre, but the “Report abuse” feature is often well hidden. As if app managers prefer “it’s better not to know” that there is a leak in the hold. The most common approach is “in case of emergency, call the Hotline and enjoy the IVR music” and let the call center sort out the issue.

Many FinTech mobile app issuers would say, “well, we have a modern risk scoring and monitoring system that collects many security signals from the app like location, behavioral data of users, and many more to estimate the risk of fraud.” Indeed, many Apps use risk-based security. But the main problem of risk scoring systems is they suffer from a lack of factual information about ongoing attacks. In other words, they miss the “source of truth” of what attack vectors look like.” Risk scoring logic usually is designed based on the best knowledge of the given security team about potential attack vectors. At the same time, the creativity of cybercriminals has a much higher speed, so attack methods are changing much quicker than risk scoring logic.

On top of that, a significant portion of attacks addresses the weakest link in the security chain — humans. So it is hardly identifiable by automatic signals. So the best we can currently do is detect the scam campaign from user reports and quickly find the appropriate method to prevent it from becoming a large-scale attack.

Collective Cyber Defense

It is known that there is nothing more efficient against a common enemy than an alliance. In our App world, the governors of cities have much more chances of survival in the aggressive middle-age world if they join their efforts, i.e., form an alliance that implements the principles of a Collective Defense. The most crucial element in that collective defense is rapid information sharing about the enemy and how it is attacking.

In our real digital world, the quick distribution of detailed information about exploits is crucial (like malware binaries, scums, and zero-day vulnerabilities). In many cases, ML-driven mechanisms can automatically prevent many problems if they are trained by the “source of truth” information about the attack. Thus every reported attack can make the whole group more resilient.

It brings us to the question of which users would prefer to delegate the surveillance role and to who would they be happy to share the information about attacks? Is it governments, operating system vendors, device vendors, corporations like banks, small app issuers, professional communities, dedicated NGOs, etc.?

Summary

Let’s wrap up the takeaways of App security we touched on during this philosophizing exercise.

• Safety first, not security. Safety is about making the “right” balance between freedom, security, and comfort. This topic can’t be fully delegated to marketing-minded or tech-minded middle management since it is a strategic brand development question.

• App Security measures need to be visualized and explained for end-users to be perceived as safety elements and not just a security nuisance.

• Engaging users in the Security Journey through educational content, gamification, and feedback (report issue), is an efficient way to gain loyalty and prevent many security-related problems.

• Attack claims are a vital feature for building countermeasures. It should be simple and intuitive.

• Consider joining the AppSec community to benefit and contribute.

Author: Sergiy Ykymchuk

Co-founder of Talsec (.)

Mobile Apps Security Company

P.S.

Startups generally aim to change the world with their Apps and “make an impact” and influence people. The depth of our responsibility determines our actual influence. We are designing and manifesting our future influence by setting the boundaries of responsibility that we take.

Key Takeaways:

• Emulators have both good and bad uses—they help developers test apps but also allow unfair advantages in games.

• Common cheating methods include automation, running multiple game accounts, GPS spoofing, and memory hacks.

• Game developers use different detection techniques, but cheaters always try to stay ahead.

• Most importantly: There’s almost a perfect protection solution—AppiCrypt and Talsec RASPs!

Mobile gaming isn’t just small games played during pause—it’s a billion-dollar competitive industry. In 2024, the global mobile gaming market generated approximately $92.6 billion in revenue, accounting for nearly half of the total gaming market. Projections indicate that this figure will continue to rise, with expectations to reach $105.7 billion by the end of 2025.

A significant portion of this revenue comes from free-to-play (F2P) games. In 2024, F2P mobile games alone generated an estimated $83.21 billion globally. This model has become the industry standard, with 82% of mobile gamers preferring free games that include ads over paid games without ads [4].

As mobile gaming grows, so does the challenge of keeping it fair. Some players look for shortcuts, using cheats and hacks to gain an edge. One way to use these exploits? Emulators. What is an emulator, how can it be misused, and how can we protect against the threats it poses?

Emulators and Their Usage

Let’s start with a technical talk. An emulator is software that acts like a real device. It allows a computer to run apps meant for another system—no original hardware required. Want to play an old Nintendo game on your PC? No problem. Need to develop an Android app but don’t have a physical device? An emulator makes that happen. The main properties of emulators include:

• Running guest software

Emulators allow the host system to run software and applications designed for the guest system without requiring the original hardware.

• Data separation

Emulators typically keep the data of the host and guest systems separated. This is important for system integrity and security.

• System observation

Emulators often allow users to observe the data and memory of the guest system. This is particularly useful for debugging and memory analysis.

• Hardware manipulation

Emulators often also simulate guest system hardware; therefore, guest hardware can be manipulated.

Common Use Cases

It's important to point out that using an emulator alone doesn't necessarily imply malicious intent. Developers, researchers, security analysts, and even ordinary users may have a valid reason to use emulators. Most typical use cases are:

• App/Game Development & Testing

Developers use emulators such as Android Studio Emulator and Genymotion to test their applications across multiple devices without physical hardware. This allows them to provide well-tested and optimised applications without requiring hundreds of physical devices.

• Security Research

Beyond development, emulators play a huge role in security research. Ethical hackers and researchers (like us in Talsec) use them to test app vulnerabilities in a controlled environment, with deeper memory access than a standard phone allows.

• Gameplay Enhancement

Gamers have found their own uses too. Emulators like BlueStacks, LDPlayer, and NoxPlayer let people play mobile games on PCs, often with better performance and additional features.

• Multi-Instancing

Some gaming emulators, such as MuMu Player, allow users to run multiple app/game instances simultaneously, facilitating activities like account farming. With a physical device, this would be more complicated (but still possible).

Threats and Attacks Enabled by Emulators

But emulators aren’t just for developers and tech enthusiasts—cheaters love them too. They can use them to bend the rules, exploit game mechanics, and automate tasks to gain an unfair edge. From auto-clickers to fake GPS locations, emulators can give players an unfair edge, making games less fun for everyone else.

Input Automation (Scripting) & Macro Abuse

People are naturally competitive—they want to be the best, win, and prove their skills. Gaming is no different. Whether it’s casual trash talk or heated debates about who’s a pro and who’s a noob, competition is at the heart of it. So it’s no surprise that players look for any way to gain an advantage (or “skill”).

One way to do that in mobile gaming is by changing the tools you play with. Some believe that using a keyboard, mouse, or gamepad instead of touchscreen controls makes all the difference. Therefore, many emulators allow users to map touchscreen controls (screen coordinates) to a keyboard, mouse, or gamepad. This enables faster, more efficient, and more precise actions compared to an average mobile player.

Additionally, some emulators offer macro functionality, letting players record and repeat actions automatically—no need to tap the same button over and over when a script can do it perfectly every time. More advanced tools can even go beyond simple inputs, automating entire tasks like auto-clicking, switching apps, or turning system features like Wi-Fi and GPS on and off.

Examples of Exploits and Cheating

• Action Automation

In time-based games, players can wait and collect resources by hand, manipulate time (speed hack - more on that later) or automate waiting and resource collection.

• An unfair advantage in FPS games

While some games officially support alternative input methods, others strictly enforce touchscreen-only controls. The debate between “touchscreen-only” and “any input method” is often heated, especially in competitive FPS games (PUBG, CoD)

Multi-Instance Abuse

Gaming-focused emulators also often have multi-instance feature. This allows players to run multiple instances of the same game, oftentimes simultaneously. Players can control multiple player accounts at once. Main techniques of multi-instancing are:

• Manifest File

Since Android 12, developers may enable multi-instance support via the app's manifest file.

• Work Profile

Work Profile is a feature of Android which allows users to separate personal and work-related apps, data and settings on the same device by creating a secure container. Each work profile has its own user ID, creating a distinct environment that keeps data isolated

• Third-Party Apps

Tools like Parallel Space contains a special virtualization engine which creates a separate environment for running cloned apps. It also uses proxy components and Android calls interceptions to handle this.

• App Cloning

App cloning works by modifying the package name of the application. Android then sees these applications as separate.

• Manufacturer feature

Manufacturers like Samsung or Xiaomi provide this feature on a system level. Implementation of this may vary between each technology.

Examples of Exploits and Cheating

• Resource Farming

The other account can be used for resource farming which will be then transferred to main account.

• Matchmaking Manipulation

A high-level account can team up with low-level, possibly manipulating how high (or low in this case) will be levels of other players.

• Botnets/Emulator Farms

Players may generate unlimited in-game referral rewards by creating multiple instances of application and accounts.

GPS Spoofing

GPS spoofing is faking a device's location by overriding or manipulating its GPS data. This is typically achieved on Android by hooking system APIs, using developer options, feeding system services with fake data, or even low-level modifications. There are a few ways to fake the GPS signal:

• Android Developer Options (Mock Locations)

Android has a built-in feature which allows you to mock locations. When enabled, location API are intercepted and real GPS data are replaced with fake coordinates.

• Intercepting System Calls

Xposed Framework with FakeGPS module can hook into Android system calls and modify GPS data. This only works on rooted devices.

• Spoofing via System Modification

  • Modifying system files

  Some emulators allow modifying the /system/etc/gps.conf file to inject fake satellite data.

  • Using Virtual Machine

  Genymotion allows GPS spoofing via Genymotion Shell (gmsaas):

gmsaas instances set-location <instance_id> 40.7128 -74.0060

Memory Scraping

One way to gain an unfair advantage in a game is by modifying stats or acquiring items that would otherwise be unobtainable. This can be achieved through memory scraping, a technique used to scan and extract data directly from a system’s RAM (random-access memory) while it is being processed. Memory scraping is commonly used by both ethical security researchers and malicious attackers to analyse applications. Beyond reading data, it can also be used to modify data at runtime.

Memory scraping can be used for:

• Game Hacking

Tools like GameGuardian or CheatEngine use memory scraping to find and modify in-game values, such as health, currency, or character stats.

• Malware & Cybercrime

RAM scrapers are used in malware—such as point-of-sale (POS) threats like BlackPOS—to steal unencrypted credit card data before it is securely transmitted.

• Security Research

Ethical hackers use memory scraping to test software security, detect vulnerabilities and improve system protections.

How Memory Scraping Works

• Scanning RAM

A program searches the system’s memory for specific patterns, such as game variables, passwords, or credit card numbers.

• Extracting Data

Once the desired information is found, it is copied from memory before it is encrypted, modified, or removed.

• Processing and Storage

The extracted data can be logged, altered, or transmitted to an external server for further use. Game Manipulation

GameGuardian

GameGuardian is a game hacking tool for Android that allows users to modify in-game values by directly altering memory data. By scanning and editing memory addresses, players can adjust in-game currency, speed, health, and other parameters in real-time. It operates through a floating overlay, making it accessible while running a game.

Key Features & Use Cases

• Memory Scanning & Value Editing:

Users can search for specific numerical values (e.g., coins, XP) and modify them for an advantage. It supports fuzzy searches for unknown values and encrypted data.

• Scripting & Automation:

GameGuardian supports Lua scripting, allowing users to create and run automated cheats, bot functions, or repetitive tasks.

• Evasion Techniques:

To bypass anti-cheat mechanisms or license restrictions, GameGuardian includes stealth modes, memory protection features, and randomization techniques, making detection more challenging.

GG Scripting

What makes GG really powerful is scripting. Users can dump and modify memory by hand, using tools provided by GG application. However, this can be quite tedious. Scripting automates memory modifications, making it easier to apply cheats without manually searching and changing values every time a game is launched. This is particularly useful for repetitive hacks, bot automation, and complex multi-step exploits.

GameGuardian provides a built-in Lua API, which interacts with game memory. Key functions include:

gg.alert(message): Displays a pop-up message.

• gg.searchNumber(value, type): Searches for a specific value in memory.

• gg.getResults(count): Retrieves a set number of search results.

• gg.editAll(value, type): Modifies all matching results.

• gg.setValues(table): Applies specific changes to memory addresses.

• gg.sleep(time): Introduces a delay in script execution.

Script Example

-- Search for 1000 in memory (assuming currency value is stored as DWORD)
gg.searchNumber("1000", gg.TYPE_DWORD)
local results = gg.getResults(10) -- Retrieve the top 10 results

-- Modify each result found
for i, v in ipairs(results) do
    v.value = 999999  -- Change currency to 999999
end

gg.setValues(results) -- Apply modifications
gg.alert("Currency updated successfully!") -- Notify user

CheatEngine is a similar tool that works for other platforms, not just Android.

Examples of Exploits and Cheating

• Infinite Resources: Modifying in-game currency, lives, or skill points to unlimited amounts.

• Speed Hacks: Altering game speed to slow down or speed up gameplay for an unfair advantage.

• God Mode: Adjusting health, attack and other parameters to make character invincible

• Wallhacks & Vision Modification: Changing rendering parameters to see through walls or reveal hidden elements.

• Time Manipulation: Altering in-game timers to shorten cooldowns or bypass waiting mechanics.

• Auto Farming Bots: Using scripts to automate repetitive tasks such as collecting resources or attacking enemies.

Detecting Emulators

As discussed in the previous section, spotting an emulator isn’t as easy as you’d think. Some stick out like a sore thumb, while others go undercover, pretending to be real phones. Game developers and security researchers have to play detective, using system checks, behavior tracking, and file inspections to catch them in action.

Detection Techniques: How it can be done

System Properties Checks

Emulators often exhibit distinct system properties that differentiate them from real devices. These include:

• Hardware Identifiers Many emulators report generic values (e.g., ro.hardware = goldfish or ro.product.manufacturer = Genymotion).

• Device Model Unusual models such as sdk_gphone_x86 indicate an emulated environment.

• Build Fingerprints Comparing ro.build.fingerprint against known emulator values helps identify virtualized environments.

File and Directory Checks

Emulators create specific files and directories that do not exist on real devices. Examples include:

• /dev/qemu_pipe

• /sys/class/android_usb/android0/state

• Emulator configuration files in /proc/ or /system/lib/

Behavioral Analysis

Certain runtime behaviors can indicate emulation:

• Input Patterns: Automated, predictable touch events may signal bot activity Tapping too long/short; one tap always takes an exact constant amount of time; scrolling speed is perfectly even, scroll direction is a perfect straight line,...

• Performance Metrics: Emulators often lack genuine hardware performance fluctuations Mobile/Wi-Fi signal always has same perfect intensity; battery is always 100% even when not charged for weeks and months,...

• Sensor Data: Lack of real accelerometer, HW-backed keystore, gyroscope, or GPS variation suggests emulation. Missing basic components like accelerometer or gyroscope; missing HW-backed keystore (also serious because of cryptography); sensors return perfect or very predictable data,...

Advanced Detection Methods

• Side-Channel Analysis: Detecting emulator-specific timing discrepancies, cache behavior, or instruction execution anomalies.

• Machine Learning: AI models trained on real vs. emulated device data can detect subtle differences more effectively.

Detection Techniques: Shortcut

Detecting emulators is a complex and ever-evolving challenge. Developers can implement detection techniques manually, but this comes with significant drawbacks.

1. High Complexity & Maintenance Writing emulator detection from scratch requires deep knowledge of system behavior, hardware properties, and low-level interactions. Even a small mistake can lead to false positives (flagging real devices as emulators) or false negatives (failing to detect actual emulators).

2. Constant Updates Needed Emulator developers continuously refine their software to better mimic real devices. A detection system that works today may become obsolete in just a few months. Keeping up with new emulator tricks and evasion techniques is an ongoing battle.

3. Integration Challenges Emulator detection is only one piece of a larger security strategy. It needs to be efficient, lightweight, and compatible with other anti-cheat or anti-fraud measures in an app.

Because of these challenges, many companies choose ready-made security solutions rather than building their own. These solutions are designed, tested, and frequently updated to stay ahead of the latest emulator advancements.

Talsec RASP

One such solution is Runtime Application Self-Protection (RASP), which helps apps detect and react to security threats in real-time. RASP can:

• Identify if an app is running in an emulator or virtualized environment.

• Detect signs of system tampering or unauthorized modifications.

• Block or limit app functionality when a threat is detected.

• Detect other kinds of problems like active VPN, screen recording or enabled development mode

Talsec offers a free community version of its detection system (freeRASP), which covers the basics of app security.

Cat and Mouse: Detecting detections Attackers use various methods to bypass emulator detection, including:

• Modifying System Properties: Tools like Magisk can spoof ro.build.fingerprint and other properties.

• Masking Emulator Presence: Xposed modules and custom ROM modifications can remove emulator-specific files and directories.

• Disabling Protections: When attackers are aware that an application uses an extra protection layer, such as RASP library or DRM, they often try to use methods mentioned above (like memory scraping or application repackaging) to disable these detections.

• Challenges and Limitations: Detection methods can yield false positives, impacting legitimate users. Moreover, advanced evasion techniques continue to evolve, requiring adaptive detection mechanisms.

Talsec AppiCrypt

Talsec RASP provides an additional layer of protection against its bypass by using AppiCrypt. AppiCrypt is protection which essentially binds the state of the device to network calls of application. Every network request protected by AppiCrypt requires cryptographic proof (called cryptogram) which contains the security state of the device. If an application or device is compromised, the cryptogram will contain this information. The server can then decide whether it allows or denies the request. If the Talsec SDK is totally disabled, the application cannot generate cryptograms, hence not being able to make network calls.

Conclusion: The Double-Edged Sword of Emulators

Emulators are powerful tools that let people run mobile apps on different devices, making them useful for app development, security research, and gaming convenience. However, they also open the door for cheating and security risks, as they allow players to automate actions, fake locations, and manipulate game data in ways that aren’t possible on real devices.

Game developers and security experts are in a constant battle against cheaters. As emulators evolve, so do the methods to detect them. There’s no perfect solution, but staying ahead of the game is what matters. The future of mobile gaming depends on staying one step ahead—where innovation meets security, and fair play always wins.

Key Takeaways:

• Emulators have both good and bad uses—they help developers test apps but also allow unfair advantages in games.

• Common cheating methods include automation, running multiple game accounts, GPS spoofing, and memory hacks.

• Game developers use different detection techniques, but cheaters always try to stay ahead.

• Most importantly: There’s almost a perfect protection solution—AppiCrypt and Talsec RASPs!

JWT Token, MiTM Attacks and API Protection. Keep them properly protected and don’t put your enterprise at risk.

Part 1 (link) ↓

• Disassemble app.

• Extract its secrets.

Part 2 (link) ↓

• Make a fake clone.

• Check every transmitted JSON.

• Inject code.

Part 3 (this article) ↓

• Steal authentication tokens.

• and attack the API.