Android – Forbidden Tricks

In this article, we will try to study the used constructions of the programming language for the operation of malicious software. The main task is to find out if the malware for the Android OS contains any useful and interesting undocumented OS features, or if they are just applications that cleverly perform their functionality using standard techniques.

Malware can consist of tens of thousands of lines of source code, if not more. Therefore, for a reference point in this sea of ​​code, we will consider the following characteristics:

  • the programming language used;

  • a set of privileges that are available to the software;

  • procedure for providing remote access;

  • peculiarities of software implementation (if any).

Disclamer: The article does not claim to be complete and provides information for educational purposes only.

Malicious software and OS

As you know, the Android system owes its kernel to Linux. And like its progenitor, the Android OS was considered impregnable for malicious software. As the system developed, new functions were added to it, which were supposed to further secure the system. Among them:

  • sandbox for each individual application;

  • organization of access to OS resources due to a large number of SELinux subsystem rules;

  • using notification for users with a list of privileges necessary for the application to work.

However, this did not help to protect the system 100%. Why? The most common way to infect a given OS is using patched software and social engineering. Moreover, users are usually offered to work with an interface that is indistinguishable from the system one – that is, any Android OS application can use notifications and Intent s that the OS itself uses.

Malware for Android is developing partly along the path of open source: the source codes of malicious programs that were used by cybercriminals are periodically leaked onto the network, which in turn helps less qualified virus writers to accelerate the creation of their own malware. Let’s try to get these sources from public sources.

The first test subject will be the Anubis Trojan. Here here there is relatively fresh news about what and how this Trojan works.

Anubis

Used programming language: Java. To do this, you don’t even need to read the source code of the project, since almost all files have the Java extension.

The set of required privileges is really off the charts. Here is a part AndroidManifest:

...
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.GET_TASKS" />
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.READ_SMS" />
    <uses-permission android:name="android.permission.WRITE_SMS" />
    <uses-permission
        android:name="android.permission.PACKAGE_USAGE_STATS"
        tools:ignore="ProtectedPermissions" />
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.CALL_PHONE" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.RECORD_AUDIO" />
    <uses-permission android:name="android.permission.READ_CONTACTS" />
    <uses-permission android:name="android.permission.READ_PHONE_STATE" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
...

It seems that the application will be systemic, and will also monitor user activity almost 24/7 and receive the necessary data for its purposes. The OS should not interfere with the activity of this application if the user has agreed to such a set of privileges.

Malware is a Trojan that can provide access to an infected device. This is done through the creation of a service that has a self-explanatory name “ServiceRAT”. It is registered in the standard way – through the manifest. Part of the source of the service itself:

