Use Case: Bypassing In-App Purchase By Payment Client-Side Validation

Android Store

In-app purchases (IAP) are fundamental to modern Android applications, allowing users to unlock premium features or subscribe to services. However, when developers do not adequately secure the billing process, vulnerabilities can arise, bypassing payment verification. This blog will cover how Frida, a dynamic instrumentation toolkit, can bypass Android in-app billing mechanisms. We will demonstrate how insecure purchase flows can be exploited and what developers can do…

Frida is a dynamic instrumentation toolkit for developers, reverse engineers, and security researchers. It enables you to inject custom scripts into running processes. Using Frida, we can manipulate Android apps in real-time, hooking into Java methods, modifying responses, and bypassing critical verification functions like those involved in in-app purchases.

The vulnerability lies in the app's performance of purchase validation on the client side rather than through a secure backend server. When an Android app trusts the client to verify purchases, attackers can intercept and modify the purchase validation flow to trick the app into unlocking premium features without paying.

Client-Side Validation: This can be intercepted if the app verifies the purchase.No Server-Side Verification: Purchases should be verified with a backend server, which can query Google’s API to check if the purchase is legitimate.Static Purchase Token Validation: Static purchase tokens are vulnerable to interception and manipulation if not handled securely.

In this example, we identified a vulnerability in File Manager: File Explorer, a file manager app with over 10 million downloads on the Google Play Store. File Manager offers premium features and themes through in-app purchases, which we were able to bypass by using Frida.

Tools Used:

Frida: To hook into the app’s runtime.
Android Emulator: To run File Manager in a controlled environment.
Jadx: To decompile the APK and inspect the app’s source code.

Decompile the APK with Jadx: The first step is decompiling the APK to find the classes and methods responsible for the in-app purchases. For File Manager, the BillingManager class manages the in-app purchase flow.Hooking Billing Methods with Frida: Using Frida, we hook into the querySkuDetailsAsync() method of BillingManager, which queries the in-app purchase details from Google Play. By intercepting this method, we can simulate a successful purchase without interacting with Google's servers.Java.perform(function() { var BillingManager = Java.use("com.explorer.filemanager.billing.BillingManager"); BillingManager.querySkuDetailsAsync.implementation = function(details, callback) { console.log("[*] Intercepting purchase request…"); // Create a fake SkuDetails object var SkuDetails = Java.use("com.android.billingclient.api.SkuDetails"); var fakeSkuDetails = SkuDetails.$new("{"productId":"premium_feature","price":"0.00"}"); // Call the callback with the fake details callback.onSkuDetailsResponse([fakeSkuDetails]); }; });

3. Bypassing Purchase Validation: The app uses a method like validatePurchase() to verify the purchase token after the user completes the payment. By hooking this method, we can simulate a valid purchase response.

var PurchaseValidator = Java.use("com.explorer.filemanager.billing.PurchaseValidator"); PurchaseValidator.validatePurchase.implementation = function(purchaseToken) { console.log("[*] Intercepting Purchase Validation…");

4. Unlocking Premium Features:

Jadx review code

The ProActivity class manages premium features and themes. We can intercept the premium check logic to ensure all premium features are unlocked.

var ProActivity = Java.use("com.explorer.filemanager.module.activity.ProActivity"); ProActivity.k0.implementation = function(isPremium) { console.log("[*] Unlocking premium features…"); return true; //

Final Script

Combining these techniques into one Frida script allows us to bypass all billing mechanisms:

Java.perform(function() {
var BillingManager = Java.use("com.explorer.filemanager.billing.BillingManager");
var PurchaseValidator = Java.use("com.explorer.filemanager.billing.PurchaseValidator");
var ProActivity = Java.use("com.explorer.filemanager.module.activity.ProActivity");
BillingManager.querySkuDetailsAsync.implementation = function(details, callback) {
console.log("[*] Intercepting purchase request...");
var SkuDetails = Java.use("com.android.billingclient.api.SkuDetails");
var fakeSkuDetails = SkuDetails.$new("{"productId":"premium_feature","price":"0.00"}");
callback.onSkuDetailsResponse([fakeSkuDetails]);
};
PurchaseValidator.validatePurchase.implementation = function(purchaseToken) {
console.log("[*] Intercepting Purchase Validation...");
return true;
};
ProActivity.k0.implementation = function(isPremium) {
console.log("[*] Unlocking premium features...");
return true;
};
});

Once the Frida script is injected, the app behaves like the user has made a legitimate purchase. The premium features are unlocked, and all in-app purchases are bypassed.

The application Is premium now.

Mitigating the Vulnerability

Server-Side Validation: Always validate purchases on the server side. Google provides APIs to verify the purchase token, and this should be done in a secure backend environment, not in the client app.

Obfuscation: Use tools like ProGuard or R8 to obfuscate sensitive code related to billing logic. This makes it more difficult for attackers to reverse-engineer the app and find vulnerabilities.

Tamper Detection: Implement checks to detect if the app is running in a modified or tampered environment, such as root detection, emulator, and integrity checks.

Disclosure Timeline

10 October 2024 | Vulnerability was initially discovered
11 October 2024 | Contacted team at public official emails
17 October 2024 | Initial Response from the Company After informing the company of the vulnerability affecting File Manager: File Explorer (used by over 10M+ users), the company responded that it does not consider the issue a problem and has not taken steps to resolve it.
17 October 2024 | Request for Public Disclosure
17 October 2024 | Vendor Response The vendor informed us that they do not consider the identified vulnerability a problem and are permitted to make the details public without resolving the issue.