1 Introduction

Because Android is an open source platform, its internal structure can be easily analyzed by hackers. It means that Android is inherently weak in security and vulnerable to attacks. According to the report [13] from NQ Mobile in 2012, 95% of malicious codes in mobile environments targeted Android. According to Juniper Networks, their Global Threat Center found a 400% increase in Android malware since summer 2010 [10]. The reasons why most mobile malware targets Android are an increase of Android users and ease of creation of malicious codes. Because most Android Apps are implemented in Java that is highly portable, malicious code injection and repackaging are not difficult due to ease of reverse engineering. In addition, Google’s Android Play Store [7] entrusts everything to developers. So the risk ratio of malicious code distribution is greater than that of Apple’s App Store.

The volume of personal information on Android mobile phones is getting higher compared to second generation mobile phones. For instance, smartphone devices can manage a wide range of SNS information, private web search details, personal location data, and sensitive financial transactions that cannot be handled by second generation mobile phones. The data that can be handled by smartphones is as wide as personal computers. In terms of personal information, smartphones can handle more data compared to personal computers. Accordingly, the devices are highly vulnerable to malicious attacks by hackers.

As mobile smartphones are becoming more powerful, various multimedia applications are being used. Private information on smartphones are obtained using multimedia device like microphones and cameras. As a result, not only the user’s private information such as SMS, email, contact lists, calling history, and location information but their multimedia contents like voice/image (picture)/video need protection. L. Wu et al. [17] presented the attack models in mobile multimedia applications. Furthermore, through experimentation, he evalated feasibility and effectiveness of these attacks, and proposed an effective defence scheme to secure a smartphone from these spy camera attacks.

A malware that is contained in a Multimedia content can easily be a threatening behaviour without the need to rob a specific authority from OS, since a Multimedia player has already acquired an authority from OS/user. As the Player plays a role of VM (Virtual Machine), it is possible to check for presence or absence of malware for the Player application itself, but a malware can exists in a content operating in a layer above. Because these malwares are not mounted on the Player itself, it is difficult to detect them with a general malware scan.

Recently, as many different types of spyware are increasing, those malicious codes are collecting privacy data (e.g. call details, text messages, location change events, etc.) and delivering them in order exploit that data. Because the spyware is usually deployed as a form of Android apps, it cannot be easily detected in the apps deployment stage. There are many types of spyware present such as GPS Spy, SMS Replicator and most notably Mobile Spy [15], the first Android spyware released by Retina-X Studios in November 2009.

In the Android platform environment, various techniques to detect personal information leakage are being introduced currently but effective blocking is still long way ahead. The reasons are as follows:

  • Malicious codes are evolving. Initial Android malware used a comparatively simple method that injects malicious code in a well-known application and repackages it. Thus the signature-based detection was possible that scans source code and content. However, recent malwares are applying obfuscation and encryption to source codes to avoid the signature-based detection. In addition, they are installed as normal applications but they download source code via Internet. Thus the signature-based detection in the application level is impossible.

  • The detection methods from previous studies are not easy to apply in mobile phone environments. Android based on Linux Kernel 2.6 applies a security model called Sandbox [12]. Basically, an application cannot access other applications because it receives a unique UID and runs in a separate process. It also cannot acquire system level privileges so dynamic analysis is impossible through access to system memory, network, and disks. Dynamic analyses proposed by other previous studies are very difficult to apply in smartphones because they analyze through a separate server or virtual environment.

In order to get over the limitations in the application-level’s static analysis and the kernel-level’s dynamic analysis, the proposed scheme detects suspicious APIs (taking photo, access to location information, access to SMS/MMS, access to private information, etc.) upon a call in real-time and delivers those events to users to block those behaviors in advance and protect their private information. In addition, the scheme can continually expand the reach of behavior detection mechanism according to the malicious behavior type against the target application and API behaviors. In addition, its business rules can be periodically updated through the server to keep the engine up to date. It can also overcome the post-processing limitations of anti-virus programs and block potential malicious behaviors by users.