...
public class ServiceRAT extends IntentService {
    String botid="";
    UtilsClass utilsClass = new UtilsClass();
    Constants const_ = new Constants();
    RequestHttp  http = new RequestHttp();
    StoreStringClass storeStringClass = new StoreStringClass();
...

No frills, we use http for data transfer, and we encrypt everything through RC4. One could find fault with the code style, but it seems that attackers are not worried about this. The malware itself works in a classic way – it receives encrypted data from the server and performs:

...
  UtilsClass utilsClass = new UtilsClass();
        try
        {
            byte[] data = Base64.decode(textDE_C, Base64.DEFAULT);
            textDE_C = new String(data, "UTF-8");
            byte[] detext = utilsClass.hexStringToByteArray(textDE_C);
            ClassRC4 rcd = new ClassRC4(key.getBytes());
            return  new String(rcd.decrypt(detext));
...

If you look at the device control code in full, then the eye will catch on the following fragment:

...
responce = utilsClass.trafDeCr(responce);
           utilsClass.Log("RATresponce",""+responce);

           if(responce!="**"){
               utilsClass.Log("RAT_command", "" + responce);
               if(responce.contains("opendir:")){

                   String opendir = responce.replace("opendir:","");
                   opendir = opendir.split("!!!!")[0];

                   if(opendir.contains("getExternalStorageDirectory"))opendir = Environment.getExternalStorageDirectory().getAbsolutePath();

                   String getFileFolder = utilsClass.listFilesWithSubFolders(new File(opendir));
                   ...

It seems that the author had 100% confidence that any command for malware will always be entered 100% correctly. Therefore, you can not worry about filling opendir and just execute the command.

Conclusion: this malware does not use any interesting “tricks”. Permitted actions, which are fully described in the manifest, subordinate almost completely the entire OS. All functions are implemented as part of the standard use of OS functions and its libraries. Code style is missing.

Cerber

Another piece of malware whose source code was leaked to the network. Recent news about him functional… This malware has an interesting feature: almost all functions are implemented in a separate file, apparently the developer thus wanted to take out the entire algorithm and be able to obfuscate it by automatic means. Perhaps it would be more convenient to add additional functionality this way, but if you think about it, this is probably one of the methods to bypass the application verification mechanism for Google Play, since malware often appears in the official store.

Used programming language: Java. Privilege set:

...
    <application
        android:allowBackup="true"
        android:label="module"
        android:supportsRtl="true"
        android:theme="@android:style/Theme.Translucent.NoTitleBar">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.app.role.SMS" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
...

There are no privilege declarations, the application has only one Intent. Fragment of the handler source:

...
import java.lang.reflect.Method;

public class MainActivity extends Activity {

    mod tt = new mod();
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
       
        tt.checkProtect(this);
        try {
            Class c = Class.forName("com.example.modulebot.MainActivity");
            Method m = c.getMethod("ssss");
            m.invoke(c.newInstance());
        } catch (Throwable t) {
        }
        tt.main(this,"");
    }
...

As mentioned earlier, the main malware algorithm is written in a separate module. You can track the operation of the algorithm by the object “tt“. The author of the malware is also not particularly worried about the support of this code, all objects have no clear naming. Apparently, this module was not planned to be used for a long time.

The malware’s functionality is not limited to sending SMS, it also has work with the application module update:

...
case "updateModule":
                        utl.SettingsWrite(context, "statDownloadModule", "0");
                        try {
                            new File(context.getDir("apk", Context.MODE_PRIVATE), "system.apk").delete();
                        }catch (Exception ex){
                            utl.SettingsToAdd(context, consts.LogSMS , "(MOD5)  | updateModule " + ex.toString() +"::endLog::");
                        }
....

The additional file “system.apk”, unfortunately, is not included in the source code, but it was probably downloaded from the command and control server. This malware does not provide remote access at all. All functionality is implemented on the basis of a config, which automatically performs the operations that the attacker gave him at the launch stage.

Conclusion: The malware only works with SMS, which are proxied into the log and sent to a specific number. Again, the complete absence of code style.

DefensorId

Another malware that was distributed on the Android OS. Relatively fresh news about him can be found here… Again, the programming language is Java, it seems the malware categorically does not want to use Kotlin.

The set of requested privileges:

...
<uses-permission android:name="android.permission.SYSTEM_OVERLAY_WINDOW" />
    <uses-permission android:name="android.permission.BIND_ACCESSIBILITY_SERVICE"
        tools:ignore="ProtectedPermissions" />
    <uses-permission android:name="android.permission.REQUEST_DELETE_PACKAGES"/>
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE"/>
    <uses-permission android:name="android.permission.WRITE_SETTINGS"
        tools:ignore="ProtectedPermissions" />
        <service
            android:name=".CoreService"
            android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"
...

The malware is famous for the fact that it can work with the user interface and steal user data. For such functionality in the Android OS, you need to have special privileges that are issued only to a special functionality – “Advanced input capabilities” (ACCESSIBILITY). Below is a piece of code that tries to request such privileges to be able to draw your Intent on top of other applications:

...
public void overayPermission(){
            if (!Settings.canDrawOverlays(this)) {
                Intent myIntent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION);
                startActivityForResult(myIntent, WIN_REQ_CODE);
            }

    }

    public void AccessibilityAllow() {
        AlertDialog.Builder gsDialog = new AlertDialog.Builder(this);
        gsDialog.setTitle("Message");
        gsDialog.setCancelable(false);
        gsDialog.setMessage("please need to allow the permission");
        gsDialog.setPositiveButton("OK", new DialogInterface.OnClickListener() {
            public void onClick(DialogInterface dialog, int which) {
                startActivityForResult(new Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS),CORE_REQ_CODE);
            }
        }).create().show();
    }
    ...

Social engineering at its finest. If the system did not allow the application to start with the ability to place your Intent on top of other applications, ask the user for this opportunity. With a high degree of probability, the notification from the system will be confirmed by it without suspicion. Remote access to the device is not provided in this malware, all functionality is processed automatically.

Output: The code was created by a more experienced programmer, there is a meaningful naming of objects. The functionality is implemented due to the capabilities of the OS itself and is used for social engineering.

Output

In most cases, the code of malicious software does not go beyond the usual programming for the Android OS. Moreover, we can say that most malware is written by self-taught people who collect functions from official documentation. The code lacks a clear definition of the objects of their functionality, there is no processing of data from the user, since the implementation of the functionality is written “in order to work.” As a result, “undocumented OS functions” are only skillful manipulations of attackers to mislead the user.


The author of the article is Alexander Kolesnikov.

The article was prepared as part of the courses Android Developer. Basicand Android Developer. Professional

We also invite you to an open webinar on the topic “Drawing our own quotes chart in Android”… During the lesson, participants together with an expert:
– will consider the basic tools for drawing;
– study the capabilities of the classes Canvas, Path, Paint;
– draw a customized quote chart and add animations to it.
Join us!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *