Add Rules

Android malware analysis engine is not a new story. Every antivirus company has their own secrets to build it. With curiosity, we develop a malware scoring system from the perspective of Taiwan Criminal Law in an easy but solid way.

We have an order theory of criminal which explains stages of committing a crime. For example, crime of murder consists of five stages, they are determined, conspiracy, preparation, start and practice. The latter the stage the more we’re sure that the crime is practiced.

According to the above principle, we developed our order theory of android malware. We develop five stages to see if the malicious activity is being practiced. They are

  1. Permission requested.

  2. Native API call.

  3. Certain combination of native API.

  4. Calling sequence of native API.

  5. APIs that handle the same register.

We not only define malicious activities and their stages but also develop weights and thresholds for calculating the threat level of a malware.

But before we explain how to set weights and thresholds, we need to define crimes and corresponding five stages.

An example of defining crime “Send Location via SMS” is shown below. We use json format to construct the rule of the crime.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
     "crime": "Send Location via SMS",

     "permission": [
         "android.permission.SEND_SMS",
         "android.permission.ACCESS_COARSE_LOCATION",
         "android.permission.ACCESS_FINE_LOCATION"
     ],

     "api": [
         {
             "class": "Landroid/telephony/TelephonyManager",
             "method": "getCellLocation"
         },
         {
             "class": "Landroid/telephony/SmsManager",
             "method": "sendTextMessage"
         }
     ],

     "score": 4
}

So let me walk you through the json file.

"crime": "Send Location via SMS"

First, we define the crime. Our principle of constructing a crime is Action + Target. In this example, the action is “Send SMS” and the target is Location info. Therefore, the crime of our first rule is defined as: “Send Location via SMS”.

"permission": [
      "android.permission.SEND_SMS",
      "android.permission.ACCESS_COARSE_LOCATION",
      "android.permission.ACCESS_FINE_LOCATION"
]

permission is where we fill in permission requested by the apk to practice the crime. For instance, we need permission android.permission.SEND_SMS to send information through SMS. We also need permission android.permission.ACCESS_COARSE_LOCATION and android.permission.ACCESS_FINE_LOCATION to practice the crime.

"api": [
      {
          "class": "Landroid/telephony/TelephonyManager",
          "method": "getCellLocation"
      },
      {
          "class": "Landroid/telephony/SmsManager",
          "method": "sendTextMessage"
      }
]

api means this field can be used to practice analysis from stage 2 to stage 4.

In stage 2, we need to find key native APIs that do the Action and Target. And since the API method name can be used by self-defined class. We need to fill in information of both the native API class name and method name.

Note

We like to keep our crime/rule simple. So do not fill in more than 2 native APIs.

In stage 3, we will find the combination of the native APIs we define in stage 2. Further, we will check whether they’re called in the same method. If so, we will say that the combination of crime is caught! And we don’t need to do anything to adjust the api field.

Note

We know that the native API might be wrapped in other methods. We use XREF to solve this problem.

In stage 4, we will find whether the native APIs are called in a right sequence. If so, we have more confidence that the crime is practiced.

Note

Please place the APIs in the order as the crime is being committed.

In stage 5, we will check whether the native APIs are operating the same parameter. If so, we are 100% sure that the crime is practiced.

As for the field score, we will be updating our principles of weight defining. please check that part later.