The evolution of Android malware has made incontestable progress in the last few years and it often follows in the footsteps of PC-based malware, except that it happens at an accelerated pace.
Often, malicious apps gain control of a system in several steps, using different modules. There is typically only one initial module which, once it gets executed, either drops some embedded modules or downloads other modules and installs them to achieve its full range of mischievous behavior.
On the Android platform, users have limited visibility when installing packages, especially when side-loading (i.e. manually installing packages or installing from non-official app markets). This is why most Android malware that includes other malware does this embedding in the simplest way: they simply include the payload either as a raw resource or as an asset in their own package.
This used to be the case for PC-based malware when simple Trojan horse programs (often called “Droppers”) were simply attaching other malicious executable files as resources or appending them to their main executable. However, this process soon changed and malware authors started to use encryption to obfuscate those embedded modules in an attempt to slow down discovery and detection by security products.
It looks like the same thing is currently happening with Android malware.
For instance, Android.Gamex is using a trivial encryption (byte XOR with 0x12) to hide a package in assets/logos.png.
Here is an encrypted block from that file:
And here is that block after decryption:
The actual code to decrypt the data is quite small:
The availability of strong cryptographic functions in the standard Android API makes them an equally easy-to-implement option for obfuscation. For instance, Android.Pris uses DES encryption to hide its payload in assets/config1.
In the following image we can see what the decryption code looks like:
Certainly, it is more complicated than the XOR decryption in the preceding example, but it is still very easy to code and provides a much stronger encryption. We can see in the above example that DES decryption is used with the secret key 19821208. Not a particularly strong key, but it does the job. This key actually looks like a date—it could be anything from the author’s birthday to the day that his favorite pet died.
The threat is employing the same decryption scheme for downloaded packages and for command-and-control (C&C) server traffic. Strangely enough, we have seen the code from this threat reused in some droppers for Android.Jsmshider, but even though some embedded packages are encrypted with DES, the package for Android.Jsmshider is stored as a plain unencrypted raw resource. I guess malware writers have to cut corners sometimes to meet deadlines!
Today’s mobile processors provide enough computational power for industry-standard encryption and these strong encryption schemes become a standard component of the operating environment. It seems only natural to expect this trend of encrypting components to consolidate for mobile malware, but Norton Mobile Security is not fooled by these techniques and is able to detect these threats.