Adversaries may attempt to make a payload or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the device or in transit. This is common behavior that can be used across different platforms and the network to evade defenses.
Payloads may be compressed, archived, or encrypted in order to avoid detection. These payloads may be used during Initial Access or later to mitigate detection. Portions of files can also be encoded to hide the plaintext strings that would otherwise help defenders with discovery. Payloads may also be split into separate, seemingly benign files that only reveal malicious functionality when reassembled.
AndroidOS/MalLocker.B has employed both name mangling and meaningless variable names in source. AndroidOS/MalLocker.B has stored encrypted payload code in the Assets directory, coupled with a custom decryption routine that assembles a .dex file by passing data through Android Intent objects. 
Charger encodes strings into binary arrays to make it difficult to inspect them. It also loads code from encrypted resources dynamically and includes meaningless commands that mask the actual commands passing through.
|S0539||Red Alert 2.0|
Windshift has encrypted application strings using AES in ECB mode and Blowfish, and stored strings encoded in hex during Operation BULL. Further, in Operation BULL, encryption keys were stored within the application’s launcher icon file.
|S0318||XLoader for Android|
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Dynamic analysis, when used in application vetting, may in some cases be able to identify malicious code in obfuscated or encrypted form by detecting the code at execution time (after it is deobfuscated or decrypted). Some application vetting techniques apply reputation analysis of the application developer and can alert to potentially suspicious applications without actual examination of application code.