For this purpose, various application behaviors are classified on the smartphone environment, vulnerable behaviors for monitoring are defined, the architecture to apply in the Android framework is proposed, and its stability and feasibility are verified by implementing the proposed scheme in the Android environment.

This paper is organized as follows: Chapter 2 finds the characteristics of previous studies for detecting personal information leakage. Chapter 3 classifies vulnerable application behaviors and the behaviors for monitoring. Chapter 4 introduces the architecture and operation techniques of the proposed scheme. In Chapter 5, the performance evaluation of the system implemented on the Android smartphone is verified. Chapter 6 concludes with results and explains the study plan for the future.

2 Related work

This chapter finds the characteristics of the previous studies for monitoring any personal information leakage. According to the detection level, this paper classifies previous studies into the application level and kernel level as shown in Table 1.

Table 1 Classification of studies according to detection level
Full size table

2.1 Detection of application level

In the application level, static analysis is possible as well as dynamic analysis. The static analysis in Android does not run an application but scans the content itself such as source code, permission information, layout, resource, and such.

Di Cerbo et al. [4] used the Android permission in manifest.xml to predict leakage of personal information. Kim et al. [11] disassembled DEX files as well as Android permission to create an API that tries to leak personal information. Using the API, they proposed a model that detects personal information leakage. Zhou et al. [19] created a signature based on the permission and API to quickly detect well known malicious codes in the Android market. In order to detect new types of malware that run by dynamically fetching codes, they proposed a heuristic detection scheme that detects both the original code and dynamic code. In addition, they verified the efficiency of the proposed scheme by implementing Droid Ranger. Wu et al. [16] tested various clustering algorithms to effectively classify malwares that try to leak personal information by using a combination of permission, Android components, and API and found an optimal algorithm.

Fuchs et al. [6] analyzed the general flow of personal information by implementing Scandroid that tracks the flow and using the security policy specified in manifest.xml and the Android content provider. Enck et al. [5] implemented TaintDroid to trace the flow of sensitive personal information through execution of malicious code and they verified the ability to detect personal information leakage. Zhao et al. [18] recorded the logs for access to personal information and its leakage and they found the behavioral flow and characteristics. Afterwards they applied the SVM algorithm to show a successful detection of personal information leakage. In machine learning, SVMs(Support Vector Machines) are supervised learning models with associated learning algorithms that analyze data used for classification and regressing analysis.

According to abovementioned studies, they performed the static analysis and dynamic analysis in the application level to detect personal information leakage. However, the static analyses in the application level are vulnerable to new types of attacks because it needs signatures of existing malicious codes. In addition, the dynamic analyses of previous studies require a separate virtual environment or server so they are difficult to be applied in smartphones.

2.2 Detection of kernel level

In the kernel level, it is possible to analyze behaviors in real-time because system resources can be accessed with partial system modification.

Burguera et al. [2] recorded system call logs, created a vector by extracting the characteristics of personal information leaking behaviors, and proposed a malware detection method after applying the K-means algorithm. Isohara et al. [8] recorded the logs for system calls and parameters through system call hooking method and found the signature that is used during information leakage. Blasing et al. [1] modified the system and created a virtual environment.

They proposed a comprehensive analysis that detects malwares by analyzing the permission and recording system call logs. However, previous studies in the kernel level use log-based detection techniques. So it is difficult to detect and block malwares in real-time.

3 Identification of threat behaviors

Let us classify the properties of smartphone applications based on the behavior and perform the risk analysis for each behavior. In addition, let us define vulnerable behaviors while running applications and specify the behaviors that require real-time monitoring.

3.1 Classification of behaviors in smartphone applications

The behaviors that are run in smartphone applications are classified as in Fig. 1. The behaviors in smartphone applications are classified into verified secure behaviors (White list), unverified behaviors, potentially vulnerable behaviors, and known malicious behaviors (Black list). In addition, according to the danger level, the behaviors can be classified as in Table 2.

Fig. 1
figure 1

