In our earlier blogs, we have highlighted how Android Malware authors are quickly adopting various tricks from the age-old and vast pool of desktop Malware tricks. In this blogpost, we will talk about one such trick which is an adoption from desktop malware.
While processing a recent bunch of malware collections, we have noticed heavy use of reflections in quite a few Android samples. It is important to note that the usage of reflections by malware is not new. It has been practiced by traditional desktop threats created in Java for a long time now and even we have seen the usage of it in some of the android variants sporadically since last year. Now, it is interesting to see this trend adopted in full fledged manner by the new variants in bulk numbers.
For the benefit of the readers who are not aware about the concept of reflection: Reflection is a powerful feature of the language that allows a program to inspect classes, methods, attributes at runtime even without knowing about them at compile time.
In simpler terms: Reflection can allow a program to create a “method pointer” (a rough analogy for better understanding) and invoke the target method by using it.
So, why does it matter?
The malware sample in our discussion uses this feature to deceive any casual static code analysis module which tries to detect whether a sample is calling the method that sends SMS messages. (e.g.:sendTextMessage())
Fig.1: The code snippet from the malware that sends SMS using reflection.
Fig.1 shows the snippet of the code. It can be observed that the sample first gets the reference of sendTextMessage API and stores it in a handle and later uses that handle to call the sendTextMessage API to send a text message.
In the older variants of the AndroidOS/FakeInst malware family, when a sample wants to send a text message, it would simply call the sendTextMessage() directly and which will attract the attention of the code analysis tools that scans for the samples sending SMS messages. Usage of reflections is not a fool-proof way to thwart the static code analysis tools and this pattern also can be traced with one more layer of intelligence added to them.
The sample also stores an encrypted data file. The creators of this malware taken extra steps to hide their content and in this case it’s not a simple XOR decryption as seen in the older variants.
Fig.2: A portion of the encrypted data file.
The first byte serves as an obfuscated marker to indicate the encrypted data block and key.
During runtime, the data file is read and decrypted to an XML file in memory. Fig.3 illustrates a snippet capture during runtime.
Fig.3: decrypted content.
Though there has been support for multiple countries and message centers, currently the sample does not seem to utilize it. It sends out SMS messages to the destination number with the messagebody taken from “XXX” dialect.
In order to demonstrate the messges reaching the target msg centers, we have instrumented the sample to send the messages to an emulated device running inside the lab. Fig.4 shows the messages.
Fig.4: The messages reaching to the instrumented target
Fig.5 shows the information about the device IMEI number, model, manufacturer getting posted to a remote site.
Fig.5: info posted to the remote site.
Looking at the code and behavior of this specific sample, it is clear its just a work-in-progress sample and we can expect more variants of it with added functionalities and “support” to different message centers. As always we suggest users to be aware about what they are installing and the source from where they are downloading the application along with keeping your security software up to date.
Leave a reply
