Documentation

Go to Portal Website

Rename Classes

PlanPlatformsMASVS
TeamAndroidMASVS-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:

  1. Manifest-Referenced Classes: Activities, services, broadcast receivers, content providers, and other components declared in AndroidManifest.xml
  2. XML-Referenced Classes: Custom views, layout behaviors, and framework configuration classes referenced in XML resource files
  3. Reflection-Loaded Classes: Classes referenced via Class.forName() or as string literals in FQCN format
  4. ServiceLoader Classes: Implementation classes listed in META-INF/services/ configuration files
  5. JNI-Referenced Classes: Classes appearing in native method signatures or FindClass calls in native libraries
  6. Parcelable/Serializable Classes: Classes implementing Android IPC mechanisms that rely on class names
  7. Annotation-Marked Classes: Classes with @Keep annotations
  8. 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

PlatformMinimum VersionStatus
AndroidAPI 26+ (8.0)✅ Supported
iOSN/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.