Classification of behaviors in smartphone applications

Full size image
Table 2 Risk analysis according to application behaviors
Full size table

The operation models that can analyze the behaviors of applications and enable a secure service environment on smartphone devices are shown in Fig. 2. While a secure service can be provided by restricting risky behaviors, minimization of restrictions can increase the danger with increase of applications running.

Fig. 2
figure 2

Operation models based on application behaviors in a smartphone

Full size image

With (a), it restricts all behaviors other than verified ones. This high ranked protection model blocks personal information leakage from the origin and causes only restricted applications to run. With (b), this middle ranked protection model restricts running known malicious behaviors and suspicious behaviors to prevent explicit and potential dangers but most applications can be run in this model. With (c), this low ranked protection model restricts only known malwares to prevent explicit dangers. With (d), this lowest ranked protection model does not monitor and restrict any special behaviors in the devices.

3.2 Selection of target behaviors for monitoring

This paper selected malicious behaviors that require monitoring in a smartphone device as shown in Table 3. Each individual behavior or a combination of those behaviors can give threat to smartphone security.

Table 3 Major behaviors that require monitoring in a smartphone
Full size table

The selected behaviors determine whether or not to block them through real-time monitoring. Especially, the behaviors to monitor are taking photos, collection of position information, access to personal information, access to files of user, network access, calling phones, SMS delivery, and such. Furthermore, it requires a detection map that runs these behaviors to monitor while in LCD On/Off or background status. When the corresponding application calls an API for these behaviors, user must be allowed to block desired behaviors and other threatening behaviors must be blocked always.

For instance, network access that operates after photo shoot, collection of position information, access to personal information, and access to files of user can have significant potential privacy leakage. In addition, it is possible for a user to set rules and options – Selectively Blocking & Always Blocking – in order for the user to recognize these acts depending on the device’s LCD On/Off condition or background state. To be specific, Always Blocking mode is suitable for a device when it makes phone calls or delivers SMS while the device’s LCD state is off, as that indicates those acts to be occurring without the user’s recognition.

3.3 Requirements

In case of existing mobile anti-virus programs, known malwares are effectively detected but new types of malwares and malicious code variants cannot be screened. In addition, due to constraints in Android, malware detection through real-time monitoring is not possible inherently compared with anti-virus programs on PC.

To block malwares through behavior-based monitoring, the real-time detection is a must and the behavior-based business rules must be updated in real-time for efficiency. Furthermore, common rules for various applications must be applied. In addition, when the real-time monitoring specs are being applied while monitoring APIs, any execution performance problem may incur user inconvenience. The detailed requirements are as follows:

  • Real-time behavior control: In order to block the behaviors that have security fears, it stops or allows running core APIs in Android according to the predefined business rules.

  • Update of blocking rules: The function that updates the blocking rules with synchronizing with the server must exist and new blocking rules are downloaded from the client for application of them.

  • Overhead minimization: Using the background process, the overhead must be minimized for running applications and calling a relevant API.

  • Compatibility: The proposed scheme must be available in all Android applications and devices not restricted in several applications and devices.

4 SafeGuard: malware detection scheme through application behavior monitoring

In order to securely protect personal information from potential security threats that cannot be screened by existing anti-virus programs by extracting unknown security threats found in behaviors on a Mobile device, the scheme is proposed that blocks running the corresponding application through real-time application behavior monitoring and malicious APIs’ calling pattern recognition.

4.1 Operational principle of the SafeGuard

This paper proposes the solution SafeGuard that can detect and block malicious behaviors of smartphone applications in real-time. The solution consists of the server that manages and deploys blocking rules and the device solution that monitors various types of behaviors of applications in Android devices.

The SafeGuard intends to securely protect personal information on smartphones by monitoring behaviors of various applications. If an application violates any behavior-based rule, the proposed scheme blocks the application.

Figure 3 shows the operational principle of the proposed scheme. The Rule Check Layer in an Android device determines whether or not to block behaviors of an application running by comparing with the predefined black and white lists. User can decide whether or not to run the behavior when an alert is received that says the behavior is not allowed. In addition, the rule database that has malicious behaviors is periodically updated so detection is possible in real-time.

Fig. 3
figure 3

Operational principle of SafeGuard

Full size image

4.2 Architecture and components in android platform

SafeGuard interoperates with the components of the Android platform to monitor malicious behaviors of applications so the left components shown in Fig. 4 are required to be added in the basic Android platform on the right.

Fig. 4
figure 4

SafeGuard architecture and components in Android platform

Full size image

The roles and functions of newly added modules are as the following:

  • The SafeGuard library is added to Android RT to receive the call logs of core libraries and decide whether or not to run a behavior according to the predefined rules. If any rule violation happens, it notifies user of an alarm and an exception occurs to block the behavior. The Rule provider stores allowed API calls for each application for management and the Rule update service receives the rules that are pushed remotely and delivers them to the rule provider. The AppMonitor module displays alarms to user, provides an interface to change the rules, and notifies user of blocking results and blocking rules, and determines whether or not to use the rule for user deletion. It is provided in the form of application to be installed and it can be updated for support of additional rules.

The existing Android core libraries call the SafeGuard check function for the API to monitor. The content provider calls the SafeGuard check function in the methods such as query(), insert(), update(), and delete() for monitoring the content provider.

Upon call of the core library of an Android application, it is required to insert a code to several methods in the core library and contentProvider. For this, collaboration is required from the device manufacturer. According to the behavior to monitor, the method to insert is determined. So at the initial stage, starting with several limited behaviors is recommended. The core library with an inserted code is dependent on the SafeGuard library. So it is required to preload the SafeGuard library along with the Android core library.

For the code insertion for the monitoring behavior-related method, the SafeGuard method call is inserted in the start area of the method and the SafeGuard class determines whether or not to allow the behavior to take no action or result in a security exception. As shown in Fig. 5, because all method parameters from SafeGuard must be defined in the same format as the inserted method, the parameters are delivered in the same order. For the behavior to block, SecurityException occurs that is a sub class of RuntimeException. In the method to insert, the method execution is stopped without extra processes.

Fig. 5
figure 5

Example of code insertion in core libraries (MediaRecoder)

Full size image

4.3 SafeGuard operating scenario

Figure 6 shows the scenario that blocks malicious codes in an application on an Android device. SafeGuard runs with three separate modules equipped in the device. The entire operation scenario up to blocking is as follows.

Fig. 6
figure 6

SafeGuard operating scenario

Full size image

When a system API call is encountered by a malicious code for an application, the Android core library calls the SafeGuard library that corresponds to the API and the SafeGuard library retrieves the blocking status from the SafeGuard agent to determine whether or not to block the behavior according to the blocking rule database and return the result to the SafeGuard library. If a malicious code is found, the judgment result is returned to the SafeGuard library and SecurityException occurs to block the malicious code. The SafeGuard application (UI) displays the blocking result for confirmation.

The SafeGuard agent periodically checks the blocking rules for update from the server. If required, the rules are automatically updated. The SafeGuard server responses against the update inquiry from the SafeGuard agent. If required, the server provides the blocking rules to the agent.

5 Implementation and evaluation

This chapter explains how to implement three Android device modules (SafeGuard library, SafeGuard agent, and SafeGuard application) in the SafeGuard solution. In addition, it also provides the evaluation results for security and performance overhead of the proposed scheme. It intends to verify the feasibility and compatibility of the scheme.

5.1 Implementation of SafeGuard

  • SafeGuard Library

The SafeGuard library is applied in the Android Core library to determine whether or not to block behaviors upon system API call. If considered as a malicious behavior, the SecurityException is performed for blocking.

For real-time monitoring in Android applications, the SafeGuard library code was inserted in the location with a security fear (GPS), hardware (camera, microphone), unique device values (IMEI, IMSI), and the core library that is related to personal information access and software installation call. Table 4 shows the targets for code insertion.

Table 4 Code insertion targets
Full size table

Figure 7 shows examples for location-related system library code insertion. It is required to insert a code and reference SafeGuard.jar while building framework.jar to include the code in framework.jar.Core libraries: Example of getLocationManagerframeworks\base\core\java\android\app\ContextImpl.java

Fig. 7
figure 7

Example of location-related code insertion

Full size image

  • SafeGuard Agent

The module determines whether or not to block behaviors. According to the blocking rules specified, it processes for SafeGuard library’s blocking inquiries. In addition, it updates blocking rules via communication with the server.

It plays a core role in SafeGuard to check whether any blocking rules exist from database after combining the application information in the SafeGuard library and the phone’s status. If any matched blocking rules, the blocking command is delivered to the SafeGuard library. In other cases, the execution permission is delivered to the SafeGuard library.

The blocking rules delivered from the blocking rule management server are kept in the database that runs with the SafeGuard agent to use in judgment for blocking. The decision must be made within a short time so the real-time inquiry is not permitted.

In case of specific APIs for monitoring, they can be called repeatedly by applications. In this case, it can affect the application performance. To prevent this, the system caches the predefined amount of blocking judgment results to make decision by using the cached data. The cached data is managed with a FIFO queue so the last cached judgment is removed first from the cache.

The SafeGuard library exists on the Android platform so the context that called the relevant API cannot be used. It means that API tools that are used by general applications are unavailable. To solve this problem, the SafeGuard library performs communication through the UNIX domain socket, through which the blocking inquiry is called in the RPC format to complete a service.

  • SafeGuard Application

The SafeGuard application is implemented in a general application format to display blocking details to users and provide configures the blocking rule settings.

The blocking rules that are managed by a SafeGuard agent can be accessed from a SafeGuard application through the content provider. If any blocking happens, through the Android platform, a message appears that the risky App is terminated abnormally and the blocking notification appears on the status bar. When the status bar is enlarged, a simplified blocking result appears. Upon selection of a blocking item, the SafeGuard application is executed for display of the result.

The blocking result displays the applied blocking rules and blocked applications in sequential order. In case of specific rules that are applied for package installation, the package name appears instead of the application name. Because the displayed data appears for reference only so users can delete blocking results with use of menu buttons. If user does not want to use the blocked applications, the application can be removed.

Figure 8 shows the examples for the SafeGuard application implementation. The application has the blocking rule selection menu, which enables user to set the custom rule according to the danger level. Using the blocking rule update function, the changed or added rules are downloaded in real-time while synchronizing with the server and the detection function is run according to the updated rules.

Fig. 8
figure 8

User interfaces of SafeGuard application

Full size image

5.2 Security

The SafeGuard system uses the protocol HTTP/1.1 through communication with devices to deploy blocking rules to the devices. The request message uses the Get method without Body and the response message is delivered using the Post method after blocking rules are built in the XML Body format. Because the message of SafeGuard consists of the request for update and its response, the HTTP connection of the client once authenticated, responses to the request and it is closed. For every request, authentication is performed for response.

  • HTTP Authorization Flow

In order to block malicious accesses by purported agents, the SafeGuard server uses the HTTP authorization mechanism (rfc2617) to receive blocking rules by receiving the requests from allowed clients.

The HTTP authorization has two schemes for Basic and Digest. Basic has the disadvantage that UserID:Password is Base64 encoded in the HTTP Header so it is easily exposed to anybody. To compensate for this, the Digest scheme is created. Thus, the SafeGuard server uses the Digest authentication.

Figure 9 shows the flow of the Digest scheme.

Fig. 9
figure 9

HTTP authorization flow (Digest scheme)

Full size image

① General Request without Authentication Data: The device agent sends the general HTTP request without authentication data.

② 401 Unauthorized: If no authentication data in the request, the server delivers the data to the device agent that can generate the authorization header with including it in WWW-Authenticate Header.

WWW-Authenticate Header is sent only when the nonce value of Authorization Header uploaded by the device exceeds the specified time period (e.g. 1 day, 3 days, 7 days), the device requests for update, or Authorization Header does not exist.

