KRDroid: Ransomware-Oriented Detector for Mobile Devices Based on Behaviors

Abstract

Ransomware has become a serious threat on Android and new cases of ransomware are continuously growing. Most existing ransomware detectors use sensitive text or APIs to detect ransomware. Some goodware applications with the functionalities of locking screen and encrypting files have similar behaviors with ransomware. It is difficult for ransomware detectors to identity them. In this paper, we made detailed analyses of three kinds of active ransomware. We proposed a behavior-based ransomware detector on Android, called KRDroid. KRDroid deploys on servers or PCs, that is, ransomware cannot be activated and cause any loss during testing. Experiments showed that our ransomware-oriented detector can find 1809 of 1862 unseen ransomware. It can also distinguish goodware with similar ransom behaviors to ransomware with an accuracy of 97.5%.

1. Introduction

With the unprecedented outbreak of different kinds of ransomware in recent years, devices and files from all walks of life have been locked. It has brought economic losses to both individuals and enterprises. Ransomware have been growing from the last few years since 2017, and it has become a key threat to mobile devices [1]. There are at least 150 countries with 300,000 users are attacked by the WannaCry (a kind of ransomware) according to the statistics. It causes economic losses as high as USD 8,000,000,000. According to the new report released by Precise Security, WannaCry remains one of the most influential ransomware in 2019. In 2019, a new kind of ransomware, Silex, was found by researchers. The spread of these types of ransomware is rapid. Silex first affected 350 devices and then quickly expanded to more than 1500 devices. According to the statistics released by Coveware, the payment ransomware require in the second quarter of 2020 is four times higher than in 2019 [2].

It is reported that the number of mobile devices based on the Android platform has sharply increased [3,4,5,6]. It is worth noting that the number of Android devices will be approximately 6.1 billion by the end of 2020 [6,7,8,9]. At present, ransomware running on Android is still a threat to mobile devices. In this work, we mainly focus on detecting ransomware based on the Android platform for mobile devices.

Ransomware detection on Windows has been relatively well established. For instance, 2entFOX can detect highly survivable ransomware with high detection accuracy and low false-positive rate [10]. UNVEIL uses filesystem to monitor and OCR to detect locking devices and encrypting files ransomware [11]. ShieldFS [12] and reference [13] can identify ransomware by I/O request packets. EldeRan uses dynamic analysis to distinguish ransomware from goodware [14]. Some works [15,16,17,18] focus on encrypting ransomware detection by using traffic characteristics or sensitive APIs.

The methods of detecting ransomware on other platforms could not be directly applied on Android. On the one hand, detectors [15,16,17,18] use traffic to identify ransomware. This means detected ransomware should have network access, while most ransomware on Android can ransom without network access. On the other hand, Android has its own security mechanism, meaning that there are many different files and features that can be used for Android ransomware detection.

For Android, the approach for ransomware-oriented detection is incomplete. In 2016, N.Andronio et al. [19] first proposed a ransomware detector based on machine learning. To our best knowledge, HelDroid [19] and GreatEatlon [20] are the earliest ransomware-oriented detectors based on static analysis with machine learning. They detect ransomware based on threatening text detectors, lock detectors, and encryption detectors. If the ransomware uses unseen language, it may cause many misjudgments. The execution time is nearly seconds per sample on average [19]. There are also some detectors that use dynamic analysis to identify ransomware. DNA-Droid [21] combines static and dynamic analysis to detect ransomware. R-PackDroid [22] is a practical on-device detector of Android ransomware. Azmoodeh et al. [23] focus on files encryption ransomware in IoT and detect them by using energy consumption. If users need to detect large-scale samples by using detectors with dynamic analysis, it may be time consuming.

Many ransomware detectors identify ransomware based on sensitive APIs. However, there are some ransomware that use insensitive API callings to ransom. For example, a ransomware application can make its interface be the top-level interface suspending on the screen though users press Home buttons or Back buttons. Detectors may misjudge them as goodware behaviors. Some goodware applications that have the functions of locking devices and encrypting files have behaviors similar to ransomware. For example, some goodware applications such as time management applications lock the devices according to the time users have set. It is difficult for ransomware detectors to identity them.

Contributions. In the light of this, we made detailed analyses of three kinds of active ransomware, including the different runtime behaviors, ransom codes and the differences between ransomware and goodware with similar behaviors, for example, screen beautification applications with lock function and files management applications with an encryption function. Then, we constructed a multidimensional behavior pattern based on ransom behaviors. Finally, we proposed a behavior-based Android ransomware detector for mobile devices, called KRDroid. It retains the relational behavior patterns of ransomware. The main contributions of this paper are as follows.

The analyses of three kinds of active ransomware. We collected three kinds of active IoT Android ransomware from VirusTotal [24], AMD [25], and from open source databases [26]. According to their runtime behaviors, we sorted out ransomware into three groups: device lock ransomware, files encryption ransomware, and screen resource control ransomware. We analyzed them from multiple dimensions for their extortion behaviors and source code.

The construction of a ransomware-behavior-pattern-based multidimensional feature set. We extracted features from API callings, permissions, intents, and other dimensions to construct different kinds of ransom behavior patterns. In this way, the feature set can be seen as a formal expression set that retains the relational behaviors of ransomware.

A behavior-based ransomware-oriented detector. We proposed a behavior-based ransomware-oriented detector, KRDroid, to find Android ransomwares. KRDroid deploys on servers or PCs, that is, ransomware cannot be activated and cause any loss during testing. Experiments results show that KRDroid can detect unseen ransomware with the accuracy of 97.5%.

2. Related Research

With the increase of threats of ransomware,  ransomware-oriented detectors for IoT devices have attracted more and more attention. In terms of related research, we mainly review the ransomware detectors based on I/O, dynamic analysis, and static analysis.

2.1. Ransomware Detection Based on I/O

Song et al. [23] proposed a method to detect ransomware using I/O rate, CPU usage, and memory usage. It discriminates between normal processes and ransomware by means of monitoring file events and computing resources. The method can protect users from the damage caused by ransomware applications without any information about ransomware codes.

Continella et al. [12] proposed ShieldFS, a ransomware detection file system. ShieldFS detects ransomware by means of the I/O usage and the change of IRP loggers (I/O request package logger). This method mainly detects files encryption ransomware, and it also can recover files that have already been encrypted by ransomware.

Feng et al. [13] proposed a method to detect files encryption ransomware based on deception and behavior monitoring. They created decoy files in the device at the very beginning to induct ransomware encrypting decoy files. In this way, abnormal processes can be detected.

