Application file verification method and device, electronic equipment and storage medium

Abstract

The invention relates to an application file verification method and device, electronic equipment and a storage medium. The application file verification method comprises the following steps: acquiring a global configuration file contained in an application file, and acquiring a source code file contained in the application file; and obtaining application information of the application file contained in the global configuration file, and obtaining a byte array of the application file contained in the source code file. And verifying the application file according to the application information and the byte array. By means of the application file verification method and device, when the application file is verified, the necessary files of the application file are analyzed, all files contained in the application file do not need to be analyzed, the analysis speed of analyzing the application file information is increased, and then the verification speed of verifying the application file is increased.

Description

Technical Field

[0001] The present disclosure relates to the field of verification of terminal applications, and particularly to an application file verification method, apparatus, electronic device, and storage medium. Background Art

[0002] To avoid malicious applications from affecting the normal operation of the terminal or threatening user privacy information, the terminal needs to scan relevant files of the application, identify malicious applications, and process the malicious applications.

[0003] In related technologies, when parsing an application file to identify an application, it is necessary to parse the information of the entire application file to implement the verification of the application. The reading speed is slow and the identification efficiency is low. Summary of the Invention

[0004] To overcome the problems existing in related technologies, the present disclosure provides an application file verification method, apparatus, electronic device, and storage medium.

[0005] According to a first aspect of an embodiment of the present disclosure, there is provided an application file verification method, including: obtaining a global configuration file included in the application file, and obtaining a source code file included in the application file; obtaining application information of the application file included in the global configuration file, and obtaining a byte array of the application file included in the source code file; verifying the application file according to the application information and the byte array.

[0006] In an implementation manner, the verifying the application file according to the application information and the byte array includes: performing a first verification on the application file according to the application information to obtain a first verification result, where the application information includes package name information, signature information, and installation source information of the application file; in response to the application file failing the first verification, performing a second verification on the application file according to the byte array to obtain a second verification result.

[0007] In an implementation manner, the global configuration file includes a MANIFEST manifest file and a META_INF manifest file.

[0008] In an implementation manner, the obtaining the application information of the application file included in the global configuration file includes: parsing the MANIFEST manifest file to obtain the package name information and installation source information of the application file, and parsing the META_INF manifest file to obtain the signature information of the application file.

[0009] In one implementation, the first verification of the application file based on the application information includes: determining the installation source of the application, determining the developer of the application according to the signature information of the application file, and determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file; in response to determining the installation source of the application, the first verification result includes that the installation source of the application file is a trusted installation source and the installation source of the application file is an untrusted installation source; in response to determining the developer of the application according to the signature information of the application file, the first verification result includes that the developer of the application file is a trusted developer and the developer of the application file is an untrusted developer; in response to determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file, the first verification result includes that the package name information included in the preset whitelist matches the package name information of the application file and the package name information included in the preset whitelist does not match the package name information of the application file.

[0010] In one implementation, the application file passing the first verification meets each of the following conditions: the installation source of the application file is a trusted installation source, the developer of the application file is a trusted developer, and the package name information included in the preset whitelist matches the package name information of the application file; the application file failing the first verification meets any of the following conditions: the installation source of the application file is an untrusted installation source, the developer of the application file is an untrusted developer, and the package name information included in the preset whitelist does not match the package name information of the application file.

[0011] In one implementation, the second verification of the application file based on the byte array to obtain a second verification result includes: determining the matching relationship between the byte array included in the preset code feature library and the byte array of the application file, where the byte array included in the preset code feature library is a non-compliant byte array; in response to the byte array included in the preset code feature library not matching the byte array of the application file, confirming the application file as a trusted file; in response to the byte array included in the preset code feature library matching the byte array of the application file, confirming the application file as an untrusted file.

[0012] In one implementation, the method further includes: in response to the application file failing the first verification, uploading the package name information of the application file to the cloud, and obtaining a cloud verification result returned by the cloud. The cloud is used to determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file. The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the preset blacklist does not match the package name information of the application file. The first preset blacklist is applied to the cloud; in response to the cloud verification result indicating that the package name information included in the preset blacklist does not match the package name information of the application file, determining the matching relationship between the package name information included in the second preset blacklist and the package name information of the application file. The second preset blacklist is applied to the terminal; in response to the package name information included in the second preset blacklist matching the package name information of the application file, updating the second preset blacklist according to the first preset blacklist.

[0013] According to a second aspect of the embodiments of the present disclosure, there is provided an application file verification method, including: obtaining the package name information of the application file uploaded by the terminal, and performing cloud verification on the application file according to the package name information and a first preset blacklist to obtain a cloud verification result. The first preset blacklist includes the package name information of untrusted applications; and sending the cloud verification result to the terminal.

[0014] In one implementation, the performing cloud verification on the application file according to the package name information and the first preset blacklist includes: determining the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file; the cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the first preset blacklist does not match the package name information of the application file.

[0015] According to a third aspect of the embodiments of the present disclosure, there is provided an application file verification device, including: an obtaining unit, configured to obtain the global configuration file included in the application file, obtain the source code file included in the application file, obtain the application information of the application file included in the global configuration file, and obtain the byte array of the application file included in the source code file; and a processing unit, configured to verify the application file according to the application information and the byte array.

[0016] In one implementation, the processing unit verifies the application file according to the application information and the byte array in the following manner: perform a first verification on the application file according to the application information to obtain a first verification result, where the application information includes the package name information, signature information, and installation source information of the application file; in response to the application file failing the first verification, perform a second verification on the application file according to the byte array to obtain a second verification result.

[0017] In one implementation, the global configuration file includes a MANIFEST manifest file and a META_INF manifest file.

[0018] In one implementation, the obtaining unit obtains the application information of the application file included in the global configuration file in the following manner: parse the MANIFEST manifest file to obtain the package name information and installation source information of the application file, and parse the META_INF manifest file to obtain the signature information of the application file.

[0019] In one implementation, the processing unit performs a first verification on the application file according to the application information in the following manner: determine the installation source of the application, determine the developer of the application according to the signature information of the application file, and determine the matching relationship between the package name information included in the preset whitelist and the package name information of the application file; in response to determining the installation source of the application, the first verification result includes that the installation source of the application file is a trustworthy installation source and the installation source of the application file is an untrustworthy installation source; in response to determining the developer of the application according to the signature information of the application file, the first verification result includes that the developer of the application file is a trustworthy developer and the developer of the application file is an untrustworthy developer; in response to determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file, the first verification result includes that the package name information included in the preset whitelist matches the package name information of the application file and the package name information included in the preset whitelist does not match the package name information of the application file.

[0020] In one implementation, the application file that passes the first verification meets each of the following conditions: the installation source of the application file is a trustworthy installation source, the developer of the application file is a trustworthy developer, and the package name information included in the preset whitelist matches the package name information of the application file; the application file that fails the first verification meets any of the following conditions: the installation source of the application file is an untrustworthy installation source, the developer of the application file is an untrustworthy developer, and the package name information included in the preset whitelist does not match the package name information of the application file.

[0021] In one implementation, the processing unit performs a second verification on the application file according to the byte array in the following manner to obtain a second verification result: determining a matching relationship between the byte array included in the preset code feature library and the byte array of the application file, where the byte array included in the preset code feature library is a non-compliant byte array; in response to the byte array included in the preset code feature library not matching the byte array of the application file, confirming the application file as a trustworthy file; in response to the byte array included in the preset code feature library matching the byte array of the application file, confirming the application file as an untrustworthy file.

[0022] In one implementation, the processing unit is further configured to: in response to the application file failing the first verification, upload the package name information of the application file to the cloud and obtain a cloud verification result returned by the cloud. The cloud is used to determine a matching relationship between the package name information included in the first preset blacklist and the package name information of the application file. The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the preset blacklist does not match the package name information of the application file. The first preset blacklist is applied to the cloud; in response to the cloud verification result being that the package name information included in the preset blacklist does not match the package name information of the application file, determining a matching relationship between the package name information included in the second preset blacklist and the package name information of the application file. The second preset blacklist is applied to the terminal; in response to the package name information included in the second preset blacklist matching the package name information of the application file, updating the second preset blacklist according to the first preset blacklist.

[0023] According to a fourth aspect of the embodiments of the present disclosure, there is provided an application file verification device, including: a verification unit, configured to obtain the package name information of the application file uploaded by the terminal, and perform cloud verification on the application file according to the package name information and a first preset blacklist to obtain a cloud verification result. The first preset blacklist includes the package name information of untrustworthy applications; a sending unit, configured to send the cloud verification result to the terminal.

[0024] In one implementation, the verification unit performs cloud verification on the application file according to the package name information and the first preset blacklist in the following manner: determining a matching relationship between the package name information included in the first preset blacklist and the package name information of the application file; the cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the first preset blacklist does not match the package name information of the application file.

[0025] According to a fifth aspect of the embodiments of the present disclosure, there is provided an application electronic device, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the application file verification method described in the first aspect or any one of the implementation manners of the first aspect.

[0026] According to a sixth aspect of the embodiments of the present disclosure, there is provided an electronic device, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the application file verification method described in the second aspect or any one of the implementation manners of the second aspect.

[0027] According to a seventh aspect of the embodiments of the present disclosure, there is provided a storage medium storing instructions, which when executed by a processor, enable the processor to execute the application file verification method described in the first aspect or any one of the implementation manners of the first aspect.

[0028] According to an eighth aspect of the embodiments of the present disclosure, there is provided a storage medium storing instructions, which when executed by a processor, enable the processor to execute the application file verification method described in the second aspect or any one of the implementation manners of the second aspect.

[0029] The technical solutions provided by the embodiments of the present disclosure may include the following beneficial effects: obtaining a global configuration file and a source code file included in an application file, obtaining application information included in the global configuration file, and obtaining a byte array included in the source code file. Verifying the application file according to the application information and the byte array. Through the present disclosure, when verifying an application file, necessary files of the application file are parsed, rather than all files included in the application file, which improves the parsing speed of parsing application file information, and further speeds up the verification speed of verifying the application file.

[0030] It should be understood that the above general description and subsequent detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The accompanying drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure.

[0032] Figure 1 is a flowchart of a method for verifying an application file shown according to an exemplary embodiment.

[0033] Figure 2 is a flowchart of a method for verifying an application file shown according to an exemplary embodiment.

[0034] Figure 3 It is a flowchart of a method for obtaining application information shown according to an exemplary embodiment.

[0035] Figure 4 It is a flowchart of a method for performing a first verification on an application file shown according to an exemplary embodiment.

[0036] Figure 5 It is a flowchart of a method for performing a second verification on an application file according to string information shown according to an exemplary embodiment.

[0037] Figure 6 It is a flowchart of a method for verifying an application file shown according to an exemplary embodiment.

[0038] Figure 7 It is a flowchart of a method for verifying an application file shown according to an exemplary embodiment.

[0039] Figure 8 It is a flowchart of a method for performing cloud verification on an application file shown according to an exemplary embodiment.

[0040] Figure 9 It is a flowchart of a method for verifying an application file shown according to an exemplary embodiment of the present disclosure.

[0041] Figure 10 It is an architecture diagram of a method for verifying an application file shown according to an exemplary embodiment of the present disclosure.

[0042] Figure 11 It is a block diagram of a device for verifying an application file shown according to an exemplary embodiment.

[0043] Figure 12 It is a block diagram of a device for verifying an application file shown according to an exemplary embodiment.

[0044] Figure 13 It is a block diagram of a device for verifying an application file shown according to an exemplary embodiment. Detailed implementation manners

[0045] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present disclosure.

[0046] The application file method provided by the embodiments of the present disclosure is applied to a scenario of verifying an application based on an application file.

[0047] Terminal devices such as mobile phones and tablet computers have become important tools for people in aspects such as life, work, and entertainment. Users often download and install applications from multiple channels based on their own needs. However, users may download some malicious applications, which will affect the normal operation of the terminal and endanger the privacy and security of users. To avoid malicious applications from affecting the normal operation of the terminal or threatening the user's privacy information, the terminal needs to scan the installation package file of the application before installing the application and decide whether to install the application based on the scan result. And for the installed applications, it is necessary to scan the relevant files of the application to identify whether the corresponding application is a malicious application.

[0048] In the related art, when identifying the installation package (Android Package, apk) file of an application before installing the application, it is generally necessary to parse the overall information of the installation package file and identify the installation package file according to the parsed overall information. The time taken to parse the file is long and the identification efficiency is low. Similarly, for the identification of installed applications, it is also necessary to parse all the relevant files of the application, and there are also problems of long file parsing time and low identification efficiency.

[0049] The related art also has a technology of identifying the application installation package file by calling the existing system Application Programming Interface (API). In the process of identifying the installation package file, the MD5 file is obtained, the MD5 file is calculated by calling the API, the signature information of the installation package is obtained, and then the installation package is verified according to the signature information of the installation package. Since the application programming interface of the system needs to be called in the identification process of the above related technology, the identification speed of the installation package file is slow.

[0050] In view of this, the present disclosure provides an application file verification method. When verifying an installed application or an application installation package file, the global configuration file and the source code file included in the application file are obtained. The application information included in the global configuration file is obtained, and the byte array included in the source code file is obtained. The application file is verified according to the application information of the application file and the byte array of the application file. Through the present disclosure, when verifying the application file, the necessary files of the application file are parsed, rather than parsing all the files included in the application file, which improves the parsing speed of parsing the application file information, and thus speeds up the verification speed of verifying the application file.

[0051] Figure 1 It is a flowchart of an application file verification method shown according to an exemplary embodiment. As Figure 1 shown, the method includes steps S101 to S103.

[0052] In step S101, the global configuration file included in the application file is obtained, and the source code file included in the application file is obtained.

[0053] In step S102, obtain the application information of the application files included in the global configuration file, and obtain the byte array of the application files included in the source code file.

[0054] In step S103, verify the application files according to the application information and the byte array.

[0055] In the disclosed embodiments of the present disclosure, the application file is the installation package file corresponding before the installation of the application file or the source file of the installed application. When obtaining the application file, obtain the installation path of the application or the package name information of the application, and use the installation path of the application or the package name information of the application as the index information for obtaining the application file to obtain the application file.

[0056] In the embodiments of the present disclosure, verify the application files respectively based on the basic information (application information) and code information (byte array) of the application files. The global configuration file included in the application file in the present disclosure is the manifest file containing the application information of the application file (including the MANIFEST manifest file and the META_INF manifest file). After obtaining the global configuration file, the application information of the application file can be obtained by parsing the global configuration file. The present disclosure obtains the application information of the application file by parsing the manifest file of the application file, without having to call the existing system application programming interface, which improves the speed of obtaining the application information and improves the speed of verifying the application file. In the embodiments of the present disclosure, while verifying the application file based on the application information, the application file is also verified based on the code information (byte array) of the application file to ensure the accuracy of the verification result.

[0057] Through the present disclosure, verify the application file respectively based on the application information and the byte array of the application file, and use a special algorithm to obtain the application information of the application file from the manifest file of the application file, without having to call the existing system application programming interface. It improves the parsing speed of parsing the application file information, and then speeds up the verification speed of verifying the application file, so as to quickly determine whether the application corresponding to the application file is a virus / malicious application.

[0058] In the embodiments of the present disclosure, the above global configuration file contains the application information of the application file, the source code file contains the code information (byte array) of the application file, and the application information and the code information reflect the characteristics of different dimensions of the application file. Therefore, the verification of the application file based on the application information and the verification of the application file based on the code information are verifications of different dimensions. When the present disclosure verifies the application file based on the global configuration file and the source code file, it uses a progressive method for verification, that is, the verification of the application file based on the application information and the verification of the application file based on the code information are executed successively. The following is an example of the present disclosure to further illustrate the method for verifying the application file.

[0059] Figure 2 is a flowchart of a method for verifying an application file according to an exemplary embodiment. As Figure 2 shown, the method includes step S201 to step S202.

[0060] In step S201, the application file is first verified according to the application information to obtain a first verification result.

[0061] Among them, the application information includes the package name information, signature information, and installation source information of the application file, and the signature information corresponds to the developer of the application file.

[0062] In step S202, in response to the application file failing the first verification, the application file is secondarily verified according to the byte array to obtain a second verification result.

[0063] In the embodiments of the present disclosure, the package name information, signature information, and installation source information of the application file reflect various aspects of the application file. The package name information directly reflects the file name of the application, the signature information reflects the developer of the application, and the installation source information reflects the installation source of the application file. When the application file is first verified based on the package name information, signature information, and installation source information and the application file passes the first verification, it indicates that the application file is a trustworthy file.

[0064] In the embodiments of the present disclosure, the source code file is a file in the application file that contains the byte array of the application file. By parsing the source code file in the application file that contains the byte array of the application file to obtain the byte array of the application file, the application file can be further verified from the code dimension based on the character information of the application file, and it can be determined whether the application corresponding to the application file is a virus / malicious application.

[0065] In one implementation manner of the embodiments of the present disclosure, the above source code file is the Dex file in the application file. The content of the string block in the Dex file stores all the strings in the application code, including identifiers (class names, method names, parameter names, system API calls, etc.), static strings, etc. By parsing the Dex file in the application file, the byte array for verifying the application file at the code layer can be obtained.

[0066] In the embodiments of the present disclosure, when the application file fails the first verification, by parsing the source code file to obtain the byte array of the application file, the application file is further verified at the code level. The present disclosure verifies the application file from multiple dimensions based on the package name information, signature information, installation source information, and byte array of the application file to ensure the accuracy of the verification result.

[0067] It can be understood that in order to avoid scanning at the code level and prevent being identified as a malicious application, a malicious application will establish a file tree with a high degree of complexity, that is, set a large number of useless folders at different storage levels, and store the application code in hidden folders. When scanning malicious application files on the terminal, the scanning process will be interrupted due to too many folder levels and too many folders, so as to identify the malicious application. In view of this, when scanning application files at the code level, the present disclosure needs to avoid retrieving files folder by folder, but directly lock the storage path of the folder where the code file of the application file is located. By directly locking the folder where the code file of the application file is located, it is ensured that any application file can be verified at the code level, and the verification speed when verifying application files at the code level is guaranteed.

[0068] In an exemplary embodiment of the present disclosure, the storage path of the folder where the code file of the application file is located is directly locked through the zipfs module in the terminal Java Development Kit (JDK). It can be understood that since jdk7, the java class library has provided a standard API for establishing a file system on a Zip archive through the zipfs module, and this file system API greatly facilitates the related operations on zip files. However, the Android SDK is not a complete Java class library and does not include the zipfs module. In one example, the present disclosure provides a method for migrating the zipfs module to a terminal system (such as Android) so that the zipfs module can be used normally in the terminal system. The method includes the following steps: 1. Download a Java Development Kit with the zipfs module, such as OpenJdk11, OpenJdk17, or OpenJdk21. 2. Unzip the src.zip file in the Java Development Kit and find the source code of the jdk.zipfs module included in the src.zip file. 3. Import the source code of the jdk.zipfs module into a java jar module project, such as a Gradle build. 4. Configure the SPI of ZipFileSystem in the form of a resource file. 5. Set the target product bytecode version to java 8. 6. Continue to desugar some high-version source codes and reduce them to an equivalent low-version form. 7. Compile the source code of this module into its jar package. 8. Import the generated jar package after compilation. After importing the compiled jar package as a regular dependency into the Android project, it can be considered that the process of migrating the zipfs module to the terminal system is completed.

[0069] For the above exemplary embodiment, after the migration of the zipfs module is completed, a method of using zipfs is as follows:

[0070] 1. private val zipFile = Path("path / to / file") / / Define a private constant zipFile which represents the path to the zip file

[0071] 2. private val zfs = FileSystems.newFileSystem(zipFile, classLoader) / / Create a new file system instance using the zipFile path and the class loader, and assign it to the zfs variable

[0072] It should be noted that since the newly created file system is externally provided through the above SPI method, the classloader during file system creation needs to be specified as the application's classloader.

[0073] It can be understood that currently, various types of application files are emerging in a blowout manner, with diverse installation sources and diverse application installation packages. Therefore, when the application file fails the first verification, it cannot be characterized as a threatening application file, and further verification of the application that fails the first verification needs to be based on the source code information.

[0074] In the embodiments of the present disclosure, the application information of the above application file includes the package name information, signature information, and installation source information of the application file. The acquisition sources of the package name information and installation source information of the application file correspond to different manifest files from the acquisition source of the signature information. The following embodiments of the present disclosure further illustrate the global configuration file.

[0075] In one implementation manner of the embodiments of the present disclosure, the global configuration file includes a MANIFEST manifest file and a META_INF manifest file.

[0076] In the embodiments of the present disclosure, the global configuration file includes a MANIFEST.MF manifest file (i.e., the MANIFEST manifest file) and a META_INF manifest file. Among them, the MANIFEST manifest file contains application information such as the package name information and installation source information of the application, while the META_INF manifest file contains the signature information of the application file.

[0077] The following embodiments of the present disclosure further illustrate the method for obtaining application information from the global configuration file

[0078] Figure 3 It is a flowchart of a method for obtaining application information shown according to an exemplary embodiment. As Figure 3 shown, the method includes steps S301 to S302.

[0079] In step S301, obtain the global configuration file included in the application file.

[0080] In step S302, parse the MANIFEST manifest file to obtain the package name information and installation source information of the application file, and parse the META_INF manifest file to obtain the signature information of the application file.

[0081] In the embodiments of the present disclosure, a solution for parsing application file information by only reading the MANIFEST.MF manifest file and a fast digest calculation solution for the application file are adopted to achieve fast parsing of the MANIFEST manifest file and the META_INF manifest file, and fast reading of the application information of the application file. That is, the installation source information and package name information of the application file are obtained by parsing the MANIFEST manifest file, and the signature information of the application file is obtained by parsing the META_INF manifest file. The present disclosure parses the application information of the application file by only reading the necessary files, and does not call the existing system application programming interface when obtaining the signature information of the application, so as to improve the acquisition speed of the application signature information, the parsing file speed when verifying the application file, and the efficiency of verifying the application file.

[0082] It can be understood that all installation package files and application source code files must be signed. The application file in the present disclosure is also a jar file, which conforms to the jar package signature specification. The jar signature specification defines the MANIFEST.MF manifest file and the META_INF manifest file (global configuration file). All file entries protected by signatures and their digest information are listed inside this manifest file. That is, both the MANIFEST.MF manifest file and the META_INF manifest file are a Hash tree. Moreover, the hash values in the MANIFEST.MF manifest file and the META_INF manifest file have been calculated during the packaging of the installation package and are stored in the MANIFEST.MF manifest file and the META_INF manifest file. Based on the above characteristics of the MANIFEST.MF manifest file (global configuration file), the present disclosure calculates the MANIFEST.MF manifest file and the META_INF manifest file to replace the digest of the entire application file, that is, obtains application information such as the package name information, signature information, and installation source information of the application by parsing the global configuration file.

[0083] In the embodiments of the present disclosure, the application information of the application file includes package name information, signature information, and installation source information. When performing the first verification of the application file based on the global configuration file, it is necessary to perform verification on the application file separately based on the package name information, signature information, and installation source information. The following embodiments of the present disclosure illustrate the process of the first verification.

[0084] Figure 4It is a flowchart of a method for performing a first verification on an application file shown according to an exemplary embodiment. As Figure 4 shown, the method includes step S401 to step S402.

[0085] In step S401, parse the MANIFEST manifest file to obtain the package name information and installation source information of the application file, and parse the META_INF manifest file to obtain the signature information of the application file.

[0086] In step S402, determine the installation source of the application, determine the developer of the application according to the signature information of the application file, and determine the matching relationship between the package name information included in the preset whitelist and the package name information of the application file.

[0087] Among them, in response to determining the installation source of the application, the first verification result includes that the installation source of the application file is a trusted installation source and the installation source of the application file is an untrusted installation source; in response to determining the developer of the application according to the signature information of the application file, the first verification result includes that the developer of the application file is a trusted developer and the developer of the application file is an untrusted developer; in response to determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file, the first verification result includes that the package name information included in the preset whitelist matches the package name information of the application file, and the package name information included in the preset whitelist does not match the package name information of the application file.

[0088] In the embodiments of the present disclosure, the package name information directly reflects the file name of the application, the signature information reflects the developer of the application, and the installation source information reflects the installation source of the application file. When performing the first verification on the application file based on the application information, it is necessary to determine whether the package name information is in the preset whitelist, determine whether the installation source of the application is a trusted installation source through the signature information of the application file, and determine whether the developer of the application is a trusted installation source through the signature information of the application file.

[0089] The following embodiments of the present disclosure further illustrate the process of the first verification.

[0090] In an implementation manner of the embodiments of the present disclosure, the application file that passes the first verification satisfies each of the following conditions: the installation source of the application file is a trusted installation source, the developer of the application file is a trusted developer, and the package name information included in the preset whitelist matches the package name information of the application file; the application file that fails to pass the first verification satisfies any one of the following conditions: the installation source of the application file is an untrusted installation source, the developer of the application file is an untrusted developer, and the package name information included in the preset whitelist does not match the package name information of the application file.

[0091] In the embodiments of the present disclosure, when the installation source of the application file is a trusted installation source, the developer of the application file is a trusted developer, and the package name information included in the preset whitelist matches the package name information of the application file, it indicates that the application file is a trusted file. If the application file is an installation package file, the file can be further installed. If the application file is the original file of an installed application, it indicates that the installed application is a non-risk application, and no corresponding prompt is issued.

[0092] In the embodiments of the present disclosure, the installation source of the application file is an untrusted installation source and / or the developer of the application file is an untrusted developer and / or the package name information included in the preset whitelist does not match the package name information of the application file. It indicates that the application file is a risk file. If the application file is an installation package file, the user can be prompted whether to install the application file. If the application file is the original file of an installed application, it indicates that the installed application is a risk application, and the user can be prompted whether to uninstall the file.

[0093] In the embodiments of the present disclosure, when the application file fails the first verification, it indicates that the application file is a risk file and further verification is required. In the present disclosure, when the application file fails the first verification, the application file is further verified at the code level. The following embodiments of the present disclosure illustrate the process of the second verification.

[0094] It can be understood that the byte arrays of some features are only possessed by malicious applications. Based on this, the present disclosure determines whether the application file is a file corresponding to a malicious application by comparing the byte arrays in the application file with the malicious byte arrays. The following embodiments of the present disclosure further illustrate the method for performing the second verification of the application file according to the byte arrays.

[0095] Figure 5 is a flowchart of a method for performing a second verification of an application file according to byte arrays shown in an exemplary embodiment. As Figure 5 shown, the method includes step S501, step S502A, and step S502B.

[0096] In step S501, the matching relationship between the byte arrays included in the preset code feature library and the byte arrays of the application file is determined. The byte arrays included in the preset code feature library are non-compliant byte arrays.

[0097] In step S502A, in response to the byte arrays included in the preset code feature library not matching the byte arrays of the application file, the application file is confirmed as a trusted file.

[0098] In step S502B, in response to the byte arrays included in the preset code feature library matching the byte arrays of the application file, the application file is confirmed as an untrusted file.

[0099] In the embodiments of the present disclosure, after obtaining the byte array of the application file, the obtained byte array is compared with the byte arrays included in the preset code feature library to determine whether the application file is an untrusted file. It can be understood that certain specific strings (such as addmiuiflag) are only used by malware, and the preset code feature library in the present disclosure includes the strings that are only used by the above malware.

[0100] In an exemplary embodiment of the present disclosure, the byte pattern is used for feature comparison of byte arrays. The byte pattern refers to directly using the byte stream sequence as a feature, such as the byte sequence 0xca 0xfe 0xba 0xbec. Corresponding to the present disclosure, the specific operation sequence of the byte array is represented as an operation code (Operation Code, OPCode). It can be understood that the malicious behavior of a malware is usually completed through a series of operations. Through deserialization operations, system privilege escalation is completed. The code for the malicious application to perform malicious operations will ultimately be compiled into bytecode. The present disclosure extracts the common features of this code bytecode and adds the corresponding byte array to the preset code feature library for the identification of malicious code.

[0101] In the embodiments of the present disclosure, in the case where the application file fails the first verification, the string is directly searched as a kind of feature. By determining whether the source code file of the application file contains a specific string, it is determined whether the application file is a malicious file, and it is determined whether the application corresponding to the application file is a malicious / virus application.

[0102] It can be understood that in the above process of performing the second verification on the application file according to the byte array, it is required to ensure the accuracy of the verification result while ensuring the efficiency of the algorithm (i.e., ensuring the rate of the second verification). The conventional algorithm for finding the feature byte subsequence (corresponding to the malicious byte array above) in the byte stream (corresponding to the byte arrays included in the above preset code feature library) is a brute-force matching algorithm, which needs to traverse the byte arrays included in the preset code feature library in a traversal manner, resulting in a high time complexity and low processing efficiency. Therefore, the present disclosure provides a string matching algorithm based on the idea of an efficient string matching algorithm (i.e., the BM string search algorithm - Boyer - Moore string search algorithm) to efficiently and accurately determine whether the byte array of the application file contains a malicious byte array, ensuring the accuracy and efficiency of the second verification of the application file.

[0103] In one example, the implementation of the string matching algorithm based on the idea of the efficient string matching algorithm includes the following steps:

[0104] Step (1): Conversion of byte arrays, that is, converting a byte stream into a string literal: The purpose of using the string matching algorithm in this disclosure is to determine whether a malicious byte array is included in the byte array of the application file, that is, it is necessary to implement finding whether a specific byte subsequence (corresponding to malicious character information) exists in the byte stream (corresponding to the byte array of the application file), that is: fn search(haystack:&[u8],pattern:String)->Option <usize>。Since wildcards "??" are included in the byte subsequence when setting the specified byte subsequence, the above-mentioned specific byte subsequence cannot be represented only by a byte array. It is necessary to convert the above-mentioned specific byte subsequence into a string and represent it in the form of a string. Since the above-mentioned specific byte subsequence is represented in the form of a string, in this example, the present disclosure implements the matching of the byte array by using the idea of an efficient string matching algorithm. The difference between the solution adopted by the present disclosure and the efficient string matching algorithm is that the object for matching in the efficient string matching algorithm is a single character, while the object for matching in the solution adopted by the present disclosure is a single byte. When the present disclosure performs the conversion of the byte array, it converts the byte stream into a hexadecimal string literal and directly uses a regular expression (pattern) for matching. Further, considering the processing of the wildcard "??", the present disclosure compiles the pattern into another "byte array", converting the problem into finding whether there is a small byte array in a large byte array, where the small byte array contains wildcards.

[0105] In one example, the idea of performing byte array conversion is to compile the pattern byte pattern string into an unsigned 16-bit integer array [u16], and wildcards are identified by bits outside the u8 range and within the u16 range. Therefore, the present disclosure selects the mask 0xFFFF (0b1111_1111_1111_1111) to identify the complete wildcard "??", uses the mask 0xFFE0 (0b1111_1111_1110_0000) to identify high-order wildcards such as "?8", and uses the mask 0x07FF (0b0000_0111_1111_1111) to identify low-order wildcards such as "1?". The determined low 4 bits are placed in the low zero bits of the mask or the high 4 bits are placed in the high zero bits of the mask to retain the corresponding information, so as to achieve the purpose of identifying wildcards and containing determined bits at the same time. For example, "?8" will be compiled as 0xFFE8, and "1?" will be compiled as 0x17FF. By reasonably using the extra 8 bits of u16, the wildcards are accurate to each bit. The present disclosure splits the pattern string into single byte literals, captures the determined high 4 bits or low 4 bits containing half-byte wildcards with a regular expression, and then marks them with appropriate wildcard marks, that is, a byte pattern string is compiled.

[0106] The compilation method corresponding to the above step (1) is:

[0107]

[0108]

[0109] / / Assertion test function to check whether the result of compiling the pattern string is correct

[0110] assert_eq!(&compile_pattern_string("?8"), &[0xFFE8]);

[0111] assert_eq!(&compile_pattern_string("1?"), &[0x17FF]);

[0112] assert_eq!(&compile_pattern_string("ff"), &[0xFF]);

[0113] assert_eq!(&compile_pattern_string("?f"), &[0xFFEF]);

[0114] assert_eq!(&compile_pattern_string("f?"), &[0xF7FF]);

[0115] assert_eq!(&compile_pattern_string("??"), &[0xFFFF])

[0116] Step (2): Determine whether the target byte (corresponding to the malicious byte array) is equal to the compiled "byte" (corresponding to the result of the compiled pattern string in Step 1, i.e., the compiled malicious byte array) to ensure the accuracy of the verification result. In the present disclosure, by defining the equals method, it is determined whether the target byte is equal to the compiled "byte". The judgment logic of the above judgment is as follows: If pattern is a complete wildcard, there is no need to compare, and directly return true; if pattern is a "byte" containing a high-order wildcard, only their lower 4 bits need to be compared; if pattern is a "byte" containing a low-order wildcard, only their higher 4 bits need to be compared; if there is no wildcard, directly compare the values.

[0117] The method corresponding to the above step (2) is:

[0118]

[0119] / / Assertion test to check whether the result of the equals function is correct

[0120] assert!(equals(0xFFE8, 0x28 / * a?8 instance * / )); / / An example, when pattern is 0xFFE8, it is equal to the value of target being 0x28 (because the lower 4 bits of 0x28 are 0)

[0121] assert!(equals(0xFFE8, 0x18 / * a? 8 instance * / )); / / An example where when the pattern is 0xFFE8, it is equal to the target value of 0x18 (because the lower 4 bits of 0x18 are 1)

[0122] assert!(equals(0x17FF, 0x10 / * a 1? instance * / )); / / An example where when the pattern is 0x17FF, it is equal to the target value of 0x10 (because the higher 4 bits of 0x10 are 1)

[0123] assert!(equals(0x17FF, 0x11 / * a 1? instance * / )); / / An example where when the pattern is 0x17FF, it is equal to the target value of 0x11 (because the higher 4 bits of 0x11 are 1)

[0124] Step (III): Build a regular string matching algorithm (boyer_moore_search) without wildcard functionality based on the idea of an efficient string matching algorithm. After completing the preprocessing of wildcards and the judgment of the compiled "bytes", start implementing the core algorithm. The core algorithm accepts a byte array (corresponding to the byte array of the application file) and a preprocessed "byte array" (corresponding to the malicious byte array) and matches the two. If the match is successful, return the index of the pattern in the haystack; otherwise, return None. That is: fn boyer_moore_search(haystack: &[u8], pattern: &[u16]) -> Option <usize>。

[0125] In the above step 3, a conventional string matching algorithm without wildcard function is constructed based on the idea of an efficient string matching algorithm as follows:

[0126]

[0127]

[0128] Step (4): Based on the constructed string matching algorithm without wildcard function above, construct a converted string matching algorithm with wildcard function. For the above-mentioned conventional string matching algorithm without wildcard function constructed based on the idea of an efficient string matching algorithm, adjust and modify the bad character table rule and the part for judging whether two bytes are equal. For the part of judging whether two bytes are equal, make adaptive replacements according to the equals method implemented in step (1).

[0129] The converted string matching algorithm with wildcard function constructed in the above step (4) is as follows:

[0130]

[0131]

[0132]

[0133] It can be understood that the terminal application will be updated frequently, and the application file information of the application will change after the update. The nature of the trusted application and the malicious application may change after the update. Based on this, the preset whitelist in the terminal in the present disclosure needs to be updated frequently. The following embodiments of the present disclosure further illustrate the application file verification method in the present disclosure.

[0134] Figure 6 is a flowchart of an application file verification method shown according to an exemplary embodiment. As Figure 6 shown, the method includes steps S601 to step S603.

[0135] In step S601, in response to the application file failing the first verification, upload the package name information of the application file to the cloud, and obtain the cloud verification result returned by the cloud.

[0136] Among them, the cloud is used to determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file. The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and the package name information included in the preset blacklist does not match the package name information of the application file. The first preset blacklist is applied to the cloud.

[0137] In step S602, in response to the cloud verification result indicating that the package name information included in the preset blacklist does not match the package name information of the application file, determine the matching relationship between the package name information included in the second preset blacklist and the package name information of the application file.

[0138] In step S603, in response to the package name information included in the second preset blacklist matching the package name information of the application file, update the second preset blacklist according to the first preset blacklist.

[0139] In an embodiment of the present disclosure, a preset blacklist (second preset blacklist) containing untrusted application package name information is set locally on the terminal. Correspondingly, the present disclosure also sets a preset blacklist (first preset blacklist) containing malicious application package name information in the cloud. It can be understood that, compared with the terminal, the information update rate in the cloud is faster. Based on this, the present disclosure updates the local preset whitelist through the preset blacklist in the cloud.

[0140] In an embodiment of the present disclosure, when the application file fails the first verification, a network request is constructed to upload the application file package name information to the cloud. The cloud performs cloud verification on the package name information through a preset blacklist (virus library) to determine whether the application file that fails the first verification is included in the preset blacklist. After the cloud completes the verification, the verification result is sent to the terminal, and the terminal verifies the application file based on the local blacklist of the terminal and the package name information of the application file. When the verification result of the application file based on the cloud preset blacklist is consistent with the verification result of the application file based on the local preset blacklist of the terminal, that is, when the package name information of the application file exists in both the first preset blacklist and the second preset blacklist, it indicates that the verification result of the package name information of the application file based on the local blacklist of the terminal is accurate, and the terminal has no action. When the verification result of the application file based on the cloud preset blacklist is inconsistent with the verification result of the application file based on the local preset blacklist of the terminal, that is, when the package name information of the application file exists in the first preset blacklist but does not exist in the second preset blacklist, it indicates that the verification result of the package name information of the application file based on the local blacklist of the terminal is inaccurate, and the terminal updates the second preset blacklist to synchronize the first preset blacklist in the cloud to the local terminal.

[0141] The following embodiments of the present disclosure illustrate an application file verification method applied to the cloud.

[0142] Figure 7 It is a flowchart of an application file verification method shown according to an exemplary embodiment. As Figure 7 shown, the method includes steps S701 to S702.

[0143] In step S701, obtain the package name information of the application file uploaded by the terminal, and perform cloud verification on the application file according to the package name information and the first preset blacklist. The first preset blacklist includes the package name information of untrusted applications, so as to obtain the cloud verification result.

[0144] In step S702, send the cloud verification result to the terminal.

[0145] In the embodiments of the present disclosure, a preset whitelist containing the package name information of trusted applications is set locally on the terminal. Correspondingly, a preset blacklist containing the package name information of malicious applications is also set in the cloud. It can be understood that compared with the terminal, the information update rate in the cloud is faster. Based on this, the present disclosure updates the preset blacklist locally on the terminal through the preset blacklist in the cloud, that is, after the cloud obtains the package name information of the received application file upload, it verifies the package name information based on the preset blacklist and sends the verification result to the terminal.

[0146] The following embodiments of the present disclosure illustrate the method for performing cloud verification.

[0147] Figure 8 It is a flowchart of a method for performing cloud verification on an application file shown according to an exemplary embodiment. As Figure 8 shown, the method includes steps S801 to S802.

[0148] In step S801, obtain the package name information of the application file uploaded by the terminal.

[0149] In step S802, determine the matching relationship between the package name information included in the preset blacklist and the package name information of the application file.

[0150] Among them, the cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the first preset blacklist does not match the package name information of the application file.

[0151] In an embodiment of the present disclosure, when the application file fails the first verification, a network request is constructed to upload the application file package name information to the cloud. The cloud performs cloud verification on the package name information through a preset blacklist (virus library) to determine whether the application file that fails the first verification is included in the preset blacklist. After the cloud completes the verification, the verification result is sent to the terminal. When the verification result of the application file based on the cloud preset blacklist is consistent with the verification result of the application file based on the terminal local preset blacklist, that is, when the package name information of the application file exists in both the first preset blacklist and the second preset blacklist, it indicates that the verification result of the application file package name information based on the terminal local blacklist is accurate, and there is no action on the terminal local. When the verification result of the application file based on the cloud preset blacklist is inconsistent with the verification result of the application file based on the terminal local preset blacklist, that is, when the package name information of the application file exists in the first preset blacklist but does not exist in the second preset blacklist, it indicates that the verification result of the application file package name information based on the terminal local blacklist is inaccurate, and the terminal updates the second preset blacklist and synchronizes the first preset blacklist in the cloud to the terminal local.

[0152] In an exemplary embodiment of the present disclosure, when the application file is an APK file, such as Figure 9 As shown in the flowchart of the application file verification method, the following method is adopted to verify the application file: after the user inputs the file path (Path) or package name (PackageName) of the APK file, the application file verification system of the terminal receives the file path or package name of the APK file. Parse the APK file information, that is, use the scheme of only reading the Mainifest file to parse the apk information and the fast digest calculation scheme of the APK file to quickly read the APK information, and obtain information such as the package name, installation source, signature, etc. of the application. Verify the APK file based on the APK file information. Match the application exemption scheme of the trusted developer family. The APK file of the developer with a trusted developer signature is considered safe; check whether the package name information is the package name information of a trusted application based on the whitelist; determine whether the installation source (such as an app store, browser, etc.) of the APK file is a trusted installation source. Add the APK file that fails any of the above three verification processes to the verification list, start building a network request, and send the information of the APK file included in the verification list to the server (cloud) for scanning, that is, cloud scanning. The server uses its huge computing power and virus library (preset blacklist library) for identification and returns the result to the client. When the cloud scanning is successful, directly enter the code scanning process. When the cloud scanning is not successful, enter the local whitelist library matching process, match the blacklist of the server with the local blacklist, update the local blacklist, and enter the code scanning process. After entering the code scanning process, perform local code scanning, that is, a code feature matching process of the APK file based on the threat features (strings) cached locally. Perform matching detection based on the malicious application detection algorithm based on opcode and the malicious application monitoring algorithm based on string matching. When the result is detected, report the code scanning result, output the scanning result, and report the result of matching the blacklist of the server with the local whitelist.

[0153] In an exemplary embodiment of the present disclosure, the application file is identified based on the end-side scanning of the terminal and the cloud scanning of the cloud, such as Figure 10 As shown in the architecture diagram of the application file verification method, the architecture includes an execution structure in the cloud and an execution structure in the terminal. The architecture includes a virus scanning engine, a virus scanning program, and an automated malicious application scanning engine. Such as Figure 10 As shown, the virus scanning engine includes end-side scanning and cloud scanning. The virus scanning process includes the APK file scanning process based on the code feature library and the blacklist library matching process based on the local blacklist library. The cloud scanning process includes the application information collection process and the upload to the server for scanning process. Figure 10 As shown, the virus scanning service includes the code feature library acquisition process, the local blacklist library acquisition process, the whitelist library acquisition process, the cloud scanning capability process, the to-be-confirmed malicious application upload process, and the unknown application upload process. The above execution process is based on the code feature library, blacklist library, and whitelist library. Figure 10 As shown, the automated malicious application scanning engine includes APK full-file scanning, automated unpacking (i.e. obtaining the application's feature files), AI-based feature scanning, and scanning of application sources. Scanning application sources is used to obtain the application's installation source, which includes self-developed engine collection, installer installation, and new listings on the app store.

[0154] In the disclosed embodiment, when verifying an installed application or an application installation package file, a global configuration file and a source code file contained in the application file are obtained. The global configuration file is parsed to obtain application information of the application file, namely, package name information, signature information and installation source information, and the application information is verified, namely, to determine whether the package name information is in a preset whitelist, to determine whether the installation source of the application is a trusted installation source through the signature information of the application file, and to determine whether the developer of the application is a trusted installation source through the signature information of the application file. When the verification of the application information passes, the application file is characterized as a trusted file, and the verification process ends. When the verification of the application information fails, the application file is verified based on the source code file, the byte array contained in the source code file is obtained, and it is determined whether the byte array contains a malicious byte array. If the byte array of the application file does not contain a malicious byte array, the verification process based on the source code file passes. If the byte array of the application file contains a malicious byte array, the application file is determined to be a malicious file. Through the present disclosure, when verifying an application file, necessary files containing various application information of the application file are obtained, and the necessary files of the application file are parsed, without parsing all the files contained in the application file. While ensuring comprehensive verification of the application file and ensuring the accuracy of the verification, the parsing speed of the application file information is improved, thereby accelerating the verification speed of the application file.

[0155] Based on the same concept, the embodiment of the present disclosure also provides an application file verification device 100.

[0156] It can be understood that, in order to implement the above functions, the application file verification device 100 provided in the embodiments of the present disclosure includes the corresponding hardware structures and / or software modules for executing each function. Combining the units and algorithm steps of the various examples disclosed in the embodiments of the present disclosure, the embodiments of the present disclosure can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving the hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solutions of the embodiments of the present disclosure.

[0157] Figure 11 It is a block diagram of an application file verification device 100 shown according to an exemplary embodiment. Referring to Figure 11 this, the device includes an acquisition unit 101 and a processing unit 102.

[0158] The acquisition unit 101 is configured to acquire the global configuration file included in the application file and acquire the source code file included in the application file. The global configuration file includes the application information of the application file, and the source code file includes the byte array of the application file.

[0159] The processing unit 102 is configured to verify the application file according to the global configuration file and the source code file.

[0160] In one implementation manner, the processing unit 102 verifies the application file according to the application information and the byte array in the following manner: performing a first verification on the application file according to the application information to obtain a first verification result, where the application information includes the package name information, signature information, and installation source information of the application file. In response to the application file failing the first verification, performing a second verification on the application file according to the byte array to obtain a second verification result.

[0161] In one implementation manner, the global configuration file includes a MANIFEST manifest file and a META_INF manifest file.

[0162] In one implementation manner, the acquisition unit 101 acquires the application information of the application file included in the global configuration file in the following manner: parsing the MANIFEST manifest file to obtain the package name information and installation source information of the application file, and parsing the META_INF manifest file to obtain the signature information of the application file.

[0163] In one implementation, the processing unit 102 performs a first verification on the application file according to the application information in the following manner: determining the installation source of the application, determining the developer of the application according to the signature information of the application file, and determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file. In response to determining the installation source of the application, the first verification result includes that the installation source of the application file is a trusted installation source and the installation source of the application file is an untrusted installation source. In response to determining the developer of the application according to the signature information of the application file, the first verification result includes that the developer of the application file is a trusted developer and the developer of the application file is an untrusted developer. In response to determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file, the first verification result includes that the package name information included in the preset whitelist matches the package name information of the application file and the package name information included in the preset whitelist does not match the package name information of the application file.

[0164] In one implementation, the application file that passes the first verification meets each of the following conditions: the installation source of the application file is a trusted installation source, the developer of the application file is a trusted developer, and the package name information included in the preset whitelist matches the package name information of the application file. The application file that fails the first verification meets any of the following conditions: the installation source of the application file is an untrusted installation source, the developer of the application file is an untrusted developer, and the package name information included in the preset whitelist does not match the package name information of the application file.

[0165] In one implementation, the processing unit 102 performs a second verification on the application file according to the byte array in the following manner to obtain a second verification result: determining the matching relationship between the byte array included in the preset code feature library and the byte array of the application file, and the byte array included in the preset code feature library is a non-compliant byte array. In response to the byte array included in the preset code feature library not matching the byte array of the application file, the application file is confirmed as a trusted file. In response to the byte array included in the preset code feature library matching the byte array of the application file, the application file is confirmed as an untrusted file.

[0166] In one implementation, the processing unit 102 is further configured to: in response to the application file failing the first verification, upload the package name information of the application file to the cloud, and obtain the cloud verification result returned by the cloud. The cloud is used to determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file. The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the preset blacklist does not match the package name information of the application file. The first preset blacklist is applied to the cloud. In response to the cloud verification result indicating that the package name information included in the preset blacklist does not match the package name information of the application file, determine the matching relationship between the package name information included in the second preset blacklist and the package name information of the application file. The second preset blacklist is applied to the terminal. In response to the package name information included in the second preset blacklist matching the package name information of the application file, update the second preset blacklist according to the first preset blacklist.

[0167] Figure 12 is a block diagram of an application file verification device 200 shown according to an exemplary embodiment. Referring to Figure 12 this, the device includes a verification unit 201 and a sending unit 202.

[0168] The verification unit 201 is configured to obtain the package name information of the application file uploaded by the terminal, and perform cloud verification on the application file according to the package name information and the first preset blacklist to obtain a cloud verification result. The first preset blacklist includes the package name information of untrusted applications.

[0169] The sending unit 202 is configured to send the cloud verification result to the terminal..

[0170] In one implementation, the verification unit 201 performs cloud verification on the application file according to the package name information and the first preset blacklist in the following manner: determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file. The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the first preset blacklist does not match the package name information of the application file.

[0171] Regarding the device in the above embodiments, the specific manners in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated herein.

[0172] Figure 13 is a block diagram of a device 300 for application file verification shown according to an exemplary embodiment. The device 300 may be provided as a terminal. For example, the device 300 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0173] Reference Figure 13 , the apparatus 300 may include one or more of the following components: a processing component 302, a memory 304, a power component 306, a multimedia component 308, an audio component 310, an input / output (I / O) interface 312, a sensor component 314, and a communication component 316.

[0174] The processing component 302 generally controls the overall operation of the apparatus 300, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 302 may include one or more processors 320 to execute instructions to complete all or part of the steps of the above-described methods. In addition, the processing component 302 may include one or more modules to facilitate interaction between the processing component 302 and other components. For example, the processing component 302 may include a multimedia module to facilitate interaction between the multimedia component 308 and the processing component 302.

[0175] The memory 304 is configured to store various types of data to support the operation of the apparatus 300. Examples of such data include instructions for any application or method operating on the apparatus 300, contact data, phone book data, messages, pictures, videos, and the like. The memory 304 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disk.

[0176] The power component 306 provides power to the various components of the apparatus 300. The power component 306 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the apparatus 300.

[0177] The multimedia component 308 includes a screen that provides an output interface between the device 300 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 308 includes a front camera and / or a rear camera. When the device 300 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capabilities.

[0178] The audio component 310 is configured to output and / or input audio signals. For example, the audio component 310 includes a microphone (MIC) that is configured to receive external audio signals when the device 300 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 304 or transmitted via the communication component 316. In some embodiments, the audio component 310 further includes a speaker for outputting audio signals.

[0179] The I / O interface 312 provides an interface between the processing component 302 and a peripheral interface module, and the peripheral interface module can be a keyboard, a click wheel, buttons, etc. These buttons can include but are not limited to: a home button, a volume button, a power button, and a lock button.

[0180] The sensor component 314 includes one or more sensors for providing an assessment of the various aspects of the state of the device 300. For example, the sensor component 314 can detect the on / off state of the device 300, the relative positioning of components, such as the display and the keypad of the device 300. The sensor component 314 can also detect a change in the position of the device 300 or a component of the device 300, the presence or absence of user contact with the device 300, the orientation or acceleration / deceleration of the device 300, and the temperature change of the device 300. The sensor component 314 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor component 314 can also include a light sensor, such as a CMOS or a CCD image sensor, for use in imaging applications. In some embodiments, the sensor component 314 can further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0181] The communication component 316 is configured to facilitate communication, either wired or wirelessly, between the device 300 and other devices. The device 300 may access a wireless network based on a communication standard, such as WiFi, 2G, or 3G, or a combination thereof. In an exemplary embodiment, the communication component 316 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 316 further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0182] In an exemplary embodiment, the device 300 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the above method.

[0183] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as the memory 304 including instructions, which can be executed by the processor 320 of the device 300 to complete the above method. For example, the non-transitory computer-readable storage medium may be a ROM, Random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0184] It can be understood that in the present disclosure, "a plurality of" means two or more, and other quantifiers are similar. "And / or" describes the association relationship of associated objects and indicates that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after. The singular forms of "a", "the", and "said" are also intended to include the plural forms unless the context clearly indicates otherwise.

[0185] It can be further understood that the terms "first", "second", etc. are used to describe various information, but this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other and do not represent a specific order or degree of importance. In fact, the expressions such as "first" and "second" can be used interchangeably. For example, without departing from the scope of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information.

[0186] It can be further understood that the orientation or positional relationship indicated by terms such as "center", "longitudinal", "lateral", "front", "rear", "upper", "lower", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing this embodiment and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation.

[0187] It can be further understood that unless otherwise specified, "connection" includes direct connection without other components between the two, and also includes indirect connection with other elements between the two.

[0188] It can be further understood that although the operations are described in a specific order in the drawings in the embodiments of the present disclosure, it should not be understood as requiring these operations to be performed in the specific order or serial order shown, or requiring all the operations shown to obtain the desired result. In a specific environment, multitasking and parallel processing may be advantageous.

[0189] Those skilled in the art will readily conceive of other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. The present disclosure is intended to cover any variations, uses, or adaptations of this solution, which follow the general principles of the present disclosure and include common general knowledge or conventional technical means in the technical field not disclosed in the present disclosure.

[0190] It should be understood that the present disclosure is not limited to the exact structures already described and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present disclosure is only limited by the appended claims.< / usize> < / usize>

Claims

1. A method for applying file verification, characterized in that, Including: Obtain the global configuration file included in the application file, and obtain the source code file included in the application file; Obtain the application information of the application file included in the global configuration file, and obtain the byte array of the application file included in the source code file; Verify the application file according to the application information and the byte array.

2. The method according to claim 1, wherein The verifying the application file according to the application information and the byte array includes: Perform a first verification on the application file according to the application information to obtain a first verification result, where the application information includes the package name information, signature information, and installation source information of the application file; In response to the application file failing the first verification, perform a second verification on the application file according to the byte array to obtain a second verification result.

3. The method according to any one of claims 1 to 2, characterized in that, The global configuration file includes a MANIFEST manifest file and a META_INF manifest file.

4. The method according to claim 3, wherein The obtaining the application information of the application file included in the global configuration file includes: Parse the MANIFEST manifest file to obtain the package name information and installation source information of the application file, and parse the META_INF manifest file to obtain the signature information of the application file.

5. The method according to claim 2, wherein The performing a first verification on the application file according to the application information includes: Determine the installation source of the application, determine the developer of the application according to the signature information of the application file, and determine the matching relationship between the package name information included in the preset whitelist and the package name information of the application file; In response to determining the installation source of the application, the first verification result includes that the installation source of the application file is a trusted installation source and the installation source of the application file is an untrusted installation source; In response to determining the developer of the application according to the signature information of the application file, the first verification result includes that the developer of the application file is a trusted developer and the developer of the application file is an untrusted developer; In response to determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file, the first verification result includes that the package name information included in the preset whitelist matches the package name information of the application file, and the package name information included in the preset whitelist does not match the package name information of the application file.

6. The method according to claim 5, characterized in that, The application file passing the first verification satisfies each of the following conditions: the installation source of the application file is a trusted installation source, the developer of the application file is a trusted developer, and the package name information included in the preset whitelist matches the package name information of the application file; The application file failing the first verification satisfies any one of the following conditions: The installation source of the application file is an untrusted installation source, the developer of the application file is an untrusted developer, and the package name information included in the preset whitelist does not match the package name information of the application file.

7. The method according to claim 2, wherein The performing a second verification on the application file according to the byte array to obtain a second verification result includes: Determine the matching relationship between the byte array included in the preset code feature library and the byte array of the application file, where the byte array included in the preset code feature library is a non-compliant byte array; In response to the byte array included in the preset code feature library not matching the byte array of the application file, confirm the application file as a trusted file; In response to the byte array included in the preset code feature library matching the byte array of the application file, confirm the application file as an untrusted file.

8. The method according to claim 2, characterized in that, The method further includes: In response to the application file failing the first verification, upload the package name information of the application file to the cloud and obtain the cloud verification result returned by the cloud. The cloud is used to determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file. The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the preset blacklist does not match the package name information of the application file. The first preset blacklist is applied to the cloud; In response to the cloud verification result being that the package name information included in the preset blacklist does not match the package name information of the application file, determine the matching relationship between the package name information included in the second preset blacklist and the package name information of the application file. The second preset blacklist is applied to the terminal; In response to the package name information included in the second preset blacklist matching the package name information of the application file, update the second preset blacklist according to the first preset blacklist.

9. A file verification method, characterized in that, Includes: Obtain the package name information of the application file uploaded by the terminal, perform cloud verification on the application file according to the package name information and the first preset blacklist, and obtain the cloud verification result. The first preset blacklist includes the package name information of untrusted applications; Send the cloud verification result to the terminal.

10. The method according to claim 9, characterized in that, The performing cloud verification on the application file according to the package name information and the first preset blacklist includes: Determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file; The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the first preset blacklist does not match the package name information of the application file.

11. An application file verification device, characterized in that, Includes: An acquisition unit, configured to acquire the global configuration file included in the application file, acquire the source code file included in the application file, acquire the application information of the application file included in the global configuration file, and acquire the byte array of the application file included in the source code file; A processing unit, configured to verify the application file according to the application information and the byte array.

12. The device according to claim 11, characterized in that, The processing unit verifies the application file according to the application information and the byte array in the following manner: Perform a first verification on the application file according to the application information to obtain a first verification result. The application information includes the package name information, signature information, and installation source information of the application file; In response to the application file failing the first verification, perform a second verification on the application file according to the byte array to obtain a second verification result.

13. The device according to any one of claims 11 to 12, characterized in that, The global configuration file includes a MANIFEST manifest file and a META_INF manifest file.

14. The device according to claim 13, wherein, The obtaining unit obtains the application information of the application file included in the global configuration file in the following manner: Parse the MANIFEST manifest file to obtain the package name information and installation source information of the application file, and parse the META_INF manifest file to obtain the signature information of the application file.

15. The device according to claim 12, characterized in that, The processing unit performs a first verification on the application file according to the application information in the following manner: Determine the installation source of the application, determine the developer of the application according to the signature information of the application file, and determine the matching relationship between the package name information included in the preset whitelist and the package name information of the application file; In response to determining the installation source of the application, the first verification result includes that the installation source of the application file is a trusted installation source and the installation source of the application file is an untrusted installation source; In response to determining the developer of the application according to the signature information of the application file, the first verification result includes that the developer of the application file is a trusted developer and the developer of the application file is an untrusted developer; In response to determining the matching relationship between the package name information included in the preset whitelist and the package name information of the application file, the first verification result includes that the package name information included in the preset whitelist matches the package name information of the application file and the package name information included in the preset whitelist does not match the package name information of the application file.

16. The device according to claim 15, characterized in that, The application file passing the first verification satisfies each of the following conditions: the installation source of the application file is a trusted installation source, the developer of the application file is a trusted developer, and the package name information included in the preset whitelist matches the package name information of the application file; The application file failing the first verification satisfies any of the following conditions: The installation source of the application file is an untrusted installation source, the developer of the application file is an untrusted developer, and the package name information included in the preset whitelist does not match the package name information of the application file.

17. The device according to claim 12, wherein The processing unit performs a second verification on the application file according to the byte array in the following manner to obtain a second verification result: Determine the matching relationship between the byte array included in the preset code feature library and the byte array of the application file, and the byte array included in the preset code feature library is a non-compliant byte array; In response to the byte array included in the preset code feature library not matching the byte array of the application file, confirm the application file as a trusted file; In response to the byte array included in the preset code feature library matching the byte array of the application file, confirm the application file as an untrusted file.

18. The device according to claim 12, characterized in that, The processing unit is further configured to: In response to the application file failing the first verification, upload the package name information of the application file to the cloud, and obtain the cloud verification result returned by the cloud. The cloud is used to determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file. The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the preset blacklist does not match the package name information of the application file. The first preset blacklist is applied to the cloud; In response to the cloud verification result indicating that the package name information included in the preset blacklist does not match the package name information of the application file, determine the matching relationship between the package name information included in the second preset blacklist and the package name information of the application file. The second preset blacklist is applied to the terminal; In response to the package name information included in the second preset blacklist matching the package name information of the application file, update the second preset blacklist according to the first preset blacklist.

19. An application file verification device, characterized in that, Comprising: A verification unit, configured to obtain the package name information of the application file uploaded by the terminal, and perform cloud verification on the application file according to the package name information and the first preset blacklist to obtain a cloud verification result. The first preset blacklist includes the package name information of untrusted applications; A sending unit, configured to send the cloud verification result to the terminal.

20. The device according to claim 19, characterized in that, The verification unit performs cloud verification on the application file according to the package name information and the first preset blacklist in the following manner: Determine the matching relationship between the package name information included in the first preset blacklist and the package name information of the application file; The cloud verification result includes that the package name information included in the first preset blacklist matches the package name information of the application file, and that the package name information included in the first preset blacklist does not match the package name information of the application file.

21. An electronic device, characterized in that, Comprising: A processor: A memory for storing instructions executable by the processor; Wherein, the processor is configured to: execute the application file verification method according to any one of claims 1 to 8.

22. An electronic device, characterized in that, Comprising: A processor: A memory for storing instructions executable by the processor; Wherein, the processor is configured to: execute the application file verification method according to any one of claims 9 to 10.

23. A storage medium, characterized in that, Instructions are stored in the storage medium. When the instructions in the storage medium are executed by the processor, the processor is enabled to execute the application file verification method according to any one of claims 1 to 8.

24. A storage medium, characterized in that, Instructions are stored in the storage medium. When the instructions in the storage medium are executed by the processor, the processor is enabled to execute the application file verification method according to any one of claims 9 to 10.

Images