③ Request including the authentication information: The device agent that receives 401 response generates the response by using the WWW-Authenticate header data, username, and password to request it to server again.

The response value generation method is as follows:

response = <” > <KD (H(A1), unq(nonce-value) “:” H(A2)) > <”>.

H(data) means MD5(data) and KD(secret, data) means H (concat(secret, “:”, data). unq(x) means the string that removes the quoted-string from “x.”

A1 = unq(username-value) “:” unq(realm-value) “:” passwd.

passwd = SHA1(passwd-value).

passwd-value = concat(IMSI”:” SafeGuard Agent Version).

A2 = Method “:” digest-uri-value.

Method: Constantizes with the GET string.

Digest-uri-value: Constant (URI) that is defined in Authorization Header.

④ Blocking data delivery: The SafeGuard server performs the Digest authentication function for every request from the device agent.

It checks whether the nonce value in Authentication Header from the device is the same value from the server and performs the Base64 decoding to check whether it is within the valid time (one hour after the current time). For the request within the valid period, it generates the response in the same way as in the device agent to compare it with the response field from the device. With the same value, the “200 Ok” response is sent and download the blocking rules to Body. Otherwise, it generates a new nonce, sends the “401 Unauthorized” response, and downloads the WWW-Authenticate Header to the device.

  • Rule Update

The rule update in SafeGuard is sent to the device agent through Body in the Http response. It sends the XML generated in the format as shown in Table 5 after encryption that uses the AES symmetric key algorithm.

Table 5 XML tags definition for the rule update in SafeGuard
Full size table

At the stage of device booting, client’s Public key and Private key are created, and the server’s public key is loaded to the device. Then symmetric key which is used for AES encryption is delivered to the device through the client’s Public key from the server. The server and device use the same key that differs depending on the device agent. The key format is as follows:

AES Encryption Key: MD5 (RuleVersion: DeviceGroup: DeviceNumber).

Figure 10 shows the XML format that is delivered when the rule version is updated from the SafeGuard server. The update rule that blocks the spy camera’s behaviors is delivered to the device to block those behaviors through monitoring.

Fig. 10
figure 10

XML delivered upon rule version update

Full size image

5.3 Performance

In order to measure the overhead upon application of the proposed scheme in an Android phone, the API execution times were measured while in binary status with no SafeGudard, inactivated status, and the status for analysis was activated. For the test, the times were measured in an Android phone (Nexus S, ICS OS).

Figure 11 shows the conceptual overhead diagram.

  • Overhead = Number of API Executions * SafeGuard Execution Time (Red-colored area in the following figure)

  • Level of Perception = (Number of API Executions * SafeGuard Execution Time) / Application Operation Time * 100% (Time rate of the red-colored area compared to the total operation time as the figure below)

Fig. 11
figure 11

Conceptual overhead after running SafeGuard

Full size image

In order to measure performance decrease in the device through application of SafeGuard, the overheads were measured over main APIs that are defined in Table 4: location, hardware (camera/microphone), access to device’s unique values, personal information (Query/Delete/Update), software installation, etc.

  • Overhead comparison upon API call

Figure 12 shows the measured operation times upon API call for each target API. When measuring the time differences between API start and end points for the binary without SafeGuard and the binary with SafeGuard, it was found that an overhead is approximately 5 to 10 ms. (In case of two APIs for access to IMEI and IMSI, an overhead of approximately 10 to 17 ms was found.)

Fig. 12
figure 12

API execution time: (a) without the SafeGuard API (b) inactive SafeGuard API (c) active SafeGuard API

Full size image

The overheads did not differ for each API upon repeated calls and the performance decrease was reduced due to cached data.

  • Monitoring API call frequency from Applications

In order to measure the number of monitored API executions, the number of target API executions were measured for applications for each category in Google Play store as shown in Table 6. As the result, except for the personal information APIs, the target monitored APIs were not frequently used.

Table 6 Use frequencies of monitoring APIs for each application
Full size table

In conclusion, the overhead was found when SafeGuard was installed. The calling frequency of recording, taking pictures by camera, location information, IMEI or IMSI was not high. The API that accesses personal information (addresses, call logs, etc.) reduced the overhead by using the map cache. (When actual application usage times are compared, there were no great differences.) Because the execution performance was more dependent on the device condition rather than the effect of SafeGuard, the performance degradation was rarely affected by SafeGuard.

  • SafeGuard’s effectiveness

Evidential facts of SafeGuard detecting malcious behavors of newly issued android malware which could not be treated with existing vaccines will be provided to prove SafeGuard’s effectiveness.

Android.Geinimi (discovered 2011) is a malware which inserts and redistributes itself in a standard Andriod application. When contaminated, it delivers device user’s private information (SMS, contact list, location information) to the server every five minutes as it includes a Bot function and this ability to do so makes the malware especially dangerous. Execution of Android. Geinimi is detected by SafeGuard due to its SMS/Contact list/Location information no access rule. Initially in existing vaccine, it was not capable of detecting Android. Geinimi and Android. Geinimi could only be detected after related pattern addition.

Android-Spyware/Adrd.E, F, G, H that records phone calls without the device user’s recognition, connects to specific server and exposes phone numbers/IMEI/IMSI, sends SMS, and conceals SMS reception according to attacker’s demands. In SafeGuard, by call recording blocking rule prevents the malware. The malware was not detected by existing vaccine until pattern update.

As Kernel level can detect malwares during its run time, it is concluded to be a real-time detection. However, rather than judging the various malicious behaviors through analyzing system call logs (for example, read(), open(), kill(), etc.) recognized at Kernel level, it is believed to be more effective and precise to assess at the platform API level which is a higher layer. SafeGuard proposes to define rules of multiple cases of malicious behaviors. It is easier for implementation on smartphone, and more efficient to detect malicious behaviors during API execution compared to Kernel level detection.

Advantages and disadvantages of Application, Kernel Level and SafeGuard are tabulated below.

 

Application level

Kernel level

SafeGuard

Detection method

- Android permission analysis

- Comparison of source code or content’s Signature

- System call log analysis

- System call parameter analysis

- Real time detection of melicious api during application execution in android platform.

Pros

- Easy implementation

- Thorough detection

- Real time detection

- Blocking rule update from remote server

Cons

- Signature detection is impossible when applying encryption or code obfuscation at the application

- Proactive difficult for new malware

- Acquirement of system level’s permission is impossible

- Difficult implementation in smartphone due to requirement of analysis in separate server or virtulized environment

- Partial modification of android core library necessary (cooperation with device maker)

- Malicious behaviors definition and management required

6 Conclusions and future work

This paper intends to securely protect personal information on smartphones by monitoring behaviors of various applications. If an application violates any behavior-based rule, the proposed scheme blocks the application.

In order to get over the limitation of static analysis and dynamic analysis in the application or kernel level, SafeGuard is intended for users to detect any suspicious API calls on the Android platform in real-time. With aid of device manufacturers, upon any suspicious API calls, the newly designed code syntax inserted in the Android core library can be called by the SafeGuard API and can be linked upon Framework build for verification of its performance and functionality.

The behavior-based monitoring scheme proposed here blocks malicious behaviors through real-time monitoring of risky behaviors. Furthermore, the scheme was verified and can be applied to smartphones through implementation.

The proposed technique can easily detect personal information leakage, which is not easy to detect through the signature-based approach. Different from other proposed techniques, it can detect and block behaviors on a smartphone in real-time. Using the remote server, the blocking rules can be updated and distributed in background to minimize the overhead for running applications and calling relevant API.

The proposed scheme is not restricted to several applications but it can be applied in all Android applications and devices. Therefore its operation compatibility is guaranteed.

In the future, study on different detection approach against privilege escalation attacks and potential threats is required to proceed monitoring hooking modules that can evade the proposed technique.