A detection method, device and system for environment perception API in Android system

Abstract

The present invention provides a method, device, and system for detecting an environment-aware API in an Android system, relating to the field of network security technology. The method for detecting an environment-aware API in an Android system comprises: searching for all system services in the Android system and constructing an API list for the Android system based on the system services; wherein the API list includes a client API and a server API for each system service; deleting APIs from the API list that are not used for environment-awareness by malware; calling each API in the deleted API list in a real device environment and a simulator environment, respectively, and recording the execution result of each API; and determining, based on the execution results, APIs that have execution differences in different environments to obtain APIs with environment-awareness capabilities. The present invention can detect environment-aware APIs in the Android system on a large scale, effectively improving the detection efficiency of environment-aware APIs.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a method, device and system for detecting an environment perception API in an Android system. Background Art

[0002] On the Android platform, the app store is the primary way users access apps. As the bridge connecting users and apps, app stores have a greater responsibility to conduct pre-launch testing and analysis of apps to ensure they pose no threats to user privacy or even system security. In response to the demand for large-scale application testing, comprehensive malware analysis systems and frameworks have gained widespread adoption.

[0003] Existing malware analysis technologies mainly use dynamic analysis as the main method and static analysis as the auxiliary method. Dynamic analysis technology is usually based on simulators to detect the runtime behavior of applications. However, simulators are only a simulation of the real operating environment and still have many differences from real devices. Malware can exploit these differences to evade detection. For example, when malware finds that it is running in a virtual environment, it can deregister its own malicious components, conceal malicious behavior, and disguise itself as a normal application, which can easily lead to misjudgment during malware detection.

[0004] The behavior of application software detecting its own operating environment is called environmental perception. Since the Android system provides a large number of APIs (Application Programming Interfaces) for application programs to call, any slight difference between these APIs on a real device and in the simulator can be used by malware to perceive the operating environment and conceal its own malicious behavior. With the continuous updates of the Android SDK and system services, the attack points of malware through APIs for environmental perception are also constantly changing. In the confrontation between security analysts and malware, the party that first finds and discovers the environmental perception API will take the initiative. Malware can use the environmental perception API to enhance the concealment of its malicious behavior, and security analysts can also use these APIs to enhance the concealment of their analysis environment. Detecting all APIs in the Android system and finding APIs with environmental perception capabilities is of great significance to improving the detection capabilities of malware analysis systems. Therefore, how to detect APIs with environmental perception capabilities in the Android environment has become an urgent problem to be solved. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a method, device and system for detecting environmental perception APIs in Android systems, which can detect environmental perception APIs existing in Android systems on a large scale, effectively improving the detection efficiency of environmental perception APIs, and is of great significance to ensuring the security of Android systems.

[0006] In order to achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows:

[0007] In the first aspect, an embodiment of the present invention provides a method for detecting an environment-aware API in an Android system, comprising: searching for all system services in the Android system, and constructing an API list of the Android system based on the system services; wherein the API list includes a client API and a server API for each system service; deleting APIs in the API list that will not be used for environment-awareness by malware; calling each API in the API list after the deletion operation in a real device environment and a simulator environment, respectively, and recording the execution result of each API; determining APIs with execution differences in different environments based on the execution results, and obtaining APIs with environment-awareness capabilities.

[0008] Furthermore, an embodiment of the present invention provides a first possible implementation method of the first aspect, wherein the step of searching for all system services in the Android system and constructing the API list of the Android system based on the system services includes: statically parsing the Android system source code to determine the system services registered in the Android system; dynamically analyzing the operating environment of the Android system to determine the system services dynamically running in the Android system environment; constructing the system service list of the Android system based on the system services registered in the Android system and the system services dynamically running in the Android system environment; extracting the system API from the client and server of each system service in the system service list to obtain the API list of the Android system.

[0009] Furthermore, an embodiment of the present invention provides a second possible implementation method of the first aspect, wherein the step of extracting the system API from the client and server of each system service in the system service list to obtain the API list of the Android system includes: extracting the client API based on the software development kit or development documentation of the system service, extracting the server API based on the interface definition file or implementation code of the system service, and constructing the API list based on the client API and server API of each of the system services.

[0010] Furthermore, an embodiment of the present invention provides a third possible implementation method of the first aspect, wherein the step of deleting the APIs in the API list that will not be used by malware for environmental perception includes: constructing a test sample; wherein the granted permissions of the test sample include all permissions that can be used by third-party applications in the Android system; obtaining the client API of each system service in the API list based on the test sample, and deleting the APIs in the API list that the test sample cannot access due to insufficient permissions; performing static analysis on the interface definition file of the server API of each system service in the API list, and deleting the APIs in the API list that satisfy the keyword oneway in the interface prototype, or deleting the APIs whose return value in the interface prototype is empty and all input parameters do not have the out keyword.

[0011] Furthermore, an embodiment of the present invention provides a fourth possible implementation method of the first aspect, wherein the steps of calling each API in the API list after the deletion operation in the real device environment and the simulator environment respectively, and recording the execution result of each API, include: searching for the function prototype of each API in the API list and constructing the input parameters; calling each API in the API list after the deletion operation in the real device environment and the simulator environment respectively, and recording the execution result of each API; wherein the execution result includes the API identifier, the API execution status, the return value after the API execution, and the values of each input parameter.

[0012] Furthermore, an embodiment of the present invention provides a fifth possible implementation of the first aspect, wherein the input parameter construction method includes: when the parameter type of the input parameter of the function prototype is a basic type and has semantic meaning, constructing the input parameter based on parameter semantics; when the parameter type is the basic type but has no clear semantic meaning, randomly initializing the input parameter according to the parameter type; when the parameter type is an object type, calling the construction method to create an object, initializing the corresponding member variables, and constructing the input parameter according to the parameter type of the member variables.

[0013] Furthermore, an embodiment of the present invention provides a sixth possible implementation of the first aspect, wherein the step of determining the system services in the API list that have execution differences in different environments based on the execution results, and obtaining an API with environment-awareness capabilities, includes: deleting the target API in the API list that corresponds to the same API execution status, return value after API execution, and input parameter values in the execution results obtained in the real device environment and the simulator environment, and obtaining an API with environment-awareness capabilities that has execution differences in different environments.

[0014] In the second aspect, an embodiment of the present invention also provides a detection device for an environment-aware API in an Android system, comprising: an enumeration module for searching all system services in the Android system, and constructing an API list of the Android system based on the system services; wherein the API list includes the client API and server API of each system service; a filtering module for deleting APIs in the API list that will not be used for environment perception by malware; a triggering module for calling each API in the API list after the deletion operation in a real device environment and a simulator environment, respectively, and recording the execution result of each API; an analysis module for determining APIs with execution differences in different environments based on the execution results, and obtaining APIs with environment-aware capabilities.

[0015] In a third aspect, an embodiment of the present invention provides a detection system for an environmental perception API in an Android system, comprising: a processor and a storage device; a computer program is stored on the storage device, and when the computer program is run by the processor, it executes the method described in any one of the first aspects.

[0016] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, and wherein the computer program executes the steps of the method described in any one of the above-mentioned first aspects when executed by a processor.

[0017] An embodiment of the present invention provides a method, device and system for detecting environment-aware APIs in an Android system. The method includes: searching for all system services in the Android system, and building an API list for the Android system based on the system services; wherein the API list includes the client API and server API of each system service; deleting APIs in the API list that will not be used for environment-awareness by malicious software; calling each API in the deleted API list in a real device environment and a simulator environment, respectively, and recording the execution result of each API; determining, based on the execution results, system services in the API list that have execution differences in different environments, and obtaining APIs with environment-awareness capabilities.

[0018] By constructing an API list for the Android system, the present invention fully considers the client API and the hidden API on the server side, thereby improving the listed attack surface coverage. By first deleting system services from the API list that will not be used by malware for environmental perception, and then detecting APIs with environmental perception capabilities based on the API call execution results in real device environments and simulator environments, the present invention can detect environmental perception APIs existing in the Android system on a large scale, effectively improving the detection efficiency of environmental perception APIs, which is of great significance to ensuring the security of the Android system.

[0019] Other features and advantages of the embodiments of the present invention will be described in the following description, or some features and advantages can be inferred or determined without doubt from the description, or can be learned by implementing the above-mentioned technologies of the embodiments of the present invention.

[0020] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 A flow chart of a method for detecting an environment perception API in an Android system provided by an embodiment of the present invention is shown;

[0023] Figure 2 A schematic diagram of a partial AIDL file code provided by an embodiment of the present invention is shown;

[0024] Figure 3 A schematic diagram of an API call process provided by an embodiment of the present invention is shown;

[0025] Figure 4 A schematic diagram of a process for determining an API that can be used for environmental perception provided by an embodiment of the present invention is shown;

[0026] Figure 5 A schematic flow chart of a method for detecting an Android environment perception API provided by an embodiment of the present invention is shown;

[0027] Figure 6 A schematic diagram of an interaction model between an Android application and a system service provided by an embodiment of the present invention is shown;

[0028] Figure 7 A schematic structural diagram of a detection device for an environment perception API in an Android system provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments.

[0030] Currently, on the Android platform, app stores are the primary way users access apps. As of June 26, 2022, the number of apps available for installation on Google Play, the world's largest Android app store, reached 3.84 million. These apps have brought great convenience to users in various aspects of learning, work, life, and entertainment, forming a vast Android ecosystem. However, this vast ecosystem has also attracted numerous criminals who attempt to infect user devices with malicious apps. As a bridge connecting users and apps, app stores have a greater responsibility to conduct testing and analysis of apps before listing them, ensuring that they do not pose a threat to user privacy or even system security.

[0031] In response to the demand for large-scale application detection, comprehensive malware analysis systems and frameworks, such as MobSF and CodifiedSecurity, have been widely adopted in the industry. The widespread use of various code protection technologies (such as hardening and obfuscation) makes static analysis difficult to implement effectively. Therefore, these analysis systems typically adopt a dynamic-first, static-secondary analysis model. Dynamic analysis often relies on simulators to detect application runtime behavior. Simulators, in layman's terms, are virtualization technologies that provide an environment for dynamic application execution. Compared to real devices, simulators offer advantages such as security, convenience, and cost-effectiveness. However, simulators are merely a simulation of the actual runtime environment, and many differences exist between them and real devices. Malware can exploit these differences to evade detection. For example, when malware discovers it is running in a virtual environment, it can deregister its malicious components, conceal its malicious behavior, and disguise itself as a normal application. This can easily lead to misjudgments during malware detection by analysts, creating security risks.

[0032] The behavior of the application software detecting its own operating environment is called environmental perception. The core process of environmental perception technology is to discover the differences between simulated devices and real devices. The inventors have found that the differences between simulated devices and real devices can be mainly divided into the following categories:

[0033] 1) CPU emulation differences. Real Android devices typically use the ARMv7-A architecture, and the X86 emulator has some emulation flaws when emulating ARM CPU instructions. Therefore, when executing the same instruction, the real and emulated CPUs may enter different states. For example, the instruction cond:4|0001|op:4|*:12|1001|*:4 is an undefined instruction on a real device, but is emulated as an SWP instruction on the QEMU emulator.

[0034] 2) File system differences. The emulator usually contains some special system files, such as qemu-pipe in the / sys / class / misc directory.

[0035] 3) System API differences. Many system APIs have different return values on the simulator and on a real device. For example, the API getLine1Number is used to obtain the device's phone number. On the simulator, the return value of this API is fixed as 15552155XX.

[0036] 4) Differences in user behavior. For example, malware can perform environmental awareness based on information such as the number of installed apps and the remaining battery level of the device. This is because simulated environments typically only have some system apps installed and the remaining battery level remains constant.

[0037] For these types of features, the automated detection model Proteus can effectively detect and correct CPU instruction discrepancies between real devices and emulators. At the file system level, Google has almost completely banned third-party applications from accessing the / sys directory since Android 7. Differences in user behavior are less accurate and can only serve as reference features. Therefore, current environmental awareness technologies primarily focus on differences in Android system APIs. The Android system provides a large number of APIs for applications to call. Any minor differences in these APIs between real devices and emulators can be exploited by malware to perceive the operating environment and conceal its malicious behavior. Furthermore, with the continuous updates of the Android SDK and system services, the attack points for malware to gain environmental awareness through APIs are constantly evolving.

[0038] In the battle between security analysts and malware, the first to discover context-aware APIs will gain the upper hand. Malware can leverage context-aware APIs to conceal its malicious activities, and security analysts can also leverage these APIs to conceal their analysis environments. Therefore, detecting all APIs in the Android system and identifying those with context-aware capabilities is crucial for improving malware analysis systems' detection capabilities, enhancing Android system security, and protecting user privacy.

[0039] In order to find out the API with environment perception capability in the Android system, the embodiment of the present invention provides a method, device and system for detecting the environment perception API in the Android system. The embodiment of the present invention is introduced in detail below.

[0040] This embodiment provides a detection method for the environment perception API in the Android system, which can be applied to any electronic device installed with the Android system. Figure 1 The flowchart of a detection method of an environment perception API in an Android system is shown, and the method mainly includes the following steps:

[0041] Step S102: Search for all system services in the Android system, and construct an API list of the Android system based on the system services.

[0042] Find all system services in the Android system, extract and record the methods (i.e., API, Application Program Interface) in each system service, and build the Android system API list. The above API list includes the client API and server API of each system service.

[0043] All Android APIs are provided by system services. To list all Android APIs, we first list the system services. We can list the system services in the Android system statically and dynamically, then combine the static and dynamic listings to obtain a system service list. For each system service in the system service list, we list the APIs from both the client and server sides to obtain the Android system API list.

[0044] Step S104: Delete the APIs in the API list that will not be used by malware for environment perception.

[0045] The constructed API list is filtered based on accessibility and functionality, removing APIs that are unlikely to be used by malware for environmental awareness. From a threat model perspective, environmental awareness APIs should be callable by third-party malware. From a functional perspective, environmental awareness APIs should behave differently in different environments. Therefore, the constructed API list is initially filtered based on these two perspectives to improve the efficiency of subsequent detection.

[0046] Step S106 , calling each API in the API list after the deletion operation in the real device environment and the simulator environment respectively, and recording the execution result of each API.

[0047] In the real device environment and the simulator environment, each API in the API list after the deletion operation (that is, the API list that will not be used by malware for environment perception APIs) is called, and the execution results of each API are recorded, which include the call parameters, return values, and possible exceptions.

[0048] Step S108: Determine the APIs that have execution differences in different environments based on the execution results, and obtain APIs with environment perception capabilities.

[0049] Compare the execution results of the same API in different environments to identify APIs with different execution results. These APIs are considered context-aware. These differences in execution results include different execution states and different execution results. For example, a normal state in one environment may be a failure state in another; or the return value of an execution result in one environment may be different from that in another.

[0050] The detection method of the environment-aware API in the above-mentioned Android system provided in this embodiment fully considers the client API and the hidden API on the server side by constructing the API list of the Android system, thereby improving the coverage of the listed attack surface. By first deleting the system services in the API list that will not be used by malware for environment-awareness, and then detecting the API with environment-awareness capabilities based on the API call execution results in the real device environment and the simulator environment, the environment-aware API in the Android system can be detected on a large scale, effectively improving the detection efficiency of the environment-aware API, which is of great significance to ensuring the security of the Android system.

[0051] In one embodiment, in order to accurately list all APIs in the Android system, this embodiment provides an implementation method for searching all system services in the Android system and building an API list of the Android system based on the system services. Specifically, the following steps (1) to (4) can be referred to:

[0052] Step (1): statically parse the Android system source code to determine the system services registered in the Android system.

[0053] Static parsing of the Android system source code was performed to discover system services during the parsing process. Using the JavaParser tool, the AOSP source code of the Android system was statically analyzed. All registered system services in the Android system were statically extracted using the keywords registerService, addService, and publishBinderService, which were recorded as List(Service-Static).

[0054] In the Android system, a system service must be registered before it can run. The Android system provides three service registration methods: registerService, addService, and publishBinderService. All three methods require a service name as an input parameter. For example, the first input parameter of the addService API is a string describing the service name to be registered. Therefore, by parsing the source code with the JavaParser tool and recording the service names submitted in the three registration methods, you can retrieve the system services registered in the source code.

[0055] Step (2): Dynamically analyze the operating environment of the Android system to determine the system services that are dynamically running in the Android system environment.

[0056] To extract system services from a running Android environment, use the ADB debugging tool to access the Android device shell and then use the service command line command to extract the dynamically running system services on the device, denoted as List(Service-Dynamic). The dynamic running environment can be a real Android device or an Android emulator created using tools such as Android Studio. However, the system version of the running environment must be consistent with the source code version used for static analysis.

[0057] Step (3): Based on the system services registered in the Android system and the system services dynamically running in the Android system environment, a system service list of the Android system is constructed.

[0058] The system services extracted in the above steps (1) and (2) are combined to obtain the system service list of the Android system, which is recorded as List(Service). List(Service) = List(Service-Static)∪List(Service-Dynamic).

[0059] Step (4): Extract the system API from the client and server of each system service in the system service list to obtain the API list of the Android system.

[0060] For each system service in List(Service), extract the system API from its client Manager and server Service at the same time, and record all the extracted APIs as List(API) (i.e., API list).

[0061] For each system service in the system service list, it includes two parts: the client and the server. The server code is the implementation code of the service function, and the client code is the IPC encapsulation of the server code. Usually, the API given in the official development document is the client API, and the server API is usually not exposed to application developers. Taking into account the dynamic characteristics of the Java language, the hidden API of the server may be used. Therefore, the inventor lists the APIs from both the client and server aspects of the system service. This embodiment takes into account both the client API and the hidden API of the server. The listed attack surface coverage is high, which provides a good basis for the subsequent detection of the environment perception API.

[0062] In a specific implementation, the client API is extracted based on the software development kit or development documentation of the system service, the server API is extracted based on the interface definition file or implementation code of the system service, and an API list is constructed based on the client API and server API of each system service.

[0063] For client APIs, you can view them through the software development kit (SDK) or development documentation; for server APIs, you can view them through the interface definition file (Android Interface Definition Language, AIDL file) or implementation code. The AIDL file can be understood as a tool. During the compilation process, the Android source code will automatically generate cross-process communication details for the service interface written in AIDL. Service developers generally define the interface through AIDL, and can obtain the server API from the AIDL file. Taking location services as an example, the source code paths of its client, server, and AIDL files are shown in Table 1 below. Based on the client code files, server code files, and AIDL interface definition files, you can list the APIs.

[0064] Table 1 Correspondence between files and code paths

[0065]

[0066] In one embodiment, this embodiment provides an implementation method for deleting APIs from an API list that are not used by malware for environment perception. Specifically, refer to the following steps 1) to 3) for execution:

[0067] Step 1): Construct a test sample.

[0068] The permissions granted to the above test sample include all permissions available to third-party applications in the Android system, including Normal and Dangerous permissions. Build a test sample and grant it all Normal and Dangerous permissions.

[0069] The sample construction process includes:

[0070] Get all permissions available to third-party apps in the Android system, namely Normal and Dangerous permissions. Then list all available permissions in the system using the pm list permissions command-line command. Then, based on the permission definition file (source path: / framework / base / core / res / AndroidManifest.xml), determine which permissions have Normal and Dangerous protection levels.

[0071] Declare Normal and Dangerous permissions in the sample Manifest file. In particular, for Dangerous permissions, add permission application code through the EasyPermission framework during the onCreate phase of the sample lifecycle.

[0072] Step 2): Based on the test sample, obtain the client API of each system service in the API list, and delete the API in the API list that the test sample cannot access due to insufficient permissions.

[0073] Have the test sample attempt to obtain the client Manager for each system service in the API list List(Service). During this process, record the system services that the test sample cannot access due to insufficient permissions as List(Service-Unaccessible) and the APIs in these services as List(API-Unaccessible). Delete the API List(API-Unaccessible) that cannot be accessed due to insufficient permissions.

[0074] Use Context.getSsystemService to retrieve the Manager of each system service in turn. The test process consists of two steps: ① Install the test sample in the test environment. ② Click the sample and grant all requested Dangerous permissions. Then, use the Logcat tool to view the system logs of the sample as it retrieves each system service. If a service is unavailable due to permissions issues, remove the APIs included in that service from the API list.

[0075] Step 3): Perform static analysis on the interface definition file of the server-side API of each system service in the API list, and delete the API in the API list that has the keyword oneway in the interface prototype, or delete the API that has an empty return value in the interface prototype and all input parameters do not have the out keyword.

[0076] For each service in the API list, statically analyze its AIDL (Android Interface Definition Language) file. In any AIDL file, if the interface prototype of an API meets one of the following conditions, record the API and record all APIs that meet the conditions as List (API-Unchangable).

[0077] ①The interface prototype contains the keyword oneway.

[0078] ②The return value in the interface prototype is empty and all input parameters do not have the out keyword.

[0079] Filter the extracted API list, i.e., List(API) = List(API) - List(API-Unaccessible) - List(API-Unchangable).

[0080] The specific implementation process of functional filtering is to use AIDL file keywords to determine the APIs in the service that cannot be used for environment awareness. Figure 2 The following is a schematic diagram of some AIDL file codes: Figure 2The following shows part of the AIDL code content of the Android system service ActivityManagerService (AMS). The API finishReceiver has the keyword oneway, which means that the data flow during the call of the API is one-way, that is, the data will only flow from the caller to the server. Therefore, malware cannot obtain any information through this API, and it is impossible to perform environmental perception. The API clearApplicationUserData has a Boolean return value, which may be different in different environments, so this API may be used for environmental perception. The return values of the API setDebugApp and getMemoryInfo are both void, but the outInfo input parameter of getMemoryInfo has the keyword out, indicating that the parameter data may be modified by the server, so this API may be used for environmental perception, and the input parameters of setDebugApp do not have the out keyword, indicating that these parameters are passed from the caller to the server, and the server will not modify these parameters, so this API cannot be used for environmental perception. In summary, Figure 2 In the example shown in , the APIs finishReceiver and setDebugApp are removed from the system API list.

[0081] In one embodiment, this embodiment provides an implementation method for calling each API in the API list after the deletion operation in a real device environment and a simulator environment, and recording the execution result of each API. The specific implementation can be referred to the following steps:

[0082] Step a: Find the function prototype for each API in the API list and construct the input parameters.

[0083] For each API in the API list List(API), find its function prototype and construct each input parameter. The construction process follows the following strategy:

[0084] ① When the input parameter type of the function prototype is a primitive type and has semantic meaning, the input parameter is constructed based on the parameter semantics. If the parameter type is a primitive type and has semantic meaning, it is constructed according to the parameter semantics. For example, the string parameter PackageName is constructed as com.example.test, and the integer parameter time is constructed as the current system time.

[0085] ② When the parameter type is a basic type but has no clear semantic meaning, the input parameter is randomly initialized according to the parameter type. If the parameter type of the input parameter of the function prototype is a basic type but has no clear semantic meaning, the input parameter is randomly initialized according to the parameter type.

[0086] ③ When the parameter type is an object, the constructor is called to create the object, the corresponding member variables are initialized, and the input parameters are constructed based on the parameter types of the member variables. If the parameter type is an object, the constructor is first called to create the object, and then the member variables are further initialized. If a member is a basic parameter type, strategies ① and ② are executed; if it is an object type, strategy ③ is recursively executed. To avoid infinite loops, the maximum recursion depth is 3.

[0087] Step b: calling each API in the API list after the deletion operation in the real device environment and the simulator environment respectively, and recording the execution result of each API.

[0088] The above execution results include the API identifier, API execution status, and the return value after API execution and the values of each input parameter. Call the API in the real device environment and the simulator environment respectively, and record the execution results in the form of a (APIName, ErrorMessage, Value) triple. APIName is used to identify the API, ErrorMessage is used to record the execution status of the API, and Value is used to record the return value after API execution and the values of each input parameter. When the API is executed successfully, ErrorMessage is empty, and when the API fails, the value describes the reason for the failure and the Value value in the triple is empty. Repeat steps a to b above three times.

[0089] See for example Figure 3 The API call process diagram shown in the figure takes API getConnectionInfo and startSoftAp as examples. Figure 3As shown, it includes the following steps: ① Find the API function prototype and determine the input parameter type. The above two APIs are APIs provided by the WIFI system service. Their function prototypes can be found in the file IWifiManager.aidl. Furthermore, it is not difficult to see from the API prototype that the input parameter of API getConnectionInfo is of string type, while the input parameter type of API startSoftAp is WifiConfiguration. ② Construct input parameters. The input parameter of API getConnectionInfo has actual semantic meaning, so it is constructed as the package name of the test sample. The input parameter of API startSoftAp is a complex object type, so it is necessary to first create the object through the constructor, and then further construct the member variables in the object. For the object type in the member variable, such as IpConfiguration, continue to call its constructor. Obviously, this recursive way of creating objects will lead to an infinite loop in some cases, such as when two objects are member variables of each other, so the present invention limits the maximum depth of recursion to 3. ③ Call the API in different environments and record the results. It should be noted that by connecting to the test sample through the debugger during the dynamic operation of the API, it is convenient to record the possible exceptions caused by the API operation and the values of each parameter in memory after the operation. Ultimately, the results are stored in the form of triples.

[0090] In one embodiment, this embodiment provides a specific implementation method for determining system services in an API list that have execution differences in different environments based on execution results, and obtaining an API with environment-awareness capabilities: the target APIs whose API execution status, return value after API execution, and input parameter values correspond to the same in the execution results obtained in the real device environment and the simulator environment in the API list are deleted, and an API with environment-awareness capabilities that has execution differences in different environments is obtained.

[0091] Compare the execution status (i.e., the recorded ErrorMessage) of the same API in different environments. If the status is the same, continue to compare the return value and each input parameter (i.e., Value) of the same API after execution in different environments. If the results are the same, remove the API from the API list. After execution is completed, the analysis of the execution results of all APIs is completed. At this time, the APIs remaining in the List(API) are the APIs with environment awareness capabilities, which is the final output.

[0092] See for example Figure 4The flowchart for determining the APIs that can be used for environmental perception shown mainly includes the following: ① Comparing the API execution status ErrorMessage, which is empty under normal conditions and is used to describe the cause of failure when the API execution fails. If the execution status of the API is inconsistent in different environments, for example, it is successfully executed on a real device but an exception occurs on a simulated device, or different exceptions occur on a real device and a simulated device, then the API is retained in the API list, otherwise the execution result Value is continued to be compared. ② Taking the execution result of the API getConnectionInfo as an example, its return value is an object of type WifiInfo. The present invention adopts a depth-first algorithm to traverse and compare the member variables in the WifiInfo object. During the traversal process, if a difference is found, the API is retained in the API list, otherwise it is deleted. When all API analyses are completed, the remaining APIs in the API list are the output APIs with environmental perception capabilities. These APIs will show differences in execution status or execution results in different environments and can be used for environmental perception.

[0093] The detection method for the environment-aware API in the above-mentioned Android system provided in this embodiment can detect the environment-aware APIs existing in the Android system on a large scale. These APIs can be used to enhance the concealment of the malware analysis environment, thereby strengthening its analysis capabilities, which is of great significance to protecting the security of users and systems; at the same time, the client API and the hidden API on the server are taken into account, and the listed attack surface coverage rate is high, which provides a good foundation for the subsequent detection of the environment-aware API; the attack surface is preliminarily filtered from the two levels of accessibility and functionality, and the detection efficiency of the method is effectively improved without affecting the accuracy of the detection results; the implementation of each step is not affected by the specific Android system version, is platform-independent, can be effectively applied to any version of the Android system, and has good compatibility.

[0094] Based on the above embodiment, this embodiment provides an example of a detection method for the environment perception API in the above Android system, which can automatically detect and analyze all APIs in the Android system to find out the potential APIs that can be used for environment perception behavior. Figure 5 The following is a flowchart of the method for detecting the Android environment perception API:

[0095] Step 1: Find all system services in the Android system, extract and record the methods (i.e., APIs) in each service, and build a system API list.

[0096] The specific process of step 1 includes:

[0097] Step 1.1: Use the JavaParser tool to statically parse the AOSP source code, and statically extract all system services in the Android system through the keywords registerService, addService, and publishBinderService, which are recorded as List(Service-Static).

[0098] In step 1.2, enter the Android device shell through the ADB debugging tool, and then use the service command line instruction to extract the system services running dynamically on the device, which is recorded as List(Service-Dynamic).

[0099] Step 1.3: Combine the system service lists extracted in steps 1.1 and 2.2, and record them as List(Service). List(Service) = List(Service-Static)∪List(Service-Dynamic).

[0100] Step 1.4: For each system service in List(Service), extract the system API from its client Manager and server Service at the same time, and record all the extracted APIs as List(API list).

[0101] Step 2: Filter the API list constructed in step 1 based on accessibility and functionality, and remove APIs that are unlikely to be used by malware for environmental awareness.

[0102] The specific process of step 2 is:

[0103] Step 2.1: Build a test sample and grant it all Normal and Dangerous permissions. Let the test sample try to obtain the client Manager of each system service in List(Service). During this process, record the system services that the test sample cannot access due to insufficient permissions as List(Service-Unaccessible) and the APIs of these services as List(API-Unaccessible).

[0104] Step 2.2: For each service, statically analyze its AIDL (Android Interface Definition Language) file. In any AIDL file, if the interface prototype of an API meets any of the following conditions, record the API and create a list of all APIs that meet the conditions (API-Unchangable).

[0105] (1) The interface prototype contains the keyword oneway.

[0106] (2) The return value in the interface prototype is empty and all input parameters do not have the out keyword.

[0107] In step 2.3, based on the analysis results of steps 2.1 and 2.2, the API list extracted in step 1.4 is filtered, that is, List(API) = List(API) - List(API-Unaccessible) - List(API-Unchangable). The API list obtained after filtering is a list of potential APIs that may have environmental perception capabilities.

[0108] Step 3: For each API in the API list filtered in step 2, call it in the real device environment and the simulator environment respectively, and record the execution status of each API, including calling parameters, return values and possible exceptions.

[0109] The specific process of step 3 is:

[0110] Step 3.1: For each API in step 2.3, List(API), find its function prototype and construct each input parameter. The construction process follows the following strategy:

[0111] If the parameter type is a primitive type and has semantic meaning, it is constructed according to the parameter's semantics. For example, the string parameter PackageName is constructed as com.example.test, and the integer parameter time is constructed as the current system time.

[0112] If the parameter type is a basic type but has no clear semantic meaning, the input parameter is randomized based on the parameter type.

[0113] If the parameter type is an object type, first call its constructor to create the object, and then further initialize its member variables. If a member is a basic parameter type, execute strategies ① and ②; if it is an object type, continue recursively executing strategy ③. To avoid infinite loops, the maximum recursive depth is 3.

[0114] In step 3.2, call the API on both the real device and the simulator, and record the execution results as a triplet (APIName, ErrorMessage, Value). The APIName identifies the API, the ErrorMessage records the execution status of the API, and the Value records the return value and input parameter values after the API is executed. Note that the ErrorMessage is empty when the API is executed successfully, but when the API fails, the ErrorMessage describes the failure reason and the Value in the triplet is empty.

[0115] Step 3.3: Repeat steps 3.1 to 3.2 three times.

[0116] Step 4: Analyze the execution results in step 3 to find out the APIs whose execution conditions are different in different environments. These APIs are potential APIs with environment-aware capabilities.

[0117] In step 4.1, compare the execution status of the same API in different environments (i.e., the ErrorMessage in step 3.2). If the status is the same, proceed to step 4.2.

[0118] In step 4.2, compare the return parameters and input parameters (i.e., the Value in step 3.2) after executing the same API in different environments. If the results are the same, proceed to step 4.3.

[0119] In step 4.3, remove the API from the API list in step 2.3.

[0120] When step 4 is completed, the analysis of the execution results of all APIs is completed. At this time, the remaining APIs in List(API) are APIs with environmental perception capabilities, which are the final output results.

[0121] The purpose of step 1 above is to list the attack surface. Attack is the behavior of malware to perceive the environment through API, and the attack surface is the API in the system. The wider the attack surface is, the greater the possibility of finding attack points from the attack surface in the subsequent steps. In order to list all APIs in the system as much as possible, the present invention specifically adopts the following two methods: ① Combining static scanning of AOSP source code and Shell dynamic acquisition to list system services in the system. ② See Figure 6The diagram of the interaction model between Android applications and system services is shown. The system service runs in the system_server process and is protected by the sandbox mechanism. The application process needs to access the system service through IPC. In order to facilitate application access to services, each system service usually corresponds to a Manager, which is a cross-process call encapsulation of service functions. The application can call remote service functions through the Manager in its own process. Usually, the API used by the application is the function encapsulated in the Manager, that is, the client API. As for the API of the remote server, it is usually not exposed to the application. However, considering that the application may access the hidden API through reflection call, the present invention extracts not only the client API but also the server API for each listed system service.

[0122] The purpose of step 2 above is to perform preliminary filtering of the attack surface to improve the execution efficiency of subsequent steps 3 and 4. This embodiment employs the following two methods: ① The malware under consideration is a third-party application. From an accessibility perspective, due to restrictions on Android system permissions and SELinux rules, the APIs that third-party applications can access are limited. To filter out APIs that the malware cannot access, the present invention constructs a test sample and grants it all the permissions that a third-party application could obtain. It then dynamically detects inaccessible services, ultimately filtering out the APIs contained in these services from the attack surface. ② Detects APIs with context-aware capabilities. The fundamental characteristic of these APIs is that they exhibit different results in different environments. AIDL is an interface definition language. In AIDL, the keyword oneway modifies the interface, indicating that data can only be transmitted from the client to the server. Therefore, when malware calls such APIs, it cannot receive any messages from the server. When AIDL describes parameters, the keyword out indicates that the parameter may be modified by the server. Therefore, if an API has no return value and none of its input parameters contain the out keyword, the caller cannot obtain any data through the API. These APIs that do not respond to any results naturally cannot be used for environmental perception. The attack surface can be further filtered through AIDL description files.

[0123] The purpose of steps 3 and 4 above is to detect context-aware APIs. From a fundamental perspective, context-aware APIs should behave differently in different environments. Step 3 involves calling each API in different environments and recording the execution results. In step 4, the execution results are analyzed to ultimately determine whether an API is context-aware.

[0124] The beneficial effects of this embodiment are:

[0125] 1) This paper proposes a method for detecting Android context-awareness APIs, which can be used to detect context-awareness APIs in the Android system on a large scale. These APIs can be used to enhance the stealthiness of malware analysis environments, thereby strengthening their analytical capabilities. This invention is of great significance for protecting user and system security.

[0126] 2) When enumerating attack surfaces, the present invention takes into account both client APIs and hidden APIs on the server side. The listed attack surfaces have high coverage, providing a good foundation for the subsequent detection of environment-aware APIs.

[0127] 3) The present invention performs preliminary filtering on the attack surface from the two levels of accessibility and functionality, effectively improving the detection efficiency of the method without affecting the accuracy of the detection results.

[0128] 4) The implementation of each step in the solution of the present invention is not affected by a specific Android system version and is platform-independent. The solution is effectively applicable to any version of the Android system and has good compatibility.

[0129] Corresponding to the detection method of the environment perception API in the Android system provided by the above embodiment, the embodiment of the present invention provides a detection device of the environment perception API in the Android system, see Figure 7 The following is a schematic diagram of a detection device for an environment perception API in an Android system, which includes the following modules:

[0130] The enumeration module 71 is used to search for all system services in the Android system and build an API list of the Android system based on the system services; wherein the API list includes the client API and the server API of each system service;

[0131] A filtering module 72, configured to delete APIs from the API list that are not used by malware for environment perception;

[0132] The trigger module 73 is used to call each API in the API list after the deletion operation in the real device environment and the simulator environment respectively, and record the execution result of each API;

[0133] The analysis module 74 is configured to determine, based on the execution results, APIs that have execution differences in different environments, and obtain APIs with environment-awareness capabilities.

[0134] The detection device for the environment-aware API in the above-mentioned Android system provided by this embodiment, by constructing the API list of the Android system, fully considers the client API and the hidden API of the server, improves the coverage of the listed attack surface, and first deletes the system services in the API list that will not be used by malware for environment-awareness, and then detects the API with environment-awareness capabilities based on the API call execution results in the real device environment and the simulator environment. It can detect the environment-aware API in the Android system on a large scale, effectively improves the detection efficiency of the environment-aware API, and is of great significance to ensuring the security of the Android system.

[0135] In one embodiment, the above-mentioned enumeration module 71 is used to statically parse the Android system source code to determine the system services registered in the Android system; dynamically analyze the operating environment of the Android system to determine the system services dynamically running in the Android system environment; construct a system service list of the Android system based on the system services registered in the Android system and the system services dynamically running in the Android system environment; extract the system API of the client and server of each system service in the system service list to obtain the API list of the Android system.

[0136] In one embodiment, the above-mentioned enumeration module 71 is used to extract the client API based on the software development kit or development documentation of the system service, extract the server API based on the interface definition file or implementation code of the system service, and build an API list based on the client API and server API of each system service.

[0137] In one embodiment, the filtering module 72 is used to construct a test sample; wherein the granted permissions of the test sample include all permissions that can be used by third-party applications in the Android system; based on the test sample, the client API of each system service in the API list is obtained, and the API in the API list that the test sample cannot access due to insufficient permissions is deleted; the interface definition file of the server API of each system service in the API list is statically analyzed, and the API in the API list that meets the keyword oneway in the interface prototype is deleted, or the API in the interface prototype whose return value is empty and all input parameters do not have the out keyword is deleted.

[0138] In one embodiment, the trigger module 73 is used to search for the function prototype of each API in the API list and construct input parameters; call each API in the API list after the deletion operation in the real device environment and the simulator environment respectively, and record the execution result of each API; wherein the execution result includes the API identifier, the API execution status, the return value after the API execution, and the value of each input parameter.

[0139] In one embodiment, the above-mentioned input parameter construction method includes: when the parameter type of the input parameter of the function prototype is a basic type and has semantic meaning, the input parameter is constructed based on the parameter semantics; when the parameter type is a basic type but has no clear semantic meaning, the input parameter is randomly initialized according to the parameter type; when the parameter type is an object type, the construction method is called to create an object, the corresponding member variables are initialized, and the input parameters are constructed according to the parameter type of the member variables.

[0140] In one embodiment, the above-mentioned analysis module 74 is used to delete the target APIs whose API execution status, return value after API execution, and input parameter values correspond to the same in the execution results obtained in the real device environment and the simulator environment in the API list, and obtain an API with environment-awareness capabilities that has execution differences in different environments.

[0141] The detection device for the environment perception API in the above-mentioned Android system provided in this embodiment can detect the environment perception APIs existing in the Android system on a large scale. These APIs can be used to enhance the concealment of the malware analysis environment, thereby strengthening its analysis capabilities, which is of great significance to protecting the security of users and systems; at the same time, the client API and the hidden API on the server are taken into account, and the listed attack surface coverage rate is high, which provides a good foundation for the subsequent detection of environment perception APIs; the attack surface is preliminarily filtered from the two levels of accessibility and functionality, and the detection efficiency of the method is effectively improved without affecting the accuracy of the detection results; the implementation of each step is not affected by the specific Android system version, is platform-independent, can be effectively applied to any version of the Android system, and has good compatibility.