Ko et al. [27] proposed a real-time ransomware detection with the help of intercepting requests from APIs to read or write to a file and judges whether the file is encrypted based on Shannon entropy.

In summary, ransomware detectors based on I/O usage are sensitive to files encryption ransomware used for encryption needs with much input and output file stream. Ransomware that lock devices or control screen resources may not applicable for these methods.

2.2. Ransomware Detection Based on Dynamic Analysis

Sgandurra et al. [14] proposed EldeRan, a ransomware-oriented detector based on dynamic analysis and machine learning classification. EldeRan focuses on the installation of applications to check for characteristics signs of ransomware by means of monitoring the selected APIs [14].

Abdullah et al. [28] proposed an Android ransomware detector based on dynamic analysis. It extracts system calls with the help of dynamic analysis and uses them as features. Algorithms such as Random Forest, J48, and Naïve Bayes are used to train the model.

Considering some ransomware may use complicated packing techniques, Chen et al. [29] proposed RansomProber, a real-time ransomware detection system with dynamic analysis. Instead of monitoring APIs, RansomProber uses information entropy to measure the degree of data transformation in sensitive directories [29]. To some extent, it can detect files encryption ransomware with customized cryptosystems.

Detectors with dynamic analysis can detect ransomware in real time. The analysis time of detectors for an application is approximately 5 seconds [29]. When detecting the large-scale samples, it will be time consuming.

2.3. Ransomware Detection Based on Static Analysis

Bibi et al. [30] proposed an effective Android ransomware detector. It extracts features from traffic with the help of 8 different feature filtration techniques and chosen 19 important features. Karimi et al. [31] proposed a method for Android ransomware detection based on transforming the sequence of executable instructions into a grayscale image and exploited valuable features by means of using LDA.

HelDroid [19] is a ransomware-oriented detector, which identifies ransomware by means of sensitive text based on NLP, lock-device function, and file-encrypt function based on FlowDroid [32]. According to the judge logic of the detector, a ransomware behavior must have ransom text. It requires the training corpus to be all-inclusive of the keywords of the ransom, as well as the language. When facing applications with unseen language, the detector will not identify the ransomware even if it has ransom behaviors. The execution time is nearly seconds per sample on average [19].

After approximately one year, some researchers improved HelDroid [19] and proposed GreatEatlon [20], a new ransomware-oriented detector. It extends FlowDroid [32] to track encryption-related information flows to improve the encryption detector. It also adds a lightweight prefilter to filter goodware behaviors from the analysis queue to shorten execution time [20]. When facing ransomware with unseen language, the detector cannot identify ransomware either.

In order to detect ransomware with confusion, R-PackDroid [22] was proposed in 2018. Different from HelDroid [19] and GreatEatlon [20], it is designed as an application that can be installed on mobile phones. This detector uses static detection and extract API packages to represent the application and uses random forest for classification. R-PackDroid has the resilience of the related information against obfuscation [22]. Due to the detection mode of R-PackDroid [22] being “install–detect”, large-scale samples detection may be time consuming.

3. Characterization of Ransomware

In order to have a better knowledge of ransomware, we collected 754 ransomware from the AMD dataset [25] and VirusTotal [24]. This section will analyze the characterization of different kinds of ransomware.

3.1. Analysis of Different Kinds of Ransomware

To our best knowledge, according to the behaviors, ransomware can be divided into three groups. The $R$ represents the set of ransomware. As shown in formula (1), $R$ contains three kinds of ransomware $R_{DL}$, $R_{SRC}$, and $R_{FE}$. $R_{DL}$ represents device lock ransomware, which ransom users by automatically modifying the passwords of devices. $R_{SRC}$ represents screen resource control ransomware, which ransom users by constantly holding the screen resource. $R_{FE}$ represents files encryption ransomware, which ransom users by encrypting private files.

$$\mathit{R}=\left\{{\mathit{R}}_{\mathit{D}\mathit{L}},{\mathit{R}}_{\mathit{S}\mathit{R}\mathit{C}},{\mathit{R}}_{\mathit{F}\mathit{E}}\right\}$$

(1)

3.1.1. Device Lock Ransomware

Device lock ransomware behaviors are the most common and easy-to-implement ransomware. After they are activated, they can automatically modify the passwords, PINsm or gesture passwords. There were 461 device lock ransomware behaviors in the collected data, and we summarized 186 features of device lock ransomware.

A typical device lock ransomware can be represented as $R_{DL}$. As shown in formula (2), $r_{dl}$ contains permission of $BIND\_DEVICE\_ADMIN$, typical API callings and sensitive strings. $p_{dl}$ represents the permission of ransomware, such as $android.permission.BIND\_DEVICE\_ADMIN$. After applying this permission, a ransomware application can obtain super administrator rights. Android set the ransomware as the device manager to prevent being accidentally uninstalled. $s_l$ represents sensitive or threaten strings in applications. A ransomware application usually uses threaten strings to call for payment.

The tuple $〈A_{sub},R_r〉$ represents API calling sequences. As shown in formula (3), $R_r$ is the subset of $\{\phi ,\&,\parallel \}$. $\phi$ represents the relationship between each API is none, & represents the relationship between each API is $and$ and $\parallel$ represents the relationship between each API is $or$. As shown in formula (4), $A_{sub}$ is the subset of $A_k$ and $A_k$ represents the universal set of $a_k$. $a_k$ represents APIs related to device lock. As shown in

Table 1. Typical features of device lock ransomware applications.

Feature	Meaning
resetPassword()	Reset the password.
resetView()	Reset the gesture view.
setParameter(SpeechConstant.SAMPLE_RATE,"8000")	Set the voice password.
lockNow()	Lock the device.
android.permission.BIND_DEVICE_ADMIN	Apply and get super administrator rights.
Ladrt/R/ADRTLogCatReader	AIDE (IDE in Android) feature.

, $resetPassword\mathit{\left(}\mathit{\right)}$ is used to reset the password of the device, $resetView\mathit{\left(}\mathit{\right)}$ is used to reset the gesture view of the device, $setParameter\mathit{(}SpeechConstant.SAMPLE\_RATE,“8000”\mathit{)}$ is used to set the voice password of the device, and $lockNow\mathit{\left(}\mathit{\right)}$ is used to lock the device. A device lock ransomware may first call $resetPassword\mathit{\left(}\mathit{\right)}$ to modify the password and then call $lockNow\mathit{\left(}\mathit{\right)}$ to lock the device. Both API callings are indispensable.

$${\mathit{R}}_{\mathit{D}\mathit{L}}=\left\{{\mathit{r}}_{\mathit{d}\mathit{l}}=\left({\mathit{p}}_{\mathit{d}\mathit{l}},\left.〈{\mathit{A}}_{\mathit{s}\mathit{u}\mathit{b}},{\mathit{R}}_{\mathit{r}}>,{\mathit{s}}_{\mathit{l}}\right)\mid \mathit{l}=1,\dots ,∥{\mathit{s}}_{\mathit{l}}∥\right\}\right.$$

(2)

$${\mathit{R}}_{\mathit{r}}\subseteq \{\mathit{\phi },\mathit{\&},\mathit{\parallel }\}$$

(3)

$${\mathit{A}}_{\mathit{s}\mathit{u}\mathit{b}}\subseteq {\mathit{A}}_{\mathit{k}}=\left\{{\mathit{a}}_1,{\mathit{a}}_2,\dots ,{\mathit{a}}_k\mid \mathit{k}=1,\dots ,∥{\mathit{a}}_{\mathit{k}}∥\right\}$$

(4)

3.1.2. Files Encryption Ransomware

Files encryption ransomware behaviors are also a kind of common ransomware. After they are activated, ransomware applications automatically encrypt the privacy files on the device, including photos, txt files, etc. There were 223 files encryption ransomware behaviors in the collected data, and we summarized 411 features of files encryption ransomware.

A typical files encryption ransomware can be represented as $R_{FE}$. As shown in formula (5), $r_{fe}$ contains permissions related to read or write, typical attack mode, and sensitive strings. $p_{fe}$ represents related permissions such as $android.permission.WRITE\_EXTERNAL\_STORAGE$, which allows ransomware writing files on storage. $s_l$ represents sensitive or threaten strings in applications.

${\mathit{att}}_k$ represents the attack mode of files encryption ransomware. As shown in formula (6), attack mode contains attack time, attack target, encryption method, attack order, and attack flow. The subset of ${\mathit{att}}_k$ contains the typical API calling sequences. ${\mathit{att}}_{time}$ represents the attack time. It includes encrypting files immediately and waiting for commands. ${\mathit{att}}_{target}$ represents the encryption folder. ${\mathit{att}}_{order}$ represents the attack order of the ransomware, i.e.,  the ransomware application encrypts files after obtaining the complete file list or encrypting each file when it is discovered by the ransomware. ${\mathit{att}}_{enmethod}$ represents the encryption method, including calling $AES\mathit{\left(}\mathit{\right)}$, $DES\mathit{\left(}\mathit{\right)}$ or other methods. ${\mathit{att}}_{fea}$ represents the attack flow of the ransomware. As shown in

Table 2. Typical features of files encryption ransomware applications.

Feature	Meaning
android.permission.WRITE_EXTERNAL_STORAGE	Apply for reading and writing access to SDCard.
setCancelable()	Applying for creating and deleting file permissions in SDCard.
Landroid/content/Intent→addCategory()	Traversing and encrypting the specified file.
Landroid/content/Intent→createChooser()
Ljavax/crypto/Cipher→getInstance()
Ljavax/crypto/Cipher→<init>
Ljavax/crypto/Cipher→doFinal()
Ljavax/crypto/spec/SecretKeySpec→<init>

, the ransomware loops the storage structure of the device to find the target type of the files by $addCatefory\mathit{\left(}\mathit{\right)}$ and $createChooser\mathit{\left(}\mathit{\right)}$; Once it finds the eligible files, it obtains data by calling $read\mathit{\left(}\mathit{\right)}$ or $FileInputStream\mathit{\left(}\mathit{\right)}$, then calls encrypt API, such as $Ljava/crypto/spec/IvParameterSpec$ to encrypt data; finally, it uses $write\mathit{\left(}\mathit{\right)}$ or $FileOutputStream\mathit{\left(}\mathit{\right)}$ to write the encrypted file in the storage.

$${\mathit{R}}_{\mathit{F}\mathit{E}}=\left\{{\mathit{r}}_{\mathit{f}\mathit{e}}=\left({\mathit{p}}_{\mathit{f}\mathit{e}},\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{k}},{\mathit{s}}_{\mathit{l}}\right)\mid \mathit{k}=1,\dots ,∥\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{k}}∥,\mathit{l}=1,\dots ,∥{\mathit{s}}_{\mathit{l}}∥\right\}$$

(5)

$$\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{k}}=<\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{t}\mathit{i}\mathit{m}\mathit{e}},\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{t}\mathit{a}\mathit{r}\mathit{g}\mathit{e}\mathit{t}},\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{e}\mathit{n}\mathit{m}\mathit{e}\mathit{t}\mathit{h}\mathit{o}\mathit{d}},\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{o}\mathit{r}\mathit{d}\mathit{e}\mathit{r}},\mathit{a}\mathit{t}{\mathit{t}}_{\mathit{f}\mathit{e}\mathit{a}}>$$

(6)

3.1.3. Screen Resource Control Ransomware

The screen resource control ransomware applications are uncommon ransomware. There were only 70 screen resource control ransomware behaviors in the collected data. After they are activated, there are 25 ransomware applications that make their interfaces as the top-level interfaces suspending on the top of devices and disable the Home and Back buttons. That is to say, other applications or other system functions cannot be used. Although another 45 ransomware applications make their interfaces the top-level interfaces, the user can press the Home and Back buttons to exit. However, this kind of exit is temporary, and the interface of the ransomware will suspend on the screen in a very short time to prevent users from using their phones normally. After analyzing these applications, we summarized 378 features of screen resource control ransomware.

A typical screen resource control ransomware can be represented as $R_{SRC}$. As shown in formula (7), $r_{src}$ contains related permissions, intents, typical API callings, and sensitive strings. $p_{src}$, ${\mathit{in}}_{src}$ represent the related permissions and intents. $s_l$ represents sensitive or threaten strings in applications.

The tuple $〈A_{sub},R_r〉$ represents API calling sequences. As shown in formula (8) and formula (9), $R_r$ is the subset of $\{\phi ,\&,\parallel \}$. $A_{sub}$ is the subset of $A_k$ and $A_k$ represents the universal set of $a_k$. $a_k$ represents APIs related to the screen resource control. As shown in

Table 3. Typical features of screen resource control ransomware applications.

