Information Security 40 min read

Can You Hide Android App Features from AI‑Based Detection? A Dynamic Obfuscation Guide

This article explores why Android apps are increasingly linked in AI‑driven security assessments, examines academic papers on feature extraction, compares static and dynamic obfuscation techniques, reviews industry protection solutions, and proposes a plug‑in‑based dynamic obfuscation framework that maximizes feature dispersion while preserving app functionality.

Inke Technology
Inke Technology
Inke Technology
Can You Hide Android App Features from AI‑Based Detection? A Dynamic Obfuscation Guide

Background

AI‑based feature analysis is widely used for application security and privacy evaluation. Platforms may associate multiple apps from the same developer, causing collateral treatment of non‑offending apps when one is flagged. Developers lack effective channels for analysis and must resort to technical methods to increase feature dispersion and avoid unintended association.

App Feature Extraction Techniques – Current Research

1. Paper References

Because most feature‑extraction methods are black‑box, we surveyed representative papers to infer detection points and key technical features:

Function‑call graphs (call graph, PDG)

Variable feature matrices

Platform API call sequences

Network traffic patterns

2. Technical Direction Summary

Dynamic runtime features such as function‑call relations, PDG dependency graphs, variable matrices, API sequences, and network flow are currently the most effective targets; static symbol obfuscation is largely ineffective against them.

Static Obfuscation vs. Dynamic Obfuscation

Feature

Static

Dynamic

Class/Method names

String constants

Function‑call relations

Variable features

PDG

Platform API sequence

?

Network traffic

Sandbox file system

Industry App Hardening Solutions

1. VirtualApp Virtualization

VirtualApp creates a sandboxed Android environment similar to Docker, allowing full control over installation, startup, file storage, and system hooks. While it hides the original APK, the resulting app exhibits obvious shell characteristics, making it a "feature‑bearing" obfuscation.

VirtualApp diagram
VirtualApp diagram

2. Commercial Hardening (DexGuard, etc.)

Commercial solutions combine Dex dynamic obfuscation, VMP, native code packing, OLLVM, certificate checks, anti‑debug, anti‑emulator, anti‑hook, and root detection to hide code features. DexGuard’s extensive static and dynamic techniques (name obfuscation, local code virtualization, control‑flow flattening, call hiding, algorithm obfuscation, native code obfuscation, data encryption, log removal) are valuable references.

DexGuard features
DexGuard features

3. Hook‑Based Auditing Systems

These inject a Hook framework into the app to intercept all internal behavior. They are highly confidential and unsuitable for feature dispersion.

Proposed App Feature Dispersion Techniques

1. Feature‑Based vs. Feature‑less Obfuscation

Existing hardening focuses on protecting core logic, not on eliminating detectable features. We need "feature‑less" obfuscation that introduces no new identifiable traits while dramatically increasing inter‑app feature distance. DexGuard provides many useful ideas, but its own features remain detectable.

2. Android App Build Process

Understanding the compilation and packaging pipeline helps identify insertion points for dynamic obfuscation.

a. Overall Packaging Flow

Packaging flow
Packaging flow

b. Code Compilation Flow

Compilation flow
Compilation flow

3. Obfuscation Workflow – Forward vs. Reverse

Unpack APK/AAB, extract XML, resources, .so, .dex.

Decompile dex to smali.

Perform multi‑dex expansion to bypass 65 535 method limit.

Apply a series of smali‑level obfuscation plugins.

Recompile smali to dex.

Re‑link resources.

Package new APK/AAB.

Align and re‑sign the package.

Overall Architecture

The framework is implemented in Python, orchestrating tools such as apktool, aapt2, bundletool, and a custom BundleDecompiler.jar (patched for Android 12 and AAB support). Plugins are loaded dynamically, each implementing a specific obfuscation strategy.

Framework architecture
Framework architecture

Command‑Line Example

<code>python3 obfuscapk/cli.py -p -i -e --use-aapt2 \
  -o LibEncryption -o AssetEncryption -o CallIndirection -o ArithmeticBranch \
  -o Goto -o FieldRename -o MethodRename -o ClassRename \
  -o Rebuild -o NewAlignment \
  "$1" -d "$2" \
  --obfuscate-packages-file "$OBFUSCATE_PACKAGES_FILE"
</code>

4. Plugin Design

Obfuscator plugins inherit from IBaseObfuscator and implement obfuscate(self, obfuscation_info) . Plugins are categorized as trivial, rename, encryption, code, resource, or other. The Obfuscation context tracks state, remaining field/method capacity, and provides utility methods for file handling.

<code>class IBaseObfuscator(ABC, IPlugin):
    def __init__(self):
        self.is_adding_fields = False
        self.is_adding_methods = False
    @abstractmethod
    def obfuscate(self, obfuscation_info: Obfuscation):
        raise NotImplementedError()
</code>

Core Workflow Code

<code>def perform_obfuscation(input_apk_path, obfuscator_list, ...):
    obfuscation = Obfuscation(...)
    manager = ObfuscatorManager()
    for name in obfuscator_list:
        obfuscator = manager.get_obfuscator(name)
        obfuscator.obfuscate(obfuscation)
    obfuscation.cleanup()
</code>

Obfuscation Strategies

a. Rename (Class, Field, Method)

Renames classes, fields, and methods while respecting black‑/white‑list configurations. Order matters: FieldRename → MethodRename → ClassRename to keep package‑based filters effective.

<code>python3 obfuscapk/cli.py -p -i -e --use-aapt2 \
  -o FieldRename -o MethodRename -o ClassRename \
  "app.apk" -d "app‑mod.apk" \
  --ignore-packages-file ignore.txt \
  --obfuscate-packages-file obfuscate.txt
</code>

b. Encryption

Encrypts assets, constant strings, resource strings, and native libraries, inserting runtime decryption logic. Example strategies:

AssetEncryption – encrypts files accessed via AssetManager .

ConstStringEncryption – encrypts literal strings in code.

ResStringEncryption – encrypts strings in resource XML.

LibEncryption – encrypts .so files and rewrites load logic.

c. Code‑Level Dynamic Obfuscation

Implements techniques that alter runtime characteristics without changing semantics:

ArithmeticBranch – inserts meaningless arithmetic branches.

AdvancedReflection – rewrites sensitive API calls to use reflection.

CallIndirection – extracts sub‑methods and replaces calls with indirect invocations.

Goto – injects goto statements to scramble control flow.

MethodOverload – creates overloaded variants with extra parameters.

Reorder – randomly shuffles code blocks marked with special labels.

Reorder Strategy Example (simplified)

<code>class Reorder(ICodeObfuscator):
    def obfuscate(self, obfuscation_info):
        for smali_file in obfuscation_info.get_smali_files():
            # Insert jump labels and invert if‑conditions
            # Then collect code blocks marked with "#!code_block!#"
            # Shuffle blocks and write back
            pass
</code>

Conclusion and Outlook

We built an extensible dynamic obfuscation framework supporting unpack‑obfuscate‑repack workflows, integrating static, encryption, and dynamic strategies to achieve feature dispersion. Evaluations show effective reduction of cross‑app association. Future work must address emerging techniques such as weighted API‑PDG and variable similarity matrices, and consider whether the goal should remain pure evasion or shift toward transparent, explainable analysis for developers.

AndroidsecurityDynamic AnalysisApp ObfuscationFeature Dispersion
Inke Technology
Written by

Inke Technology

Official account of Inke Technology

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.