An Android application trusted environment detection method, device, equipment and storage medium

Abstract

The application provides an Android application trusted environment detection method, device and equipment and a storage medium, and belongs to the technical field of computer security, which comprises the following steps: obtaining environment information of an Android application; the environment information comprises device fingerprint information, emulator information or system integrity information; the device fingerprint information comprises an Android ID, hard disk information or a MAC address; performing device fingerprint detection, emulator detection and system integrity detection according to a preset method; and if the device fingerprint detection, emulator detection and system integrity detection all satisfy preset conditions, determining that the running environment of the Android application is trusted. The application collects the characteristics of a mobile phone in multiple ways, and combines multi-dimensional detection technology in multiple levels to detect the trusted environment of the Android application, thereby greatly improving the accuracy of the trusted environment identification of the Android application, and effectively resisting attacks such as emulators, disguising tampering and simulated clicks.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, and in particular to a method, apparatus, device, and storage medium for detecting a trusted environment for Android applications. Background Technology

[0002] Current popular detection technologies mainly rely on API functions provided by the system to obtain hardware information features of the mobile phone for judgment, including manufacturer, brand, model, CPU, memory, flash memory, sensors, screen resolution, Bluetooth, IMEI, MAC address, and mobile phone number. While this hardware information can indeed be used for trusted environment detection, the weakness of the solution is that some practitioners can easily disguise and tamper with it, making it easy to bypass detection and carry out cybercrime. Summary of the Invention

[0003] This invention provides a method, apparatus, device, and storage medium for detecting the trusted environment of Android applications. It collects mobile phone features in multiple ways and performs Android application trusted environment detection from multiple dimensions and multiple levels of detection technology, which greatly improves the accuracy of Android application trusted environment identification and effectively combats attacks such as emulators, spoofing and tampering, and simulated clicks.

[0004] In a first aspect, embodiments of the present invention provide an Android application trusted environment detection method, the Android application trusted environment detection method comprising:

[0005] Obtain information about the Android application's runtime environment;

[0006] The environmental information includes: device fingerprint information, emulator information or system integrity information. Device fingerprint information includes: Android ID, hard drive information or MAC address.

[0007] Device fingerprint detection, simulator detection, and system integrity detection are performed according to preset methods;

[0008] If the device fingerprint detection, emulator detection, and system integrity detection all meet the preset conditions, then the Android application's operating environment is determined to be trustworthy.

[0009] Optionally, acquiring device fingerprint information and performing device fingerprint detection according to a preset method includes:

[0010] Obtain the first Android ID via system API;

[0011] The second Android ID is obtained by retrieving the cache in the HashMap using Java reflection.

[0012] Indirectly obtain the third Android ID through ContentResolver;

[0013] The fourth Android ID can be indirectly obtained by querying using the query command;

[0014] Based on the reliability of the Android ID acquisition method, the weights of the first Android ID, second Android ID, third Android ID, and fourth Android ID are set as a1, a2, a3, and a4, respectively.

[0015] The first comparison result A1 is obtained by comparing the first Android ID and the second Android ID; the second comparison result A2 is obtained by comparing the second Android ID and the third Android ID; and the third comparison result A3 is obtained by comparing the third Android ID and the fourth Android ID.

[0016] If the two Android IDs being compared are the same, the comparison result is 1; if the two Android IDs being compared are different, the comparison result is 0.

[0017] The comprehensive comparison result A is calculated using the following formula:

[0018] A = (a1+a2)×A1+(a2+a3)×A2+(a3+a4)×A3; If the overall comparison result A is greater than the threshold, then the Android ID is determined to meet the preset conditions.

[0019] Optionally, acquiring device fingerprint information and performing device fingerprint detection according to a preset method further includes:

[0020] Obtain the first hard drive information via system API;

[0021] Obtain information about the second hard drive by executing Linux commands;

[0022] Use the lowest-level SVC instructions to write assembly code to obtain information about the third hard drive;

[0023] Based on the reliability of the hard drive information acquisition method, the weights of the first hard drive information, the second hard drive information, and the third hard drive information are set as b1, b2, and b3 respectively.

[0024] The first comparison result B1 is obtained by comparing the information of the first hard drive and the information of the second hard drive, and the second comparison result B2 is obtained by comparing the information of the second hard drive and the information of the third hard drive.

[0025] If the information of the two hard drives being compared is the same, the comparison result value is 1; if the information of the two hard drives being compared is different, the comparison result value is 0.

[0026] Calculate the comprehensive comparison result B according to the following formula:

[0027] B=(b1+b2)×B1+(b2+b3)×B2;

[0028] If the overall comparison result B is greater than the threshold, then the hard disk information is determined to meet the preset conditions.

[0029] Optionally, acquiring device fingerprint information and performing device fingerprint detection according to a preset method further includes:

[0030] Obtain the first MAC address via the system API;

[0031] The second MAC address can be obtained by executing the cat command or by directly reading a file containing network card information.

[0032] Obtain the third MAC address through the lowest-level kernel communication method, NETLINK;

[0033] Based on the reliability of the MAC address acquisition method, the weights of the first MAC address, the second MAC address, and the third MAC address are set as c1, c2, and c3 respectively.

[0034] The first MAC address and the second MAC address are compared to obtain the first comparison result C1, and the second MAC address and the third MAC address are compared to obtain the second comparison result C2.

[0035] If the two MAC addresses being compared are the same, the comparison result is 1; if the two MAC addresses being compared are different, the comparison result is 0.

[0036] The comprehensive comparison result C is calculated using the following formula:

[0037] C=(c1+c2)×C1+(c2+c3)×C2;

[0038] If the overall comparison result C is greater than the threshold, then the MAC address is determined to meet the preset condition.

[0039] Optionally, emulator information is obtained and emulator detection is performed according to a preset method, including:

[0040] The CPU architecture type is obtained through the system API. Whether it is an emulator is determined based on whether the CPU architecture type is ARM. The first detection result D1 is obtained based on the judgment result.

[0041] The presence of feature files that can mark simulators is detected by inline SVC to determine whether it is a simulator, and the second detection result D2 is obtained based on the judgment result.

[0042] Whether it is an emulator is determined by comparing the peripheral features with the preset features of the emulator. The third detection result D3 is obtained based on the judgment result.

[0043] The system determines whether it is an emulator by comparing the underlying cache design with the emulator's preset design pattern. The fourth detection result, D4, is obtained based on the judgment result.

[0044] If it is an emulator, the detection result value is 1; if it is not an emulator, the detection result value is 0.

[0045] Based on the reliability of the judgment method, the weights of the first detection result, the second detection result, the third detection result, and the fourth detection result are set as d1, d2, d3, and d4 respectively.

[0046] The comprehensive simulator detection result D is calculated according to the following formula:

[0047] D=d1×D1+d2×D2+d3×D3+d4×D4;

[0048] If the overall emulator detection result D is less than the threshold, then the Android application is determined to be running in a non-emulator environment.

[0049] Optionally, system integrity information is obtained and system integrity is checked according to a preset method, including:

[0050] The system integrity check is determined by obtaining signature information through the IPC protocol and verifying whether the signature has been tampered with. The first detection result E1 is obtained based on the judgment result.

[0051] The system integrity test is determined by checking whether Xposed, Magisk, or Frida modification software exists in the environment. The second test result E2 is obtained based on the judgment result.

[0052] If the system integrity check passes, the check result value is 0; if the system integrity check fails, the check result value is 1.

[0053] Based on the reliability of the judgment method, the weights of the first and second detection results are set as e1 and e2 respectively; the overall operating environment tampering detection result E is calculated according to the following formula:

[0054] E = e1 × E1 + e2 × E2;

[0055] If the overall runtime environment tampering detection result E is less than the threshold, it is determined that the Android application's runtime environment has not been tampered with.

[0056] Secondly, embodiments of the present invention provide an Android application trusted environment detection device, the Android application trusted environment detection device comprising:

[0057] The acquisition module is used to obtain environment information for the Android application.

[0058] The environmental information includes: device fingerprint information, emulator information or system integrity information. Device fingerprint information includes: Android ID, hard drive information or MAC address.

[0059] The detection module is used to perform device fingerprint detection, simulator detection, and system integrity detection according to preset methods;

[0060] The judgment module is used to determine that the Android application's running environment is trustworthy if the device fingerprint detection, emulator detection, and system integrity detection all meet preset conditions.

[0061] Thirdly, embodiments of the present invention provide an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method as described in any of the implementations of the first aspect.

[0062] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any of the implementations of the first aspect.

[0063] This invention provides a method, apparatus, device, and storage medium for detecting a trusted environment for Android applications. The method is as follows: acquiring the environment information of the Android application's operation; the environment information includes: device fingerprint information, emulator information, or system integrity information, wherein the device fingerprint information includes: Android ID, hard disk information, or MAC address; performing device fingerprint detection, emulator detection, and system integrity detection according to preset methods; if the device fingerprint detection, emulator detection, and system integrity detection all meet preset conditions, then the Android application's operating environment is determined to be trusted. This invention collects mobile phone features through multiple methods and combines multi-dimensional and multi-layered detection technologies to detect the trusted environment of Android applications, greatly improving the accuracy of Android application trusted environment identification and effectively combating attacks such as emulators, spoofing, and simulated clicks.

[0064] It should be understood that the description in the Summary of the Invention is not intended to limit the key or essential features of the embodiments of the present invention, nor is it intended to restrict the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0065] The above and other features, advantages, and aspects of the various embodiments of the present invention will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements.

[0066] Figure 1 This is a flowchart of an Android application trusted environment detection method according to an embodiment of the present invention;

[0067] Figure 2 This is a flowchart of another Android application trusted environment detection method according to an embodiment of the present invention;

[0068] Figure 3 This is a schematic diagram of the structure of an Android application trusted environment detection device according to an embodiment of the present invention;

[0069] Figure 4 This is a structural diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0070] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0071] It should be noted that the embodiments of the present invention are described only to more clearly illustrate the technical solutions of the embodiments of the present invention, and do not constitute a limitation on the technical solutions provided by the embodiments of the present invention.

[0072] Figure 1 This is a flowchart of a trusted environment detection method for Android applications according to an embodiment of the present invention. Figure 1 As shown, it includes:

[0073] S101. Obtain the environment information for running the Android application.

[0074] The environmental information includes: device fingerprint information, emulator information, or system integrity information. Device fingerprint information includes: Android ID, hard drive information, or MAC address.

[0075] S102. Perform device fingerprint detection, simulator detection, and system integrity detection according to preset methods.

[0076] Specifically, such as Figure 2 As shown, Android ID detection is as follows:

[0077] For example, the first Android ID can be obtained through the most basic system API methods, and the code for obtaining it can be as follows:

[0078] Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID).

[0079] For example, after obtaining the first Android ID through the most basic system API, the trusted system will save the Android ID in a HashMap to prevent multiple IPC initializations. Therefore, by using Java reflection, the cache in the HashMap can be retrieved a second time to obtain the second Android ID.

[0080] For example, a third-party Android ID can be indirectly obtained through ContentResolver, and the code for obtaining it can be shown below:

[0081] ContentResolver.call(Uri.parse("content: / / settings / secure"),"GET_secure","android_id").

[0082] For example, the fourth Android ID can be indirectly obtained by querying using the query command. The code for obtaining the ID is shown below:

[0083] Content query--uri content: / / settings / secure--where name=android_id.

[0084] Optionally, the weights of the first Android ID, second Android ID, third Android ID, and fourth Android ID are set to a1, a2, a3, and a4 respectively, based on the reliability of the Android ID acquisition method.

[0085] The weight is directly proportional to the reliability of the acquisition method; that is, the larger the weight, the higher the reliability of the acquisition method.

[0086] For example, the order of the weights can be: a1 <a2<a3<a4。

[0087] Optionally, the first Android ID and the second Android ID are compared to obtain a first comparison result A1, the second Android ID and the third Android ID are compared to obtain a second comparison result A2, and the third Android ID and the fourth Android ID are compared to obtain a third comparison result A3;

[0088] If the two Android IDs being compared are the same, the comparison result is 1; if the two Android IDs being compared are different, the comparison result is 0.

[0089] Furthermore, the comprehensive comparison result A can be calculated using the following formula:

[0090] A=(a1+a2)×A1+(a2+a3)×A2+(a3+a4)×A3;

[0091] If the overall comparison result A is greater than the threshold, then the Android ID is determined to meet the preset conditions.

[0092] Specifically, such as Figure 2 As shown, the hard drive information is detected as follows:

[0093] Optionally, hard drive information (file system type, block size, total data blocks, free blocks, free blocks available to non-privileged users, total number of file nodes, number of free file nodes, and maximum file name length) can be obtained from the device fingerprint in various ways.

[0094] For example, the first hard drive information can be obtained through the system API, as shown in the following code: Android.os.StatFs.getTotalInfos(" / storage / emulated / 0").

[0095] For example, information about the second hard drive can be obtained by executing Linux commands. The advantage of this method is that the results are not easily tampered with. The code for obtaining the information is as follows:

[0096] stat -f / storage / emulated / 0.

[0097] For example, assembly code can be written using the lowest-level SVC instructions to obtain information about a third hard drive. The advantage of this method is that it cannot be intercepted at the application layer. The code for obtaining the information is as follows:

[0098] SVC call sys_statfs_num.

[0099] Optionally, the weights of the first hard disk information, the second hard disk information, and the third hard disk information are set to b1, b2, and b3 respectively, based on the reliability of the hard disk information acquisition method.

[0100] The weight is directly proportional to the reliability of the acquisition method; that is, the larger the weight, the higher the reliability of the acquisition method.

[0101] For example, the order of the weights can be: b1 <b2<b3。

[0102] Optionally, the information of the first hard drive and the information of the second hard drive are compared to obtain a first comparison result B1, and the information of the second hard drive and the information of the third hard drive are compared to obtain a second comparison result B2;

[0103] If the information of the two hard drives being compared is the same, the comparison result value is 1; if the information of the two hard drives being compared is different, the comparison result value is 0.

[0104] Furthermore, the comprehensive comparison result B can be calculated using the following formula:

[0105] B=(b1+b2)×B1+(b2+b3)×B2;

[0106] If the overall comparison result B is greater than the threshold, then the hard disk information is determined to meet the preset conditions.

[0107] Specifically, such as Figure 2 As shown, the MAC address is detected as follows:

[0108] For example, the first MAC address can be obtained through the system API, as shown in the following code: WifiManager.getConnectionInfo().getMacAddress().

[0109] For example, the second MAC address can be obtained by executing the cat command or by directly reading the network card information file. The file paths are as follows: / sys / class / net / wlan0 / address, / sys / devices / virtual / net / wlan0 / address.

[0110] For example, a third MAC address can be obtained through the lowest-level kernel communication NETLINK method. This method communicates directly with the kernel and processes the received data packets through inline SVC when receiving messages, which greatly increases the security of the data packets and prevents them from being intercepted and replaced. The code to obtain the address is as follows: socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE).

[0111] Optionally, the weights of the first MAC address, the second MAC address, and the third MAC address are set to c1, c2, and c3 respectively, based on the reliability of the MAC address acquisition method.

[0112] The weight is directly proportional to the reliability of the acquisition method; that is, the larger the weight, the higher the reliability of the acquisition method.

[0113] For example, the order of the weights can be: c1 <c2<c3。

[0114] Optionally, the first MAC address and the second MAC address are compared to obtain a first comparison result C1, and the second MAC address and the third MAC address are compared to obtain a second comparison result C2;

[0115] If the two MAC addresses being compared are the same, the comparison result is 1; if the two MAC addresses being compared are different, the comparison result is 0.

[0116] Furthermore, the comprehensive comparison result C can be calculated using the following formula:

[0117] C=(c1+c2)×C1+(c2+c3)×C2;

[0118] If the overall comparison result C is greater than the threshold, then the MAC address is determined to meet the preset condition.

[0119] Specifically, such as Figure 2 As shown, the simulator information is detected as follows:

[0120] For example, the CPU architecture type can be obtained through the system API. Whether it is an ARM architecture is determined to be an emulator. The first detection result D1 is obtained based on the judgment result. The code is as follows: System.getProperty("ro.product.cpu.abi");

[0121] Optionally, if the CPU architecture type is ARM, then it is not an emulator; if the CPU architecture type is not ARM, then it is an emulator.

[0122] For example, the presence of a feature file that can mark a simulator can be detected by inline SVC to determine whether it is a simulator. The second detection result D2 is obtained based on the judgment result. The feature files of the simulator are shown in Table 1 below:

[0123] Table 1

[0124] microvirt-prop NoxPlayer libdroid4x.so Seahorse Simulator nox-prop NoxPlayer ttVM-prop Daily Simulator libc_malloc_debug_qemu.so Google Simulator ldAppStore LDPlayer init.titan.rc Light Speed ​​Virtual Machine

[0125] Optionally, if a emulator's feature file exists, then it is an emulator; if a emulator's feature file does not exist, then it is not an emulator.

[0126] For example, whether it is an emulator can be determined by comparing the peripheral characteristics with the preset characteristics of the emulator. The third detection result D3 is obtained based on the judgment result. The differences between emulators and trusted devices in terms of peripherals are shown in Table 2 below:

[0127] Table 2

[0128]

[0129] Optionally, if the comparison is successful, it is an emulator; if the comparison is unsuccessful, it is not an emulator.

[0130] For example, it can be determined whether it is an emulator by comparing the underlying cache design with the emulator's preset design pattern to see if it is successful, and the fourth detection result D4 is obtained based on the judgment result;

[0131] Specifically, ARM's L1 cache is divided into I-Cache (instruction cache) and D-Cache (data cache), while the x86 architecture does not distinguish between instruction cache and data cache. During detection, a piece of executable code is dynamically mapped into memory. When this code is dynamically modified on the x86 architecture, the instruction cache is updated synchronously. However, on the ARM architecture, the contents of the D-Cache are modified, and the instructions in the I-Cache are not updated. The program then behaves differently on the ARM and x86 architectures. Based on the calculation results, it can be determined whether the program is running in a trusted environment. The specific code is as follows:

[0132]

[0133] Optionally, if the comparison is successful, it is an emulator; if the comparison is unsuccessful, it is not an emulator.

[0134] Optionally, if it is an emulator, the detection result value is 1; if it is not an emulator, the detection result value is 0.

[0135] Optionally, the weights of the first detection result, the second detection result, the third detection result, and the fourth detection result are set to d1, d2, d3, and d4 respectively, based on the reliability of the judgment method.

[0136] The weight is directly proportional to the reliability of the judgment method; that is, the larger the weight, the higher the reliability of the judgment method.

[0137] For example, the weights can be related as follows: d1 < d2 <d3<d4。

[0138] Furthermore, the integrated simulator detection result D can be calculated using the following formula:

[0139] D=d1×D1+d2×D2+d3×D3+d4×D4;

[0140] If the overall emulator detection result D is less than the threshold, then the Android application is determined to be running in a non-emulator environment.

[0141] Specifically, such as Figure 2 As shown, the system integrity information is detected as follows:

[0142] For example, the signature information can be obtained through the IPC protocol and the system integrity check can be determined by verifying whether the signature has been tampered with. The first detection result E1 can be obtained based on the judgment result.

[0143] Optionally, the acquisition process is as follows: call to get PackageInfo -> PackageManager receives the request, checks if a cache exists, if not -> server-side agent -> initiates Binder protocol -> server receives, processes and writes -> client receives.

[0144] Optionally, if the signature has not been tampered with, the system integrity check passes; if the signature has been tampered with, the system integrity check fails.

[0145] For example, the system integrity check can be determined by checking whether Xposed, Magisk, or Frida modification software exists in the environment, and a second check result E2 can be obtained based on the result.

[0146] Optionally, the specific inspection items are shown in Table 3 below:

[0147] Table 3

[0148]

[0149] Optionally, if Xposed, Magisk, or Frida modification software is present, the system integrity check will fail; if Xposed, Magisk, or Frida modification software is not present, the system integrity check will pass.

[0150] Optionally, if the system integrity check passes, the check result value is 0; if the system integrity check fails, the check result value is 1.

[0151] Optionally, the weights of the first detection result and the second detection result are set to e1 and e2 respectively, based on the reliability of the judgment method.

[0152] The weight is directly proportional to the reliability of the judgment method; that is, the larger the weight, the higher the reliability of the judgment method.

[0153] For example, the order of the weights can be: e1 <e2。

[0154] Furthermore, the overall operating environment tampering detection result E can be calculated using the following formula:

[0155] E = e1 × E1 + e2 × E2;

[0156] If the overall runtime environment tampering detection result E is less than the threshold, it is determined that the Android application's runtime environment has not been tampered with.

[0157] S103. If the device fingerprint detection, emulator detection and system integrity detection all meet the preset conditions, then the Android application's operating environment is determined to be trustworthy.

[0158] Specifically, such as Figure 2 As shown:

[0159] If the Android ID, hard drive information, or MAC address detection all meet the preset conditions, and the emulator detection confirms that the Android application's runtime environment is not an emulator, and the system integrity detection confirms that the Android application's runtime environment has not been tampered with, then the Android application's runtime environment is ultimately determined to be trustworthy.

[0160] This invention provides a method for detecting the trusted environment of Android applications. It collects mobile phone features through multiple methods and combines multi-dimensional and multi-layered detection technologies to detect the trusted environment of Android applications, greatly improving the accuracy of trusted environment identification and effectively combating attacks such as emulator attacks, spoofing, and simulated clicks. It can help internet companies identify and prevent internet fraud, such as malicious registration or false information; it can help e-commerce platforms identify and prevent e-commerce fraud, such as fake transactions or order-brushing; and it can help financial institutions identify and prevent financial fraud, such as telecommunications fraud or online loan fraud.

[0161] The following combination Figure 3 This invention provides a detailed description of the apparatus provided in the embodiments of the present invention, which can execute the above-described Android application trusted environment detection method.

[0162] For example, Figure 3 This is a schematic diagram of the structure of an Android application trusted environment detection device according to an embodiment of the present invention; as shown below. Figure 3 As shown, the detection device 30 includes:

[0163] Module 301 is used to obtain environment information for the Android application.

[0164] The environmental information includes: device fingerprint information, emulator information or system integrity information. Device fingerprint information includes: Android ID, hard drive information or MAC address.

[0165] The detection module 302 is used to perform device fingerprint detection, emulator detection and system integrity detection according to a preset method; the judgment module 303 is used to determine that the Android application's running environment is trustworthy if the device fingerprint detection, emulator detection and system integrity detection all meet the preset conditions.

[0166] Optionally, the acquisition module 301 and the detection module 302 are also used to obtain the first Android ID through the system API; obtain the second Android ID by obtaining the cache in the HashMap through the Java reflection mechanism; indirectly obtain the third Android ID through ContentResolver; and indirectly obtain the fourth Android ID by querying through the query command.

[0167] Based on the reliability of the Android ID acquisition method, the weights of the first Android ID, second Android ID, third Android ID, and fourth Android ID are set as a1, a2, a3, and a4, respectively.

[0168] The first comparison result A1 is obtained by comparing the first Android ID and the second Android ID; the second comparison result A2 is obtained by comparing the second Android ID and the third Android ID; and the third comparison result A3 is obtained by comparing the third Android ID and the fourth Android ID. If the two Android IDs being compared are the same, the comparison result value is 1; if the two Android IDs being compared are not the same, the comparison result value is 0.

[0169] The comprehensive comparison result A is calculated according to the following formula: A = (a1 + a2) × A1 + (a2 + a3) × A2 + (a3 + a4) × A3; if the comprehensive comparison result A is greater than the threshold, then the Android ID is determined to meet the preset conditions.

[0170] Optionally, the acquisition module 301 and the detection module 302 are also used to acquire the first hard disk information through the system API; acquire the second hard disk information by executing Linux commands; and acquire the third hard disk information by writing assembly code using the lowest-level SVC instructions.

[0171] Based on the reliability of the hard drive information acquisition method, the weights of the first hard drive information, the second hard drive information, and the third hard drive information are set as b1, b2, and b3 respectively.

[0172] The first comparison result B1 is obtained by comparing the information of the first hard drive and the information of the second hard drive, and the second comparison result B2 is obtained by comparing the information of the second hard drive and the information of the third hard drive; wherein, if the information of the two hard drives being compared is the same, the comparison result value is 1, and if the information of the two hard drives being compared is different, the comparison result value is 0.

[0173] The comprehensive comparison result B is calculated according to the following formula: B = (b1 + b2) × B1 + (b2 + b3) × B2; if the comprehensive comparison result B is greater than the threshold, then the hard disk information is determined to meet the preset conditions.

[0174] Optionally, the acquisition module 301 and the detection module 302 are also used to acquire the first MAC address via the system API; acquire the second MAC address by executing the cat command or by directly reading a file containing network card information; and acquire the third MAC address via the lowest-level kernel communication NETLINK method.

[0175] Based on the reliability of the MAC address acquisition method, the weights of the first MAC address, the second MAC address, and the third MAC address are set as c1, c2, and c3 respectively.

[0176] The first MAC address and the second MAC address are compared to obtain the first comparison result C1, and the second MAC address and the third MAC address are compared to obtain the second comparison result C2. If the two MAC addresses being compared are the same, the comparison result value is 1; if the two MAC addresses being compared are different, the comparison result value is 0. The comprehensive comparison result C is calculated according to the following formula: C = (c1 + c2) × C1 + (c2 + c3) × C2. If the comprehensive comparison result C is greater than the threshold, the MAC address is determined to meet the preset condition.

[0177] Optionally, the acquisition module 301 and the detection module 302 are further configured to: acquire the CPU architecture type via system API; determine whether it is an emulator based on whether the CPU architecture type is ARM architecture; obtain a first detection result D1 based on the judgment result; detect the existence of feature files that can mark the emulator using inline SVC to determine whether it is an emulator; obtain a second detection result D2 based on the judgment result; determine whether it is an emulator by comparing the peripheral features with the preset features of the emulator; obtain a third detection result D3 based on the judgment result; and determine whether it is an emulator by comparing the underlying cache design with the preset design mode of the emulator; obtain a fourth detection result D4 based on the judgment result. Wherein, if it is an emulator, the value of the detection result is 1; if it is not an emulator, the value of the detection result is 0.

[0178] Based on the reliability of the judgment method, the weights of the first detection result, the second detection result, the third detection result, and the fourth detection result are set as d1, d2, d3, and d4 respectively.

[0179] The overall emulator detection result D is calculated according to the following formula: D = d1×D1 + d2×D2 + d3×D3 + d4×D4; if the overall emulator detection result D is less than the threshold, then the Android application is determined to be running in a non-emulator environment.

[0180] Optionally, the acquisition module 301 and the detection module 302 are further configured to acquire signature information via the IPC protocol and determine whether the system integrity test has passed by verifying whether the signature has been tampered with, and obtain a first detection result E1 based on the judgment result; and determine whether the system integrity test has passed by checking whether Xposed, Magisk, or Frida modification software exists in the environment, and obtain a second detection result E2 based on the judgment result; wherein, if the system integrity test passes, the value of the detection result is 0, and if the system integrity test fails, the value of the detection result is 1;

[0181] Based on the reliability of the judgment method, the weights of the first detection result and the second detection result are set to e1 and e2 respectively.

[0182] The overall runtime environment tampering detection result E is calculated according to the following formula: E = e1 × E1 + e2 × E2; if the overall runtime environment tampering detection result E is less than the threshold, it is determined that the runtime environment of the Android application has not been tampered with.

[0183] This invention also provides a computer electronic device. Figure 4 A schematic diagram of the structure of an electronic device to which embodiments of the present invention can be applied is shown, such as... Figure 4 As shown, this computer electronic device includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 402 or programs loaded from storage section 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via bus 404. An input / output (I / O) interface 405 is also connected to bus 404.

[0184] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from them can be installed into storage section 408 as needed.

[0185] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0186] The modules or modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules or modules can also be set in a processor. For example, it can be described as: a processor including an acquisition module 301, a detection module 302, and a judgment module 303. In some cases, the names of these modules do not constitute a limitation on the module itself. For example, the acquisition module 301 can also be described as "acquisition module 301 for acquiring environment information of Android application operation".

[0187] In another aspect, the present invention also provides a computer-readable storage medium, which may be the computer-readable storage medium included in the Android application trusted environment detection device described in the above embodiments; or it may be a standalone computer-readable storage medium not assembled into an electronic device. The computer-readable storage medium stores one or more programs, which are used by one or more processors to execute the Android application trusted environment detection method described in the present invention.

[0188] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention is not limited to the specific combination of the above-described technical features, but also includes other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for detecting a trusted environment in an Android application, characterized in that, The trusted environment detection method for Android applications includes: obtaining the environment information in which the Android application runs; The environmental information includes: device fingerprint information, emulator information, and system integrity information. The device fingerprint information includes: AndroidID, hard disk information, or MAC address. Device fingerprint detection, emulator detection, and system integrity detection are performed according to preset methods. If the device fingerprint detection, emulator detection, and system integrity detection all meet their corresponding preset conditions, then the Android application's operating environment is determined to be trustworthy. Obtain device fingerprint information and perform device fingerprint detection according to a preset method, including: obtaining the first AndroidID through system API; obtaining the second AndroidID by retrieving the cache in a HashMap through Java reflection; indirectly obtaining the third AndroidID through ContentResolver; indirectly obtaining the fourth AndroidID by querying using a query command; setting the weights of the first AndroidID, second AndroidID, third AndroidID, and fourth AndroidID to a1, a2, a3, and a4 respectively based on the reliability of the AndroidID acquisition method; and setting the first AndroidID... The first comparison result A1 is obtained by comparing the second Android ID with the third Android ID. The second comparison result A2 is obtained by comparing the second Android ID with the third Android ID. The third comparison result A3 is obtained by comparing the third Android ID with the fourth Android ID. If the two Android IDs being compared are the same, the comparison result value is 1. If the two Android IDs being compared are different, the comparison result value is 0. The comprehensive comparison result A is calculated according to the following formula: A = (a1 + a2) × A1 + (a2 + a3) × A2 + (a3 + a4) × A3. If the comprehensive comparison result A is greater than the threshold, it is determined that the device fingerprint detection meets its corresponding preset conditions.

2. The Android application trusted environment detection method according to claim 1, characterized in that, The system acquires emulator information and performs emulator detection according to preset methods, including: obtaining the CPU architecture type via system API, determining whether it is an emulator based on whether the CPU architecture type is ARM, and obtaining a first detection result D1 based on the judgment result; detecting the existence of feature files that can mark the emulator using inline SVC to determine whether it is an emulator, and obtaining a second detection result D2 based on the judgment result; determining whether it is an emulator by successfully comparing peripheral features with the emulator's preset features, and obtaining a third detection result D3 based on the judgment result; and determining whether it is an emulator by successfully comparing the underlying cache design with the emulator's preset design pattern. For an emulator, a fourth detection result D4 is obtained based on the judgment result; where the value of the detection result is 1 if it is an emulator, and 0 if it is not an emulator; the weights of the first, second, third, and fourth detection results are set to d1, d2, d3, and d4 respectively according to the reliability of the judgment method; the comprehensive emulator detection result D is calculated according to the following formula: D = d1 × D1 + d2 × D2 + d3 × D3 + d4 × D4; if the comprehensive emulator detection result D is less than the threshold, it is determined that the Android application's running environment is a non-emulator, and the emulator detection meets its corresponding preset conditions.

3. The Android application trusted environment detection method according to claim 1, characterized in that, The system integrity information is obtained and a system integrity test is performed according to a preset method, including: obtaining signature information through the IPC protocol and determining whether the system integrity test passes by verifying whether the signature has been tampered with, and obtaining a first test result E1 based on the judgment result; determining whether the system integrity test passes by checking whether Xposed, Magisk, or Frida modification software exists in the environment, and obtaining a second test result E2 based on the judgment result; wherein, if the system integrity test passes, the value of the test result is 0, and if the system integrity test fails, the value of the test result is 1; the weights of the first test result and the second test result are set to e1 and e2 respectively according to the reliability of the judgment method; the comprehensive runtime environment tampering detection result E is calculated according to the following formula: E = e1 × E1 + e2 × E2; if the comprehensive runtime environment tampering detection result E is less than the threshold, it is determined that the runtime environment of the Android application has not been tampered with, and the system integrity test meets its corresponding preset conditions.

4. An Android application trusted environment detection device, characterized in that, The Android application trusted environment detection device includes: an acquisition module, used to acquire environmental information of the Android application running; The environmental information includes: device fingerprint information, emulator information, and system integrity information. The device fingerprint information includes: AndroidID, hard drive information, or MAC address. A detection module is used to perform device fingerprint detection, emulator detection, and system integrity detection according to a preset method. A judgment module is used to determine that the Android application's operating environment is trustworthy if the device fingerprint detection, emulator detection, and system integrity detection all meet their corresponding preset conditions. Obtaining device fingerprint information and performing device fingerprint detection according to a preset method includes: obtaining a first AndroidID through a system API; obtaining a second AndroidID by obtaining the cache in a HashMap through Java reflection; indirectly obtaining a third AndroidID through ContentResolver; indirectly obtaining a fourth AndroidID by querying using a query command; and determining the reliability of the AndroidID acquisition method based on the reliability of the first AndroidID. The weights of AndroidID, second AndroidID, third AndroidID, and fourth AndroidID are set as a1, a2, a3, and a4, respectively. A first comparison result A1 is obtained by comparing the first AndroidID and the second AndroidID; a second comparison result A2 is obtained by comparing the second AndroidID and the third AndroidID; and a third comparison result A3 is obtained by comparing the third AndroidID and the fourth AndroidID. If the two compared AndroidIDs are the same, the comparison result value is 1; if the two compared AndroidIDs are different, the comparison result value is 0. The comprehensive comparison result A is calculated according to the following formula: A = (a1 + a2) × A1 + (a2 + a3) × A2 + (a3 + a4) × A3. If the comprehensive comparison result A is greater than a threshold, it is determined that the device fingerprint detection meets its corresponding preset condition.

5. An electronic device, characterized in that, The method includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 3.

Images