Feature	Meaning
LayoutParams→FLAG_FULLSCREEN	Suspend the interface.
Window→setFlags(I,I),v2,v4,v4	Set the top-level window by modifying parameter.
android.intent.category.HOME
onWindowFocusChanged()	Monitor the Home button and disable the Home button.
sendBroadcast()
Dialog→setCancelable()	Set the current window cannot be cancelled or make it constant appearing.

, $LayoutParams-$>$FLAG\_FULLSCREEN$ is used to suspend the interface as full screen. $setCancelable\mathit{\left(}\mathit{\right)}$ and $setFlags\mathit{\left(}\mathit{\right)}$ are used to suspend the interface as well, for the parameters of them have different meanings. Modifying the default parameter from $True$ to $False$ in $setCancelable\mathit{\left(}\mathit{\right)}$ means that users cannot press the external area of the dialog, using parameter 1024 in $setFlags\mathit{\left(}\mathit{\right)}$ means that the system window will be set as a full-screen window.

$OnkeyDown\mathit{\left(}\mathit{\right)}$ and $OnAttachWindow\mathit{\left(}\mathit{\right)}$ are used to disable $Home$ and $Back$ buttons; for the $Home$ button that is the system button, the KeyEvent barely captures the click events; thus, developers need to rewrite the $OnAttachWindow\mathit{\left(}\mathit{\right)}$. If the version of Android is version 2.3 and below, the method can be rewritten similar to Listing 1. If the version of Android is version 4.0 and above, the method can be rewritten similar to listing 2.

Listing 1. An example of OnAttachWindow.

Listing 1. An example of OnAttachWindow.

If the version of Android is version 4.0 and above, the method can be rewritten similar to Listing 2.

Listing 2. An example of OnAttachWindow.

Listing 2. An example of OnAttachWindow.

The OnKeyDown() will be rewritten similar to Listing 3.

Listing 3. An example of OnKeyDown.

Listing 3. An example of OnKeyDown.

The API calling sequences shown in Listing 3 are used to disable the $Home$ buttons. android.intent.category. $Home$ is used to register the monitor of the $Home$ button. $Landroid/app/Activity$→$onWindowFocusChanged\mathit{\left(}\mathit{\right)}$ is used to monitor whether the $Home$ button is being clicked or not. $sendBroadcast\mathit{\left(}\mathit{\right)}$ is used to send the fake click broadcast. The button can be disabled by means of calling these API sequences.

$${\mathit{R}}_{\mathit{S}\mathit{R}\mathit{C}}=\left\{{\mathit{r}}_{\mathit{s}\mathit{r}\mathit{c}}=\left({\mathit{p}}_{\mathit{s}\mathit{r}\mathit{c}},\mathit{i}{\mathit{n}}_{\mathit{s}\mathit{r}\mathit{c}},<{\mathit{A}}_{\mathit{s}\mathit{u}\mathit{b}},{\mathit{R}}_{\mathit{r}}>,{\mathit{s}}_{\mathit{l}}\right)\mid \mathit{l}=1,\dots ,∥{\mathit{s}}_{\mathit{l}}∥\right\}$$

(7)

$${\mathit{R}}_{\mathit{r}}\subseteq \{\phi ,\&,\parallel \}$$

(8)

$${\mathit{A}}_{\mathit{s}\mathit{u}\mathit{b}}\subseteq {\mathit{A}}_k=\left\{{\mathit{a}}_1,{\mathit{a}}_2,\dots ,{\mathit{a}}_{\mathit{k}}\mid \mathit{k}=\mathit{1},\dots ,∥{\mathit{a}}_{\mathit{k}}∥\right\}$$

(9)

3.2. Differences Between Ransomware and Goodware

In our research, we found that some ransomware and goodware applications have similar runtime behaviors. Some typical behaviors such as device lock and files encryption also exist in goodware applications. For example, as shown in Figure 1, screen beautification applications and time management applications have the function of locking devices. Furthermore, files management applications have the function of encrypting files.

We randomly selected 50 screen beautification applications, time management applications, and 50 files management applications from the internet [33] and uploaded them to VirusTotal [24]. The result showed that 10% of screen beautification and time management applications were misjudged as ransomware, and 19% of the files management applications were misjudged as ransomware. That is, the similar behaviors between the two may make detectors identify some goodware applications as ransomware.

In order to have a better knowledge of the differences between ransomware and goodware applications, we analyzed the differences between device lock ransomware, files encryption ransomware, and goodware applications.

3.2.1. Device Lock and Screen Resource Control Ransomware vs. Goodware Applications

As shown in Figure 2, though both ransomware and goodware applications apply the permission of $BIND\_DEVICE\_ADMIN$ to obtain super administrator rights and use $lockNow\mathit{\left(}\mathit{\right)}$ to lock the device, there are some differences between them in runtime behaviors and source code.

As shown in formula (10) and formula (11), goodware applications with similar behaviors to ransomware can be represented as $G_{D\&S}$, $g_{D\&S}$ contains related permissions $p_{D\&S}$. and typical API callings $a_k$. The feature intersection of goodware applications and the union of device lock ransomware and screen resource control ransomware applications include $android.permission.BIND\_DEVICE\_ADMIN$, $lockNow\mathit{\left(}\mathit{\right)}$, etc. For these goodware applications, only reset the wrappers or extend the device unlock time according to the settings of users. Though goodware applications monitor the Power Off buttons and lock the devices, they do not reset the PINs, gesture passwords, or voiceprints of the devices, that is, users can unlock their devices with their own passwords and use their devices normally.

$${\mathit{G}}_{\mathit{D}\&\mathit{S}}=\left\{{\mathit{g}}_{\mathit{D}\&\mathit{S}}=\left({\mathit{p}}_{\mathit{D}\&\mathit{S}},{\mathit{a}}_{\mathit{k}}\right)\mid \mathit{k}=1,\dots ,∥{\mathit{a}}_{\mathit{k}}∥\right\}$$

(10)

$${\mathit{G}}_{\mathit{D}\&\mathit{S}}\cap \left({\mathit{R}}_{\mathit{D}\mathit{L}}\cup {\mathit{R}}_{\mathit{S}\mathit{R}\mathit{C}}\right)=\{\mathit{LockNow}\left(\right),\mathit{permission}.\mathit{BIND\_DEVICE\_ADMIN},\dots \}$$

(11)

The device-locking ransomware applications lock the device and modify the original passwords. The device cannot be returned to the Home menu by clicking Home buttons or $Back$ Buttons. When the user presses the $Power Off$ button, it can be hibernated as normal. However, when the user tries to reset the device again, the device is still locked by the ransomware application. In this way, the user has to pay ransom to receive the correct password.

