HAL-Based Resource Manipulation Monitoring on AOSP

Nowadays, Android malware uses sensitive APIs to manipulate an Android device’s resources frequently. Conventional malware analysis uses hooking techniques to detect this harmful behavior. However, this approach is facing many problems, such as low coverage rate and computational overhead. To solve this problem, we proposedHALWatcher, an alternative technique to monitor resource manipulation on Android Open Source Project (AOSP). By modifying Hardware Abstract Layer (HAL) resource accessing interfaces and their implementation, we can embed more monitoring functions at critical methods that are in charge of transferring data between the Hardware Driver and the Framework Layer. Hence, HALWatcher provides a lightweight and high coverage rate system that can perform resource manipulation monitoring for Android OS. In this paper, we prove that the hooking technique is limited in detecting resource manipulation attacks. Besides that, HALWatcher shows an outperform detection rate with a low computational effort.

ey have invested a huge effort to generate effective architectures to defend against Android malware [6]. Generally, a detection solution has two main parts: Malware analysis and Detection algorithm. e analysis part can be done by two main approaches: Static and Dynamic Approach. In the end, this part provides a set of patterns or features which are fed to the Detection algorithm.
Both Static and Dynamic approaches try to figure out the malicious behaviors of malware. Resource manipulation is one of the most popular harmful attacks. By different techniques, the malicious apps manipulate user's device resources, e.g., Camera, Phone, and SMS, to steal sensitive information or send messages to premium numbers without user awareness [7]. e privilege escalation attack is even more dangerous. ey can take over device resources without user interaction. So there is a great need to design a detecting model for resource manipulation attacks.
Existing analysis techniques can be applied to solve this problem. One of the typical static analysis approaches is building a flowgraph based on critical API calls. Based on that, we can deduce what resources the malicious app manipulates. However, Android malicious samples have been obfuscated or encrypted using various evasion techniques. is difficulty significantly decreases detection accuracy. Dynamic behavior analysis seems to be a good supplementary solution. is approach uses hooking tools, such as xPosed, Frida, etc., to monitor and trace malware behaviors. ere are many sensitive APIs that are related to controlling the device's resources. Hooking into all of these APIs may cause the computational overhead problem due to mobile devices' limited computing resources. erefore, malicious apps are often crashed while the analysis is operating. Moreover, hooking tools are detectable due to its direct interference with the process's memory.
To address the limitation of hooking techniques, we design HALWatcher, a general method for monitoring Android hardware resources inside Hardware Abstract Layer (HAL). e idea is that HAL provides the interface for the communication between the Android Framework Layer, which handles the requests of getting resources from applications or processes, and the Hardware Driver inside the kernel layer. By modifying HAL interfaces and implementation codes, we can keep track of all the manipulating hardware resources without any knowledge requirement about various vendors' hardware drivers. Moreover, HALWatcher does not require root permission because it is already working as a part of the Android system. Furthermore, the detection of HALWatcher in the system is almost impossible because of the various ways of modifying HAL in such a large number of developers. Although the flexibility is not high, our method dramatically reduces the amount of data collection work from dynamic analysis while also providing sufficient information for Android devices' protection service against bad actors.
HALWatcher architecture can be applied to develop various applications both in research and industry field. It is a useful technology to track malware behaviors, then constructing a complete dataset for dynamic analysis is achievable. Besides, this technology is suitable for all Android mobile device hardware because it only interferes with Hardware Abstract Layer. erefore, developing a hardware resources manipulation system on real-world Android devices is uncomplicated. Moreover, root privilege is nonessential for HALWatcher, in which other hooking frameworks are strongly dependent.
In summary, this paper has the following contributions.
We demonstrated that the hooking techniques might not be useful for detecting resource manipulation attacks. We proposed HALWatcher, an efficient and lightweight method to detect resource manipulation attacks. By modifying HAL, this module runs along with the Android system so that it is almost undetectable. e rest of this paper is organized as follows: the background of HAL and resource manipulation monitoring is introduced in the second section. In the third section, we discuss how to detect resource manipulation attacks. After that, we present HALWatcher, a HAL based resource monitoring system running along with the Android OS. e implementation and the design of experiments are shown in the next section. Finally, we will discuss future work and conclusions about our work.

