A Look
At A Promon Shield Bypass – Part 2

System properties on Android are global key/value strings managed by init and stored in a shared memory region every process maps read-only at startup. There are two libc APIs that libRASP.so actually uses to read them, and we found both by hooking the libc exports and logging every property name whose return address landed inside libRASP.so‘s code range:

• __system_property_get(const char *name, char *value) — the classic one. You hand it a property name as a C string, it copies the current value into your buffer. Single call, single property, used heavily.
• __system_property_read_callback(const prop_info *pi, callback_fn, void *cookie) — the modern one, introduced in Android O. Instead of returning the value, you first call __system_property_find() to get a prop_info* handle for a given name, then hand that handle to __system_property_read_callback along with a callback function. The callback gets invoked with the property’s name, value, and a serial number. The serial number is the whole reason this API exists: properties whose values can change at runtime (anything not under ro.) need the serial to detect mid-read updates, and the older __system_property_get can’t do that. libRASP.so uses this API even for ro.* properties — probably because it’s harder to hook generically (callback-based APIs don’t have a single chokepoint where the value is “returned”) and because mixing both APIs forces a bypass to cover both.

libRASP.so also imports __system_property_foreach for one or two enumeration passes, but the bulk of the actual root-relevant reads go through find + read_callback.

The properties Promon cares about, in three groups:

• Build-type indicators. ro.secure should be 1 on production, 0 on engineering builds. ro.debuggable should be 0 on production, 1 on userdebug/eng. ro.build.tags should be release-keys on OEM-signed firmware, test-keys on AOSP/custom ROM builds. ro.build.type should be user, not userdebug or eng. These are the oldest root indicators in the book — any custom ROM that forgot to fix them is instantly flagged.
• Verified Boot state. This is the critical group, set by the bootloader before userspace exists. ro.boot.verifiedbootstate should be green (locked, verified boot passing, OEM key) — the alternatives are yellow (locked, user-installed key), orange (unlocked), or red (verification failed). ro.boot.flash.locked should be 1. ro.boot.vbmeta.device_state should be locked. Together these three are a near-perfect proxy for “this device can have Magisk installed on it,” because Magisk requires an unlocked bootloader and an unlocked bootloader can’t produce green/1/locked. A stock-rooted Pixel reports orange/0/unlocked, full stop, and Promon kills the app immediately when it sees that.
• ADB/init service state. init.svc.adbd reports whether adbd is running. Not a root indicator on its own, but Promon weighs it.

Those eight properties are exactly the watch list we reconstructed from our hook logs — pulled directly from the bypass script as the CLEAN_PROPS map:

var CLEAN_PROPS = {
  "ro.secure":                   "1",
  "ro.debuggable":               "0",
  "ro.build.tags":               "release-keys",
  "ro.build.type":               "user",
  "ro.boot.verifiedbootstate":   "green",
  "ro.boot.flash.locked":        "1",
  "ro.boot.vbmeta.device_state": "locked",
  "init.svc.adbd":               "stopped"
};

The kill, as with the /proc scanning layer, isn’t issued from the native code itself. The native side reads the properties, packs the verdict into a result array, and a downstream Java-side comparison in attachBaseContext is what actually throws. There’s also a second consequence we’ll come back to in a later section: when this property check flags the device, the first real Activity downstream uses the same native verdict to seed a decryption routine, and the seeded-with-bad-data routine eventually runs the process out of memory with a 438 MB allocation. So this layer doesn’t just have one kill path — it has a fast Java throw and a slow OOM trap, both fed by the same native property reads.

(We will come back to the “out of memory” issue in a future blog post).

Why hooking the libc APIs is fragile

The obvious bypass is to Interceptor.attach on __system_property_get, __system_property_read_callback, and __system_property_foreach, scope the hooks to calls coming from inside libRASP.so‘s code range, and rewrite the values on the way out. This is exactly what one of our Frida bypasses did and it worked — for about 25 seconds.

Three things go wrong:

The callback API doesn’t have a clean return-value to rewrite. __system_property_read_callback doesn’t return the property value; it invokes a function pointer Promon supplied, with the value as one of the arguments. To spoof it, you have to wrap Promon’s callback in your own callback that calls Promon’s with the spoofed value substituted. We did exactly this — built a small native trampoline at runtime that intercepted the cookie/name/value triple, swapped the value pointer to one of our pre-allocated clean strings if the name was in the watch list, and forwarded to the original. The full hook, as it appeared in our bypass script, looks like this:

Interceptor.attach(libc.getExportByName("__system_property_read_callback"), {
  onEnter: function(args) {
    var origCB = args[1];

    // Scope to calls originating from inside libRASP.so only
    var fromAc70 = false;
    try {
      var mod = Process.findModuleByAddress(this.context.lr);
      if (mod && mod.name.indexOf("ac70") !== -1) fromAc70 = true;
    } catch(e) {}
    if (!fromAc70) return;

    var origFn = new NativeFunction(origCB, "void",
                    ["pointer","pointer","pointer","uint32"]);

    var wrapper = new NativeCallback(function(cookie, namePtr, valPtr, serial) {
      var name = namePtr.readCString();
      if (spoofedStrings[name]) {
        origFn(cookie, namePtr, spoofedStrings[name], serial);
        return;
      }
      if (name && (name.indexOf("magisk") !== -1
               || name.indexOf("supersu") !== -1
               || name.indexOf("xposed") !== -1)) {
        origFn(cookie, namePtr, emptyString, serial);
        return;
      }
      origFn(cookie, namePtr, valPtr, serial);
    }, "void", ["pointer","pointer","pointer","uint32"]);

    wrapperCBs.push(wrapper);
    if (wrapperCBs.length > 1000) wrapperCBs.splice(0, 500);
    args[1] = wrapper;    // replace Promon's callback with ours
  }
});

It works, but the wrapper trampolines have to be allocated somewhere, kept alive forever, and tracked across thousands of calls — we capped them at 1000 and recycled. Every wrapper is one more thing in /proc/self/maps — the very file the other native layer is scanning. The two bypasses interact: aggressive callback wrapping pollutes maps; aggressive maps filtering has to know about the wrapper allocations.

The __system_property_get hook is simpler — it has a real return buffer to overwrite on the way out — but requires the same caller-scoping discipline:

Interceptor.attach(libc.getExportByName("__system_property_get"), {
  onEnter: function(args) {
    this.name = args[0].readCString();
    this.vbuf = args[1];
  },
  onLeave: function() {
    if (this.name && CLEAN_PROPS[this.name])
      this.vbuf.writeUtf8String(CLEAN_PROPS[this.name]);
  }
});

Inline hooks on libc trip Promon’s code-integrity check. Once you’ve got Interceptor.attach installed on __system_property_get, the first few bytes of that function in libc have been overwritten with a branch to Frida’s trampoline. Promon (in a separate detection layer covered later) scans the prologue bytes of specific libc functions via raw svc reads of its own loaded libc image and notices when the bytes don’t match. The property hook itself is what trips that check.

We spent a multi-day stretch trying to make inline-hook-based property spoofing work, and documented every failure:

• ADRP crash at 43ms. All three hooks installed. Process dies 43ms after load. Saved prologue in the trampoline page contained a PC-relative ADRP instruction. When that instruction executes from the trampoline’s address rather than its original location, the computed page address is wrong by however far the trampoline is from the original code — the function dereferences garbage and faults.
• mprotect degradation. Switched to a restore-call-rehook approach: restore the original bytes before calling the function, execute the real function, re-hook afterward. No prologue relocation needed. But mprotect marks the page rwx the first time and it never fully restores to read-execute — Promon’s rwx-page scanner (the same one that catches Frida’s COW trampolines in /proc/self/maps) flags it on the next scan pass. Five test iterations, five different failure timings, all the same root cause.
• zygote fork invalidation. Inline hooks installed in the zygote process are COW-mapped into every forked child. The trampoline pages don’t inherit correctly — address space layout shifts on fork, the trampolines point into the parent’s layout, and the first call through a hooked function in the child process segfaults. This killed every non-target app on the device that used __system_property_get, which is essentially all of them.

The conclusion was that hooking the reader is the wrong layer. Promon goes to lengths to make sure it can detect modifications to the reader. The right layer is the source data.

Property reads happen too early to hook from Java. libRASP.so‘s property scan runs from inside JNI_OnLoad, which the runtime invokes synchronously during System.loadLibrary(), which Promon triggers from Application.attachBaseContext before Java.perform is usable on Android 15. Even if you could install your hooks fast enough, you couldn’t install them from a Java context. Native-side hook installation works but you’re now doing it from your own Frida agent, and as we just covered, being a Frida agent in the process is itself something Promon detects.