Frida and App Integrity detection not working as expected

[thisisyusub]

Describe the bug We have released and configures security with freerasp. But our pentester team investigated that, in the following scenerio, it is not working as expected to catch jailbreak, frida and app integrity check.

To Reproduce

From Mobile App Side

1. Create App Protection Service like following:

class InAppProtectionService {
  InAppProtectionService();

  Future<void> init() async {
    final config = TalsecConfig(
      // For Android
      isProd: kReleaseMode,
      androidConfig: AndroidConfig(
        packageName: 'az.azerconnect.inside',
        signingCertHashes: [
          'base64 from sha256 from Google Play Console',
        ],
      ),

      // For iOS
      iosConfig: IOSConfig(
        bundleIds: ['az.azerconnect.inside'],
        teamId: 'Team ID from App Store Connect',
      ),

      // Common email for Alerts and Reports
      watcherMail: 'any email',
    );

    final callback = ThreatCallback(
      onAppIntegrity: () => exit(0),
      onDebug: () => exit(0),
      onPrivilegedAccess: () => exit(0),
      onSimulator: () => exit(0),
      onUnofficialStore: () => exit(0),
      onHooks: () => exit(0),
    );

    Talsec.instance.attachListener(callback);
    await Talsec.instance.start(config);
  }
}

---

2. Start it in the main.dart file:

runZonedGuarded<Future<void>>(
    () async {
      WidgetsFlutterBinding.ensureInitialized();

      final appProtectionService = InAppProtectionService();
      await appProtectionService.init();

      /// initializes [Firebase] for application
      await Firebase.initializeApp(
        options: DefaultFirebaseOptions.currentPlatform,
      );
      await AppStartupWrapper.initialize(environment, overrides);
    },
    (error, stack) async {
      return FirebaseCrashlytics.instance.recordError(
        error,
        stack,
        fatal: true,
      );
    },
  );

3. build.gradle file if it is interested:

---

4. Build app for android with the following command:

   flutter build apk --obfuscate --split-debug-info=obfuscate/symbols --build-name=1.14.1 --build-number=60

From Pentest Side

1. Download the app from Play Store (1.14.1) https://play.google.com/store/apps/details?id=az.azerconnect.inside

2. Use “reflutter” tool to modify APK. In order to monitor the app traffic, select first option and enter your Burp Suite IP.

   reflutter app.apk

   

---

3. Sign modified APK with “uber-apk-signer” tool.

   java -jar uber-apk-signer-1.2.1.jar --apks inside_modified.apk

   

---

4. Install signed APK to the device. adb install inside_modified-aligned-debugSigned.apk

---

6. When the app is launched, it will crash instantly. To prevent that use following Frida script.

   Java.perform(function() {
   let C7508g = Java.use("s1.g"); C7508g["$init"].implementation = function(z, z2, z3) {
   console.log(`C7508g.$init is called: z=${z}, z2=${z2}, z3=${z3}`);
   this["$init"](true, false, false); };
   });

   ---

7. Run the app using Frida script.

   

8. App will be launched successfully. Tap the “Skip” button.

   

---

9. Enter an email and a password.

---

10. Login request will be captured successfully.

Expected behavior After all these processes, it should detect if app:

• runs on simulator, emulator, rooted device or not
• if it is hooked with Frida
• if this app is installed from Play Store or not (integrity check)

Please complete the following information:

• OS version: Android 11
• Version of freeRASP: 6.4.0

Tools Used:

• Reflutter 0.7.7
• Frida 15.2.2
• Uber APK Signer 1.2.1
• Burp Suite v2023.12.1.5
• Genymotion 3.6.0

[yardexx]

Hello.

Thanks for raising this issue. We are looking into it.

[cbarlow26]

Hi,

I know nothing about pen testing and this may be a very stupid question, but I was wondering if the Frida script is somehow modifying the kDebugMode, kProfileMode, and kReleaseMode constants?

If this is happening, then using isProd: kReleaseMode would bypass all the release level callbacks like onAppIntegrity. Maybe try isProd: true and retest?

[thisisyusub]

Hi,

I know nothing about pen testing and this may be a very stupid question, but I was wondering if the Frida script is somehow modifying the kDebugMode, kProfileMode, and kReleaseMode constants?

If this is happening, then using isProd: kReleaseMode would bypass all the release level callbacks like onAppIntegrity. Maybe try isProd: true and retest?

It can be true, but documentation mentioned that you can use in this way.

[yardexx]

I know nothing about pen testing and this may be a very stupid question, but I was wondering if the Frida script is somehow modifying the kDebugMode, kProfileMode, and kReleaseMode constants?

My (educated) guess is that Frida hooks Talsec Android SDK which is implemented in a plugin. We are currently investigating that.

We generally recommend using isProd: true because it ensures that production mode is true even if the attacker messes around with Flutter SDK constants.

[thisisyusub]

Any update about it?

[SirionRazzer]

We investigated the issue and found a solution. We believe the countermeasure could be rolled out in the next freeRASP release. Thank you for your help!

[dragongesa]

any update sir?

[martinzigrai]

Hello,

We've identified the issue and we're currently brainstorming about the possible solutions. The hooked class is responsible for the internal notifications, and we can harden it so it's not bypassable by the script above. However, it won't fix the bigger issue that is present in freeRASP.

The major disadvantage of the freeRASP is the public API that is used to notify the application about detected threats. If the attacker/pen. testing team is trying to focus on the protection itself (freeRASP library); after some time, they will find the single point of failure -> the notification threat listener (onHookDetected, onDebuggerDetected, ...). We can check the freeRASP's execution state, but if we discover that it's compromised, we are expected to notify the application using that threat listener.

This issue could be resolved by adding some automatic "app crash" mechanisms into the freeRASP, but we are reluctant to do this as it could cause crashes that are not transparent to the developers (as they lack access to the audit logs/reporting).

We'll add protection against this type of hook script in future release, but if you require a more robust solution to protect your application, please refer to our business solution (Business RASP+) and its advantages.

[rakesh0689]

Helloo.. Any update on this? In my case Even after simply refluttering the apk and signing the refluttered apk using ubersigner the pen.testing team is able to open the app without using a frida scripts i believe. I have asked for confirmation as well regarding the same. I am using isProd : true in my app too.

[syakymchuk]

Hello @rakesh0689,

I let the team respond on this. I just wanted to confirm that freeRASP is not designed to sustain professional pentesting. The Commercial Version is designed for this. freeRASP will always have intentional architecture restrictions and Fair Usage Policy limitations.

Sergiy Yakymchuk
Talsec Co-founder

[rakesh0689]

Hello @syakymchuk,

See if freeRASP will always have intentional architecture restrictions - meaning it does not withstand even simple Pen Testing then it should be mentioned somewhere right. We had confidence that freeRasp will be our first line of defence that's why we added it to our production application as well. Had we known this earlier we would not have put our application at risk. This issue is along with freeRasp not detecting Root & Hooking immediately as mentioned in other problems (bugs) puts our application at serious help. Kindly provide us with a way to improve the detection speed. Earlier builds like 5.0 or so didn't have this issue, i believe. I understand free version will not be similar to the paid one but that does not mean basic functionalities also needs to be restricted right? Kindly help.

[syakymchuk]

Hello @rakesh0689,

We try to be as transparent as possible with our community. The limitations of freeRASP vs. Business plans are clearly outlined here. We will consider making it more explicit and visible to avoid confusion. Thank you for drawing attention to the topic.

We don't consider this bypass method using hooking frameworks trivial. The business version is resilient to this, but freeRASP is not. It may be improved in the future, but business version improvements, SLAs, and commitments will go first.

The detection speed is always a matter of compromise between accuracy and performance. In the Business version, you can adjust the balance by configuration. Since rooting techniques evolve, the detection may take longer; in freeRASP, it works in an async way. Some improvements are planned for freeRASP here too. Stay tuned to get it as soon as available (Get updates form).

If this limitation impacts the business and has negative consequences, please contact the business team, and we will try to find the right business-grade solution for you.

[xprikryl2]

Hello @rakesh0689,

The disadvantage of freeRASP is the public interface used to inform the app about detected threats. If the pen testers do some analysis of your application, they will probably find the code where the freeRASP is executed or the threat callbacks are handled. It's essential for us that you understand, that this limitation is caused by the nature of this product -> it's just a library. And the library is executed within your application and can be modified or stripped away. The same applies to other libraries; if I use RootBeer inside my application, I can always disassemble the APK, find the place where isRooted() is called, and remove it.

However, this doesn't mean that using freeRASP is pointless. Our goal is that freeRASP can withstand various types of automated attacks. For example, if you used only the reFlutter to resign the APK (without the additional analysis and modification of the app), our library should detect it. The same applies to the predefined Frida scripts that are publicly available, and they should be detected. Even the code analysis isn't trivial if the application correctly sets up obfuscation rules. We recommend enabling obfuscation in our documentation, but it's up to the developers to choose the rules correctly and ensure that obfuscation is correctly applied. It adds time and effort to break your application (proportional to the skill level of the attacker), and we admit that removing/bypassing freeRASP is possible. If you have any ideas, observations, or issues, please feel free to let us know.

Regarding the slower detection speeds. As @syakymchuk already mentioned, the techniques are still evolving. We'll look at the sudden performance drop of the root/hook detection in the latest versions, and let you know.

Best regards, Ondřej from Talsec team

[rakesh0689]

Ok @xprikryl2 Thank you for letting me know the details. Please do look into the increase in detection time.

[SirionRazzer]

Hello @rakesh0689 ,

I tested the current version, past version and monitoring data. The experienced slowdown may happen during reverse engineering or under conditions described in this wiki page: https://github.com/talsec/Free-RASP-Community/wiki/Callback-Delay,-Telemetry-Impact,-and-Threat-Scanning-Completion-Status

We expect improvements in the upcoming version that will incorporate new cloud infrastructure. Yet, the limitations of freeRASP vs. commercial version stay the same (as @syakymchuk written here: https://github.com/talsec/Free-RASP-Flutter/issues/103#issuecomment-2242809484 ), esp. "Network calls for the data collection are performed before the callbacks are invoked.". This means under bad network conditions; callbacks may take some time to be delivered as freeRASP first try to finish the data collection.

Best Regards, Tomas

[github-actions[bot]]

Hello! This issue has been marked as inactive. If there is no further activity within the next 14 days, this issue will be automatically closed. If you believe this issue is still relevant and requires attention, please comment or provide additional information.

[vallerydelexy]

so you guys basically said, "nah we we aint gon fix this, if you want this feature, then upgrade to paid plan or f off"

[syakymchuk]

so you guys basically said, "nah we we aint gon fix this, if you want this feature, then upgrade to paid plan or f off"

Not exactly. The security limitation of freeRASP (bypass possibility) will stay, but latency due to bad_network related UX problems should be solved.

[AhmedHammad0900]

@thisisyusub can u share your frida js file please to know which script u used to bybass this , and is the problem still or they fixed in next releases ? ty .