Resources Manipulation.
Android malware analysis is well-studied nowadays [8]. Analytical techniques include dynamic analysis [9][10][11][12][13] and static analysis [5,[14][15][16][17]. Some frameworks seek to classify malicious code through application behavior following signature [9,14], while others track data flow [15,18]. Static analysis is the way to understand the application by finding the signatures of malicious code (e.g., permissions that the application has declared, APIs that the application uses). Dynamic analysis directly executes malicious apps in a sandbox environment [3], then collects the necessary information and organizes them to process. e data from dynamic analysis and static analysis are then fed into algorithms to assess application behavior. In particular, the application of machine learning and deep learning in the classification of malicious apps is trendy due to its high accuracy [6,12,[19][20][21][22].
Data collection from the dynamic and static analysis has always faced many difficulties and obstacles [4]. Evasion techniques make it difficult for static analysis to locate the used APIs or to figure out the execution flow of data [15]. Meanwhile, dynamic analysis has difficulty finding ways to execute all the behavior of the application being analyzed automatically [10], along with a large amount of information that may not be needed after running malicious apps. However, we must recognize the flexibility that current dynamic analytical techniques are very high. e hybrid approach combines static analysis and dynamic analysis to solve the limitations of each technique [4,23]. Wong et al. proposed IntelliDroid [24] that generates input for the dynamic analysis using the static analysis technique.
Malware behavior tracking is a common problem. One of the efficient ways to track malicious behavior is to detect resources that are manipulated by malware from an Android device. Almost all attackers' purposes are trying to steal sensitive data from the user by manipulating the phone resources such as CAMERA, MICROPHONE, PHONE, and SMS. Jiang et al. designed a resource management system architecture to collect data for behavior detection [25]. Static analysis is limited to detect unauthorized resource usage. Meng et al. constructed a graph-based model to describe the control flow of an application. However, their approach does not seem much effective with 89.5% precision [26]. Zhao et al. leveraged the power of Androguard to extract a set of sensitive APIs to represent the application's behavior [27]. e dynamic analysis uses hooking techniques. Using Java function hooking technology, Soewito and Suwandary successfully illustrate that their proposal is applicable to data leakage prevention [28]. Hooking technologies are easy to install and detectable to monitor resource manipulation. For instance, Frida, a hooking framework, interferes with the application's memory, which process it needs to analyze. e agent and then needs high privileged access because the Linux kernel does not allow any processes to interfere with each other's memory without authorization. erefore, to use the hooking techniques, the device must be rooted, or the agent of the hooking framework must be attached to the application they want to analyze.
Frida framework has two ways to hook the function of target APK. First, it needs to run frida server inside the devices as root permission or nonroot permission with enough capability to access other processes 'memory. e frida server then modifies the memory to overwrite the functions which are specified in the JavaScript-based hooking script. e target app will use the overwritten function instead of the original function for its execution. For the second way of using Frida, we need to attach the frida-agent.so library into the target APK and repackage the APK. frida-agent.so then acts as frida server but with no root privileges requirement because the attaching agent is now a part of the application to fully access its memory.
Strace is a possible solution to hide from evasion malware. However, the massive log of the system call is quite complex to process.

Hardware Abstract Layer. A HAL (Hardware Abstract
Layer) 1 defines a standard interface for hardware vendors to implement, enabling Android to be agnostic about lowerlevel driver implementation. Using a HAL allows you to implement functionality without affecting or modifying the higher-level or lower-level system. e legacy HALs is the old architecture for Android Nougat (7.0) and the previous versions. In Android 8.0 and higher, the architecture is designed to meet the requirements of modularity.

Resource Manipulation Attack Detection
Currently, the dynamic analysis approach can use the hooking technique for detecting resource manipulation attacks. Figure 1(a) describes the method of using Frida to keep track of the SendSMS function. To know whether the app manipulates SMS resources by requesting SendSMS or not, we hook into sendTextMessage(). e logging method is used in this example to gather the manipulation information. We found some disadvantages to this method.
Detectable. Hooking techniques require access to application memory during the analysis. Self-checking memory is one way to figure out the strange agents (e.g., frida-agent.so). Besides, the requirement of root privileges (i.e., in the case of frida server) makes it exposed to the Android system. Darvin claims in his blog 2 that there are many ways for an application to detect the existence of Frida inside the execution environment. Szczepanik et al. proposed an algorithm using stack-trace on detecting hooking tools [29]. Messy or Imperfect Data. Some SDK APIs call each other when the app requests a resource. Even the analyzer tries to reduce the number of sensitive APIs, but this is hard work. On the other hand, some APIs might be missed in the hooking list leading to the increasing of False-positive and False-negative. Inapplicable to End-User Products. Most of the hooking techniques are applied in solving behavior analysis problems. It is hard to include these techniques into real end-user products due to the risk of misappropriation for wrong usage (i.e., bypass the protection mechanisms of apps).
Modifying HAL is the best choice for monitoring manipulation resources for many reasons. Firstly, all hardware resource requests go through HAL. erefore, monitoring resources based on HAL gives a high coverage rate. Secondly, HAL is independent of the hardware driver. e monitoring module in HAL can work correctly for a wide range of Android devices. Last but not least, even the attack aimed to get rooted in the Android device, it cannot disable the monitoring module in HAL because this module is not running as a service, a part of the Android Operation System. We started to investigate the HAL source code and then came to these conclusions.
First, we can simply add more functions to monitor the manipulating resources with a small coding effort. Listing 1 shows a simple logging code of sendSms() function inside HAL. Line 5 is the only code that we need to add. On the other side, Frida needs more effort (i.e., see Listing 1 to hook into sendTextMessage(), which will request for sending SMS (i.e., the same resource of example in Listing 1).
Second, the information collected from HAL interfaces or functions is sufficient for detecting resource manipulation attacks. ere are multiple Android APIs that act the same behavior. For instance, both sendTextMessage() and sendMultipartTextMessage() can be used to send SMS through radio network. Moreover, sendTextMessage() have 2 different overloading methods. erefore, there is a need to develop two hooking functions for each sendTextMessage() to cover all the resource manipulation APIs. Besides, HALWatcher performs monitoring procedure accurately by adding one line of code (i.e., for logging) into the sendSms() implementation function (i.e., for the sendSms interface) as shown in Listing 2.

HALWatcher: Resource Manipulation Monitoring Module
HALWatcher, as shown in Figure 2, then works as a part of the Android Operation System. erefore, there is no requirement of the rooted system or repackaging the target application. All of the installed packages from the Play store or other Vendor market can be monitored. Besides, the process generated from a Remote Code Execution (RCE) attack is also under monitoring. Moreover, because of the diversity of vendor Android firmware (or ROM) types, the detection of HALWatcher is almost impossible. Our model generates information whenever the resource requests the hardware. erefore, the amount of information (e.g., logs) is significantly reduced but ensures that all resource manipulation behavior is recorded and reported. In the next subsection, we will give some examples of how to build HALWatcher in many types of hardware resources. Based on the previous section's conclusions examining the HAL source code, we provide a detailed design for HALWatcher. First of all, all requests to access hardware information and resources will start from the Framework Layer, namely, the Java Native Interface (JNI). We consider the Malware or RCE attack in equal measure because all hardware resource manipulating requests must go through the JNI. e information will then be moved down to the Hardware Abstraction Layer (HAL). In HAL, interfaces are feature independent; that is, there are no interfaces that share the same purpose. At the critical methods of each resource type (which we discuss in more detail in the next section), we embed one or more code lines to record any action and related information about the manipulated resource.
ese code lines are called resource monitoring modules. Listing 2 shows an example of one resource monitoring module. At line number 5, we add one line of code into the RadioImpl::sendSms interface to monitor the SMS resource by logging whenever this interface is called. In short, all resource monitoring modules are developed following three steps: figure out resources implementing interface source code in HAL, embed monitoring functions into the interfaces, manage, and send monitoring information to monitoring service. Mobile Information Systems 3

Resources Manipulation Monitoring Module in HAL
e resource monitoring modules are basically located in many critical HAL interfaces and implementation functions. In this work, we illustrate HALWatcher in monitoring SMS, PHONE, and CAMERA resources in detail. For other resources, we conduct a list of modules' locations of HALWatcher for further works.

SMS and Phone.
Both SMS and Phone permissions on the Android device allow the application of the right to access carrier service. Android communicates with carrier providers through SIM (subscriber identity module), which needs a radio baseband device to run radio service. Each baseband device has its own vendor's driver represented as "libril-vendor.so" file. Android HAL performs a RIL (Radio Interface Layer) connecting Android Framework and vendor's driver. erefore, all resource usage related to SMS and  Mobile Information Systems Phone permissions go through RIL. While analyzing the RILD, we found two types of RIL command: REQUEST and UNSOL. REQUEST command is used by the Android Framework Layer (i.e., rilj), to request data (e.g., signal strength) or functions (e.g., send SMS, conduct a call). UNSOL stands for unsolicited responses, which originate from the baseband (e.g., new SMS).

Camera. Recently, sensitive information leaked through
Camera. e Android application might run as a service that has no activity screen. In that case, the malicious application or vulnerable application attacked by an intruder can handle a camera resource silently without any notification to the user. HAL Camera interfaces have been implemented inside hardware/camera/device/1.0/default/CameraDevice.cpp. ese interfaces provide methods to communicate to Camera hardware driver such as getCameraInfo(), dumpState(), etc. Some focus on managing the memory resources for Camera device (e.g, CameraHeapMemory()), others open or close Camera device (e.g., Camera::open(), Camera::close()), and others provide normal task of the Camera functions such as startRecording(), stopRecording(), takePicture(), cancelPicture(). In order to keep an eye on Camera resources, we create logs about the function when the Camera is opened and closed. We also keep a log for the working time of the Camera because of the irregular using period.

Other Resources
Monitoring. Similar to Camera resources, other resources also have the implementation code inside/hardware/resource_name. Table 1 shows the list of hardware resources and their implementation source code. Regarding resource monitoring, we can add more features than logging the needed information for those resources.

Resources Manipulation Monitoring Service.
is service is responsible for getting data from the monitoring module inside HAL. By using the logging method, this component is not required because the log data can be got from logcat command. HAL resources manipulation module does not log for any sensitive data of the user or the phone so that this log data can be public. e service can be any application inside or outside the phone, which is the only convenient purpose for the user or analysis researcher.

Implementation and Evaluation
6.1. Implementation. We implemented our approach using AOSP version 9.0.0_r47 on a Hikey960 board 3 . e limitation of the Hikey960 is that it does not support full hardware that usually exists on a real phone (e.g., Vibrator). erefore, to prove that the HAL modifying method for resource monitoring is possible, we focused on SMS and PHONE resources.
ese resources HAL interface are implemented in hardware/ril/ as known as Radio Interface Layer Deamon, which stands in the middle of the communication between the Android Framework Layer (RILJ) and the Hardware driver (i.e., carrier baseband).
Hikey960 board has a list of hardware devices that need the corresponding HAL modules to work with. ese components are defined in hikey/device-common.mk and hikey/hikey960/device-hikey960.mk config file. Because of the limitation of hardware that the Hikey960 board supports, we can only see the impact of HAL modifying when we change the source code of the component that we listed in Table 2.
Hikey960 does not have a SIM card reader. erefore, we used the Huawei 4G E173 USB stick as a SIM card reader. en we added the Huawei lib-ril (i.e., the driver that supports E173 USB stick to work as a baseband device) at the driver layer of the final compiled AOSP. Typically, the Linux kernel will accept USB as a storage device. erefore, to make the kernel recognize the dongle as a 3 G/4G USB device, we switched the USB mode of the device using usb_modeswitch tool.
en we needed to customize the Hikey960 kernel (i.e., kernel 4.9) and add more kernel module that supports the usb_modeswitch function. We also customized the RIL daemon to automatically switch the USB device to PPP mode before loading the driver.
We evaluate our method by modifying directly to log information that goes through radio methods in RIL. In total, we customize several requesting methods, which are most related to send SMS and conduct phone calls. We also can hook the other implementation functions in the same way.

High Coverage Rate.
We used the default Messaging of AOSP to send normal SMS, Premium SMS, conduct Phone calls, and send USSD. en, we tried to send an SMS without using the application. We found a way to send SMS messages through iSms service-a default service in AOSP. We denote that Frida can not work in this situation of monitoring SMS resources. e iSms service is called by service call command through ADB shell 4 with the form: adb shell service call isms 7 i32 0 s16 "com.android.mms.service" s16 "+1234567890" s16 "null" s16 "Hello" s16 "null" s16 "null". To prove that HALWatcher can work without root privileges, we removed/ xbin/su binary and built a non-userdebug version of AOSP to unroot the ADB shell. Finally, we ran Trojan-SMS on both  Table 3 shows that 100% of data can be logged using HALWatcher. For some samples of Trojan-SMS, they detect root device so that the app immediately crashes. Some malware samples use obfuscation techniques, so the frida-agent.so may be wrongly embedded and leads to crash the app after spawning. Obviously, HALWatcher performs resource monitoring better than the Frida framework.

Compact and Complete Data.
In comparison with hooking techniques, HALWatcher is less flexible (i.e., the need for rebuilding AOSP). However, this method gives compact and complete data that can be used for real-time hardware resources manipulation and malware analysis. To observe this possibility, we compared HALWatcher with Frida by hooking into sensitive APIs that require the use of SMS [27]. We looked at two datasets, benign and malicious applications (e.g., FakePlayer). For HALWatcher, we recorded RIL requests related to SMS. Both Frida and HALWatcher used the same logging method, which logged only the called function's name and the timestamp of the calling. We ran and triggered the app to send SMS, then terminate the apps.
e result in Figure 3 shows that the log from HAL-Watcher is less than hooking techniques, while the testing application manipulates the same hardware resources. Listing 3 shows the example of different log sizes between HALWatcher and Frida on monitoring send SMS resources. e log size retrieved from hooking on the normal app is much larger than malware. We found that the normal message application has call getSubscriptionId() API   We compared the total CPU usage and Memory usage in three scenarios: (1) run the samples without Frida hooking and HALWatcher; (2) run the samples with Frida hooking; (3) run the samples with HALWatcher. For Frida hooking on (2), we conducted hooking progress on the target process only.
As shown in Figure 4, both CPU and Memory usage rates in (2) are more 5% higher than (1) and (3). We denote that the hooking script is injected into only the target application. However, in a practical resource monitoring system, we should implement instrumentation for all running processes. At that time, the system might be crashed (i.e., 5% extra computational resource for each process). Meanwhile, the indicators are almost no different in (1) and (3) whether the sample is malware or benign. Besides, the crashing samples rate is dramatically increased while we were running the test. is crashing happens because some samples are not suitable in AOSP 9.0; some samples are only crashed while we start Frida for hooking progress.

Conclusions and Discussion
Resource manipulation attacks are the most widespread malicious behaviors of Android malware. Current solutions, including static and dynamic analysis, are not efficient    enough to detect this attack. HALWatcher is a new approach that modifies Hardware Abstract Layer to monitor resources. is approach addresses the limitations of hooking techniques. HALWatcher provides a high coverage rate in monitoring hardware resources with low computational effort. In addition, HALWatcher can be applied to build a protecting mechanism in real-world devices because of the nonrooted environment requirement. However, HAL-Watcher faces some limitations. First, there is a need for strong knowledge about the Hardware Abstract Layer development to extend and deploy HALWatcher. Second, HALWatcher is only capable of monitoring hardware resources, not for others, which are already stored in system storage (e.g., CALENDAR, CONTACT, PHOTO, etc.). For our future research, we plan to research the new approach to monitoring other system resources that can integrate with HALWatcher to make a complete resource manipulation defending framework.

Data Availability
e source code and log file can be found at https://github. com/josebeo2016/HALModifying. Disclosure is paper is a revised version of the presented Poster: "HAL Based Resource Manipulation Monitoring on AOSP" in WISA 2020, Jeju, South Korea.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper.