Configuration of Shielding Tool rules
You can specify a rules list in the App Shielding configuration. This list determines how App Shielding will modify the Android application, especially with regards to shielding and obfuscation.
Find below information about how the rules list can be used to match classes, fields, and methods to resolve issues with shielding or obfuscation.
Syntax
class_op+ [[!]@annotation] [[!]access] [[!]flag]* [[!]class_spec] class_name [[!]extension class_name] (; | {
[member_op]* [[!]@annotation] [[!]access] [[!]flag]* [member_type]
})
You can specify as many rules as needed, and the rules are matched from top to bottom.
When configuring rules, you can use one line per rule, or, for better readability, you can use multiple lines for one rule.
# Comment
class_operation [[!]access] [!]class_spec class_name [[!]extension class_name] (; | {
[[!]access] [[!]class_mod] member type name;
})
set_operation name value;
firstdex class_name;
verify regex;
Definitions
The following tables list the commands to be used in a rules list.
class_operation options
member_operation options
Class and member definitions
Element | Description | Supports wildcards | Can be negated |
---|---|---|---|
@annotation | Optional. A qualified class name, e.g. @com.example.myannotation. | ✓ | ✓ |
access |
Optional. Possible values:
|
✓ | |
flag |
Optional. Possible values:
Multiple choices are allowed. |
✓ | |
class_spec |
Optional. Possible values:
|
✓ | |
class_name | Mandatory. The fully qualified name of the Java class. | ✓ | |
extension |
Optional. Possible values:
Must be followed by class_name. |
✓ | |
member_type |
Optional. Possible values:
|
||
return_value | Optional. Primitive type or fully-qualified name of a Java class. | ✓ | |
member_name |
Mandatory. The name of the class field(s) and/or method(s). The following additional matchers are available:
|
✓ | |
value | Optional. A double-quote string, any integer or Boolean (true or false). | ||
method_arguments |
Optional. Comma-separated list of arguments in class_name format in brackets, e.g. (class_name, class_name) To be used for method identification only. Use (...) to match methods with at least 1 argument (any type). |
✓ |
Specification
Negating
For the rules, most class specifiers can be negated by adding an exclamation mark in front of them.
Wildcards
Wildcards can be used as follows:
- * matches zero or more characters.
- + matches one or more characters.
- ? matches exactly one character.
*Test matches MyTestOne and Test but not TestTwo.
Comments
Comments are prefixed with #.
# Verify a single file
verify "assets/my-asset.bin";# Verify all files in the assets folder
verify "^assets/.*";# Verify all HTML/JS in the assets folder
verify "^assets/(.+)\.(html|js)$";# Verify all files inside the APK
verify ".*";
Rule examples
Class-level rule
-
No values from MyClass will be removed:
untouchable class com.example.MyClass;
-
No values from any class inside the com.example.* package will be removed:
untouchable class com.example.*;
-
No class that implements MyInterface will be modified:
untouchable class * implements com.example.MyInterface;
-
No class that (immediately) derives from MyBaseClass will be modified:
untouchable class * extends com.example.MyBaseClass;
Method-level rule
-
This rule only matches the public static method getValue that returns int within MyClass:
untouchable class com.example.MyClass
{
public static method int getValue;
} -
This method matches any public method called getValue and setValue in any class that implements SomeInterface. All other methods in these classes can still be modified:
untouchable class * implements SomeInterface
{
public method * getValue;
public method void setValue;
} -
To match a constructor, it must be added as a regular method <init> with a void return value:
untouchable class com.example.MyClass
{
public method void <init>;
}