The screen resource control ransomware applications set their own activities as the top-level activities by setting particular parameters in the bytecode. The ransomware disables $Home$ buttons and $Back$ buttons, in addition to disabling $Power Off$ buttons. In this way, the ransomware forces the device to constantly operate without being hibernated and forces users to pay ransom for the exit password. Some ransomware applications continue to suspend the interfaces although the users click the $Home$ or $Back$ buttons. Moreover, some researchers also found some ransomware applications disable the USB of devices to prevent users from uninstalling the application by ADB commands. The detailed differences between device lock and screen resource ransomware and goodware applications are shown in

Table 4. Differences between device lock and screen resource control ransomware and goodware applications.

	Ransomwares		Goodwares
	Device Lock	Screen Resource Control
lock screen	✓ 1	✕ 2	✓
reset password	✓	✕	✕
top-level interface	✕	- 3	✕
constant appear	✕	-	✕
disable Home Button	✓	-	✕
disable Back Button	✓	-	✕
disable USB interface	-	-	✕
lockNow()	✓	✕
resetPassword()	✓	✕	✕
setCancelable()	✕	-	✕
Window→setFlags(I,I),v2,v4,v4	✓	✓	✕
OnkeyDown()/OnkeyUp()	-	✓	✕
onAttachedToWindow()	-	✓	✕

1 ✓ means this kind of applications have the feature. 2 ✕ means this kind of applications don’t have the feature. 3 - means this kind of applications may have the feature.

.

3.2.2. Files Encryption Ransomware vs. Goodware Applications

As shown in Figure 3, both files encryption ransomware and files management applications can encrypt privacy files of devices, but there is still some differences between them in encrypt–decrypt mode.

Files management applications are a kind of privacy protection application. They give the users encryption options and wait orders to encrypt the customized files. These goodware applications show progress indicator bars to remind users of the current encryption progresses, and give corresponding prompts after the encryption operation is completed. Users can decrypt the files by the passwords they set.

Ransomware applications first loop the target files and automatically encrypt these files in devices without any information. As shown in formula (12) and formula(13), $E_{mode}$ represents the encryption mode of ransomware and $e_i$ represents the encryption process. $R$ represents read operation, $E$ represents encrypt operation, $W$ represents write operation, $N$ represents new operation, $D$ represents delete operation, $RE$ represents rename operation, and $M$ represents move operation. In this paper, we mainly introduce five encryption modes.

$${\mathit{E}}_{\mathit{mode}}=\left\{{\mathit{e}}_{\mathit{1}},{\mathit{e}}_2,{\mathit{e}}_3,{\mathit{e}}_4,{\mathit{e}}_5\right\}$$

(12)

$${\mathit{E}}_{\mathit{mode}}=\left[\begin{array}{cccccccc}& \mathit{R}& \mathit{E}& \mathit{W}& \mathit{N}& \mathit{D}& \mathit{M}& \mathit{R}\mathit{E}\\ {\mathit{e}}_1& 1& 1& 1& 0& 0& 0& 0\\ {\mathit{e}}_2& 1& 1& 1& 1& 1& 0& 1\\ {\mathit{e}}_3& 1& 1& 1& 1& 1& 0& 0\\ {\mathit{e}}_4& 1& 1& 1& 1& 1& 0& 0\\ {\mathit{e}}_5& 1& 1& 1& 0& 0& 1& 0\end{array}\right]$$

(13)

${\mathit{e}}_1$ represents the encryption mode that is reading files, encrypting data, and then writing them back to the original files.

${\mathit{e}}_2$ represents the encryption mode that is reading files, encrypting data, creating new files, writing encrypted data to the new files, and deleting original files.

${\mathit{e}}_3$ represents the encryption mode that is reading files, encrypting data, creating new files, writing encrypted data to the new files, renaming the new files, and deleting original files.

${\mathit{e}}_4$ represents the encryption mode that is reading files, deleting original files, encrypting data, creating new files, and writing encrypted data to the new files.

${\mathit{e}}_5$ represents the encryption mode that is moving original files to other folders, reading files, encrypting data, writing the encrypted data back to the original files, and moving the files back to the original location.

The detailed differences between files encryption ransomware and files management applications are shown in

Table 5. Differences between files encryption ransomware and goodware applications.

	Files Encryption Ransomwares	Goodwares
Encrypt file	✓	✓
User can choose which file to encrypt	✕	✓
Can recover encrypted with password user set	✕	✓
Backstage encrypt files automatically	✓	✕
Has target default encryption type of file	✓	✕
EndecodeUtils.deCrypto()	✕	✓
Landroid/content/Intent→addCategory Landroid/content/Intent→createChooser Ljavax/crypto/Cipher→getInstance Ljavax/crypto/Cipher→<init> Ljavax/crypto/Cipher→doFinal Ljavax/crypto/spec/SecretKeySpec→<init>	✕	✓

.

4. A Ransomware-Oriented Detector

In this section, we introduce a ransomware-behavior-pattern-based, multidimensional, ransomware-oriented detection approach for mobile devices. It uses static analysis to analyze the source code and extract features based on behavior patterns; it also uses the form of binary feature to represent the feature information of samples and XGBoost to classify samples.

4.1. Workflow

The detailed workflow of the ransomware-oriented detector is shown in Figure 4.

When an application needs to be tested, the AndroidManifest.xml and classes.dex are first extracted from the apk file. Second, Androguard [34], a static analysis tool, is used to extract features. Then, features are divided into two parts. For the features that do not need to be counted for their frequency, we use $1$ to represent their existence and $0$ to represent the opposite. Next, all the features are combined to form the feature vectors and use XGBoost to classify them. Lastly, the detector outputs the results of the detection.

4.2. Feature Extraction

With the help of Androguard [34], a tool that can read the binary format of Android XML files(AXML) and decompile DEXfiles [35], we extracted features from AndroidManifest.xml and classes.dex. The feature set contains sensitive strings set and other features set.

Sensitive Strings Set. The sensitive strings mentioned in this paper mean constant strings declared in the Dalvik bytecode. In order to better distinguish ransomware from other applications, we segmented the constant strings based on the word segmentation method in NLP. As shown in Algorithm 1, the steps of building sensitive strings set are as follows.

(1) Segmentation. We used special characters such as " " for the baseline of the segmentation. $T_r$ represents the text set of ransomware after segmentation, and $T_o$ represents the text set of other applications after segmentation.

(2) Deletion. We removed some meaningless words from $T_r$ and $T_o$. The meaningless words include stop words such as a, $the$, and some obvious common words. We used $T_r^{\prime }$ to represent the ransom text set after deletion and used $T_o^{\prime }$ to represent other text sets.

(3) Keywords Extraction. We used $tf-idf$ to calculate the weight of each word in $T_r^{\prime }$ and $T_o^{\prime }$. The result of $tf-idf$ refers to whether the word has the discrimination between ransomware and other applications. The weight can be expressed similar to formula (14). The $t_{i,j}$ represents the number of the word t appears in $T_r^{\prime }$ and in $T_o^{\prime }$. The ${\sum }_i{t}_{ri}^{\prime }+{\sum }_j{t}_{oj}^{\prime }$ represents the total words in both $T_r^{\prime }$ and $T_o^{\prime }$. The ${\sum }_i$ label${}_{ri}$ represents the number of ransomware, and the ${\sum }_j$label${}_{oj}$ represents the number of other applications. The ${\sum }_{i,j}$ label ${}_{t_{ij}}$ represents the number of applications containing the word $\mathit{t}$.

$$\mathit{weight}=\frac{{\mathit{t}}_{\mathit{i},\mathit{j}}}{{\sum }_{\mathit{i}}{\mathit{t}}_{\mathit{r}\mathit{i}}+{\sum }_{\mathit{j}}{\mathit{t}}_{\mathit{o}\mathit{j}}}\mathit{log}\left(\frac{{\sum }_{\mathit{i}}\mathit{l}\mathit{a}\mathit{b}\mathit{e}{\mathit{l}}_{\mathit{r}\mathit{i}}+{\sum }_{\mathit{j}}\mathit{l}\mathit{a}\mathit{b}\mathit{e}{\mathit{l}}_{\mathit{o}\mathit{j}}}{{\sum }_{\mathit{i},\mathit{j}}\mathit{l}\mathit{a}\mathit{b}\mathit{e}{\mathit{l}}_{{\mathit{t}}_{\mathit{i}}}+1}\right)$$

(14)

Algorithm 1 The algorithm of building sensitive strings set

Input: apks, label

Output:S

1: $T_r\leftarrow \mathbf{Segment}(apks,{label}_r)$

2: $T_o\leftarrow \mathbf{Segment}(apks,{label}_o)$

3: $T_r^{\prime }\leftarrow \mathbf{Deletion}(T_r,meaningless\_word)$

4: $T_o^{\prime }\leftarrow \mathbf{Deletion}(T_o,meaningless\_word)$

5: for $t\in T_r^{\prime }\cup T_o^{\prime }$ do

6:     $weight\leftarrow \frac{t_{i,j}}{{\sum }_i{t}_{ri}+{\sum }_j{t}_{oj}}log\left(\frac{{\sum }_{i}labe{l}_{ri}+{\sum }_{j}labe{l}_{oj}}{{\sum }_{i,j}labe{l}_{t_i}+1}\right)$

7:     if $weight>threshold$ then

8:          $S\leftarrow S\cup t$

9:      end if

10: end for

return S

Other Features Set. The algorithm of building other features set is shown in Algorithm 2. The other features set can be represented as set F. As shown in formula (15), $f_m$ contains permissions, intents, API callings, and sensitive strings. The $p_i$ represents permissions, a kind of the security model of Android. Permissions need to be declared before calling sensitive APIs. The ${\mathit{in}}_i$ represents intents, the runtime binding mechanism of Android. Intents are responsible for internal communication. The $s_l$ represents sensitive strings related to ransom, which we obtained based on tf-idf.

Algorithm 2 The algorithm of building feature set

Input: apks

Output:F

1: $S=\mathbf{Sensitive\; Strings\; Set\; Aggregation}(apks,label)$

2: for $eachapk$ do

3:     $F\leftarrow \mathbf{Extract}(p_i,{in}_j,a_k,s_l)$

4:     $<A_{sub},R_r>\leftarrow \mathbf{Extract}\left(a_i,\dots ,a_j,\phi ,\&,\parallel \right)$

5:     if $F=\phi ,<A_{sub},R_r>=\phi$ then

6:          $\mathit{continue}$

7:     else

8:         $F\cup <A_{sub},R_r>$

9:     end if

10: end for

return F

As shown in formula (16) and formula (17), $R_r$ is the subset of $\{\phi ,\&,\parallel \}$. $A_{sub}$ is the subset of $A_k$, and $A_k$ represents the universal set of $a_k$. The $a_k$ represents API callings, which provide certain functions for developers to access a set of routines based on Android. Developers can use different API calling sequences to implement different functions.

$$\mathit{F}=\left\{\begin{array}{cc}\hfill {\mathit{f}}_{\mathit{m}}=& \left({\mathit{p}}_{\mathit{i}},\mathit{i}{\mathit{n}}_{\mathit{j}},<{\mathit{A}}_{\mathit{s}\mathit{u}\mathit{b}},{\mathit{R}}_{\mathit{R}}>,{\mathit{s}}_{\mathit{l}}\right)\mid \hfill \\ \hfill \mathit{i}& =1,\dots ,∥{\mathit{p}}_{\mathit{i}}∥,\mathit{j}=1,\dots ,∥{\mathit{in}}_{\mathit{j}}∥,\mathit{l}=1,\dots ,∥{\mathit{s}}_{\mathit{l}}∥\hfill \end{array}\right\}$$

(15)

$${\mathit{R}}_{\mathit{r}}\subseteq \{\phi ,\&,\parallel \}$$

(16)

$${\mathit{A}}_{\mathit{s}\mathit{u}\mathit{b}}\subseteq {\mathit{A}}_{\mathit{k}}=\left\{{\mathit{a}}_1,{\mathit{a}}_2,\dots ,{\mathit{a}}_{\mathit{k}}\mid \mathit{k}=1,\dots ,∥{\mathit{a}}_{\mathit{k}}∥\right\}$$

(17)

4.3. Classification

In this paper, we transfer the extracted features to vectors. As shown in formulas (18) and (19), $\mathit{Vec}$ represents the vector set, containing a binary vector set and a value vector set. ${\mathit{Vec}}_{value}$ represents the value vector set. The value of each dimension of the vector is float. ${\mathit{Vec}}_{binary}$ represents the binary vector set. The value of each dimension of the vector is int. If ${\mathit{Vec}}_i$ exists in the feature set, no matter how many times it appears in the application, the value of ${\mathit{Vec}}_i$ is $1$. Otherwise, the value of ${\mathit{Vec}}_i$ is $0$.

