Read the entry point first
Both protections act before the app's own code, so the manifest names the component that runs first. Open the manifest and read the application class, then list the native libraries and the dex files. That gives you the three places where an injected layer shows up, and it costs one pass over the archive.
A build with no protection names the developer's own application class and ships the libraries the app's dependency graph implies. A wrapped build names something else, or adds metadata, providers and libraries that the app's own code does not reference. The difference is the signal.
Artefacts that indicate PairIP wrapping
PairIP is applied after the developer's build, at distribution, so the wrapper never passes through the app's own shrinker and its names are not renamed. That makes its footprint stable to read.
- The manifest names a wrapper application class. The developer's entry point is replaced by a stub, and a licence flag or metadata entry often sits beside it.
- A native library ships for each ABI. The library is not part of the developer's own stack, and it appears in every architecture directory the build supports.
- A licence check package appears in the dex. The package handles the store message that the wrapper shows when the install source or signature does not match.
- Strings point at the store. The wrapper's own text survives obfuscation because it was added after the developer's build, so it reads as ordinary prose.
Those artefacts confirm that wrapping happened and say nothing about which checks run in this version. Read the stub to see which native functions it calls and what each result controls.
Artefacts that indicate AppDome
AppDome is a build service rather than a post-distribution wrapper, so its layer is present in the APK as it was produced. The injected runtime announces itself through additional native libraries, an initialisation path that runs before the app's own setup, and extra classes and providers that the app's own code does not reference. Vendor strings and configuration values can appear among the added constants.
The category is recognisable even when the exact file names change between versions. A build with a long list of native libraries where the source project used few, plus an application class that delegates to a generated initialiser, looks like an injected protection runtime rather than an ordinary app.
What detection does not prove
Presence is not enforcement. A library can be shipped and never consulted on the flow you care about, and a check that runs can be configured to observe rather than to refuse. Detection tells you what to expect from the build, and it does not tell you which checks run against the target action.
Finding one product does not rule out the other, or a third. An app can pass through a commercial protector at build time, through AppDome, and then through Play wrapping, and each layer leaves its own artefacts. Treat the checks as independent rather than as a single answer.
Detection also says nothing about the network path. Some protection layers guard startup and leave traffic untouched, while others hook the HTTP stack and inspect requests. The file layout cannot tell you which of those applies, and a plan built on the assumption that it can will miss the layer that matters.
The diagnostic step that settles it
Confirm by behaviour once the file review narrows the possibilities. Run the app on a stock device, watch the startup log, and observe whether the target call still works. Compare a device where the protection is satisfied with one where the install or the environment differs, and note where the two runs diverge.
- List the native libraries and compare them with an earlier version of the same app to see exactly what was added.
- Check the dex count and watch for classes that resolve only at run time, which indicates a layer that loads code rather than one that only renames it.
- Watch the first network call and the startup sequence together, so you can tell whether a check gates the process or the traffic.
- Read the entry point chain and record which component runs first, which is the component whose result decides everything downstream.
What this changes about a project
The result of detection is a method, not a diagnosis. A PairIP build with an untouched network path can be approached through observation on a runnable install. A build carrying a second runtime that hooks the HTTP layer needs that layer identified before the request work starts. When both are present, the order of work follows the entry point rather than the file list.
Send the APK and the target action. We identify the layers actually in the build, separate process gating from protocol behaviour, and reconstruct the request flow. AppDome reverse engineering covers injected runtimes, and PairIP reverse engineering covers the distribution wrapper.
Related work
Reviewed 28 September 2026 · SReverse research desk