Shedun: adware/malware family threatening your Android device

This can be explained by the natural will of developers to earn some extra penny with the solution they make, but some of them are going too far, creating an application which doesn’t do anything else, except displaying annoying advertisement messages.

One of these is, of course, the Shedun family applications – which in fact, are nothing else, but an aggressive adware/malware, being detected as such by the Avira Protection Labs.

We see approximately 1500-2000 user detections of that adware/malware family per day.

In this article we will go through one of these applications, taking a look at what is inside, what it consists of and what in fact, it actually does.

Despite the fact that the internal structure of the package we’ll analyse today might vary (different package names, assets set, pictures, videos etc. ), the “behavior” of those applications remains unchanged. Once the application is installed, nothing seems to be malicious, but is that really so ? I doubt it.

We will start our analysis with the internal structure of an App.

Like any other clean Android app it consists of classes.dex, AndroidManifest.xml, resources folder etc., but our main focus will be – assets folder. Its structure looks like this:

That is the first suspicious thing about this APK, because it has two other APKs inside. If we try to open them, we’ll fail, because they are encoded. (In fact only the header of the file is encoded with rolling XOR).

Let’s take a look at AndroidManifest.xml because it’s also very interesting.

As you can see, there are several activities (com.pronclub.GdetailActivity, com.pronclub.GwebActivity, etc.), which don’t belong to original application (org.gro.jp.QZycJlsdApp), thus the code, which will be executed in these activities, is dynamically loaded from another application.  If we try to decompile classes.dex file from the main application, we’ll see that the code is using Java reflection to create dex loader and dynamically load code, from one of the apks . After decrypting all the strings inside the classes.dex file we will find out more interesting things about this app.

First thing that the application does is creating separate folders for libraries and for APKs which will be extracted later and dynamically loaded. This is happening here:

We removed here a lot of “garbage code’ which doesn’t do anything.  In this code piece the application is getting applications main activity thread map of current packages, then creating class loader for additional APK, and substituting this class loader value with custom class loader.

Another interesting piece of code is inside the onCreate method, which substitutes the current application with a newly started application:

Well, basically what happens here is the following: the Application is getting access to the current activity thread, then gets its data information and substitutes it with another application data information, then removes firstly created data info from global register and creates a new application, after that substitutes activity thread initial application with the newly created one. This means, that in starting application, another app is created and the first one is doing something like “self destruction”. This explains why in AndroidManifest we have such strange Activity tags description.

Now we’ll take a closer look at other components which are stored in assets folder.

Let’s start with import.apk, which is, in fact,  a video player library that provides video playing functionality.

Protect.apk is more interesting. Mostly it contains a lot of different advertisement frameworks and does nothing else but displaying to the user an advertisement which it downloads from internet. This can be easily identified by the TCP/IP data analysis. In fact it starts few connections and displays FACEBOOK and Amazon advertisements and offers to download pictures and videos from the Internet. The most interesting part in this apk is in com.qq package, which is used to create a new file in application cache and download its content. It’s relatively easy to see here:

So in this piece of code new HTTP connection will take place and file will be downloaded in hidden “.p.apk” package. This package doesn’t have anything except one more DEX file so the application is trying to change it’s permissions and try to install newly downloaded hidden app in /system/app/ folder.

In this piece of code, we clearly see, that the application is loading a newly downloaded DEX file, and using Java reflection with specific arguments is executing the executeRoot method in cn.engine.RootPerApi package which in fact, is changing /sytem/app permissions and remounting the whole system folder to enable to write there. This will allow the attacker to put his own binaries inside /system/ sub folders and execute them with root privileges.

Now let’s take a closer look at what cn.engine.RootPerApi does. When we translate this class code into SMALI we see some of the methods in this class which are particularly interesting.

Let’s take a closer look at class initialization:

So in the initialization of this class we see that two hidden files will be created in /system/xbin/ folder. Their content will be downloaded and will be put in those two files. Both of them are clear malware. First of these files .ext.base is a demon application in addition to that it requires root permissions and will be launched by second hidden.b file. Both of them are of course UPX packed ARM binaries.

Let’s take a closer look at unpacked .b file. Its internal structure and behaviour we can illustrate with the following figure.

Unpacked .ext.data file reads configuration commands from the file.

Afterwards create socket and waits for connection, when connection is established, .ext.data is waiting for incoming data from the client and executes this using /dev/ptmx root terminal.

The whole process could be illustrated with the following diagram:

So in all in all this application on the background drops downloaded packages, extracts binaries from them and tries to start them with root privileges on the device which clearly isn’t what an ordinary application would do. And these are the really malicious actions of this app.

From the research that has been carried out I’d like to mention that nowadays, malware creators produce more and more sophisticated pieces of software, embedding them into different packages which are targeted for specific devices and platforms. In this example, I wanted to show what a so called “clean” application might consist of, what it actually tries to do, and how well hidden the real motives can be.