Rename Classes
| Plan | Platforms | MASVS |
|---|---|---|
| Team | Android | MASVS-RESILIENCE-3 |
Overview
Rename Classes (RenameClasses) obfuscates application code structure by renaming internal class names to short, meaningless identifiers. This build-time transformation replaces human-readable class names (e.g., PaymentProcessor, UserSession) with sequential obfuscated names (e.g., ca, cb, cc), making reverse engineering significantly more difficult for attackers attempting to understand the application's architecture.
The control operates during the AppTego Android protected build process after the protected app is decompiled to smali bytecode. It systematically renames classes while preserving functionality by protecting classes that are resolved by name at runtime (manifest components, XML resources, reflection, JNI, etc.).
How It Works
Class Name Obfuscation
The control analyzes all smali files in the decompiled application and builds a rename map for internal classes. Each qualifying class is assigned a sequential obfuscated name using a deterministic base-26 naming scheme: ca, cb, cc, ... cz, caa, cab, etc.
Original class structure:
com/example/tenant/
├── payment/
│ ├── PaymentProcessor.smali
│ ├── CreditCardValidator.smali
│ └── TransactionLogger.smali
└── auth/
├── LoginManager.smali
└── SessionHandler.smali
After RenameClasses:
com/example/tenant/
├── payment/
│ ├── ca.smali
│ ├── cb.smali
│ └── cc.smali
└── auth/
├── cd.smali
└── ce.smali
The package structure is preserved (classes remain in their original packages), but the class names themselves become meaningless identifiers.
Protected Classes
The control automatically protects classes that must retain their original names for runtime correctness:
- Manifest-Referenced Classes: Activities, services, broadcast receivers, content providers, and other components declared in
AndroidManifest.xml - XML-Referenced Classes: Custom views, layout behaviors, and framework configuration classes referenced in XML resource files
- Reflection-Loaded Classes: Classes referenced via
Class.forName()or as string literals in FQCN format - ServiceLoader Classes: Implementation classes listed in
META-INF/services/configuration files - JNI-Referenced Classes: Classes appearing in native method signatures or FindClass calls in native libraries
- Parcelable/Serializable Classes: Classes implementing Android IPC mechanisms that rely on class names
- Annotation-Marked Classes: Classes with
@Keepannotations - Framework Classes: Android SDK classes (
android.*,androidx.*,com.google.*,kotlin.*)
Multi-Pattern Replacement
After building the rename map, the control uses an Aho-Corasick automaton to perform efficient single-pass replacement of all class references across the entire codebase. This ensures that every reference to a renamed class (in field types, method signatures, inheritance declarations, etc.) is consistently updated.
Threats Mitigated
Reverse Engineering and Code Comprehension
Obfuscating class names forces attackers to reverse engineer the application without the benefit of meaningful identifiers. Instead of seeing PaymentProcessor and immediately understanding its purpose, attackers encounter ca and must deduce functionality through time-consuming static or dynamic analysis.
Intellectual Property Protection
Class names often reveal proprietary algorithms, business logic structure, and architectural patterns. Renaming classes obscures this intellectual property, making it harder for competitors to understand and replicate your application's design.
Automated Attack Tool Evasion
Many automated analysis tools and decompilers rely on class name patterns to identify security-relevant code (e.g., AuthManager, CryptoHelper). Obfuscated class names reduce the effectiveness of these automated reconnaissance tools.
Caveats and Limitations
Android Entry Points Are Preserved
Classes declared in AndroidManifest.xml (activities, services, etc.) cannot be renamed because the Android framework resolves them by name at runtime. These entry points will remain readable in decompiled code. This is intentional and necessary for application functionality.
Reflection-Based Class Loading Requires Explicit Keep Rules
If your application or its dependencies load classes by name using reflection (Class.forName("com.example.MyClass")), those class names must be protected from renaming. The control automatically detects FQCN string literals, but complex reflection patterns (e.g., constructing class names dynamically from string concatenation) may require manual intervention or allowlist configuration.
Framework and Third-Party Libraries Unchanged
The control only renames classes within the protected application's own codebase. Android SDK classes, Google Play Services, and third-party library classes remain unchanged because they are resolved from separate DEX files or system frameworks.
Complementary to RenamePrivateMembers
For maximum obfuscation, enable both RenameClasses (class name obfuscation) and RenamePrivateMembers (method and field name obfuscation). Used together, these controls make the codebase significantly more difficult to reverse engineer.
Build-Time Only
This is a build-time transformation applied to smali bytecode. Classes loaded dynamically at runtime (e.g., via plugin systems, downloaded modules) will not have obfuscation applied unless they are rebuilt through the MobileDefender build pipeline.
No Impact on R8/ProGuard
This control operates independently of R8/ProGuard obfuscation. If the tenant application already uses R8 with class obfuscation enabled, MobileDefender's RenameClasses control provides an additional layer of obfuscation on top of R8's transformations.
Support Matrix
| Platform | Minimum Version | Status |
|---|---|---|
| Android | API 26+ (8.0) | ✅ Supported |
| iOS | N/A | ❌ Not Supported |
How to Enable the Control
Navigate to Code Obfuscation from the AppTego portal, and expand the Name Obfuscation section. Under this section you will find the Rename Classes control. Click Enable to apply it to the next protected build.
API Configuration Example
Enable Rename Classes with protection mode:
{
"RenameClasses": {
"protection": true
}
}
The control does not support detection mode (no detection key). Set protection: false to disable class renaming.
Related Controls
- RenamePrivateMembers: Renames private methods and fields to obfuscated identifiers, complementing class-level obfuscation
- EncryptStrings: Encrypts string literals to prevent static analysis of hardcoded values
- CallIndirection: Redirects static method calls through a dispatcher to obscure call graphs