Binding

The binding process modifies the Dalvik class files (classes.dex), by extracting values and constants from the application code and rewriting them so that these values will be invalid in the application without App Shielding.

When the app is launched, App Shielding will initialize these values correctly, or provide them for the app only if the security policy is satisfied.

This approach makes it extremely difficult for an attacker to attempt to remove App Shielding from the app, since the app will be missing key pieces of information without it.

There are two types of binding mechanisms used:

Push binding:
These values are extracted and removed from the app. After App Shielding has initialized, these values will be injected (pushed) into the relevant static class variables (fields). The app code is rewritten to fetch this value from this static class field.

Pull binding:
These values are also extracted and removed from the app, but the app code has been modified to fetch the values by calling a native method provided by App Shielding. App Shielding will only return this value if the security policy is met.

All extracted values are encrypted and stored in the .APK file.

Excluding classes from binding

Since some parts of the app code need to run before App Shielding is launched, the Shielding Tool will automatically trace and mark these parts as untouchable, meaning that they should not be modified in any way.

By default, Application <clinit> and all variables and method calls invoked from it are marked as untouchable. Reflection may become an obstacle and prevent the tracer from finding certain method calls.

For these cases there is a generic way to exclude classes and methods in a declarative manner so that the Shielder tool will not modify them in any way by marking them as untouchable. See Configuring Shielding Tool rules for information on how this is done.