Memory Integrity & Anti-Manipulation: The use of a custom VM inherently provides some integrity: the bytecode in assets could be encrypted or signed such that if it’s altered, it won’t execute properly. On top of that, the FNV-1 hash calculations seen in the opcode handlers may indicate that the VM is continuously hashing the executed instructions or values. This can act as a checksum – if an attacker tried to tamper with the bytecode or the VM’s data, the resulting hash would change and the VM could detect it. We don’t have full confirmation of what PairIP does with these hashes, but a reasonable guess is that it could validate a final hash against an expected value (ensuring the bytecode ran through exactly as intended). Moreover, the self-modifying nature of libpairipcore.so (code is fixed up at runtime) itself hinders tampering – the code on disk is incomplete and only materializes in memory, making patching it on disk ineffective. All these measures contribute to a layered defense. If any check fails, PairIP’s typical response is to prevent the app from running normally. This could be an explicit crash (throwing an exception or killing the process), or a controlled UX flow (like showing a “not authorized” dialog then exiting). For example, if signature verification fails, the app throws a runtime exception with the message “Apk signature is invalid.” and likely aborts. If the installer check fails, it might start an Activity pointing to Play Store (which, if Play is not reachable, might yield a generic error). If debugging is detected, PairIP may deliberately crash the app (sometimes manifesting as a segmentation fault in libpairipcore.so). In one case, bypassing some checks led to an immediate crash with SIGSEGV_MAPERR because the library likely detected inconsistency and tried to read an invalid memory address to force a crash. The net effect is a robust shield: the app protects itself at runtime by using PairIP to constantly monitor its environment and integrity. This is analogous to having a security guard thread/process running alongside the app’s main code, except much of that guard is running in an obfuscated VM.
Integration with Apps: Real-World Examples
Since PairIP is relatively new, it’s been found in a selection of apps and games, often high-value targets for modders or pirates. Here are some known examples and what we know about their usage of PairIP:
-
BitLife (Candywriter) – BitLife is a popular life-simulator mobile game. Around late 2022, players and modders noticed that newer versions of BitLife contained unusual anti-tampering behavior. On inspection, BitLife’s APK was found to contain libpairipcore.so and a half-dozen dex files (classes.dex, classes2.dex, …) with obfuscated code. The presence of multiple DEX files and an assets/audience_network.dex (related to ads) initially confused analysts, but digging deeper, they found the PairIP components and references to a license check. Indeed, BitLife’s code was invoking SignatureCheck.verifyIntegrity() and included PairIP’s license client classes. This suggests the developers integrated PairIP to prevent modded APKs that unlock premium features without purchase. APKiD (an Android malware/packer scanner) flags BitLife as protected, and an issue filed on its tracker confirmed the license check logic was present in BitLife’s PairIP code.
-
Northgard – Northgard is a strategy game ported to Android. A modded (“cracked”) version 2.0.3 of Northgard was analyzed in mid-2023, and it showed both libpairipcore.so and another library libRMS.so. It turns out the modders attempted to bypass PairIP by removing references to libpairipcore.so and substituting their own stub (libRMS.so) in the Unity engine binaries. The idea was to hijack calls intended for PairIP’s VM (e.g., Unity calling an ExecuteProgram function) and prevent the real checks from running. However, this approach didn’t fully succeed – the game ended up crashing with a segmentation fault, as the underlying integrity checks likely failed or the VM logic wasn’t executed as needed. This cat-and-mouse shows that Northgard’s developers enabled PairIP to protect game logic and detect unauthorized changes, and simple patch jobs by modders were not enough to keep the game running.
APKiD’s database labels libpairipcore.so as a “Google Play Integrity” protector when it appears. So Northgard’s protected APK was a textbook case, containing all the PairIP components (and indeed required a proper license/Play installation to work).
-
Roblox – Roblox is a hugely popular online game platform. In early 2023, users running Roblox on unsupported environments (like Waydroid, an Android emulator on Linux) encountered errors indicating PairIP. One Reddit post showed a java.lang.UnsatisfiedLinkError: dlopen failed: library "libpairipcore.so" not found when trying to launch Roblox on Waydroid. This suggests that Roblox’s APK expected libpairipcore.so to be present (and likely Waydroid didn’t have the full installation or some mismatch occurred). It’s plausible that Roblox enabled Automatic Integrity Protection to crack down on modded clients and cheating tools. The error on Waydroid also hints that if the integrity library can’t load (perhaps Waydroid’s pseudo-environment interfered), the app refuses to run. Roblox may use PairIP to ensure its game client isn’t instrumented or altered, complementing its anti-cheat measures.
-
Spotify – While not confirmed by official sources, there was community speculation that Spotify experimented with Google’s new VM-based protection to combat modified APKs (which remove ads for non-premium users). A Hacker News discussion in late 2022 mentioned “Google is developing a new obfuscation VM called PairIP (that libpairipcore.so)” and implied that it could spell the end of cracked Spotify APKs. If Spotify adopted PairIP, the goal would be to ensure the app’s code cannot be easily patched to bypass ads or subscription checks. Given Spotify’s scale, they might have been a partner in early trials of Automatic Integrity Protection. As of mid-2023, many Spotify mods still existed, so if PairIP was tested, it may not have rolled out fully to all users. Nonetheless, the fact that it was discussed in that context highlights PairIP’s reputation as a serious roadblock for modding.
-
VPNify (Secure VPN) – In an example from a reversed APK, the app VPNify (a VPN client) had been wrapped with PairIP. The com.vpn.free.hotspot.secure.vpnify package’s Application class was invoking SignatureCheck.verifyIntegrity() via the com.pairip.application.Application wrapper. This indicates even utility apps like VPNs, which might have premium versions or want to prevent tampered clones, are using PairIP. By verifying signature and possibly using the license check (if it’s a paid VPN service), the developers ensure the app can’t be republished by third parties or used illegitimately.
-
Google’s Own Apps: There is curiosity whether Google employs PairIP on its first-party apps. One example is Google Camera (GCam) – known to be a target for modding (porting to other devices). APKiD scans of GCam 8.7 showed anti-disassembly and anti-emulator checks, but it’s unclear if that was PairIP or just standard obfuscation. Google might not need PairIP for its free apps, but could be testing it in some (or using parts of it, like the anti-debug library components). We do know that Automatic Integrity Protection requires Play App Signing, which Google’s own apps already use, so technically it’s possible. However, the most concrete usage so far is in third-party apps/games distributed via Play.
In all these cases, the common theme is protecting revenue and fairness: BitLife and Northgard want to prevent free unlock of paid content, Roblox wants to stop cheating and unofficial clients, Spotify wants to enforce its subscription model, and VPNify wants to ensure only official clients (and paying users) use their service. PairIP provides a generalized solution for these needs, backed by Google’s infrastructure.
Symptoms of PairIP Protection
For end-users or testers, an app using PairIP may exhibit distinctive behaviors when the protection is triggered. Recognizing these symptoms can clue you in that the app has an integrity mechanism active:
-
Immediate Crash on Launch: One of the most common signs is that a repacked or tampered APK will simply crash or exit as soon as it’s opened. This happens because the signature check fails almost instantly in attachBaseContext. The app might not show anything more than a flash of a splash screen (or nothing at all) before terminating. In logcat, you would see a runtime exception like SignatureCheck$SignatureTamperedException: Apk signature is invalid. being thrown. If uncaught, this exception will crash the app with a stack trace pointing to com.pairip.SignatureCheck.verifyIntegrity. This is a strong indicator that the APK’s signature didn’t match what was expected – implying the app was re-signed (hence likely modded or sideloaded).
-
Black Screen or Hang: In some cases, the app might not immediately kill itself but will refuse to proceed past a certain point. For example, if an emulator or root is detected, the developers might choose to blank the UI or show a static screen while the app silently disables functionality. However, most implementations we’ve seen prefer an outright exit or redirect rather than leaving the user hanging. Still, a black screen on a rooted device (while working on a stock device) could be a symptom of PairIP halting the normal app flow intentionally.
-
Redirect to Play Store / “Get the app on Google Play”: If you sideload an APK that is PairIP-protected and it uses the installer check, you may be immediately bounced to the Google Play Store listing of that app. The user experience might be: you open the app, and suddenly Google Play app launches, showing you the app’s page (as if prompting you to install it from there). In Google’s official terms, “If the installer check fails, users will be prompted to get your app on Google Play”. This behavior has been reported by users of paid apps – essentially, the app knows it wasn’t installed via Play, so it insists on the legitimate route. If the app is already installed via Play but somehow flagged as modified, it could also ask for re-installation.
-
License Error or Trial Expiry Messages: Apps that integrate the license check part of PairIP might show a dialog like “Licensing service could not verify purchase” or a generic “You are not licensed to use this app.” If offline, as noted, the Play Store might show an offline error, or the app itself might display something like “No network – unable to verify license” and then exit. The Stack Overflow discussion we saw had a crash due to a BadTokenException when PairIP tried to show a dialog from a background context– meaning the PairIP code attempted to alert the user (likely about a license issue) but encountered an Android window error. In any case, if you see unexpected dialogs or crashes related to LicenseClientV3 or similar, it’s a symptom of the license enforcement kicking in.
-
Logcat Clues (for developers/testers): If you have access to logcat (e.g., via adb logcat on a debug device), there are a few things to look for:
-
Look for the tag “SignatureCheck” or “VMRunner” – PairIP logs some info if the internal debug flag is enabled. For instance, if logging is on, you’d see VMRunner: Executing <bytecode file name> and VMRunner: Finished executing <file> in X ms. By default, logging is likely off in production, but modders sometimes enable it by flipping the loggingEnabled flag to “true” for insight.
-
An entry like VMRunner.executeVM or VMRunner.invoke in a stack trace indicates the app was in the middle of running the protected VM code when something went wrong (e.g., a crash). This could manifest if the VM encountered an unexpected situation (like a tampered bytecode or an active hook) and aborted. A Unity developer forum post showed a crash in libpairipcore.so (ExecuteProgram+196) in the– here ExecuteProgram is presumably an internal alias of executeVM, and the crash suggests the VM deliberately or incidentally caused a fault. Seeing libpairipcore.so mentioned in a native crash (tombstone) is a sure sign the protection was running when the app died.
-
If debugging with Frida or a similar tool, you might see the process terminate without warning as soon as you inject. In some cases, the app may kill itself (with kill(pid, SIGKILL)) if it detects the frida server or a debugger – this can look like an abrupt end of log output. Or, you might catch a message in logcat about ptrace or security right before the death.
-
Some have also noticed the creation of a secondary process (with the app’s UID) that quickly exits – likely PairIP’s fork for anti-debug. This can show up as app_process or <app_package>:pairip briefly in process listings.
-
Device-Specific Outcomes: On an emulator or uncertified device, the app might immediately exit. On a rooted device, some apps simply refuse to run (with maybe a toast “Unsupported device” if the dev was kind enough). PairIP doesn’t necessarily display a message for root; it often just ensures a crash. But a combination of SafetyNet/PlayIntegrity and PairIP might be used – e.g., a banking app could use Play Integrity API to show a message “This device is not supported” and PairIP to enforce closure of the app. If you see both behaviors (message then crash), that’s a coordinated integrity enforcement likely involving server attestation and PairIP local checks.
In summary, if an app quickly closes on launch, especially after you modified it or on a non-standard device, it could very well be PairIP at work. The typical user might just think “the app is buggy” or “doesn’t support my device,” but the underlying cause is the app intentionally terminating to protect itself. For testers, correlating these symptoms with the presence of libpairipcore.so or com.pairip classes in the APK will confirm the diagnosis.
Reverse Engineering PairIP: Approaches and Findings
Analyzing an app protected by PairIP is a challenge even for seasoned reverse engineers. It combines many techniques to impede analysis. Nonetheless, the security research community has started to peel back the layers. Here we discuss some methods and key findings from reversing PairIP’s internals (with the goal of understanding, not defeating it for malicious purposes):
-
Static Analysis (APK teardown): The first step is often to look at the app’s contents. Tools like APKTool or Jadx can reveal the added com.pairip classes in the dex files. From those, you can identify critical points such as where SignatureCheck.verifyIntegrity() is called, or how VMRunner.invoke() is used. Knowing the expected signature (the Base64 string in SignatureCheck) can tell you which developer or entity signed the official app. You might also find references to asset file names in the Java code (though they could be obfuscated strings). The presence of System.loadLibrary("pairipcore") and a native method declaration for executeVM in VMRunner is a dead giveaway of PairIP. However, static analysis of the native library is far more difficult. Opening libpairipcore.so in IDA Pro or Ghidra will show you a binary with almost no function names and a lot of opaque, seemingly arbitrary code. This is because the library likely uses opaque predicates and control flow flattening (common obfuscation techniques) to thwart decompilers. One researcher noted “it seems obfuscated with no useful strings exposed”, which aligns with the observation that the library imports things dynamically (so even typical library function names don’t appear as clear imports). Standard static analysis by itself doesn’t yield much beyond confirming that JNI_OnLoad exists and maybe spotting some suspicious system calls (ptrace, fork, etc.).
-
Identifying Registered Natives: Since the library uses JNI_OnLoad to register the native executeVM method, one static approach is to simulate or recover that registration. The JEB Decompiler team, for instance, created a plugin that emulates JNI_OnLoad to find JNI registrations. Using such a tool on libpairipcore.so found that “the aarch64 library libpairipcore.so registered one method for com.pairip.VMRunner.executeVM, and mapped it to a routine at 0x5F180”. This tells us where in the binary the actual native code for executeVM resides (once loaded). Knowing that offset, a reverse engineer can then focus on that part of the disassembly. In one case, after dumping the runtime-fixed library, the executeVM function was found at an offset (e.g., 0x54414 or similar). Recognizing this function is crucial, because it contains the VM interpreter loop.
-
Dynamic Instrumentation and Dumping: Given the runtime modifications and anti-analysis, dynamic analysis is often required. Researchers have used Frida in creative ways to bypass some of the anti-Frida measures. One approach: hook the process very early (before PairIP fully initializes) to intercept dlopen. By placing a hook on dlopen("libpairipcore.so"), you can execute code right after the library is loaded but before it does its nastiness. At that point, you can use Frida’s Stalker or other APIs to monitor what the library is doing – for example, logging all calls to RegisterNatives to catch where executeVM gets registered. Once the library has loaded and perhaps decrypted/unpacked its code in memory, you can dump the entire libpairipcore.so from the process memory. Tools like parasyte’s mem-dump or Frida-based dumpers can grab the RWX memory segments. This yields a “post-init” version of the library that is far more analyzable (since any runtime-decrypted code is now visible). Indeed, Byteria’s blog outlines steps: find RegisterNatives -> find executeVM in memory -> dump modified lib -> analyze executeVM.
It’s worth noting that you might need to temporarily disable some checks to reach this stage. Some have patched the in-memory image to nop out the ptrace calls or the self-kill calls on the fly using Frida, just to keep the process alive while dumping.
-
Analyzing the VM Interpreter: Once you have the dumped native code for executeVM, you’ll likely see a large function with a complex control flow graph. Reverse engineers have identified the structure as a typical VM dispatcher with opcode handlers. The top of the function sets up some context (VM entry, possibly saving registers or setting up a fake stack), then there’s a big loop/switch that reads an opcode from the bytecode and jumps to a handler. Each handler is a block of assembly that does whatever that opcode is supposed to do (it could perform arithmetic, manipulate an operand stack, call some native function, etc.). The presence of two jump targets for each opcode (likely success/fail or next instruction) was noted, meaning the VM might have a concept of conditional execution or different flows based on a condition code.
Byteria’s analysis gave a concrete example: opcode 0x58 was inspected, and within its handler they found the FNV-1 hash calculation being updated with each byte. This likely means opcode 0x58 (and many others) incorporate a hashing step, using uVar50 = uVar50 * 0x100000001b3 ^ data_byte repeatedly (which is the FNV-1 algorithm). They inferred that uVar50 was tracking a hash of something – possibly the bytecode stream or some critical data. This kind of operation is unusual in normal program logic, so it hints at an anti-tamper checksum. The fact that it’s spread across handlers could mean every executed instruction contributes to a running hash (e.g., to ensure the sequence of opcodes executed matches the expected sequence). If an opcode was altered or skipped, the hash at the end wouldn’t match, and the VM could detect it and abort. In summary, reverse engineering the VM is non-trivial, but it reveals that PairIP’s VM is not just a dumb interpreter – it has built-in safeguards like hashing to detect manipulation and possibly to tie the VM execution to a unique fingerprint.
-
Other Native Observations: Within libpairipcore.so, outside the VM loop, researchers found many of the anti-debug and environment checks we described earlier. For instance, Solaree’s GitHub report shows the library using dlopen/dlsym to get __system_property_read and then calling it in a loop to query properties. They also saw calls to access("/dev/__properties__/...") for various property namespaces (a way to iterate over the low-level property storage on Android). After that, it opens directories and files (using opendir, readdir) presumably to scan for known files (like checking for the existence of /magisk folder, etc.). Finally, it performs the Frida detection. The precise method for Frida wasn’t fully detailed, but one guess is it might attempt to connect to tcp:27042 (Frida default port) or look for the /data/local/tmp/frida-server process via some means. The key takeaway is that the native code is one giant sequence of checks and setup before and after running the VM code. It’s orchestrated in a way that if anything looks wrong, it can prevent the VM code from returning meaningful results to the app (or simply crash the app).
-
Restoring Stripped-Out App Data: Another interesting aspect of PairIP is that it can be used to hide string constants and other data from the Java side. The PNF Software blog mentioned a case where a protection (libpairipcore) removed static strings from the DEX, and instead, the app would call into a native function to retrieve those strings at runtime. Using JEB’s emulator plugin, they were able to run those routines to recover the original strings. This indicates that beyond anti-tamper, PairIP is also an obfuscator: developers can remove things like API keys or sensitive strings from their APK, and have PairIP supply them securely when needed. The native VM bytecode likely contains these strings (perhaps encrypted) and the logic to decrypt them. Only when the app runs under the PairIP VM are the strings produced and given back to the app. This technique ensures that even if someone decompiles the APK, they can’t find certain secrets in it – they’d have to break open the VM to get them.
Overall, reverse engineering PairIP is an arms race. Tools and techniques like emulation, hooking, and memory dumping are essential. The findings so far show a sophisticated VM-based protector that combines the best of many worlds: virtualization, environment checks, encryption, and self-modifying code. White-hat researchers approach it similarly to how one would approach a piece of malware or a commercial packer: by isolating it, dumping memory, and carefully bypassing checks one at a time to reveal the core logic.
Listing 1: PairIP’s Java SignatureCheck.verifyIntegrity() uses an SHA-256 hash of the app’s signing certificate to ensure the APK has not been re-signed or tampered. If the computed signature doesn’t match any of the expected values, a runtime exception is thrown to terminate the app
. This check is performed at application start-up, before any sensitive code runs.
The above snippet (reconstructed from reversed code) shows how straightforward the Java side check is – it relies on the unmodifiable nature of the APK signing. Bypassing this alone is easy (just remove the call), but the native side will perform its own validations as described.
Debugging and Bypass Strategies (White-Hat Perspective)
From a legitimate security research or app-testing perspective, one might want to temporarily bypass PairIP protections to analyze an app’s behavior or security. It’s important to note that doing so on software you don’t own can violate terms of service or even laws in some cases (for DRM), so the discussion here is strictly about white-hat analysis on apps you’re authorized to test or for academic curiosity. With that said, here are strategies that have been used:
-
Removing or Patching the Java Hooks: The most accessible way to weaken PairIP is to modify the app’s Java code. For example, using APKTool to decompile and then strip out the call to SignatureCheck.verifyIntegrity() in the Application class can avoid the immediate signature kill-switch. Indeed, researchers have noted that the Java integrity check “can be easily bypassed by removing the call”
. However, this is just step one. You could also stub out the LicenseClient calls – for instance, making LicenseClient.connectToLicensingService() return true immediately or bypassing dialog displays to avoid crashes like the BadTokenException. Essentially, disabling the com.pairip.licensecheck logic could let the app run offline or without purchase (for testing!). Keep in mind, after such modifications, you have to re-sign the APK, which PairIP’s native layer might catch unless you also disable the native signature check.
-
Bypassing Native Checks in Memory: Since modifying the native library on disk is very difficult (it’s packed/obfuscated), a common tactic is to patch it in memory at runtime. Using Frida, one can attach to the process (if you manage to sneak past its anti-Frida, perhaps by launching the app with Frida’s gadget or using an emulator with Frida built-in at a lower level). Once attached, you can use Frida to intercept certain functions. For example:
-
Hook ptrace and make it return an error (so when PairIP tries to ptrace itself to prevent debugging, it fails and maybe thinks it’s already being traced – you have to experiment carefully here).
-
Hook the function that calls kill(getpid(), SIGKILL) and prevent it from doing so (or change the signal to 0 which does nothing). If you identify the exact point where the library is about to terminate the process (perhaps when a check fails), you can NOP it out.
-
Return safe values for system property checks. Frida can hook the __system_property_read function or higher-level JNI calls that retrieve properties. You could make any check for ro.debuggable or ro.build.tags return values as if it’s a normal device (e.g., ro.build.tags = release-keys).
-
Simulate an always-passing environment: return “not rooted” for any root file existence check (you can hook open/access syscalls via Frida’s Interceptor and return -1/ENOENT for paths like /system/xbin/su to pretend they’re not there).
These in-memory patches can allow the process to continue further than it normally would. This is how researchers were able to dump the lib and observe the VM execution without interference. Essentially, you trick the protector into thinking everything is fine. This is a cat-and-mouse – for every check you bypass, there may be another one later. One has to methodically intercept many calls to comprehensively disable checks.
-
Using Xposed or LSPosed Modules: If you have control of the device (rooted device for testing), an Xposed module can be written to target the PairIP routines. For instance, hook VMRunner.invoke() in the app process: you could short-circuit calls for certain bytecode files. Suppose you identify one particular asset file that contains “the code that kills the app on tamper” – you might intercept invoke for that and simply not execute it (or always return a success value). One commenter in the APKiD thread mentioned blocking the asset from loading as a bypass, with caution to only block non-critical ones. Using Xposed, you could override readByteCode(filename) to return an empty byte array for a specific filename, causing that check to effectively do nothing. The risk is if that bytecode also contained something needed, the app might misbehave. This approach requires knowing or guessing what each asset file does.
Another Xposed approach is to hook into the Google Play licensing service (which runs in the Play Store process). If you can intercept the license query, you could feed a “LICENSED” response even if the user isn’t actually licensed. This is how older LVL cracks worked – by patching the result of the license check. But because PairIP likely relies on the official closed-source Play app, doing this might be non-trivial unless you patch the Play app itself or simulate the license service.
-
Emulator with Correct Signals: To analyze in an emulator without immediate death, one can create an Android Virtual Device (AVD) that passes as much integrity checks as possible. This means:
-
Use a build fingerprint from a real device (to pass property checks).
-
Ensure the emulator is Google Play certified (you can actually get an emulator with Google Play and with basicIntegrity/ctsProfile passing using some hacks or simply use a physical device).
-
Do not root the emulator (no root access, hide adb root too).
-
Disable developer options (PairIP might check if adb is enabled or if the device is debuggable).
By tuning the emulator, you might get PairIP to not realize it’s an emulator. There are projects that allow changing the emulator’s device properties (even the emulator’s device name, model, etc.). If done well, the app could run in the emulator, letting you use standard tools (like Android’s built-in “Layout Inspector” or memory dumps) in a more controlled environment. This doesn’t bypass everything (if you try to attach gdb, it might still catch you), but it can make the app at least not self-destruct.
-
Creating a Fake PairIP Library: In extreme cases, one might replace libpairipcore.so entirely with a custom made so that simply pretends to do what PairIP does. For example, you could write a libpairipcore.so that exports a dummy JNI_OnLoad and an executeVM that just returns some default value without doing any checks. Then modify the APK to include this fake library instead of the real one (ensuring the file name and architectures match). This is effectively what the modders of Northgard attempted with libRMS.so
. The challenge is, the rest of the app might expect certain behaviors or results from the real PairIP VM. If the protected bytecode was actually critical (not just checks but actual game logic), skipping it means losing that logic. The app might crash or not function properly because something that was supposed to happen in the VM didn’t happen. Therefore, a fake stub library is only viable if the VM was doing only security checks that you want to bypass, and not contributing essential outcomes. If that’s the case, the stub can just always report “all good” and let the app proceed. But if the VM calculates, say, a game puzzle solution, you’d break the app by removing it. In any event, constructing such a stub requires advanced skill in JNI and understanding of what the VM is expected to return.
-
Monitoring Execution: If one manages to neuter enough checks, you can then observe what PairIP was guarding. For example, after bypassing signature and license, you could run the app in a debugger (or instrument it) to see what those asset bytecodes are actually doing. This is more of an analysis technique than a bypass, but it’s the ultimate goal for a researcher: to fully disassemble the PairIP VM code back into meaningful logic. Tools like Unicorn (CPU emulator) or custom bytecode disassemblers might be employed to analyze the extracted bytecode files outside the app. This is a burgeoning area of research – as more people dump those bytecode files from various apps, patterns might emerge (perhaps it’s a variant of Java bytecode or some understandable format after all).
-
Caution and Legality: It should be stressed that bypassing DRM or license checks can be illegal in many jurisdictions (because of anti-circumvention laws). So, while a white-hat researcher might do this on an app they are assessing for security (with permission), doing it on proprietary apps to use them for free is not advised. From a defender’s perspective, knowing these bypasses helps improve the protection. Google can update PairIP to, say, detect if certain hooks are present or to use more advanced anti-debug (maybe integrating with hardware security in the future).
In conclusion, bypassing PairIP even temporarily requires a multi-faceted approach – patching, hooking, and emulating in tandem. It’s a testament to PairIP’s strength that it requires this level of effort, whereas older protections might be defeated by a single smali patch or a trivial root hide. Researchers have to combine static patches (removing known calls) and dynamic instrumentation to gradually disable or fool each check until the app is operational in a controlled environment for analysis. Even then, the custom VM means the code you’re interested in isn’t in a nice high-level form – you might end up reverse-engineering machine code anyway, just a different flavor of it.
Relationship to Play Integrity API and Future Outlook
PairIP is part of Google’s broader Play Integrity initiative, which can be seen as a multi-layered replacement for SafetyNet Attestation. While the Play Integrity API (PIAPI) focuses on attesting the device and app authenticity to a server (providing signals like “MEETS_DEVICE_INTEGRITY” or “LICENSED” to the app’s backend), PairIP operates on-device to enforce integrity in real-time. The two are complementary:
-
Play Integrity API is used by developers to get a signed verdict from Google’s servers about the device (and optionally, user account, app license, etc.), which the app can then forward to its server for verification.
-
PairIP (Automatic Integrity Protection) injects code into the app that locally checks the app’s integrity and environment and takes direct action (like blocking the app). It does not report anything to a server; it simply acts within the app.
Google’s documentation makes it clear: “SafetyNet Attestation API is deprecated and has been replaced by the Play Integrity API”. It then introduces that Google Play has added a new infrastructure (which we now know includes PairIP) starting in 2024. The Play Integrity ecosystem thus has: cloud attestation tokens, and automatic on-device protection. A developer can use both – for example, an online game might use the API to check device tampering on login (preventing known-cheater devices from connecting to servers) and also use PairIP to prevent the app from running at all on tampered devices (stopping cheaters from even loading the game UI).
One key relation is the “LICENSED” signal of the Play Integrity API. If a developer opts in, Google will include a field that indicates whether the user has legitimately acquired the app. This corresponds to the old “LVL license” check. In PairIP, we see it actively performing license checks itself. In the future, Google might unify these such that PairIP sets a flag that the API token also includes, ensuring consistency. Already, the Automatic Integrity Protection requires Play App Signing and is managed through Play Console, which ties it closely to Play services.
Currently, Automatic Integrity Protection is opt-in for select partners . But Google may expand this to more developers, possibly even as a default for new apps (especially games) distributed via the Play Store. The fact that it’s integrated into Play’s release process implies that over time, improvements to PairIP can be rolled out without developers having to modify their apps — Google can update the version of libpairipcore.so and the injected code as attackers learn to bypass older versions. In essence, it’s a moving target that Google controls, much like how Google Play Protect updates regularly to tackle new threats.
Another relationship worth noting is with Android platform security. Some features of PairIP could theoretically be done at the OS level (for example, blocking debuggers or enforcing installer integrity). Android 12+ introduced a safety feature where apps can signal they don’t want to be debugged even on developer devices (via android:debuggable="false" and some extra checks). But that’s not foolproof. PairIP goes further by including logic that would be too application-specific or heavy to include in every app by default. By making it an optional injection, Google can give enhanced security to those who need it without bloating every Android process. In the future, if PairIP proves very effective, Google might bake some of its concepts into Android itself (for instance, an OS-level toggle that only allows running apps that pass integrity checks).
Developers planning for the future should keep an eye on Google Play’s App Integrity offerings. PairIP (Automatic Integrity Protection) might become more broadly available – perhaps in 2024-2025 it will open to all developers via an API or a simple checkbox in Play Console. There might also be more synergy between the explicit API and the automatic protection, with Google encouraging use of both: automatic in-app protection for basic defense, and the API for server-verified decisions (like banning users or restricting features on altered devices).
One thing to consider is the arms race with attackers. History shows that given enough time and incentive, even advanced protections (DRM, Denuvo on PC games, etc.) get bypassed. PairIP will likely be no exception – already researchers have found ways to dump and analyze it. It’s possible that modding communities will develop tools to semi-automate patching of common PairIP patterns (though it’s very hard, given the obfuscation and the custom nature per app). Google will surely continue to iterate on it – for example, they could incorporate hardware-backed attestation (device tamper flags from the TrustZone) to detect rooted devices more reliably, or use self-healing code that re-checks itself continuously.
From a user perspective, PairIP doesn’t change much except that getting “modded” or sideloaded apps might become more frustrating (they just won’t work). From a developer perspective, it’s largely a boon: a powerful shield provided by the platform. And from a security analyst perspective, it raises the bar we have to clear to do deep app analysis – but it also makes it more interesting!
Detecting PairIP-Protected Apps
If you’re a developer or tester wanting to know if an app uses PairIP (Automatic Integrity Protection), there are a few straightforward indicators:
-
Presence of libpairipcore.so: Check the APK’s lib folder for a file named exactly libpairipcore.so. If it’s there (especially in both arm64-v8a and armeabi-v7a directories), that’s a strong sign. This library name is quite distinctive. For example, APKiD’s output for a protected APK shows libpairipcore.so and labels it accordingly. No legitimate functionality (outside this protection) would have a library by that name.
-
PairIP Java Package: When you decompile the APK (e.g., using Jadx or by converting dex to jar), search for “pairip”. You will likely find the package com.pairip with several classes as mentioned. If you see com.pairip.VMRunner or com.pairip.SignatureCheck, it’s conclusive – those are part of PairIP’s client code. The naming has remained consistent (since it’s hardcoded in the library’s JNI mappings). The classes might be slightly renamed in future (e.g., they could change package name to something less obvious), but as of now, “pairip” is the keyword.
-
Asset file anomalies: Because PairIP moves code into asset files, you might notice in the APK’s assets folder a collection of files that don’t belong to the app’s normal assets. They often have random-looking names (strings of characters). For instance, the image we saw showed files like B4Xz1P3JSIjMScli and KNJS... in the assets【36†】. If an app normally wouldn’t need such data files, their presence could indicate they are PairIP bytecode files. Size can be a hint too – they might be tens of KB each, possibly with a file extension omitted to avoid drawing attention. Not all apps will have obvious asset files, but it’s one thing to look for.
-
Behavioral clues: If you run the app on an emulator or test device and it instantly crashes or opens the Play Store, and you know the app is a paid app or high-profile target, suspect PairIP. Many ordinary apps won’t self-terminate on root/emulator (they might show a warning at best), but PairIP-protected ones will aggressively close. So if you see that pattern (works on stock device, fails on rooted/emulated device with no clear error), that hints at an integrity check. You can confirm by scanning logcat for the tags or messages discussed earlier.
-
APKiD or Similar Tools: The community has been updating scanners to flag PairIP. APKiD, for example, added a signature to detect PairIP’s presence (it looks for the lib and possibly the VMRunner pattern). Running APKiD on an APK will output something like “protector: Google Play Integrity” if PairIP is found. This is useful when you have many apps to triage and want to quickly pick out those with such protections.
For those building automated testing frameworks or app analysis pipelines, encountering a PairIP-protected app means you should adapt your approach:
-
Dynamic analysis (like UI automation or instrumentation tests) may fail because the app won’t run in your instrumented environment. You may need to allow using a real device with Play Store to test such apps, or stub out the checks as described if you have the skill.
-
Static analysis will miss some code (since it’s in assets). If you rely on static analysis for vulnerabilities, be aware that some logic is hidden. However, security vulnerabilities are less likely in the protected parts (since those are mostly integrity logic), but you never know – if someone misused the PairIP VM for game logic, that logic could have bugs that static scanners won’t see.
-
Manual security review: If you’re pen-testing an app and see PairIP, schedule extra time. You might need to get creative to bypass it in order to inspect the app’s deeper functionality. Alternatively, you focus on testing the app as a black box (since white-box approaches are hindered).
From a defensive point of view, developers using PairIP should test their apps thoroughly in various scenarios:
-
Ensure that turning on PairIP doesn’t inadvertently lock out legitimate users (for example, someone who legitimately bought the app but has no internet at first launch – does your app handle that gracefully?).
-
Watch crash logs in the Play Console (Google even advises monitoring for increased crashes). If enabling integrity protection caused a spike in crashes, investigate if something in the PairIP flow is misbehaving (like the dialog issue some devs hit stackoverflow.com).
-
Don’t mix multiple protections without careful testing. Google warns “take care when mixing anti-tamper solutions”. If you already have another protector (like commercial obfuscators), make sure they don’t conflict with PairIP’s injected code.
Conclusion
PairIP represents a significant advancement in Android app protection, elevating the platform’s built-in defenses to a new level. Acting as a built-in anti-tampering, anti-piracy, and anti-cheat mechanism, PairIP leverages Google’s ability to inject and hide code within apps to secure them in ways that were previously only available via third-party solutions or custom implementations. With its combination of cryptographic signature checks, distribution enforcement, environment verification, and a custom virtual machine, PairIP makes it exceedingly difficult to modify an app or run it in an unauthorized environment without detection.
Our deep dive into libpairipcore.so and its surrounding components highlights the sophistication of this protection. It’s not a trivial checksum or simple license key – it’s effectively a miniature VM-based obfuscator and shield within the app. Google has drawn on techniques seen in advanced malware and commercial game protections (like dynamic code loading, virtualization obfuscation, anti-debugging traps) and integrated them seamlessly into the Android app ecosystem. The result is that apps using PairIP gain a robust defense: repackaging is thwarted, rooted or emulated environments are scrutinized (often leading to the app exiting), and even live debuggers are kept at bay. For developers worried about their APKs being modded or pirated, PairIP (via the Play Integrity infrastructure) offers a powerful tool – one that requires minimal effort on their part. It can ensure users running the app have the official, untampered version, and it can nudge users to obtain the app legitimately on Google Play. Especially for paid apps and games, this can protect revenue and maintain a level playing field (e.g., in online games where mods or cheaters could ruin the experience).
However, no security is unbeatable. PairIP raises the cost and skill required to crack an app, but given enough incentive, determined reverse engineers will try to circumvent it. We’ve seen that with enough knowledge, one can dump the PairIP VM code and analyze it – but this is far from what casual pirates can do. PairIP’s goal isn’t to be unbreakable; it’s to dramatically reduce the number of people who can break it, ideally dissuading the casual modding scene. In that, it appears to be successful so far.
It’s also a reminder that mobile app security is evolving. Where once a simple root check or ProGuard obfuscation was the norm, we now have full-fledged virtualized code and real-time self-defense. This may push the community (both attackers and defenders) to sharpen their tools. On one hand, researchers will innovate new ways to analyze such protected code (perhaps devirtualization techniques or improved Frida cloaking). On the other hand, Google will likely refine PairIP, maybe tying it into hardware (imagine requiring a trusted execution environment to decrypt some code) or improving performance so that more of the app can be protected without user impact.
In the big picture, PairIP and the Play Integrity API together are Google’s answer to a longstanding problem on Android: how to assure developers that distributing on Android/Play Store is safe from rampant app abuse. By tackling the distribution and tampering issues, Google strengthens the Android ecosystem’s security and profitability for developers. Users benefit too, as they’re less likely to be harmed by rogue modified apps masquerading as legitimate ones.
In summary, PairIP is a milestone in Android application security – a Google-supplied layer that transforms how apps can defend themselves. It embodies the principle of defense-in-depth, forcing any adversary to overcome numerous hurdles across Java and native layers, some of which run in a completely custom environment. As it rolls out further, we expect to see the cat-and-mouse between protectors and crackers play out in the Android arena much like it has on desktop software. And for those of us in security research, PairIP provides a fertile ground for learning and honing reverse engineering skills – after all, to understand the shield, one must attempt to break it, and in doing so, appreciate the craftsmanship behind it.
Sources: Google & Android developer documentation, reverse engineering reports, and community analyses of PairIP-protected apps have all informed this deep dive into the PairIP mechanism. These insights shed light on PairIP’s inner workings and its role in the wider Play Integrity framework.
For further questions you can contact with us from live chat (heysmmreseller or heysmmprovider support team)