$$\mathit{Vec}={\mathit{Vec}}_{\mathit{binary}}\cup {\mathit{Vec}}_{\mathit{value}}$$

(18)

$${\mathit{Vec}}_{\mathit{b}\mathit{i}\mathit{n}\mathit{a}\mathit{r}\mathit{y}}=\left\{\mathit{v}\mathit{e}{\mathit{c}}_{\mathit{i}}=\left\{\begin{array}{c}0,\mathbf{not}\mathbf{in}\mathbf{feature}\mathbf{set}\hfill \\ 1,\mathbf{in}\mathbf{the}\mathbf{feature}\mathbf{set}\hfill \end{array}\mid \mathit{i}=1,\dots ,∥\mathit{v}\mathit{e}{\mathit{c}}_{\mathit{i}}∥\right\}\right.$$

(19)

Next, we combined the two groups of features as a whole vector, which represents the information of the application. Then, we used XGBoost, a supervised approach, to train the ransomware-oriented detector. We divided the ransomware and goodware applications into two parts, randomly used 80 percent of them to train, and used 20 percent of them to test.

5. Evaluation

We conducted three experiments to evaluate its detection capability and efficiency. To test the detection performance of KRDroid, we first evaluated it on a dataset with ransomware and other samples. Then, we compared the ransomware detection capability with HelDroid [19], a well-known ransomware detector and R-PackDroid [22], an on-device ransomware detector.

5.1. Dataset

$D$ represents the dataset we used in our experiment. As shown in formula (20), $D$ contains three datasets,$D_1$, $D_2$, and $D_3$. $D_1$ contains 1862 different kinds of ransomware in the period of 2014–2021 collected from reference [24,25,26,36,37], including Koler, Locker, PronDroid, Simplocker, Svpeng, Congur, Fusob, Jisut, Pigetrl, Rkor, Piom, and other types of ransomware. As shown in Figure 5, $D_1$ contains 425 ransomware applications in the period of 2014–2015, 767 ransomware applications in the period of 2015–2016, 240 ransomware applications in the period of 2017–2018, and 430 latest ransomware applications in the period of 2021.1–2021.6. We used $D_1$ to test the capability of KRDroid and evaluate whether KRDroid can still identify unseen ransomware when facing the latest samples.

$D_2$ contains 1000 different kinds of malware (except ransomware), including Smsreg, a malware family that makes users register to premium services unknowingly, Windadware, an adware family that delivers adwares to devices, Emial, a malware family that monitors SMS messages on devices, Agentspy, a malware family that steals privacy information on devices, DroidKungFu, a kind of remote command and control (C&C) servers Trojans and other types of malware. We used $D_2$ to evaluate whether KRDroid misjudges malware as ransomware.

$D_3$ contains 1697 goodware applications, including screen beautification applications, files management applications, and other goodware applications. We used $D_3$ to evaluate whether KRDroid misjudges goodware applications as ransomware or misjudges ransomware as goodware applications.

$$\mathit{D}=\left\{{\mathit{D}}_1,{\mathit{D}}_2,{\mathit{D}}_3\right\}$$

(20)

5.2. Evaluation Metrics

In order to give a better evaluation of experiment results, we calculated accuracy, precision, recall, F1-score, false-positive rate, and false-negative rate for ransomware-oriented detector. As shown in formula (21)–(26), accuracy represents the total number of correct ransomware and other applications divided by the total number of classifications. Precision represents the accuracy of the detector in terms of data. The recall represents the sensitivity of the detector. F1-score represents the combination of precision and recall. False-positive rate represents the rate by which the detector misjudges negative ones as positive ones. False-negative rate represents the rate by which the detector misjudges positive ones as negative ones. In formula (21)–(26), the following are included:

(1) $\mathit{TP}$: The number of true positives, which means the classification of the detector is correct, and the application is ransomware;

(2)$\mathit{FP}$: The number of false positives, which means the classification of the detector is incorrect, and the application is not ransomware;

(3) $\mathit{FN}$: The number of false negatives, which means the classification of the detector is incorrect, and the application is ransomware;

(4) $\mathit{TN}$: The number of true negatives, which means the classification of the detector is correct, and the application is not ransomware.

$$\mathbf{accuracy}=\frac{\mathit{T}\mathit{P}+\mathit{T}\mathit{N}}{\mathit{T}\mathit{P}+\mathit{T}\mathit{N}+\mathit{F}\mathit{P}+\mathit{F}\mathit{N}}$$

(21)

$$\mathbf{precision}=\frac{\mathit{T}\mathit{P}}{\mathit{T}\mathit{P}+\mathit{F}\mathit{P}}$$

(22)

$$\mathbf{recall}=\frac{\mathit{T}\mathit{P}}{\mathit{T}\mathit{P}+\mathit{F}\mathit{N}}$$

(23)

$$\mathit{F}1\mathit{score}=2\times \frac{\mathbf{Precision}\times \mathbf{Recall}}{\mathbf{Precision}+\mathbf{Recall}}$$

(24)

$$\mathbf{false}\mathbf{positive}\mathbf{rate}=\frac{\mathit{F}\mathit{P}}{\mathit{T}\mathit{N}\mathit{+}\mathit{F}\mathit{P}}$$

(25)

$$\mathbf{false}\mathbf{negative}\mathbf{rate}=\frac{\mathit{F}\mathit{N}}{\mathit{T}\mathit{P}\mathit{+}\mathit{F}\mathit{N}}$$

(26)

5.3. Experiments

In this work, we will answer the following three questions to evaluate the detection performance of KRDroid. For each question, we first describe an experiment and give the corresponding results. Then, we provide a brief insight to summarize. The training dataset of all the experiments is the same.

We used 1526 ransomware in the period of 2014–2015 from reference [36], including Koler, Locker, PronDroid, Simplocker, Svpeng, and unlabeled ransomware applications as positive samples to train KRDroid. We used 400 malware and 1200 goodware applications in the period of 2014–2015 as negative samples to train KRDroid; in KRDroid, the issue is not to only distinguish ransomware from malware applications but rather to distinguish ransomware from goodware applications.

In addition, we compared the MD5 of each sample in the test dataset with the training dataset before we started experiments to make sure that all the samples in the test dataset of the following experiments are different from samples used for training.

$Q1$: What is the ransomware detection capability of KRDroid?

$Q2$: Will KRDroid misjudge other malware applications as ransomware?

$Q3$: Is the efficiency of KRDroid acceptable?

5.3.1. RQ1: What Is the Detection Effect of KRDroid?

In this experiment, we took $D_1$ and $D_3$ as the dataset for testing. The test dataset contains 1862 ransomware and 1697 goodware applications from reference [24,25,26,36,37,38]. In order to better evaluate the capability of KRDroid, we compared KRDroid with two ransomware-oriented detectors, HelDroid [36] and R-PackDroid [38]. HelDroid is a well-known ransomware-oriented detector, and we reproduced HelDroid from reference [36]. R-PackDroid is an on-device Android ransomware-oriented detector, and it can be download from reference [38]. The detailed result of this experiment is shown in

Table 6. The comparison results of KRDroid, R-PackDroid, and HELDORID.

Model	Positive(TP+TN)		Negative(FP+FN)	Accuracy	Precision	Recall	F1-Score
	Ransomware	Goodware
HelDroid	1558	1397	604	83.03%	83.67%	83.85%	83.76%
R-PackDroid	1692	1613	254	92.86%	90.87%	95.27%	93.02%
KRDroid	1809	1665	95	97.33%	97.15%	97.73%	97.44%

.

HelDroid correctly identified 1558 ransomware and 1397 goodware applications. The accuracy of HelDroid is 83.03%. R-PackDroid correctly identified 1692 ransomware and identified 1613 goodware applications. The accuracy of R-PackDroid is 92.86%. KRDroid correctly identified 1809 ransomware and 1655 goodware applications. The accuracy of KRDroid is 97.33%. The precision, recall, and F1-score of KRDroid are also higher than the two detectors.

We randomly sampled 46 true negatives and further analyzed the result of HelDroid. After the real machine test and decompile analysis, we found that there were 28 samples in 46 true negatives cannot be detected because of the unseen languages. Nine ransomware applications in the rest of the true negatives cannot be detected because of the unsuccessful lock detection. All of these samples had already been detected as sensitive text. In addition, we found that there were four samples in these nine ransomware applications that belong to screen resource control ransomware. As we mentioned before, this kind of ransomware does not need some real lock APIs such as lockNow() to reach their goals. The last nine ransomware applications that are misjudged are true negatives, which had not been detected.

The goal of R-PackDroid is to use a compact set of information more than enough to detect a wide variety of samples [22]. When building the detector, it uses the system API package list to represent the application rather than building multidimensional attack-pattern-based features. To some extent, it may cause some misjudgments because of the lack of effective information.

In addition, as is aforementioned, ransomware in $D_1$ is in the period of 2014–2021.6. KRDroid has good performance on identifying unseen ransomware in this experiment, which means that KRDroid is still valid when facing the latest samples in 2021.

Insight. Due to the accurate characterization and comprehensive behavior-based features build of ransomware applications, KRDroid can detect ransomware by analyzing source code. It detects ransomware by means of detecting ransom behaviors. In this way, national languages requirements do not need to be taken into consideration during detection.

KRDoid has good generalization. It can identify unseen ransomware similar to the training samples and can also identify unseen ransomware applications after they have already evolved. To some extent, it can also show that our analysis and behavior-based feature extraction of ransomware applications is valuable.

5.3.2. RQ2: Will KRDroid misjudge other malware applications as ransomware?

Since a ransomware application is a kind of malware, we still need to test that the accuracy of KRDroid is independent of malware classification. We randomly sampled 1000 ransomware in $D_1$ and randomly sampled 1000 goodware in $D_3$. These samples are collected from reference [24,26]. We used these samples and 1000 malware in $D_2$ as the dataset for test in this experiment. As mentioned above, all the applications in $D_2$ are malware, which is different from ransomware.

As shown in Figure 6, we found that there are 981 samples that can be correctly identified as ransomware, and only 19 ransomware misjudged as non-ransomware. There are 1986 samples that can be correctly identified as non-ransomware, and only 14 non-ransomware misjudged as ransomware. The false-positive rate of KRDroid is 1.94%, and the false negative rate is 0.7%.

Insight. KRDroid is a ransomware-oriented detector rather than a malware detector. It does not misjudge other malware applications as ransomware because other malware applications do not have typical ransom behaviors.

5.3.3. Is the Efficiency of KRDroid Acceptable?

We measured the efficiency of KRDroid on 450 samples collected from Virustotal [24]. Meanwhile, we used the same test dataset to test the HelDroid. Because R-PackDroid is an Android on-device detector, we did not take it into consideration. We assessed the execution time of HelDroid and KRDroid by running it on six cores of a MacBook Pro laptop containing an Intel Core i7 CPU 0.6 GHz processor.

The execution time of HelDroid was nearly 4 h 30 min, and the main bottleneck is the locking strategies detection [19]. The average CPU usage of Heldroid is nearly 90%, and memory usage is 18%. The execution time of KRDroid was nearly 5 s. The CPU usage of KRDroid is 1.6%, and the memory usage is less than 1%.

Insight. The efficiency of KRDroid is acceptable for detecting large-scale applications. It can detect a number of applications with fewer resources.

6. Limitations and Future Work

KRDroid is an Android ransomware-oriented detector that deploys on servers or PCs. KRDroid detects ransomware applications based on behavior patterns with the help of static analysis. Though KRDroid can identify most ransomware applications with less time and high accuracy, and it can identify ransomware even if evolved, there is still some ransomware applications that may be misjudged. Because these ransomware applications are implemented with the help of obfuscation, steganography, reflection, and reinforcement as goodware for these methods can prevent applications from being totally decompiled and KRDroid could not obtain some core codes of ransomware. In the future, we will pay more attention to the detection of ransomware with code protection methods with the help of dynamic analysis. In addition, our research only focused on ransomware applications on Android. In the future, we will also turn our attention to the ransomware appoications in other platforms.

In addition, how to stop or prevent ransomware on Android devices is very essential for users. In our future work, we will pay our attention to on-device ransomware detectors and real-time files and devices protection against ransomware on Android devices.

7. Conclusions

In this paper, we made a detailed analysis of three kinds of active ransomware applications for mobile devices, including the different runtime behaviors and ransom code. To ensure the extracted features have discrimination, we made a comparative analysis to find out the differences between ransomware and goodware applications with similar behaviors. Then, we proposed a ransomware-oriented detector with a behavior-pattern-based multidimensional feature set. The detection can successfully identify more ransomware applications and can also distinguish ransomware from goodware with similar behaviors. It has a low false-positive rate and takes less time for detection.