[0142] The device provided in this embodiment has the same implementation principle and technical effects as those of the aforementioned embodiments. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiment.

[0143] Corresponding to the methods and devices provided in the aforementioned embodiments, an embodiment of the present invention also provides a detection system for an environmental perception API in an Android system, the system comprising: a processor and a storage device; a computer program is stored on the storage device, and when the computer program is run by the processor, it executes the detection method for the environmental perception API in the Android system provided in the aforementioned embodiments.

[0144] An embodiment of the present invention provides a computer-readable medium, wherein the computer-readable medium stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the method described in the above embodiment.

[0145] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process of the system described above can refer to the corresponding process in the aforementioned embodiment and will not be repeated here.

[0146] The computer program product of the detection method, device and system of the environmental perception API in the Android system provided by the embodiment of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the method described in the previous method embodiment. The specific implementation can be referred to the method embodiment and will not be repeated here.

[0147] In addition, in the description of the embodiments of the present invention, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood in a broad sense. For example, they may refer to fixed connections, detachable connections, or integral connections; they may refer to mechanical connections or electrical connections; they may refer to direct connections or indirect connections through an intermediate medium; and they may refer to internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0148] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0149] In the description of the present invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely to facilitate and simplify the description of the present invention. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation, and therefore should not be construed as limitations on the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0150] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A method for detecting an environment perception API in an Android system, characterized in that: include: Searching for all system services in the Android system, and constructing an API list of the Android system based on the system services; wherein the API list includes a client API and a server API for each system service; Deleting the APIs from the API list that will not be used by malware for environment perception; Calling each API in the API list after the deletion operation in a real device environment and a simulator environment respectively, and recording the execution result of each API; Determine, based on the execution results, an API having execution differences in different environments, and obtain an API with environment-awareness capability; The step of deleting the APIs in the API list that will not be used by malware for environmental perception includes: constructing a test sample; wherein the granted permissions of the test sample include all permissions that can be used by third-party applications in the Android system; obtaining the client API of each system service in the API list based on the test sample, and deleting the APIs in the API list that the test sample cannot access due to insufficient permissions; performing static analysis on the interface definition file of the server API of each system service in the API list, and deleting the APIs in the API list that meet the requirements of the keyword oneway in the interface prototype, or deleting the APIs in the interface prototype that have an empty return value and all input parameters do not have the keyword out; The step of determining the API having execution differences in different environments based on the execution results and obtaining the API with environment perception capability includes: The target APIs whose API execution status, return value after API execution and input parameter values correspond to the same in the execution results obtained in the real device environment and the simulator environment are deleted to obtain an API with environment-awareness capabilities that has execution differences in different environments.

2. The method according to claim 1, characterized in that The step of searching for all system services in the Android system and constructing an API list of the Android system based on the system services includes: Performing static analysis on the Android system source code to determine the system services registered in the Android system; Dynamically analyzing the operating environment of the Android system to determine the system services that are dynamically running in the Android system environment; Building a system service list of the Android system based on the system services registered in the Android system and the system services dynamically running in the Android system environment; Extract the system API from the client and server of each system service in the system service list to obtain the API list of the Android system.

3. The method according to claim 2, characterized in that The step of extracting the system API from the client and the server of each system service in the system service list to obtain the API list of the Android system includes: The client API is extracted based on the software development kit or development document of the system service, the server API is extracted based on the interface definition file or implementation code of the system service, and the API list is constructed based on the client API and server API of each system service.

4. The method according to claim 1, wherein The step of calling each API in the API list after the deletion operation in the real device environment and the simulator environment respectively, and recording the execution result of each API, includes: Find the function prototype for each API in the API list and construct input parameters; Each API in the API list after the deletion operation is called in the real device environment and the simulator environment respectively, and the execution result of each API is recorded; wherein, the execution result includes the API identifier, API execution status, and the return value after API execution and each input parameter value.

5. The method according to claim 4, characterized in that The input parameters are constructed in the following ways: When the parameter type of the input parameter of the function prototype is a basic type and has semantic meaning, constructing the input parameter based on parameter semantics; When the parameter type is the basic type but has no clear semantic meaning, randomly initializing the input parameter according to the parameter type; When the parameter type is an object type, the construction method is called to create an object, the corresponding member variables are initialized, and the input parameters are constructed according to the parameter type of the member variables.

6. A detection device for an environment perception API in an Android system, characterized in that: include: An enumeration module is used to search for all system services in the Android system and construct an API list of the Android system based on the system services; wherein the API list includes the client API and the server API of each system service; A filtering module, configured to delete APIs from the API list that are not used by malware for environment perception; A trigger module is used to call each API in the API list after the deletion operation in a real device environment and a simulator environment respectively, and record the execution result of each API; An analysis module, configured to determine, based on the execution results, APIs that have execution differences in different environments, and obtain APIs with environment-aware capabilities; The filtering module is used to construct a test sample; wherein the granted permissions of the test sample include all permissions that can be used by third-party applications in the Android system; based on the test sample, the client API of each system service in the API list is obtained, and the APIs in the API list that the test sample cannot access due to insufficient permissions are deleted; the interface definition file of the server API of each system service in the API list is statically analyzed, and the APIs in the API list that meet the requirements of the oneway keyword in the interface prototype are deleted, or the APIs whose return value in the interface prototype is empty and all input parameters do not have the out keyword are deleted; The analysis module is used to delete the target APIs in the API list that have the same API execution status, return value after API execution, and input parameter values in the execution results obtained in the real device environment and the simulator environment, and obtain APIs with environment-awareness capabilities that have execution differences in different environments.

7. A detection system for an environment perception API in an Android system, characterized in that: include: processors and storage devices; The storage device stores a computer program, which, when executed by the processor, executes the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are performed.

Images