WO2014000696A1

WO2014000696A1 - Security detection method and system for android application program

Info

Publication number: WO2014000696A1
Application number: PCT/CN2013/078425
Authority: WO
Inventors: 李涛; 张旭
Original assignee: 北京奇虎科技有限公司; 奇智软件（北京）有限公司
Priority date: 2012-06-28
Filing date: 2013-06-28
Publication date: 2014-01-03

Abstract

Disclosed are a security detection method and system for an Android application program to solve the problem of a slow scanning speed and a high false alarm rate in the existing antivirus method for an Android platform. The method comprises: scanning an Android installation package, and extracting designated feature information from the Android installation package (201); uploading the designated feature information to a server, and looking for a feature record matching single designated feature information or a combination thereof in a security identification library preset by the server (202); and receiving a security detection result returned by the server for the Android installation package, and displaying same on a client user interface, the security detection result containing a security level corresponding to the feature record found by the server (203). The present application combines client detection with server detection, so that the scanning speed is fast, and the checking and killing accuracy rate is high.

Description

Security check method and system for Android application

Technical leader

The invention relates to a software security technology leading city, in particular to a security detection method and system for an Android application. Background technique

Android is a Linux-based open source operating system, mainly used in mobile terminals such as mobile phones. Currently, there is no unified Chinese name. The Android platform consists of the operating system, middleware, user interface and application software. Android should refer to the application software under the Android platform.

With the popularity of Android smartphones, an industry chain of malware that is tied to the Android system has gradually formed. These malware are usually pretending to be normal application software or games to trick users into installing. Once they enter the user's mobile phone, they can customize the SP service in the background or dial the payphone to collect the user's credit, or collect the user's privacy, or steal the user's online banking and third parties. Pay the password to implement further theft. According to statistics, there are currently more than 8,000 Android malware, and more than 5 million Android phones have been infected.

With regard to these numerous Android malwares, companies dedicated to software anti-virus have launched anti-virus software for the Android platform. However, their anti-virus engine is mainly transplanted from the anti-virus engine on the PC. It uses the traditional PC anti-virus idea, checks and kills files according to files, and even scans files that cannot be run on Android phones, resulting in slow scanning speed and scanning efficiency. Low problem; Moreover, the scanning algorithm uses the method of extracting file fragments to calculate CRC (Cyclic Redundancy Check) and MD5 (Message Digest Algorithm, fifth edition) and then look up in the local database. Sex is not S, it is easy to lead to false positives, and the rate of false positives is rather embarrassing.

Summary of the invention

In view of the foregoing, the present invention has been made in order to provide a security detection method and system for an Android application library that overcomes the above problems or at least partially solves or alleviates the above problems.

According to an aspect of the present invention, a security detection method for an Android application is provided, including: scanning an Android installation package, and extracting specified feature information from the Android installation package; uploading the specified feature information Go to the service U, and search for a feature record matching the specified single feature information or a combination thereof in the server-preset security identification library; wherein the server-preset security identification library corresponds to the feature record and the feature record Security level, each feature record includes a combination of a single feature information or feature information; receiving a security test result returned by the server to the Android installation package, and displaying the result in the client user interface, the security detection result package The security level corresponding to the feature record found by the server.

According to another aspect of the present invention, a security detection method for an Android application is provided, including: receiving an uploaded specified feature information, the specified feature information being extracted from an Android installation package; Locating a feature record matching the specified single feature information or a combination thereof in the security identification library; wherein the security identification library includes a security level corresponding to the feature record and the feature record, and each feature record is individually wrapped The combination of the feature information or the feature information; the security level package corresponding to the found feature record is sent in the security detection result of the Android installation package.

According to an aspect of the present invention, a security detection system for an Android application library is provided, which is disposed on a client, and includes: a feature extraction module, configured to scan an Android installation package, and extract a designation from the Android installation package. And the uploading module, configured to upload the specified feature information to the server, and search for a feature record matching the specified single feature information or a combination thereof in the security identifier library preset by the server; wherein, the server a security level corresponding to the signature record and the feature record in the preset security identification library, and each feature record includes a combination of a single feature information or feature information; a display module, configured to receive a message returned by the server to the Android installation The security detection result of the packet is displayed on the client user interface, and the security detection result indicates the security level corresponding to the feature record found by the server.

According to another aspect of the present invention, a security detection system for an Android application library is provided, which is disposed at a server, and includes: a receiving module, configured to receive the uploaded specified feature information, where the specified feature information is from Android The network detection module is configured to search for a feature record matching the specified single feature information or a combination thereof in a server-preset security identification library; wherein the security identification library has a package feature The security level corresponding to the record and the feature record, each feature record includes a combination of a single feature information or feature information; a sending module, configured to secure the security level corresponding to the found feature record in the security of the Android installation package Sent in the test result.

According to still another aspect of the present invention, a computer program is provided, comprising computer readable code, when the computer readable code is run on a server, causing the server to perform according to any one of claims 1-15 The security detection method of the Android application library.

According to still another aspect of the present invention, a computer readable medium storing the same as claimed in claim 29 Computer program.

The beneficial effects of the invention are:

First of all, the security detection of the Android application provided by the present application does not scan all the files in the Android system, but scans the Android installation package for security detection. Since viruses, trojans, and other malicious software on Android want to enter the user's phone, they need to be packaged in the form of an Android installation package. Conversely, if it is not a legitimate Android installation package, it will not be installed on the user's mobile phone, and will not harm the user. Based on this, the anti-virus engine can focus on the scan of the Android installation package, which greatly improves the efficiency of scanning.

Secondly, the present application extracts the specified feature from the Android installation package for detection, such as the package name, version number, digital signature, information of the Android component receiver, service, activity, etc. as specified features, these specified features for detection Most representative, so compared with the traditional anti-virus engine transplanted from the PC, this application accurately grasps several key features of the application under the Android platform, which makes the scanning speed fast and the accuracy of killing and killing.

Again, the present application combines client detection with server detection to not only perform security detection on the Android application locally, but also upload the extracted features to the server for detection. Since the security identification library set by the server is always updated, no matter which client or manual identifies a new or variant virus, Trojan, etc., it will be updated to the library immediately, so the features in the library are larger and more complete. The features that are not detected locally by the client can be detected, so the ability to recognize variants of various malware is greatly enhanced.

Again, the tests performed in this application provide four levels of security, security, caution, and trojan, not only to detect viruses, Trojans, and other malware, but also to apply normal applications, safe and popular applications, and although normal However, all applications with some problems are detected. Therefore, the detection of the Android application library of the present application is not limited to the traditional virus detection, but can provide users with more prompts such as security, danger, caution and the like.

Finally, in the application of the security detection of the extracted features, the method of combining and querying various features is used to further improve the detection efficiency and the accuracy of the detection.

Of course, implementing any of the products of the present application does not necessarily require all of the advantages described above to be achieved at the same time.

The above description is only an overview of the technical solutions of the present invention, and the technical means of the present invention can be more clearly understood, and can be implemented in accordance with the contents of the specification, and the above and other objects, features and advantages of the present invention can be more clearly understood. Specific embodiments of the invention are set forth below.

DRAWINGS

Various other advantages and benefits will become apparent to those of ordinary skill in the art. The drawings are only for the purpose of illustrating the preferred embodiments and are not to be construed as limiting. Throughout the drawings, the same reference numerals are used to refer to the same parts. In the drawing:

1 is an architectural design diagram of an Android system in an embodiment of the present application;

2 is a flowchart of a security detection method of an Android application library according to an embodiment of the present application;

3 is a flowchart of a method for detecting security of an Android application according to another embodiment of the present application;

4 is a flowchart of a method for detecting security of an Android application according to another embodiment of the present application;

5 is a flow chart of security detection on the server side of the Android application library according to another embodiment of the present application; FIG. 6 is a flowchart of searching in the security identification library according to the embodiment of the present application;

7 is a flowchart of performing a search in a security identification library according to another embodiment of the present application;

FIG. 8 is a structural diagram of a security detection system of a client-side application to the Android application library according to an embodiment of the present application; FIG. 9 is a diagram of a client-side application to an Android application according to another embodiment of the present application; FIG. 10 is a structural diagram of a security detection system of a client-side application to the Android application library according to another embodiment of the present invention; FIG. 11 is a structural diagram of the embodiment of the present application. FIG. 12 is a structural diagram of a security detection system set in a server to the Android application library according to another embodiment of the present application; FIG. 12 is a structural diagram of a security detection system installed in a server application library of the Android application library according to another embodiment of the present application; 13 schematically shows a block diagram of a server for performing the method according to the invention;

Fig. 14 schematically shows a storage unit for holding or carrying program code implementing the method according to the invention. FIG. 15 is a view schematically showing an architectural design of an Android system according to an embodiment of the present invention; FIG.

16 is a flow chart schematically showing a security detection method of an Android application library according to an embodiment of the present invention; FIG. 17 is a flow chart schematically showing a search in a security identification library according to an embodiment of the present invention;

FIG. 18 is a flow chart schematically showing the search in the security identification library according to another embodiment of the present invention; FIG. 19 is a view schematically showing the security detection system of the Android application according to an embodiment of the present invention; Structure diagram Figure 20 is a schematic block diagram showing the structure of a detection module in a security detection system in accordance with one embodiment of the present invention; Figure 21 is a block diagram schematically showing a server for performing the method according to the present invention;

Fig. 22 schematically shows a storage unit for holding or carrying program code implementing the method according to the invention. Specific embodiment

The invention is further described below in conjunction with the drawings and specific embodiments.

Analysis of various anti-virus engines in the prior art, because the anti-virus engine transplanted from the PC is mainly designed for the characteristics of the PC system, and the PC system has the same characteristics and different characteristics as the Android system, but The prior art does not have a deep understanding of the characteristics of the Android system itself, so it is not completely suitable for the antivirus of the Android system, and there is a problem of slow scanning speed and false alarm rate s.

Based on this, this application combines the characteristics of the Android system itself, and proposes an anti-virus method designed specifically for the characteristics of the Android system. The following describes the design ideas.

On the Android system, an app that can be installed and run needs to be packaged into the APK file format of the Android system. The APK is an abbreviation of Android application package file, referred to as the APK file, which is the Android installation package, and can also be understood as the application software installed on the Android terminal. The APK file is actually a ZIP file format, but the suffix name is modified to

Table 1

The Android installation package (APK file) is generally downloaded and installed on the mobile phone through the Android application market. It can also be installed from the PC via a data cable interface such as a USB data cable or wireless data transmission. Viruses, Trojans, and other malware on Android that want to enter the user's phone must also be packaged in the form of an APK. Conversely, if it is not a legitimate APK file, it cannot be installed on the user's mobile phone, and it will not harm the user. Based on this, the anti-virus engine can focus on the scanning of the APK file, which greatly improves the scanning efficiency.

Then, what information in the Android installation package (APK file) can be used as the focus of the scan, and this application is analyzed. The details are as follows:

1) Package name

The Android operating system manages each installed APK through the APK package name. The "package name" is derived from the Java package concept. According to the Java package naming style, for example, the package name of an Android installation package is com.qihoo360.mobilesafe. The Android system requires each application to declare a unique package name. . If the package name of the APK to be installed is duplicated with the package name of an existing application on the current phone, the Android system will refuse the installation. Malware on the Android platform also needs to declare a package name, so the package name can be an important feature for identifying malware.

2) Digital signature

For security purposes, the Android system requires that each APK be digitally signed. When installing the APK file, the Android system will check whether the digital signature of each file in the APK is consistent with its pre-set digital signature. If it is inconsistent, or there is no digital signature, the file is considered to have been modified by the tomb, and the installation and operation of the APK is rejected. . Malware on the Android platform is no exception, so the digital signature of the APK file can also be used as an important feature to identify malware.

3) Entry information for each module listed in AndroidManifestxml

AndroidManifest.xml is a required global description file for each APK file, which lists the Android installation package. The entry information for each module used. In the Android system, only the modules listed in the AndroidManifestxml can be called by the system. Trojans on the Android platform tend to pretend to be normal applications or games to trick users into installing. Many Trojans are parasitic in a normal application or game. When the user runs it, it looks like the original software or game. But the Trojan module that is parasitic in it is activated at the right time, infecting the user's cell phone. And because the Android system requires all modules to be listed in the AndroidManifest.xml, this is an important clue to the search for parasitic Trojans. therefore,

The information of each module listed in AndroidManifestxml is also an important feature for identifying malware.

4) Dex files and ELF files

In the architecture design of the Android system, the relationship between the Android application and the entire system platform is shown in Figure 1. Android applications are usually developed in Java language t. After compiling with Android development tools, they become binary bytecodes. These bytecodes are packaged into classes.dex files, and the Dalvik virtual machine from the Android platform. To explain the implementation. In order to be able to call Android system functions, Android system provides a set of running environment (Android Framework), Android application calling system. Each function is realized by tuning the Android Framework library.

On the other hand, the Android system also supports applications running directly through JNI or native executable. At this point, the application executes the binary machine code running directly on the CPU. It does not need to be interpreted by the virtual twister. It can directly call the Android library such as libc, WebKit, SQLite, OpenGL ES, etc. to call the system functions. If the Android application is to run via JNI or native executable, you will need to compile the code to be executed into the ELF file format. ELF is an abbreviation of Executable and Linkable Format, which is a file format of executable programs and shared libraries in the Android/Linux operating system.

Malware on Android must follow the above architecture specifications in order to run on the Android system. Therefore, in the process of identifying malware, corresponding features can be extracted from Dex files (i.e., bytecode files) and ELF files, respectively.

In addition, in addition to the above list, the version number of the Android installation package and the MD5 value of each file in the Android installation package directory can also be used as important features for identifying malware. The above malware includes viruses, trojans and other malware.

The embodiments of the present application combine the above important features, and propose a security detection method for the Android application, which can scan and identify the above features of the APK to finally identify various malware (including viruses, Trojans and other malicious software) . Moreover, in the security detection method of the embodiment of the present application, the recognition result is not limited thereto, and the normal application, the application that is safe and popular, and the application that is normal but has some problems may be detected to prompt the user.

The security detection method provided by the embodiment of the present application combines client detection with server detection, and can be flexibly selected under various application scenarios.

In general, the embodiment of the present application provides two detection methods: one is to directly upload the features extracted by the client to the server for detection; the other is to detect locally before uploading the server for detection.

The various detection methods provided by the present application are described in detail below by way of examples.

Referring to FIG. 2, a flowchart of a security detection method for an Android application according to an embodiment of the present application is shown. In this embodiment, the client (such as a mobile phone) directly extracts features from the local Android installation package and uploads them to the server for detection. The client's processing is as follows:

Step 201: The client scans the Android installation package, and extracts the specified feature information from the Android installation package. The specified feature information refers to the important features listed above, such as a package name, a version number, and a digital signature. ,

The entry information of each module listed in AndroidManifestxml, the Dex file and the ELF file, and the MD5 value of each file in the Android installation package directory. These specified feature information are the most representative for safety detection and are therefore key features for detection.

The entry information of each module listed in AndroidManifest.xml includes the features in the Android component. The four components of Android development are: Activity, for performance function; Service, background running service, no interface rendering; Broadcast receiver (Broadcas tReceiver), for receiving broadcast; Content provider ( Content Provider ) , which supports storing and reading data in multiple applications, equivalent to a database.

Therefore, the specified feature information extracted from the Android installation package may include:

The package name of the Android installation package, and/or, version number, and/or, digital signature, and/or characteristics of the Android component receiver, and/or features of the Android component service, and/or characteristics of the Android component activity , and/or instructions or strings in the executable, and/or MD5 values for each file in the Android installation package directory;

It should be noted that the “and/or” means that any one of the feature information can be separately extracted from the Android installation package for use as a security detection, and a combination of multiple feature information can also be extracted for security detection. Of course, the effect of extracting multiple features at the same time is significantly better than that of the single feature, which will be described in detail in the embodiment shown in FIG. 3 later, so it is omitted here.

The executable file includes a Dex file, and/or an ELF file; the Dex file includes a classes.dex file, a file with a .jar file, and a file in a Dex format.

Specifically, in a preferred implementation of the application, the executable file includes a Dex file, and the Dex file is mainly The classes.dex file in the APK, Dalvik Executable (Dalvik virtual machine executable). It is well known that Dalvik is a Java virtual machine for the Android platform. The Dalvik VM (Dalvik VM) is one of the core components of the Android mobile device platform. It can support the running of Java applications that have been converted to .dex (Dalvik Executable) format. The dex format is a compression format designed for Dalvik, suitable for systems with limited memory and processor speed. Dalvik is optimized to allow multiple instances of virtual machines to run simultaneously in limited memory, and each Dalvik application is executed as a separate Linux process. A separate process prevents all programs from being closed when the virtual machine crashes.

More preferably, the executable file may further include a file with a .jar extension. The JAR file in the Android installation package is actually a Dex file, but its extension is .jar. For files other than classes.dex in the APK, you can decide whether to scan it by judging it as a Dex file.

In practical applications, the Dex file may also include other files in the Dex format.

In addition, the MD5 value of each file in the above Android installation package directory may be the MD5 value of the digital signature, or the MD5 value of each file in the res\, assets\, lib\ directory in Table 1.

Based on the specified features listed above, the specified feature information can be extracted from the Android installation package in the following manner. Referring to Table 1, it can be seen that:

Extract one or more of the following information from the AndroidManifest.xml file of the Android installation package: package name, version number, characteristics of the Android component receiver, characteristics of the Android component service, characteristics of the Android component activity; and / or,

Extracting the digital signature of the Android installation package from the .RSA file in the META-INF\ directory of the Android installation package; and/or,

Extracting executable instructions from the classes.dex file of the Android installation package; and/or,

Extract the instruction or string of the ELF file from the lib\ directory of the Android installation package.

The understanding of the "and/or" is the same as above, that is, any one of the feature information may be separately extracted from the Android installation package for use as a security detection, or a plurality of feature information may be extracted for use as a security detection. .

The specific feature extraction method will be explained in the following description.

Step 202: The client uploads the specified feature information to the server, and searches for a feature record matching the specified single feature information or a combination thereof in the security identification library preset by the server; wherein, the server preset security Identifying the security level corresponding to the signature record and the feature record in the library, and each feature record includes a combination of single feature information or feature information;

Step 203: The client receives the security detection result of the Android installation package returned by the server, and displays the security level corresponding to the feature record found by the server in the security detection result.

In the above process, the identification of features is mainly done by the server. The description of the server is as follows:

A plurality of feature records are preset in the security identification library preset by the server, wherein the single feature information may constitute a feature record, and the combination of the plurality of feature information may also constitute a feature record. For example, a security identification library presets dozens of feature records, wherein the first feature record lists the Android installation package name of a certain virus, and the second feature record lists a normal application. The Android installation package version number and the MD5 value of the digital signature, the third feature record lists the Android installation package name and its receiver feature of a normal application, and the fourth feature record lists a certain Trojan. Android installation package name, version number and specific strings in its ELF file, and so on.

In summary, the server-preset security identification library collects feature information identifying various malware such as viruses and Trojans, and also collects feature information for identifying normal applications, unlike many databases that are only used to identify malware.

Therefore, the feature information collected in the security identifier library preset by the server may include the following:

Various sample Android package packages, and / or, version number, and / or, digital signature, and / or, Android component receiver features, : ί. / or, Android component service features, : ί. / or, the characteristics of the Android component activity, or the instructions or strings in the executable, and / or MD5 values of the files in the Android installation package directory;

As described above, the "and/or" means that any one of the feature information can be separately extracted from the Android installation package of various samples for use as a security detection, or a combination of a plurality of feature information can be extracted. Security testing.

The executable file includes a Dex file, and/or an ELF file; the Dex file includes a classes.dex file, a file with a .jar file, and a file in a Dex format;

The sample Android installation package includes an Android installation package under various security levels.

The embodiments of the present application enumerate four security levels: security, criticality, caution, and Trojan. Among them, various security levels are defined as follows: Security: The application is a normal application, without any behavior that threatens the security of the user's mobile phone;

Critical: The application has a security trend. It is possible that the application itself is malware. It is also possible that the application is a normal software released by the company, but because of security vulnerabilities, the privacy of the user and the security of the mobile phone are threatened. Caution: The app is a normal app, but there are some problems, such as users being accidentally charged, or unfriendly ads being complained, etc. When such apps are found, users are prompted to use and inform The possible behavior of the application, but it is up to the user to decide whether to clear the application;

Trojan: This application is a virus, trojan or other malware. Here, for the sake of simplicity, it is called Trojan, but it does not mean that the application is only a horse.

Therefore, when the server is set up with the security identification library, the Android installation package under the four levels of security, crisis, caution and Trojan can be used as a sample Android installation package, so that the feature records obtained by the single feature or combination of features in the sample can be Corresponding to a security level and related behavior and description.

For example, the security levels corresponding to the first feature record and the fourth feature record are all Trojan levels, and the security levels corresponding to the second feature record and the third feature record are security levels.

Of course, the server preset security identification library can also set a feature record, which lists the version number of the Android installation package of the Trojan and the MD5 value of the digital signature, although the feature combination used in the feature record and the second item mentioned above The feature record is the same, both use the combination of the version number and the digital signature MD5 value, but the corresponding security level of the feature record is "trojan".

Therefore, the security level does not correspond to a particular feature or combination of features, but rather to a specific feature or combination of features. Therefore, as described above, for the same feature or combination of features, the specific values are different, and the corresponding security levels are also different.

Moreover, the above four levels of security, criticality, caution, and Trojan are only exemplified. According to the actual application, other security levels may be classified and defined. The scope of protection of the present application is not limited thereto.

Then, the feature record matching the specified single feature information or a combination thereof is searched in the security identifier library preset by the server, and the security level corresponding to the found feature record is packaged in the security detection result of the Android installation package. The steps can be understood as:

Finding the feature record in the server-preset security identification library, if the extracted specified single feature matches the first feature record, it can be determined that the current Android installation package is a Trojan level; if the extracted specified features are combined If the second feature record or the third feature record is matched, it may be determined that the current Android installation package is a security level; if the extracted specified features are combined and matched with the fourth feature record, the current The Android installation package is also a Trojan level.

Therefore, the security detection result of an Android installation package may be information indicating security level, security, caution, or Trojan, and the security detection result may also include a description of the behavior related to the security level. At least one prompt information such as software description, time stamp, etc., such as the prompt information corresponding to the "cautious" level may be "may cause deduction, whether to delete the application."

More specifically, in a preferred embodiment, the security detection result may include security level, behavior description information, software description information, and timestamp information. among them:

Security Level: It can be represented by a 32-bit integer, which can represent four security levels: security, criticality, caution, or Trojan. Each security level is defined as described above.

Behavior description information: It can also be represented by a 32-bit (0~31) integer, which can represent the software behavior description of each security level. Among them, one can select one flag, the flag is 0 to indicate no malicious behavior, if there is malicious behavior, you can define: the first one stands for "background secret download", the second one stands for "send private text message", the third Bits represent "package advertising", and so on. That is, each person can individually represent a description of the behavior of a piece of software.

For example, for an Android app detected as "trojan level", if the malicious behavior = 3, the translation into binary is 11, the first bit = 1 , the second bit = 1 , the malicious behavior is: at the same time with the background secret download And the act of sending text messages privately.

For another example, for the Android application library detected as "careful level", if the behavior description = 4, the translation into binary is 100, the first bit = 0, the second bit = 0, the second bit = 1 , the behavior indicated Yes: The package advertisement. Since this advertisement may be allowed by the user or may not be allowed by the user, the user will be prompted to use it cautiously, and it is up to the user to decide whether to clear it.

Software description information: Usually expressed as a string, is a description of the Android application, such as publisher, release time and other information. Timestamp information: Indicates when the feature information of the Android application (such as normal features, Trojan features, etc.) is stored in the library. In the actual application, when the client user interface displays the security detection result, the security level information may be popped first. If the user clicks the "View Details" button, the user is displayed with the behavior description information, the software description information, and the timestamp information.

After the server completes the feature recognition, the final security detection result is returned to the corresponding client, and the client displays in the client user interface to remind the user.

In summary, the security detection method for the Android application provided by the foregoing embodiment of FIG. 2 mainly performs feature recognition on the server, and has the following features:

First of all, this method does not scan all the files in the Android system, but by scanning the Android installation package. Line security testing. This kind of focus on the killing of the Android installation package scan, can greatly improve the efficiency of scanning. Secondly, the method extracts the specified features from the Android installation package for detection, such as the package name, version number, digital signature, etc. as specified features, and these specified features are most representative for detection, and thus are transplanted from the PC. Compared with the traditional anti-virus engine, this method can accurately grasp several key features of the application under the Android platform, which makes the scanning speed fast and the accuracy of killing and killing.

Again, the method uploads the extracted features to the server for detection. Since the security identification library set by the server is always updated, no matter which client or manual identifies new viruses, Trojans, etc., it will be updated to the library immediately, so the features in the library are larger and more comprehensive, and can be detected. Features that are not detected locally by the client, and thus the ability to recognize variants of various malware is greatly enhanced.

Again, the method performs detection to provide four levels of security, security, caution, and trojan, not only to detect viruses, Trojans, and other malware, but also to apply normal applications, safe and popular applications, and although normal However, all applications with some problems are detected. Therefore, the detection of the Android application in the present application is not limited to the traditional virus detection, but can provide users with more prompts such as security, danger, caution and the like.

Based on the above, the following describes the case where the local detection is prioritized and then the server detects it. At this time, the embodiment of the present application provides two cases: one is that after the local priority detection is completed, the detection result is uploaded to the server for re-detection, and then the two detection results are combined, as shown in the embodiment of FIG. The other is local priority detection. If all the extracted features are detected, there is no need to upload the server for re-detection. However, if there are unrecognized features in the local, then the server is detected again, and finally the two detection results are merged. Specifically, it is as described in the embodiment of FIG. 4.

The details are explained below.

Referring to FIG. 3, a flowchart of a security detection method for an Android application according to another embodiment of the present application is shown. Step 301: The client scans the Android installation package, and extracts the specified feature information from the Android installation package. Step 302: The client searches for the specified single feature information or a combination thereof in the locally preset security identification library. a matching feature record; wherein, the locally preset security identification library includes a security level corresponding to the feature record and the feature record, and each feature record includes a combination of single feature information or feature information;

Step 303: The client classifies the security level corresponding to the locally found feature record in the local security detection result of the Android installation package.

Step 304: The client uploads the specified feature information to the server, and searches for a feature record matching the specified single feature information or a combination thereof in the security identification library preset by the server; wherein, the server preset security Identifying the security level corresponding to the signature record and the feature record in the library, and each feature record includes a combination of single feature information or feature information; wherein, the client usually uploads all the specified features to the server for re-detection;

Step 305: The client receives a security detection result that is returned by the server to the Android installation package, and the security detection result includes a security level corresponding to the feature record found by the server;

Step 306: The client combines the security detection result returned by the server with the local security detection result, and displays the result in the client user interface after the combination.

The merging refers to: comparing the security detection result returned by the server with the local security detection result one by one, and if the two are the same, merging into one result; if the two are different, the security detection result of the server is taken as the standard.

It should be noted that the security identification library preset by the client is similar to the security identification library preset by the server. Therefore, the description of the locally preset security identification library may refer to the description of the security identification library preset by the server.

However, the difference between the two is that the security identification library set by the server is always updated, and no matter which client or manually identifies new or variant viruses, Trojans, etc., it will be updated to the library immediately, so the library The features are larger and more comprehensive, and can detect features that are not detected locally by the client, so the ability to recognize variants of various malware is greatly enhanced. This is also the main reason for uploading to the server for detection after the local detection, which can avoid the local detection of the client.

Moreover, it should be noted that, in the foregoing process, steps 302 and 303 may be performed in steps 304 and 305, or may be performed in parallel at the same time.

Referring to FIG. 4, a flow chart of a security detection method for an Android application according to another embodiment of the present application is shown. Step 41: The client scans the Android installation package, and extracts the specified feature information from the Android installation package. Step 42: The client searches for the specified single feature information or a combination thereof in the locally preset security identification library. a matching feature record; wherein, the locally preset security identification library includes a security level corresponding to the feature record and the feature record, and each feature record includes a combination of single feature information or feature information;

Wherein, the client may find a feature record that matches all the specified single feature information or a combination thereof, or may only find a feature record that matches a part of the specified single feature information or a combination thereof; Step 43: The client parses the security level corresponding to the locally found feature record in the local security detection result of the Android installation package.

The local security detection result includes a security level corresponding to all the feature records that can be found; Step 441, if the client finds all the specified single feature information or a combination thereof in the locally preset security identification database. The matching feature record cancels uploading the specified feature information to the server, and displays the local security detection result on the client user interface, and the process is terminated.

In other words, if all the specified features, whether in the form of a single feature or in a combined form, can find a matching feature record in the client's local security identification library, then the process will be terminated. Uploading to the server for detecting; Step 442, if the client finds the feature record matching the partially specified single feature information or the combination thereof in the locally preset security identification library, uploading all or the remaining part of the specified feature information Go to the server search, where the specified feature information of the remaining part is feature information that does not find the matching feature record locally;

In other words, if the client has a single feature or combination of features that cannot be recognized after searching in the local security identification database, that is, the security of the Android installation package cannot be finally confirmed locally, and then the server needs to be uploaded to the server for detection. ; When uploading, you can upload the remaining features (that is, unrecognized features), or upload all the specified features, so that the locally identified features can be reviewed on the server;

Specifically, after the specified feature is uploaded, searching for a feature record matching the specified single feature information or a combination thereof in the security identifier library preset by the server; wherein, the server presets the security identification database and the package feature record The security level corresponding to the feature record, and each feature record includes a single feature information or a combination of feature information;

Step 452: The client receives a security detection result that is returned by the server to the Android installation package, and the security detection result includes a security level corresponding to the feature record found by the server;

Step 462: The client combines the security detection result returned by the server with the local security detection result, and displays the result in the client user interface after the combination.

Based on the foregoing embodiments of FIG. 2, FIG. 3 and FIG. 4, the application scenarios of the foregoing embodiments are described below through another embodiment provided by the present application. details as follows:

Before the client looks in the locally preset security identification library, it can also include the following processing steps:

According to the preset configuration information, it is determined that the specified feature information is directly uploaded to the server for searching, or directly in the local search, or prompting the user to select whether to search locally or upload to the server for searching.

The preset configuration information may include the following:

1) when the configuration information indicates that the local preset security identification library is not allowed to be provided, determining to directly upload the specified feature information to the server for searching;

Depending on the needs of the actual application, there may be cases where the security identification library is not allowed to be set on the client. At this time, after the client extracts the feature information, it can directly upload it to the server for detection.

2) when the configuration information indicates that the local search is prioritized, it is determined to directly search locally;

In this case, after the client extracts the feature information, it will automatically find it locally. This is a common mode used in practical applications, because the client usually downloads the security identification library from the server or from the PC, so it is better to use the local security identification library for searching.

Further, the client can also set two situations in the configuration information:

First, as shown in the embodiment of FIG. 3, after the local search is completed, all upload servers are reviewed again;

Second, as shown in the embodiment of FIG. 4, after the local search is completed, it is determined according to the local search result whether the server search needs to be uploaded.

In practice, there may be hundreds of software applications installed in a mobile phone. However, due to the limited local capacity of the client, only about 20 applications can be identified. For the remaining 80 software applications, the software application is not recognized. The configuration at this time may be that after the local search is completed, all the upload servers are reviewed again, or may be configured to continue searching for the feature upload server that is not recognized locally. In actual situations, uploading all features for review is a relatively simple way to ensure the accuracy of identification.

3) When the configuration information indicates that the user is selected by priority, it is determined to prompt the user to select whether to search locally or upload to the server for searching.

In this case, the user needs to participate in the selection. After the client extracts the feature information, the client displays a prompt message on the client user interface, prompting the user to select whether to search locally or upload to the server for searching. Generally, if the user's mobile phone has monthly Internet traffic, you can choose to upload the server for searching, because the accuracy of the search is more S; if the Internet traffic is used up, and you don't want to use more traffic, you can choose to search only locally, or Look first locally, if the local search results are not complete, The remaining unrecognized features are uploaded to the server for lookup.

In short, in many scenarios in practical applications, any combination of any one or several of the above implementations can be flexibly selected, and this application is not enumerated.

Regardless of which of the above applications, the security detection process uploaded to the server can refer to the process shown in Figure 5 below. Referring to FIG. 5, a flow chart of security detection on the server side of the Android application is shown in another embodiment of the present application.

Regardless of whether the client locally detects the extracted features, as long as the client uploads the feature to the server, the server will detect it according to the following process:

Step 501: The server receives the specified feature information uploaded by the client, where the specified feature information is extracted by the client from the Android installation package.

Step 502: Search for a feature record that matches a specified single feature information or a combination thereof in a security identifier library preset by the server. The security record corresponding to the package and the feature record in the security identification library preset by the server Level, a combination of individual feature information or feature information in each feature record;

Step 503: The server sends the security level package corresponding to the found feature record to the corresponding client in the security detection result of the Android installation package.

Preferably, when the matching feature record is not found in the security identifier library preset by the server, the following steps may also be included:

Identifying the specified feature information, and determining a security level corresponding to the feature record and the feature record matching the specified single feature information or a combination thereof according to the recognition result;

Updating the security level corresponding to the feature record and the feature record to the security identification library preset by the server.

Wherein, the identification process may involve manual identification to help accurately locate the recognition result. For example, the current virus, Trojan, and other malware are industrialized, and even commercial companies are involved. They make and distribute malware to form a formalized, streamlined chain. One of the links is "antivirus software kill test." ".

Simply put, these professional producers, before distributing their own malware, will use the anti-virus software of several anti-virus software companies to update to the latest virus database and scan it again. If they are reported as viruses by anti-virus software, then they will be scanned. I will try to modify my own malware until the anti-virus software can't be scanned.

In theory, if only the one-to-one situation is considered, no matter what kind of killing logic is designed, the opponent can finally analyze the law and find the way to bypass. Generally, for an application, if the local killing engine exhausts all the feature records and there is still no matching record, then the scan is over.

The advantage of the server in the embodiment of the present application is that: all the feature records known to be exhaustive are not matched, then the feature information of the application is archived and submitted to the testing center for analysis and processing. After the detection center analyzes by manual intervention, it is security or malware, and the server's security identification database is updated, so that the next time the server kills the same application feature, the result can be returned immediately. Therefore, even if the producer of malware temporarily finds a way to bypass the current killing and killing, it passes the test of "free killing", but after the malware is actually released to the market, it will soon be detected and identified by the server. .

In summary, in the foregoing embodiments, the security detection of the Android application can be performed locally on the client or on the server, and the local detection and the server detection can be combined. Regardless of the detection mode, it can be implemented by the detailed process below.

In the process of querying the security identification database, the embodiment of the present application provides a method for judging the query, and the query adopts a combination query method for each feature, which can further improve the detection efficiency and the detection accuracy. The security identification library may be a security identification library set locally by the client, or may be a security identification library set by the server.

The basic idea of the query is to perform a combination query on the selected key components of the extracted Android installation package, and when the matching feature record is found, the security information corresponding to the feature record is returned. The security information may include a description of the security level and prompt information corresponding to the security level.

The query process will be specifically illustrated by way of example in conjunction with the flow shown in FIG. 6.

Referring to FIG. 6, a flowchart of performing a search in a security identification library according to an embodiment of the present application is shown.

First, assume that three kinds of feature information are used in the security identification library, namely feature 1, feature two and feature three. The "feature one", "feature two" and "feature three" do not specifically refer to a certain feature, but can be set according to actual conditions. Of course, the features used in the actual situation are not limited to three types, here Used as an example only.

Based on the three characteristics, the security identification library is provided with feature records composed of a single feature and a combination of features, and the feature records include: Characteristic records of the first feature, the second feature, and the third feature;

Feature record of the package 1 and feature 2;

Feature record of the first feature and feature three;

The feature record of the feature 1 of the package means that only the feature 1 is included;

The feature record of the second feature of the package is that only the feature 2 is included;

The feature record of the package feature 3 refers to only the feature III.

Since the feature record of the second feature and the feature three cannot be obviously detected in practical applications, the feature record is deleted here. Of course, some of the feature records given above may also be omitted depending on the needs of the actual application.

Based on the security identification library set as described above, the process of querying the security identification library is explained below through steps 301 to 306. details as follows:

Step 601: Determine whether the feature record of the package feature 1, the feature 2, and the feature 3 are found;

If found, return a result, the result includes security level information corresponding to the feature record; if not found, continue to step 602;

Step 602: Determine whether the feature record of the package feature 1 and the feature 2 is found.

If found, return a result, the result contains the security level information corresponding to the feature record; if not found, continue to step 603;

Step 603, determining whether the feature record of the package feature 1 and the feature 3 is found;

If found, return a result, the result includes security level information corresponding to the feature record; if not found, continue to step 604;

Step 604, determining whether the feature record of the package feature 1 is found;

If found, return a result, the result includes security level information corresponding to the feature record; if not found, continue to step 605;

Step 605: Determine whether the feature record of the second feature is found.

If found, return a result, the result includes security level information corresponding to the feature record; if not found, continue to step 606;

Step 606: Determine whether the feature record of the packet feature 3 is found.

If found, a result is returned, the result wrapping the security level information corresponding to the feature record; if not found, scanning the tie.

In the above process, it should be noted that the matching feature record is not necessarily a record of malware, but also a record of normal software. For example, the MD5 eigenvalue of an APK's digital signature for a security product is always

Dc6dbd6e49682a57a8b82889043b93a8, suppose the "feature one" in the above figure refers to the MD5 of the digital signature of the APK, then when the feature record of the MD5 value = dc6dbd6e49682a57a8b82889043b93a8 is retrieved, the corresponding 1SJ result of the feature record should be "safe", so it is not necessary Perform the following steps to identify the software directly as safe.

The above process is illustrated by a specific example.

Suppose there are 3 apps on a mobile phone (the actual phone has at least dozens of apps, which is simplified for convenience):

1. The dialing keyboard provided in the mobile phone system;

2. A mobile phone security product;

3. Trojan Pico.

First, the feature information of the three applications is extracted separately, as follows:

1. The dialing keyboard that comes with the mobile phone system

Feature one: APK package name, packageName = com. android. phone;

Feature 2: APK version number, versionCode^8;

Feature 3: MD5 value of APK digital signature,

sigHash= 8ddb342f2da5408402d7568af21 e29f9;

2. A mobile phone security product

Feature one: APK package name, ackageName = com.qihoo360.mobilesafe;

Feature 2: APK version number, versionCode^l37;

Feature 3: MD5 value of APK digital signature,

sigHash= dc6dbd6e49682a57a8b82889043b93a8;

3. Trojan Pico

Feature one: APK package name, ackageName = com.svox.pico; Feature 2: APK version number, versionCode^l;

Feature 3: MD5 value of APK digital signature,

sigHash= e89bl 58e4bcf988ebd09eb83f5378e87.

Assume that the following feature records are in the security identification library, and the feature records are saved in the form of data tables:

Table 1: Feature 1 + Feature 2 + Feature 3

Key com.svox.pico— 1—e89bl58e4bcf988ebd09eb83f5378e87; value- - Trojan; Table 2: Feature 1 + Feature 2 Table 3: Feature 1 + Feature 3

Key- com. qihoo360.mobilesafe_ dc6dbd6e49682a57a8b82889043b93a8;

Value- - security;

Table 4: Feature 1

Table 5: Feature 2 Table 6: Feature 3

Key 8ddb342f2da5408402d7568af21 e29f9;

Value is safe.

It should be noted that in Tables 1, 3, and 6 which are not empty, each table may contain multiple feature records, not just the above enumerated cases. For example, in Table 6, it is also possible to include the feature record of the key of the feature three and the value of other values.

When querying, the characteristics of the three applications are respectively queried in the security identification library according to the order of Table 1->Table 2->...., and the following query results are obtained:

For application 1: The dialing keyboard that comes with the phone system

Table 1 is not queried

Table 2 is not queried

Table 3 is not queried

Table 4 is not queried

Table 5 is not queried

Table 6 is queried, and the result is "safe" query to the east, return the result.

For application 2: A mobile phone security product ^

Table 1: No query

Table 2: No query

Table 3: The query is completed, and the result is "safe" query tie, return results.

For application 3: Trojan Pico

Table 1: The query is made, the result is "trojan", the query is east, and the result is returned.

Suppose there is an application, neither Table 1 ~ Table 6 is queried: Then the result is "unknown".

If value is another value, such as "critical" or "cautious", then and so on.

The flow shown in Figure 6 above is only an example. It is used to make the query process convenient for the technicians in the city through a specific example. However, the above example can summarize the essential process of the query, as shown in Figure 7.

Referring to Figure 7, there is shown a flow chart for performing a lookup in a secure identification library as described in another embodiment of the present application.

Step 701: Combine the specified feature information to obtain at least two feature combinations of the two components. The specified feature information refers to the specified feature information extracted from the Android installation package to be detected.

The combination refers to various possible combinations. For example, the above-mentioned feature 1, feature 2, feature three are extracted from a certain application, and the combination of the three features and the two-two combination can obtain the feature of the package. Second, the feature combination of feature three, the characteristics of the package one, the feature combination of the feature two, the feature of the package one, the feature combination of the feature three, and the feature combination of the second feature, the feature three, a total of four feature combinations. However, in the above example, the feature combination of the second feature and the third feature is not used according to the needs of the actual application.

Step 702, starting from the feature combination of the most features of the package, searching for the feature record matching the feature combination in the security identification library, if not found, proceeding to step 703;

For example, starting from the combination of features of the first feature, the second feature, and the feature three, the application 1 and the application 2 are performed. If no matching feature records are found in the security identification database, proceed to step 703; but for application 3, if the matching feature records are queried in Table 1, the corresponding results are directly returned.

Step 703, reducing the number of features in the feature combination one by one, and reducing the feature combination of the feature number, and continuing to search for the feature record matching the feature combination in the security identification library, if not found, Continue to step 704;

If found, the corresponding result is returned.

For example, for a feature combination that combines up to three features, and a feature combination that reduces one feature combines two features, then the feature combinations of the two features are searched.

In the search process, the combination of multiple features with the same number of features can be searched in a predetermined order. For example, in the flow shown in FIG. 6, there are a total of three feature combinations of the two features, and one feature combination that is not used is removed. The search order of the remaining two feature combinations is: The feature combination of the two is searched, and then the feature combination of the first feature and the third feature is searched.

It should be noted that the preset sequence needs to be set according to the feature definition and the feature combination in the actual situation, and is not limited to a certain setting situation. In practice, there may be many settings, not here - enumeration.

Step 704: Search for a feature record matching the single feature information in the security identification library.

During the search process, the single feature information can also be searched in a predetermined order.

For example, in the flow shown in FIG. 6, the feature record of the package feature 1 is first searched, then the feature record of the package feature 2 is searched, and finally the feature record of the package feature 3 is found.

As described above, the predetermined sequence needs to be set according to the feature definition and the feature combination in the actual situation, and is not limited to a certain setting. In practice, there may be many settings, not here - enumeration.

The sequence of such searches shown in Figure 7 has the following characteristics:

First, the search order is set in the order of detection accuracy from s to low, which can avoid malware miss detection and misdetection to the greatest extent;

If the combination of features of the most features of the package matches a feature record of the most features of the security identification library, the result of the search is accurate;

Conversely, in the order from top to bottom of the process, as the search conditions are relaxed, the detection accuracy is gradually reduced.

Based on this, an Android application to be detected may match two feature records in the security identification library at the same time, but it will be detected when the detection precision is better than the search condition of S, so the process ensures the detection well. Accuracy.

Second, this search order can detect almost all Android applications;

In other words, according to this process, a Trojan can be detected, and a security software can also obtain a "safe" identification result by detecting.

Third, the definition order of feature one, feature two, ... affects the search order of the entire process;

After the definition of each feature is determined (such as "feature one" refers to the APK package name, "feature two" refers to the APK version number, etc.), the order of the search in the process of Figure 4 is also determined. The second is defined as the APK package name, and the "feature one" is defined as the APK version number. Then, in the flow of FIG. 4, "Find the package feature 1 and the feature record of the feature 3" is modified to "Find the package feature 2, feature 3" The feature record "; and, in the following process, the order of finding feature one and finding feature two are also interchanged, that is, first look for feature two, then find feature one, and finally find feature three.

In summary, it can be seen from the above points that when the security identification library is actually designed, the selected feature information is different, and the feature records combined by these features will also be greatly different, and the combination of features will also affect The sequential query order of feature records with the same number of features. The detection process thus designed may be varied, but all of the various possible processes are based on the process described above with respect to Figure 4 and are therefore within the scope of this application.

Based on the above, in order to make the skilled person understand the contents of the present application, the feature extraction process will be exemplified below.

The features extracted in this example include:

1) Android installation package name: ackageName

2) Android installation package version number: versionCode

3) Digitally signed MD5 of the Android installation package: signature[0]

4) Android component receiver

5) instructions in classes. dex

6) String in the ELF file

7) MD5 of each file in the assets, res, lib, etc.

8) Android component service, activity The following is an example of several malware to illustrate the meaning of the above features and the whole process of detection.

1. Extract the package name, version number, Android component receiver ^ service, activity characteristics from the AndroidManifest.xml file of the Android installation package;

According to the design requirements of the Android system, all applications, including Trojans, whose modules (such as receiver, service, activity, etc.) need to be declared by the Android system, need to declare the class name of their module in the AndroidManifest.xml file. In particular, many Trojans embed their own code modules into normal software. Obviously, the normal software code does not actively call the Trojan code module, so the Trojan wants to execute its own code. You must modify the AndroidManifest.xml file of the normal software, add your own class name, and thus expose your own trace, which can be used as a recognition feature.

Sample 1: Android. Geinimi

The Android.Geinimi Trojan is usually parasitic in normal Android applications. For example, in this sample, it is in an application called "Magic". Unzip the sample of the Android installation package, you can get the root directory

AndroidManifest.xml file. This file is in Android Binary XML (AXML) format and can be used.

The AXMLPrinter2 tool is decoded into a text XML format.

The result of decoding is as follows:

<inteni-fi!fer

<activiiy

; receiver android:name=3⁄4om,ger?imL^dSer iceRecei

Intent-fifter>

/receiver

^service a n dro id: enabl ed^^rue" androki:name="ccT g r3⁄4in ci fem,GoogteKeybo n a ndro id; lie be! ="G oogfe keyboard"

^activity a ctrokHheme="@a dr k±s3⁄4ife/The e.Bfecl<. oT3⁄4eBa android:{a el ^=< ^®stnngapp.. n ni "

androidname-tDrn.gein!imLc torn:.^

Int8nt-filter>

! Action android::na:me= drod.inie t.act n.阙 /

Category android:name=3⁄4nlro jnienicat3⁄4ory. LAUNCHER" I>

/inient-fiif.er>

<uses-permission

Android:name="com.andro?d. launcher, perm issfon. i STAL L..SHORTCUT ⁵ >

<uses-permission

Android:name= ^: drodp^' isskm,AGCESS...F E.. LOCATION" /

Uses-permission andr. Id:name=3⁄4ndr d,p ;rnfesk> ACCESS„LOCATiO r /> < manfest>

1) Where com.wbs in package="com.wbs" is the ackageName of the Android installation package, and "1" in android:versionCode="l" is the versionCode. 2) The characteristics of the receiver are extracted from the following paragraph:

Receiver android:name^"com.geinimi.AdServiceReceiver">

<intent-filter>

</inteot-filter>

</receiver>

The reason for this code is that when the Android system android. intent. action.BOOT_COMPLETED event occurs, a class named com.geinimi.AdServiceReceiver is called.

Write this feature below as:

Android.intent. action.BOOT— COMPLETED=comgeinimi.AdServiceReceiver.

3) The characteristics of the service are extracted from the following paragraph:

<service android: enabled- 'true" android:name^"com.geinimi. custom. GoogleKeyboard" middle slightly) /> The meaning of this code is that this APK application provides an Android service library, named

com.geinimi.custom.GoogleKeyboard.

Write this feature below as:

Service^comgeinimi. custom. GoogleKeyboard.

4) The characteristics of the activity are extracted from the following paragraph:

<activity android:theme^"@android:style Theme.Black.NoTitleBar"

Android:label- '@string/app_name" an droid:name^"com.geinimi. custom. Ad0000_00000006">

<intent-filter>

Category an droid:name^" android. intent. cat egory.LAUNCHER" />

</inteot-filter>

</activity>

The reason for this code is that when the user clicks the icon of "Magic" in the application list interface of the Android system, a class named com.geinimi.custom. Ad0000_00000006 is called.

Write this feature below as follows:

MAIN_LAUNCHER=com.geinimi. custom. Ad0000_00000006.

In addition, you can notice that in the previous XML, activit actually has two, in addition to the above, there is one, as follows:

<intent-filter>

Category an droid:name^" android. intent. cat egory.LAUNCHER" />

</inteot-filter>

</activity>

In fact, this is the main library entry for the real "magic sound" application. In order to parasitize the normal application, the AndroidGeinimi Trojan uses the method of modifying the host application's main library entry to point to itself, and then jumps back to the host application's main library entry after the Trojan is started. However, the detection method described in the embodiment of the present application does not initially analyze this, but first extracts and records features, and finally determines the judgment.

So this activity also extracts features, which are described below:

LAUNCHER=. MagicVoiceActivity

It should be noted that, for ease of understanding, the steps to extract features from AndroidManifest.xml "manually" are introduced. In practical applications, in order to improve the efficiency of S feature extraction, it can be done by calling the corresponding API of the Android Framework. For example, for the APK file already installed on the mobile phone, the PackageManager.getlnstalledPackagesO method can be used to query all installed. The APK file has the characteristics of packageName, versionCode and so on. Obviously, there are many ways to extract features, and the entire detection process is not affected by the specific method of extracting features.

2. Extract the digital signature of the Android installation package from the .RSA file in the META-INF\ directory of the Android installation package.

About the META-INF directory, there is a .SF file with similar content:

Signature- Version: 1.0

SHA1 -Digest-Manifest-Main- Attributes: zasvPbp2Pj22IZ986L4058c4i8Y=

Created-By: 1.6.0 22 (Sun Microsystems Inc.)

SHA1 -Digest-Manifest: yyKV+7zSDrmYPqgsQgY0uMvhXCQ=

Name: res/drawable-hdpi/preview_bg.9.png SHA1 -Digest: EgbD5naOTDIzR7CYM+DPCmn9tjE=

Name: res/drawabl e-hdpi/ic— home—arrow— 5— focus.png

SHA1 -Digest: BzYiVw5rVmyzw9Mz CKaA9Q duEk=

Name: res/raw/ic_menu_gallery. png

SHA1 -Digest: d0vnA3rU6DlMuGhA3nzu5FtXaXQ=

Name: res/drawable pressed— application— background.9.png

SHA1 -Digest: P84RuTx2USq2RIY2hO 1 vEz9X4Ac=

Each item is a file verification information, for example, the check information of res/raw/ic_menu_gallery.png is d0vnA3rU6DlMuGhA3nzu5FtXaXQ=, if the file is changed by the tomb, ^^ and the verification information do not match, the Android system can The file was found to have been altered by the tomb and the installation was rejected.

The generation of the verification information is generated by using the private key of the digital certificate, so it cannot be forged. Below the META-INF directory is a public molybdenum file with a .RSA extension. The Android system uses public molybdenum to verify that the verification information is forged. The extraction feature is to check the public molybdenum information of the .RSA file, because the private key and the public molybdenum are paired, so as long as the characteristics of the public molybdenum are extracted, the unique private key can be corresponding, and the private key is applied by Developers keep their own, so they can be used to distinguish Trojans from normal software developers.

As mentioned earlier, the Android system requires that each APK be digitally signed. This digitally signed information can be done through the Android API, for example, an APK file that has been installed on your phone.

The PackageManager.getlnstalledPackagesO method queries the digital signature of each APK package.

An Android installation package can be signed multiple times, which is subject to the last signature. If it is a digital signature obtained through the API, then an array is obtained, the variable is named signature, and the last signed data is signature[0].

In addition, there are other APIs that can also query the digital signature in the APK package, which is not listed here. Moreover, manually extracting the signature[0] feature can also decompress the sample Android installation package. In the META-F/ directory, you will see the CERT.RSA file. This is the signature certificate. Use the ke tool-printcert-file CERT.RSA command to view the details, as follows: Owner: CN=Android Debug, 0= Android, C=US

Issuer: CN=Android Debug, 0= Android, C=US

Serial number : 4ccd020e

Validity: Sun Oct 31 13:43:42 CST 2010 - Mon Oct 31 13:43:42 CST 2011

Certificate fingerprint:

MD5:29:4F:08:AE:04:30:7A:64:93:22:52:47:13:31 :85:43

SHA1 :E4:3F:46:1E:36:07:90:00:00:6C:35:FD:F5:21:42:55:0C:35:B8:A3

Signature Algorithm Name: SHAlwithRSA

Version: 3

3. Extract executable instructions from the classes.dex file of the Android installation package;

As mentioned earlier, most Android applications are mainly written in Java, and the compiled bytecode of the Dalvik virtual machine is compiled into a classes.dex file. Parsing the classes.dex file and decompiling its bytecode gives you the instructions to be executed by the application.

You can pick a feature code that represents the malware feature in the command, and use it as a feature when you find a feature code in the classes.dex file. For example, in order to hide itself, the Android. Geinimi Trojan encrypts some key data (such as Trojan server information) and writes it into the code. These encrypted data are reversed to detect the characteristics of it. Use the dexdump tool to analyze the classes.dex file to see the following fragments in the output:

00d00c: 0003 0100 1000 0000 5535 0234 8664 ... |02d4: array- data (12 units)

00d024: 0003 0100 1000 0000 lbea c301 eadf ... |02e0: array-data (12 units)

The above segments can be extracted as features for detection recognition.

Of course, dexdump tool only shows one means by which these characteristic data, may be realized by other means a parser, and decompilation identification _c l _asses. Dex file function.

In summary, the sample does not contain the ELF file, so the ELF feature is not extracted.

After extracting the above features from sample 1, it is assumed that the following feature records exist in the security identification library:

Feature one: ackageName^com.wbs

Feature 2: None

Feature 3: MD5(signature[0])= 294f08ae04307a649322524713318543 Feature 1 + Feature 3: Security level is "trojan"

When the detection process goes to "Find the package feature 1, the feature three Trojan?", find the record and return the result as "trojan".

4. Extract the instruction or string of the ELF file from the lib\ directory of the Android installation package.

Sample 2: Androi DroidKungFu Kung Fu Trojan

Kung Fu Trojans have dozens of variants, which are generally disguised as a normal application (such as "gallery lock"). After tricking the user into installing and running, run the native executable file and install the back door on the user's phone, so that the Trojan creator can Remotely operate the user's mobile phone.

The extraction of features such as the packageName of the Kung Fu Trojan APKs, and the sample, will not be described here.

The following mainly introduces the extraction of ELF features:

In the lib/armeabi directory of the Android installation package of Kung Fu Trojan, there is a libxxx.so file with file names that vary with Kung Fu Trojans, such as Hbadv3.so, libdl.so, and so on. This is a Linux ELF file that can be read by tools such as readelf. Here is the extracted snippet:

Symbol table '.dynsym' contains 44 entries:

Num: Value Size Type Bind Vis NdxName

0: 00000000 0 NOTYPE LOCAL DEFAULT UND

I: 0000089c 0 SECTION LOCAL DEFAULT 7

2: 00001140 0 SECTION LOCAL DEFAULT 13

3: 00000000 0 FU C GLOBAL DEFAULT UND po eo

4: 0000089d 168 FUNC GLOBAL DEFAULT 7 init_predata

5: 00000000 0 FUNC GLOBAL DEFAULT UND p close

6: OOOOOcOc 0 NOTYPE GLOBAL DEFAULT ABS— exidx— end

7: 0000117c 10 OBJECT GLOBAL DEFAULT 13 PROP — RUNNING— ID

8: 00000000 0 OBJECT GLOBAL DEFAULT UND — stack — chk_guard

9: 00000000 0 FUNC GLOBAL DEFAULT UND—aeabi—unwind— cpp_pr0

10: 00007b34 0 NOTYPE GLOBAL DEFAULT ABS— bss— end—

I I: 00001194 27037 OBJECT GLOBAL DEFAULT 13 _bindata

12: 00000945 616 FUNC GLOBAL DEFAULT 7 Java— com— catsw—lockgaller

... (middle in the middle)

40: 00000000 0 FUNC GLOBAL DEFAULT UND open

41 : 00001140 5 OBJECT GLOBAL DEFAULT 13 DEFAULT — CHANNEL

42: 00001140 0 NOTYPE GLOBAL DEFAULT 13 _data_stait

43: 00000000 0 FUNC GLOBAL DEFAULT UND close

This fragment is a symbol table exported by the libadv3.so file, where the symbol of Type OBJECT is the focus of attention, where – bindata is actually a Hummer sub-package, so it can be extracted as a feature.

Of course, ELF files are flexible, and malware ELF files are not only represented in this form, so ELF files can be extracted in many ways. In addition to extracting features directly from the symbol table, you can also extract code segments. Fragments, strings, etc. as features.

The feature extracted in this embodiment is as follows: _bindata CONTAINS ELF chown unlink /system3⁄4in; Its reciprocal is to query the symbol of _bindata in the symbol table of the .so file, and the data pointed to it is "ELF", "chown" , "unlink", '7system3⁄4in" 4 sets of strings.

Assume that this feature is recorded in the security identification library as:

Feature 4: _ bindata CONTAINS ELF chown unlink /system/bin

Security level: Trojan

When the inspection process goes to "Found Trojan for the four characteristics of the package?", the record is found and the result is "trojan".

The foregoing embodiment is described by taking an application in a mobile phone as an example. However, the specific application may also be applied to application detection of other mobile devices based on the Android platform. The implementation principle is similar to that of the foregoing embodiment, and therefore will not be described again.

It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited by the described action sequence. Because certain steps may be performed in other sequences or concurrently in accordance with the present application. Secondly, the skilled person in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the present application.

Based on the description of the foregoing method embodiments, the present application further provides a corresponding system embodiment, including a security detection system (shown in FIG. 8 to FIG. 10) set on the client, and a security detection system disposed on the server (FIG. 11). Figure 12 shows). The details are explained below.

Referring to FIG. 8 , it is a security detection system of a client application library that is set on the client side according to the embodiment of the present application. Structure diagram.

The security detection system of the Android application library is set on the client, and may include the following modules:

a feature extraction module 81, configured to scan an Android installation package, and extract specified feature information from the Android installation package;

The uploading module 82 is configured to upload the specified feature information to the server, and search for a feature record that matches the specified single feature information or a combination thereof in the security identifier library preset by the server; wherein the server presets The security level corresponding to the signature record and the feature record in the security identification library, and each feature record includes a combination of single feature information or feature information;

The display module 83 is configured to receive a security detection result of the Android installation package returned by the server, and display the security level corresponding to the feature record found by the server in the security detection result.

For the system embodiment shown in FIG. 8 above, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant portions can be referred to the description of the method embodiment shown in FIG.

Preferably, in another embodiment of the present application, as shown in FIG. 9, the security detection system provided on the client may include: a feature extraction module 81, an uploading module 82, and a display module 83, and may further include:

The local detection module 84, 01 searches for a feature record matching the specified single feature information or a combination thereof in the locally preset security identification library; wherein the local preset security identification library contains the feature record and characteristics Record the corresponding security level, and each feature record includes a combination of single feature information or feature information;

The local detection module 84 is further configured to package the security level corresponding to the locally found feature record in the local security detection result of the Android installation package.

Preferably, the system may further include:

The merging module 85 is configured to combine the security detection result returned by the server with the local security detection result, and then merge and display the same on the client user interface through the display module 83.

Preferably, the local detecting module 84 may specifically include the following submodules:

a feature combination sub-module, in which the specified feature information is combined to obtain a combination of features of at least two features; a first search sub-module, configured to start from a feature combination of the most features of the package, Finding a feature record matching the feature combination in the security identification library;

a second search sub-module, configured to reduce the number of features in the feature combination one by one when the first search sub-module is not found, and reduce the feature combination of the feature number, and continue to search and search in the security identification library The feature combination matches the feature record;

And a third search submodule, configured to search, in the security identification library, a feature record that matches the single feature information when the second search submodule is not found.

Preferably, the second search sub-module searches for a plurality of feature combinations having the same number of features in a search process according to a preset sequence; the third search sub-module is spliced to a single feature information. Search in the order in which they are set in advance.

For the system embodiment shown in FIG. 9 above, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment shown in FIG.

Preferably, in another embodiment of the present application, as shown in FIG. 10, the security detection system provided at the client includes, in addition to the feature extraction module 81, the upload module 82, the display module 83, and the local detection module 84, Can include:

The cancel uploading module 86 is configured to cancel the specified feature information when the local detecting module 84 finds a feature record matching all the specified single feature information or a combination thereof in the locally preset security identification library. Uploaded to the server, and the local security detection result is displayed on the client user interface through the display module 83.

Preferably, when the local detecting module 84 finds a feature record matching a partially specified single feature information or a combination thereof in a locally preset security identification library, the uploading module 82 specifies all or the remaining portions. The feature information is uploaded to the server for searching, wherein the specified feature information of the remaining part is feature information that does not find the matching feature record locally; the merge module 85 compares the security detection result returned by the server with the local The security detection results are merged and displayed by the display module 83 on the client user interface after the combination.

For the system embodiment shown in FIG. 10 above, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment shown in FIG.

Preferably, in another embodiment of the present application, based on the contents of the embodiments of FIG. 8, FIG. 9, and FIG. 10, the security detection system provided at the client may further include:

The mode selection module is configured to: before the local detection module 84 searches in the locally preset security identification database, determine, according to the preset configuration information, directly uploading the specified feature information to the server for searching, or directly searching locally. , or prompt the user to choose to find locally or upload to the server to find.

among them, When the configuration information indicates that the local preset security identification library is not allowed to be provided, it is determined that the specified feature information is directly uploaded to the server for searching;

When the configuration information indicates that the local search is prioritized, it is determined to directly search locally;

When the configuration information indicates that the user is selected by priority, it is determined to prompt the user to select whether to search locally or upload to the server for searching. Referring to FIG. 11, there is shown a structural diagram of a security detection system provided in a server-to-Android application library according to an embodiment of the present application.

The security detection system of the Android application library is set on the server, and may include the following modules:

The receiving module 91 is configured to receive the uploaded specified feature information, where the specified feature information is extracted from an Android installation package;

The network detection module 92 is configured to search, in a security identification library preset by the server, a feature record that matches the specified single feature information or a combination thereof; wherein the security identification library corresponds to the feature record and the feature record Security level, each feature record contains a combination of single feature information or feature information;

The sending module 93 is configured to send the security level corresponding to the found feature record in the security detection result of the Android installation package.

For the system embodiment shown in Fig. 11 above, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment shown in Fig. 5.

Preferably, in another embodiment of the present application, as shown in FIG. 12, the security detection system provided at the client may include: a receiving module 91, a network testing module 92, and a sending module 93, and may further include:

The feature recognition module 94 is configured to: when the network detection module does not find a matching feature record in the preset security identification library, identify the specified feature information, and determine, according to the recognition result, the specified The feature level corresponding to the single feature information or a combination thereof and the security level corresponding to the feature record;

The update module 95 is configured to update the security level corresponding to the feature record and the feature record to the security identification library.

Preferably, in another embodiment of the present application, based on the embodiments shown in FIG. 11 and FIG. 12, the network detection module 93 may specifically include the following sub-modules:

a feature combination sub-module, configured to combine the specified feature information to obtain at least two feature combinations of the two features; the first search sub-module is configured to start from a feature combination of the most features of the package, Finding a feature record matching the feature combination in the security identification library;

Preferably, the second search sub-module searches for a plurality of feature combinations having the same number of features in a search process, and performs searching according to a preset sequence; the third search sub-module is brazed to a single feature information. , Find in the order in which they are set in advance.

Preferably, the uploaded specified feature information includes one or a combination of the following:

Android installation package package name, version number, digital signature, Android component receiver characteristics, Android component service features, Android component activity characteristics, executable file instructions or strings, MD5 of each file in the Android installation package directory Value

Preferably, the feature information in the security identification library includes one or a combination of the following:

Package name, version number, digital signature of Android sample package, characteristics of Android component receiver, characteristics of Android component service, characteristics of Android component activity, instructions or strings in executable file, each in Android installation package directory MD5 value of the file;

For the above-mentioned system device embodiment, t, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be partially described in the method embodiments shown in FIG.

The various embodiments in the present specification are described in a progressive manner, and each embodiment focuses on differences from other embodiments, and the same similar parts between the various embodiments can be referred to each other.

Various component embodiments of the present invention may be implemented in hardware or in a software module running on one or more processors Block implementations, or in combination of them. Those skilled in the art should understand that some or all of some or all of the components of the security detection system of the Android application library in accordance with embodiments of the present invention may be implemented in practice using a microprocessor or digital signal processor (DSP). Features. The invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein. Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

For example, Fig. 13 shows a server, such as an application server, which can implement the security detection method of the Android application library according to the present invention. The server conventionally includes a processor 1310 and a computer program product or computer readable medium in the form of a memory 1320. The memory 1320 may be an electronic memory such as a flash memory, an EEPROM (Electrically Destroy Programmable Read Only Memory), an EPROM, a hard disk, or a ROM. The memory 1320 has a memory space 1330 for executing the program code 1331 of any of the above method steps. For example, storage space 1330 for program code may include respective program code 1331 for implementing various steps in the above method, respectively. The program code can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks. Such a computer program product is typically a portable or fixed storage unit as described with reference to Figure 14. The storage unit may have a storage section, a storage space, and the like arranged similarly to the storage 1320 in the server of Fig. 13. The program code can be compressed, for example, in an appropriate form. Typically, the storage unit includes computer readable code 133, i.e., code that can be read by, for example, a processor such as 1310, which when executed by the server causes the server to perform various steps in the methods described above. The invention is further described below in conjunction with the drawings and specific embodiments.

On the Android system, an app that can be installed and run needs to be packaged into the APK file format of the Android system. The APK is an abbreviation of Android application package file, referred to as the APK file, which is the Android installation package, and can also be understood as the application software installed on the Android terminal. The APK file is actually a ZIP file format, but the suffix name is modified to apk. You can see the internal file structure by decompressing tools such as Unzip, as shown in the following table:

Table 1 The Android installation package (APK file) is generally downloaded and installed on the mobile phone through the Android application market. It can also be installed from the PC via a data cable interface such as a USB data cable or wireless data transmission. Viruses, Trojans, and other malware on Android that want to enter the user's phone must also be packaged in the form of an APK. Conversely, if it is not a legitimate APK file, it will not be installed on the user's mobile phone, and it will not harm the user. Based on this, the anti-virus engine can focus on the scanning of the APK file, which greatly improves the scanning efficiency.

1) Package name

2) Digital signature

3) Entry information for each module listed in AndroidManifestxml

AndroidManifest.xml is a required global description file for each APK file, which lists the Android installation package.

Entry information for each module of 01. In the Android system, only the modules listed in AndroidManifestxml can be called by the system. Trojans on the Android platform tend to pretend to be normal applications or games to trick users into installing. Many Trojans are parasitic in a normal application or game. When the user runs it, it looks like the original software or game. But the Trojan module that is parasitic in it is activated at the right time, infecting the user's cell phone. And because the Android system requires all modules to be listed in AndroidManifest.xml, this is an important clue for finding a parasitic Trojan. Therefore,

4) Dex files and ELF files

In the architecture design of the Android system, the relationship between the Android application and the entire system platform is shown in Figure 15. Android applications are usually developed in Java language t. After compiling with Android development tools, they become binary bytecodes. These bytecodes are packaged into classes.dex files, and the Dalvik virtual machine from the Android platform. To explain the implementation. In order to be able to call Android system functions, Android system provides a set of running environment (Android Framework), Android application calling system. Each function is realized by tuning the Android Framework library.

In addition, in addition to the above list, the version number of the Android installation package, the MD5 value of each file in the Android installation package directory, etc., can also be used as an important feature for identifying malware. Among them, the above malware includes viruses, trojans and other malicious soft Pieces.

The embodiments of the present application combine the above important features, and propose a security detection method for the Android application, which can scan the above features of the APK, and finally identify various malware (including viruses, Trojans and others). malicious software) . Moreover, in the security detection method of the embodiment of the present application, the recognition result is not limited thereto, and the normal application, the application that is safe and popular, and the application that is normal but has some problems may be detected to prompt the user.

The implementation process of the method described in the present application is described in detail below through an embodiment.

Referring to FIG. 16, a flowchart of a security detection method for an Android application according to an embodiment of the present application is shown.

Step 1601: Scan an Android installation package, and extract specified feature information from the Android installation package. The specified feature information refers to the important features listed above, such as a package name, a version number, a digital signature,

It should be noted that the “and/or” means that any one of the feature information can be separately extracted from the Android installation package for use as a security detection, and a combination of multiple feature information can also be extracted for security detection. Of course, the effect of extracting multiple features at the same time for detection is significantly better than that of the single feature, which will be described in detail in the embodiment shown in FIG. 15 later, so it is omitted here.

Specifically, in a preferred implementation of the application, the executable file includes a Dex file, and the Dex file is mainly

The classes.dex file in the APK, Dalvik Executable (Dalvik virtual machine executable). It is well known that Dalvik is a Java virtual machine for the Android platform. The Dalvik VM (Dalvik VM) is one of the core components of the Android mobile device platform. It supports the operation of Java applications that have been converted to .dex (Dalvik Executable) format. The dex format is a compression format designed for Dalvik for systems with limited memory and processor speed. Dalvik is optimized to allow multiple instances of virtual machines to run simultaneously in limited memory, and each Dalvik application is executed as a separate Linux process. A separate process prevents all programs from being closed when the virtual machine crashes.

Extract one or more of the following information from the AndroidManifest.xml file of the Android installation package: package name, version number, characteristics of Android component receiver, characteristics of Android component service, Android component activity Characteristics;

and / or,

Extracting the digital signature of the Android installation package from the .RSA file in the META-INF\ directory of the Android installation package;

and / or ,

Extracting executable instructions from the classes.dex file of the Android installation package;

and / or,

Step 1602, searching for a feature record matching the specified single feature information or a combination thereof in the preset security identification library; wherein, the security identification library includes a security level corresponding to the feature record and the feature record, and each feature A combination of individual feature information or feature information in the record;

Step 1603: Display the security level corresponding to the found feature record in the security detection result of the Android installation package.

The security identification library usually needs to be preset in the client local area, for example, in the mobile phone file system, a plurality of feature records are preset in the security identification library, wherein the single feature information can constitute a feature record, and the combination of multiple feature information is also A feature record can be constructed. For example, a security identification library presets dozens of feature records, wherein the first feature record lists the Android installation package name of a certain virus, and the second feature record lists a normal application. The Android installation package version number and the MD5 value of the digital signature, the third feature record lists the Android installation package name and its receiver feature of a normal application, and the fourth feature record lists a certain Trojan. Android installation package name, version number and specific strings in its ELF file, and so on.

In summary, the security identification library collects feature information identifying various malware such as viruses and Trojans, and also collects feature information identifying normal applications, unlike many databases that are only used to identify malware.

Therefore, the feature information collected in the security identification library may include the following:

Danger: The application has a security trend. It is possible that the application itself is malware. It is also possible that the application is originally a normal software released by a regular company, but because of security vulnerabilities, user privacy and mobile phone security are threatened;

Caution: The app is a normal app, but there are some problems, such as users being accidentally charged, or unfriendly ads being complained, etc. When such apps are found, users are prompted to use and inform The possible behavior of the application, but it is up to the user to decide whether to clear the application; Trojan: This application is a virus, trojan or other malware. Here, for the sake of simplicity, it is called Trojan, but it does not mean that the application is just a Trojan.

Therefore, when setting up the security identification library, the Android installation package under the four levels of security, crisis, caution and Trojan can be used as a sample Android installation package, so that the feature records obtained by the individual features or feature combinations in the sample can be separately Corresponds to a level of security and related behavior and description.

Of course, the security identification library can also set a feature record, which lists the version number of the Android installation package of a certain Trojan and the MD5 value of the digital signature. Although the feature combination used in this feature record is the same as the second feature record described above, Both use a combination of the version number and the digital signature MD5 value, but the corresponding security level for this feature record is "trojan".

Then, the feature record in the preset security identification library matches the specified single feature information or a combination thereof, and the security level corresponding to the found feature record is packaged in the security detection of the Android installation package. The steps of the result can be understood as:

Finding the feature record in the security identification library, if the extracted specified single feature matches the first feature record, it may be determined that the current Android installation package is a Trojan level; if the extracted specified features are combined and the second If the feature record or the third feature record matches, it can be determined that the current Android installation package is a security level; if the extracted specified features are combined and matched with the fourth feature record, then the current Android installation package can also be determined. For the Trojan level.

Therefore, the security detection result of an Android installation package may be information indicating that the security level is safe, critical, cautious or Trojan, and the security detection result may also include a description of the behavior related to the security level. At least one prompt message, such as software description, time stamp, etc., such as the prompt information corresponding to the "cautious" level may be "may cause deduction, whether to delete the application."

In summary, the foregoing method for security detection of the Android application library provided by the embodiment of FIG. 16 firstly, the method does not scan all the files in the Android system, but scans the Android installation package for security detection. . This kind of focus on the detection of the Android installation package scan, can greatly improve the efficiency of scanning.

Secondly, the method extracts the specified features from the Android installation package for detection, such as the package name, version number, digital signature, etc. as specified features, and these specified features are most representative for detection, and thus are transplanted from the PC. Compared with the traditional anti-virus engine, this method can accurately grasp several key features of the application under the Android platform, which makes the scanning speed fast and the accuracy of killing and killing.

Based on the foregoing, in the process of querying the security identification database, another embodiment of the present application further provides a method for judging the query, and the query adopts a combination query method for each feature, which can further improve the detection efficiency. And the accuracy of the test.

The query process will be specifically illustrated by way of example in conjunction with the flow shown in FIG.

Referring to Figure 17, there is shown a flow chart for performing a lookup in a secure identification library as described in an embodiment of the present application.

Based on the three characteristics, the security identification library is provided with feature records composed of a single feature and a combination of features, and the feature records include:

Characteristic records of the first feature, the second feature, and the third feature;

Feature record of the package 1 and feature 2;

Feature record of the first feature and feature three;

The feature record of the package feature 3 refers to only the feature III.

Based on the security identification library set as described above, the process of querying the security identification library is explained below by steps 1501 to 1506. details as follows:

Step 1701, determining whether the feature record of the package feature 1, the feature 2, and the feature 3 are found;

If found, return a result, the result includes security level information corresponding to the feature record; if not found, continue to step 1702;

Step 1702, determining whether the feature record of the package feature 1 and the feature 2 is found;

If found, return a result, the result includes the security level information corresponding to the feature record; if not found, continue to step 1703; Step 1703, determining whether the feature record of the first feature and the feature three are found.

If found, return a result, the result includes security level information corresponding to the feature record; if not found, continue to step 1704;

Step 1704, determining whether the feature record of the package feature 1 is found;

If found, return a result, the result includes the security level information corresponding to the feature record; if not found, continue to step 1705;

Step 1705, determining whether the feature record of the second feature of the package is found;

If found, return a result, the result includes the security level information corresponding to the feature record; if not found, continue to step 1706;

Step 1706, determining whether the feature record of the packet feature 3 is found;

The above process is illustrated by a specific example.

Suppose there are 3 applications on a mobile phone (the actual mobile phone has at least dozens of applications, which is simplified for convenience of explanation): 1. The dial-up keyboard that comes with the mobile phone system;

2. A mobile phone security product;

3. Trojan Pico.

1. The dialing keyboard that comes with the mobile phone system

Feature one: APK package name, packageName = com. android. phone;

Feature 2: APK version number, versionCode^8;

Feature 3: MD5 value of APK digital signature,

sigHash= 8ddb342f2da5408402d7568af21 e29f9;

2. A mobile phone security product

Feature one: APK package name, ackageName = com.qihoo360.mobilesafe;

Feature 2: APK version number, versionCode^l37;

Feature 3: MD5 value of APK digital signature,

sigHash= dc6dbd6e49682a57a8b82889043b93a8;

3. Trojan Pico

Feature one: APK package name, ackageName = com.svox.pico;

Feature 2: APK version number, versionCode^l;

Feature 3: MD5 value of APK digital signature,

sigHash= e89bl 58e4bcf988ebd09eb83f5378e87.

Table 1: Feature 1 + Feature 2 + Feature 3

Key com.svox.pico— 1—e89bl58e4bcf988ebd09eb83f5378e87; value Trojan; Table 2: Feature 1 + Feature 2

Empty

Table 3: Feature 1 + Feature 3

Key

Com. qihoo360.mobilesafe_ dc6dbd6e49682a57a8b82889043b93a8;

Value

Table 4: Feature 1

Empty

Table 5: Feature 2 Table 6: Feature 3

Key 8ddb342f2da5408402d7568af21 e29f9;

Value is safe.

For application 1: The dialing keyboard that comes with the phone system

Table 1: No query

Table 2: No query

Table 3: No queries

Table 4: No queries

Table 5: No query

Table 6: Queryed, the result is "safe" query knot, return results.

For application 2: A mobile phone security product

Table 1: No query

Table 2: No query

Table 3: The query is completed, the result is "safe" query knot, return the result.

For application 3: Trojan Pico

Table 1: The query is made, the result is "trojan", return 1SJ result.

Suppose there is an application, and none of the tables in Table 1 are queried. The result is "unknown".

If value is another value such as "critical" or "cautious, then follow the above and so on.

The flow shown in Figure 17 above is only an example. It is used to make the query process convenient for the technicians in the city through a specific example. However, the above example can summarize the essential process of the query, as shown in Figure 18.

Referring to Figure 18, there is shown a flow chart for performing a lookup in a secure identification library as described in another embodiment of the present application.

Step 1801: Combine the specified feature information to obtain at least two feature combinations of the two components. The specified feature information refers to the specified feature information extracted from the Android installation package to be detected.

The combination refers to various possible combinations. For example, the above-mentioned feature 1, feature 2, feature three are extracted from a certain application, and the combination of the three features and the two-two combination can obtain the feature of the package. Second, the feature combination of feature three, the characteristics of the package one, the feature combination of the feature two, the feature of the package, the feature combination of the feature three, and the characteristics of the second feature and the third feature Combination, a total of four feature combinations. However, in the above example, the feature combination of the second feature and the third feature is not used according to the needs of the actual application.

Step 1802, starting from the feature combination of the most features of the package, searching for the feature record matching the feature combination in the security identification library, if not found, proceeding to step 1803;

For example, starting from the combination of the feature of the first feature, the second feature, and the feature three, and the application 1 and the application 2 are not found in the security identification database, the process proceeds to step 1803; For application 3, if the matching feature record is queried in Table 1, the corresponding result is directly returned.

Step 1803, reducing the number of features in the feature combination one by one, and reducing the feature combination of the feature number, and continuing to search for the feature record matching the feature combination in the security identification library, if not found, Continue to step 1804;

If found, the corresponding result is returned.

In the search process, the combination of multiple features with the same number of features can be searched in a predetermined order. For example, in the flow shown in FIG. 18, there are a total of three feature combinations of the two features, and one feature combination that is not used is removed. The search order of the remaining two feature combinations is: The feature combination of the two is searched, and then the feature combination of the first feature and the third feature is searched.

Step 1804, searching for the feature record matching the single feature information in the security identification library.

For example, in the flow shown in Figure 17, the feature record of the packet feature 1 is searched first, then the feature record of the packet feature 2 is searched, and finally the feature record of the packet feature 3 is found.

The sequence of such searches shown in Figure 18 has the following characteristics:

Second, this search order can detect almost all Android applications;

After the definition of each feature is determined (such as "feature one" refers to the APK package name, "feature two" refers to the APK version number, etc.), the order of the search in the process of Figure 16 is determined. The second is defined as the APK package name, and the "feature one" is defined as the APK version number. Then, in the flow of Fig. 18, "Find the package feature 1 and the feature record of the feature 3" is modified to "Find the package feature 2, feature 3" The feature record "; and, in the following process, the order of finding feature one and finding feature two are also interchanged, that is, first look for feature two, then find feature one, and finally find feature three. In summary, it can be seen from the above points that when the security identification library is actually designed, the selected feature information is different, and the feature records combined by these features will also be greatly different, and the combination of features will also affect The sequential query order of feature records with the same number of features. The detection process thus designed may be varied, but all of the various possible processes are derived based on the process described above with respect to Figure 4 and are therefore within the scope of the present application.

The features extracted in this example include:

1) Android installation package name: ackageName

2) Android installation package version number: versionCode

3) Digitally signed MD5 of the Android installation package: signature[0]

4) Android component receiver

5) instructions in classes. dex

6) String in the ELF file

7) MD5 of each file in the assets, res, lib, etc.

8) Android component service, activity

The following is an example of several malware to illustrate the whole process of rectification and detection of the above features.

1. Extract the package name, version number, Android component receiver, service, activity characteristics from the AndroidManifest.xml file of the Android installation package;

Sample 1: Android.Geinimi magic sound

The Android. Geinimi Trojan is usually parasitic in normal Android applications. For example, in this sample, it is in an application called "Magic". Unzip the sample of the Android installation package, you can get the root directory

AndroidManifestxml file. This file is in Android Binary XML (AXML) format and can be used.

The AXMLPrinter2 tool is decoded into a text XML format.

The result of the decoding is as follows:

Encod;ng= ⁱ 'UTF-S ^, 7>

Manifest android:versiooCode- Ί " an:droid:versioriName= ^t! 1.0" package= ^!! com.A¥bs ^1! xmns;androsd=' p://sc emas.S:ndro^d om/apk/resandrold ^!, >

Opplicaiio n andr id;iabel= ^fI stnng/appjname"android:icon="iS)drawab!e/]con:">―'

Activity android:lai3el= ^<t @stri:ngap ..name" android:name= ^,! .MagicVoiceActl^l ^i! >

<intent-ftfier>

<category androidiname-'androldJntent.categor . LAUNCHER" /> /intent-filter>

<intent-fifter

Oction

Androd:name='8ndro ,nlent ;:fk>:n, BOOT— COMPLETED" >

■(category androidrname- 'andro Id. Inilent.calegory. LAUNCHER" /> </intent-filter

<^eceiver>

Octivity android:i eme= ^[, @andrQid:st le/T eme.Back.. oTi!fe8a androsd:ia ef= ^!: @sfrIng/a p_name ^il

andtO:id:na:me= oni.geinimLcusto .— 1⁄2000...000000}8''>

<iHtent-fiiler>

Ociion android: ame- ^! androi>d.intentact n. A! ^f! />

<;3⁄4ctivity>

<applcat n

<uses-sdk aiidr'oici:! inSdkVersiofi=''4 ^! '/>

<uses-permlssion

Andro :n.3me= csnanlro l.teun:ch _: er.permiss nj ST L„SHORTCUr /

<uses-permlssion

Aridroid:name= ^I! androldpermission. CESS„FNE__LOCAT!ON ^i! />

<uses-permissio-n androtd:name- ^s a:ndrGid. rmssion,ACCESS LOC TIONi"i><imatitfest' ―.

1) where com.wbs in package="com.wbs" is the ackageName of the Android installation package.

The "1" in android:versionCode="l" is the versionCode.

2) The characteristics of the receiver are extracted from the following paragraph:

<intent-filter>

</intent-filter>

</receiver>

The meaning of this code is that when the Android system android.intent.action.BOOT-COMPLETED event occurs, a class named com.geinimi.AdServiceReceiver is called. Write this feature below as:

Android.intent. action.BOOT— COMPLETED=comgeinimi.AdServiceReceiver.

<service android: enabled- 'true" android:name^"com.geinimi. custom. GoogleKeyboard" middle slightly) /> The meaning of this code is that this APK application provides an Android service program, named

com.geinimi.custom.GoogleKeyboard.

Write this feature below as:

Service^comgeinimi. custom. GoogleKeyboard.

<activity android:theme^"@android:style Theme.Black.NoTitleBar"

Android:label- '@string/app_name" an droid:name^"com.geinimi. custom. Ad0000_00000006"> <intent-filter>

Category an droid:name^" android. intent. cat egory.LAUNCHER" />

</inteot-filter>

</activity>

Write this feature below as:

MAIN L AUNCHER=com. geinimi. custom. Ad0000_00000006.

<intent-filter>

</inteot-filter>

</activity>

So this activity also extracts features, which are described below:

LAUNCHER=. MagicVoiceActivity

About the META-INF directory, there is a .SF file with similar content:

Signature- Version: 1.0 SHA1 -Digest-Manifest-Main- Attributes: zasvPbp2Pj22IZ986L4058c4i8Y=

Created-By: 1.6.0 22 (Sun Microsystems Inc.)

SHA1 -Digest-Manifest: yyKV+7zSDrmYPqgsQgY0uMvhXCQ= Name: res/drawable-hdpi/preview_bg.9.png

SHA1 -Digest: EgbD5naOTDIzR7CYM+DPCmn9tjE=

Name: res/drawabl e-hdpi/ic— home—arrow— 5— focus.png

SHA1 -Digest: BzYiVw5rVmyzw9Mz CKaA9Q duEk=

Name: res/raw/ic_menu_gallery. png

SHA1 -Digest: d0vnA3rU6DlMuGhA3nzu5FtXaXQ=

Name: res/drawable pressed— application— background.9.png

SHA1 -Digest: P84RuTx2US q2RIY2hO 1 vEz9X4Ac= where each item is a file verification information, for example, the check information of res/raw/ic_menu_gallery.png is d0vnA3rU6DlMuGhA3nzu5FtXaXQ=, if the file is changed by tomb, it will be 1 If the words don't match, the Android system will find that the file has been altered by the tomb and refuse to install.

Issuer: CN=Android Debug, 0= Android, C=US

Serial number : 4ccd020e

Validity: Sun Oct 31 13:43:42 CST 2010 - Mon Oct 31 13:43:42 CST 2011

Certificate fingerprint:

MD5:29:4F:08:AE:04:30:7A:64:93:22:52:47:13:31 :85:43

SHA1 :E4:3F:46:1E:36:07:90:00:00:6C:35:FD:F5:21:42:55:0C:35:B8:A3

Signature Algorithm Name: SHAlwithRSA

Version: 3

3. Extract executable instructions from the classes.dex file of the Android installation package; As mentioned above, most Android applications are mainly written in Java. After compilation, the bytecode of the Dalvik virtual machine is generated and packaged into the classes.dex file. Parsing the classes, dex files, decompiling their bytecodes, you can get the instructions that the application needs to execute.

You can select the feature code that represents the malware feature in the command. When you find the feature code in the classes.dex file, it is used as a feature. For example, in order to hide itself, the Android. Geinimi Trojan encrypts some key data (such as Trojan server information) and writes it into the code. These encrypted data are reversed to detect the characteristics of it. Use the dexdump tool to analyze the classes.dex file to see the following fragments in the output:

OOdOOc: 0003 0100 1000 0000 5535 0234 8664 ... |02d4: array- data (12 units)

00d024: 0003 0100 1000 0000 lbea c301 eadf ... |02e0: array-data (12 units)

The above segments can be extracted as features for detection recognition.

Feature one: ackageName^com.wbs

Feature 2: None

Feature 3: MD5(signature[0])= 294f08ae04307a649322524713318543

Feature 1 + Feature 3: Security level is "trojan"

Sample 2: Androi DroidKungFu Kung Fu Trojan

The following mainly introduces the extraction of ELF features:

In the lib/armeabi directory of the Android installation package of Kung Fu Trojan, there is a libxxx.so file whose file name changes with various variants of Kung Fu Trojan, such as libadv3.so, libdl.so, etc. This is a Linux ELF file that can be read by tools such as readelf. Here is the extracted snippet:

Symbol table '.dynsym' contains 44 entries:

Num: Value Size Type Bind Vis NdxName

0: 00000000 0 NOTYPE LOCAL DEFAULT UND

1: 0000089c 0 SECTION LOCAL DEFAULT 7

2: 00001140 0 SECTION LOCAL DEFAULT 13

3: 00000000 0 FU C GLOBAL DEFAULT UND pop en

4: 0000089d 168 FUNC GLOBAL DEFAULT 7 init_predata

5: 00000000 0 FUNC GLOBAL DEFAULT UND p close

6: OOOOOcOc 0 NOTYPE GLOBAL DEFAULT ABS— exidx— end

7: 0000117c 10 OBJECT GLOBAL DEFAULT 13 PROP — RUNNING— ID

8: 00000000 0 OBJECT GLOBAL DEFAULT UND — stack — chk_guard

9: 00000000 0 FUNC GLOBAL DEFAULT UND—aeabi—unwind— cpp_pr0 10: 00007b34 0 NOTYPE GLOBAL DEFAULT ABS— bss— end—

11 : 00001194 27037 OBJECT GLOBAL DEFAULT 13 — bindata

12: 00000945 616 FUNC GLOBAL DEFAULT 7 Java— com— catsw—lockgaller

... (middle in the middle)

40: 00000000 0 FUNC GLOBAL DEFAULT UND open

41 : 00001140 5 OBJECT GLOBAL DEFAULT 13 DEFAULT — CHANNEL

42: 00001140 0 NOTYPE GLOBAL DEFAULT 13 _data_start

43: 00000000 0 FUNC GLOBAL DEFAULT UND close

This fragment is a symbol table exported by the libadv3.so file, where the symbol of Type OBJECT is the focus of attention, and the -bindata is actually a Trojan sub-package, so it can be extracted as a feature.

The feature extracted in this embodiment is as follows: _bindata CONTAINS ELF chown unlink /system3⁄4in; Its reciprocal is to query the symbol of _bindata in the symbol table of the .so file, and the data pointed to it is "ELF", "chown" , "unlink", '7systen^in" 4 group strings.

Assume that this feature is recorded in the security identification library as:

Feature 4: _ bindata CONTAINS ELF chown unlink /system/bin

Security level: Trojan

Based on the description of the above method embodiments, the present application also provides a corresponding system embodiment.

Referring to FIG. 19, it is a structural diagram of a security detection system of an Android application library according to an embodiment of the present application.

The security detection system for the Android application library may include: a feature extraction module 10, a detection module 20, and a result return module 30. among them,

The feature extraction module 10, 1 scans the Android installation package, and extracts the specified feature information from the Android installation package;

The detecting module 20, 01 searches for a feature record matching the specified single feature information or a combination thereof in the preset security identification library; wherein the security identification library records the security level corresponding to the feature record and the feature record, A combination of individual feature information or feature information is included in each feature record;

The display module 30 is configured to display the security level corresponding to the found feature record in the security detection result of the Android installation package.

The specified feature information extracted from the Android installation package may include one or several combinations of the following information: an Android installation package package name, a version number, a digital signature, an Android component receiver feature, an Android component service Features, characteristics of the Android component activity, instructions or strings in the executable file, MD5 values of each file in the Android installation package directory. The executable file includes a Dex file, and/or an ELF file; the Dex file includes a classes.dex file, a file with a .jar file, and a file in a Dex format.

The feature information in the security identification library may include one or several combinations of the following information:

Package name, version number, digital signature of Android sample package, characteristics of Android component receiver, characteristics of Android component service, characteristics of Android component activity, instructions or strings in executable file, each in Android installation package directory The MD5 value of the file.

The security level includes four levels: security, criticality, caution, and Trojan.

In summary, the security detection system provided by the foregoing embodiment has the following advantages: First, the security detection of the Android application provided by the embodiment of the present application is not performed on all files in the Android system. Scan, but scan the Android installation package for security detection. Since viruses, trojans, and other malware on Android want to enter the user's phone, they need to be packaged in the form of an Android installation package. Conversely, if it is not a legitimate Android installation package, it will not be installed on the user's mobile phone, and it will not harm the user. Based on this, the goal of killing and killing can be concentrated on the scanning of the Android installation package, thereby greatly improving the efficiency of scanning.

Secondly, the embodiment of the present application extracts the specified feature from the Android installation package for detection, such as the package name, the version number, the digital signature, the information of the Android component receiver, the service, the activity, etc. as the specified features, and the specified features. The detection is the most representative, so compared with the traditional anti-virus engine ported on the PC, the embodiment of the present application accurately grasps several key features of the application under the Android platform, so that the scanning speed is fast and the accuracy of the killing is high.

Again, the detections performed in the embodiments of the present application provide four levels of security, security, caution, and trojan, which can detect not only viruses, Trojans, and other malware, but also normal applications, safe and popular applications, and Although normal but some problems exist, all applications are detected. Therefore, the detection of the Android application in the embodiment of the present application is not limited to the traditional virus detection, but can provide the user with more prompts such as security, danger, caution, and the like.

The above security detection system can be installed in a terminal device such as a mobile phone. When the user needs to install an Android application, the security detection system can detect it and give corresponding prompts to mention the security of the terminal.

Based on the content of the above system embodiment, in another embodiment of the present application, as shown in FIG. 20, the detecting module 20 may include the following sub-modules:

a feature combination sub-module 21, configured to combine the specified feature information to obtain at least two feature combinations of the two features;

The first search sub-module 22 is configured to start, in the security identification library, a feature record that matches the feature combination, starting from a feature combination of the most features of the package;

The second search sub-module 23 is configured to reduce the number of features in the feature combination one by one when the first search sub-module 22 is not found, and reduce the feature combination of the feature number, and continue in the security identification library. Searching for a feature record matching the feature combination; a third search sub-module 24, configured to search for a feature record matching the single feature information in the secure identification library when the second search sub-module 23 is not found .

Preferably, the second search sub-module 23 performs a search according to a preset sequence in a plurality of feature combinations with the same number of features in the searching process; the third search sub-module 24 is soldered to a single feature. Information, search in the order of pre-set.

When the detection module 20 shown in FIG. 20 performs security detection on the extracted features, a combination query is performed on each feature to further improve the detection efficiency and the detection accuracy. Based on the content of the above system embodiment, in another optional embodiment of the present application, the feature extraction module 10 may include the following sub-modules:

a first extraction submodule, configured to extract one or more combinations of the following from the AndroidManifest.xml file of the Android installation package: a package name, a version number, a feature of an Android component receiver, a feature of an Android component service, Android ί 件 activity characteristics;

and / or,

a second extraction submodule, configured to extract a digital signature of the Android installation package from an .RSA file in the META-INF\ directory of the Android installation package;

and / or,

a third extraction submodule, configured to extract executable instructions from the classes.dex file of the Android installation package; and/or,

The fourth extraction submodule is configured to extract an instruction or a string of the ELF file from the lib\ directory of the Android installation package.

For the above-mentioned security detection system embodiment, t is relatively simple because it is similar to the method embodiment, and the relevant parts can be partially described with reference to the method embodiments shown in FIGS. 16 to 18. The various embodiments in the present specification are described in a progressive manner, and each embodiment focuses on differences from other embodiments, and the same similar parts between the various embodiments can be referred to each other.

It will be readily apparent to those skilled in the art that any combination of the various embodiments described above is possible, and therefore any combination between the various embodiments described above is an embodiment of the present application, but due to space limitations, the present specification is hereby Not detailed one by one.

In this document, relational terms such as first and second are used merely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such. The actual relationship or order. Moreover, the terms "comprising" and "including" are intended to include not only those elements, but also other elements that are not explicitly listed, or the elements that are inherent to the process, method, item, or device. An element defined by the phrase "comprising", without limiting the invention, does not exclude the presence of additional elements in the process, method, article, or device that comprises the element.

Moreover, "and/or" in the above means that the relationship between "and" is also covered in this article, and the relationship of "or" is also included, where: If scenario A and scenario B are "and", In this embodiment, the scheme A and the scheme B can be included in the embodiment. If the relationship between the scheme A and the scheme B is "or", it means that the scheme A can be separately included in the embodiment, or the scheme B can be separately included.

The various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof. Those skilled in the art should understand that some or all of the functionality of some or all of the components of the security detection system of an Android application in accordance with an embodiment of the present invention may be implemented in practice using a microprocessor or digital signal processor (DSP). . The invention can also be implemented as a part or all of a device or device program (e.g., a computer program and a computer program product) for performing the methods described herein. Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

For example, FIG. 21 illustrates a server, such as an application server, that can implement the security detection method of the Android application according to the present invention. The server conventionally includes a processor 710 and a computer program product or computer readable medium in the form of a memory 720. The memory 720 may be an electronic memory such as a flash memory, an EEPROM (Electrically Destroy Programmable Read Only Memory), an EPROM, a hard disk, or a ROM. Memory 720 has a memory space 730 for program code 731 for performing any of the method steps described above. For example, storage space 730 for program code may include separate implementations for implementing the above Each program code 731 of various steps in the method. The program code can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks. Such a computer program product is typically a portable or fixed storage unit as described with reference to FIG. The storage unit may have a storage section, a storage space, and the like arranged similarly to the storage 720 in the server of FIG. The program code can be compressed, for example, in an appropriate form. Typically, the storage unit includes computer readable code 73, i.e., code that can be read by a processor, such as 710, which when executed by the server causes the server to perform various steps in the methods described above.

"an embodiment," or "an embodiment," or "an embodiment," In addition, it should be noted that the examples of the words "in one embodiment" are not necessarily all referring to the same embodiment.

Numerous specific details are set forth in the description provided herein. However, it is understood that the embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of the description.

It is to be noted that the above-described embodiments are illustrative of the invention and are not intended to be limiting of the invention, and that the embodiments of the invention can be devised without departing from the scope of the appended claims. In the claims, any reference signs placed between the. The word "a package" does not exclude the presence of elements or steps that are not listed in the claims. The word "a" or "an" preceding the element does not exclude the presence of a plurality of such elements. The hardware of thousands of different components is implemented by means of a suitably programmed computer. In the unit claims enumerating thousands of devices, thousands of these devices may be embodied by the same hardware item. The use of the second, third, etc. does not indicate any order. These words can be interpreted as names.

In addition, it should be noted that the phrase t used in the present specification has been selected primarily for the purpose of readability and teaching, and is not selected to explain or define the subject matter of the present invention. Therefore, many modifications and variations of the present invention will be apparent to those skilled in the art. The disclosure of the present invention is intended to be illustrative, and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

Rights request

A security detection method for an Android application, comprising:

Scanning an Android installation package, and extracting specified feature information from the Android installation package;

Uploading the specified feature information to the server, and searching for a feature record matching the specified single feature information or a combination thereof in the security identifier library preset by the server; wherein the server presets the security identification library The security level corresponding to the feature record and the feature record, and each feature record includes a combination of single feature information or feature information;

Receiving the security detection result of the Android installation package returned by the server, and displaying the security level corresponding to the feature record found by the server in the security detection result.

2. The method according to claim 1, further comprising:

Searching for a feature record matching the specified single feature information or a combination thereof in the locally preset security identification library; wherein the security level corresponding to the package feature record and the feature record in the locally preset security identification library is A combination of single feature information or feature information is included in the feature record;

The security level corresponding to the locally found feature record is included in the local security detection result of the Android installation package.

3. The method according to claim 2, further comprising:

The security detection result returned by the server is merged with the local security detection result, and then combined and displayed on the client user interface.

4. The method according to claim 2, wherein

If a feature record matching all of the specified single feature information or a combination thereof is found in the locally preset security identification library, it also includes:

The uploading the specified feature information to the server is cancelled, and the local security detection result is displayed on the client user interface.

5. The method according to claim 2, wherein

If the feature record matching the partially specified single feature information or a combination thereof is found in the locally preset security identification library, all or the remaining part of the specified feature information is uploaded to the server for searching, wherein the remaining portion The specified feature information is that the feature information of the matching feature record is not found locally;

The method according to claim 2, wherein before the searching in the locally preset security identification library, the method further comprises: determining, according to the preset configuration information, directly uploading the specified feature information to the server to search , or directly in the local search, or prompt the user to choose to find locally or upload to the server to find.

7. The method of claim 6 wherein:

When the configuration information indicates that the local preset security identification library is not allowed to be provided, it is determined that the specified feature information is directly uploaded to the server for searching;

When the configuration information indicates that the user is selected by priority, it is determined to prompt the user to select whether to search locally or upload to the server for searching.

The method according to claim 2, wherein the searching for the feature record matching the specified single feature information or a combination thereof in the locally preset or server preset security identification library comprises:

Combining the specified feature information to obtain a combination of features of at least two features;

Starting from the feature combination of the most feature of the package, searching for the feature record matching the feature combination in the security identification library, if not found,

Decreasing the number of features in the feature combination one by one, and reducing the feature combination of the feature number, and continuing to find the feature record matching the feature combination in the security identification library, if not found,

A feature record matching the single feature information is found in the security identification library.

9. The method according to claim 1, wherein the security detection result further comprises at least one of the following:

Behavior description information, software description information, timestamp information.

10. A security detection method for an Android application, comprising:

Receiving the uploaded specified feature information, the specified feature information is extracted from the Android installation package; searching for a feature record matching the specified single feature information or a combination thereof in the server-preset security identification library; a security level corresponding to the signature record and the feature record in the security identification library, and each feature record includes a combination of single feature information or feature information;

The security level package corresponding to the found feature record is sent in the security detection result of the Android installation package.

The method according to claim 10, wherein, when the matching feature record is not found in the security identification library preset by the server, the method further includes: Identifying the specified feature information, and determining, according to the recognition result, a security level corresponding to the feature record and the feature record that match the specified single feature information or a combination thereof;

The method according to claim 10, wherein the searching for the feature record matching the specified single feature information or a combination thereof in the security identifier library preset by the server comprises:

13. The method of claim 12, wherein:

In the searching process, the plurality of feature combinations having the same number of features are searched according to a preset sequence; the single feature information is searched according to a preset sequence.

14. The method according to claim 10, wherein the uploaded specified feature information comprises one or a combination of the following:

Android installation package package name 'version number, digital signature' Android component receiver characteristics, Android component service features, Android component activity characteristics, executable file instructions or strings, MD5 files in the Android installation package directory Value

15. The method according to claim 10, wherein the feature information in the security identification library comprises one or a combination of the following:

16. A security detection system for an Android application library, comprising:

a feature extraction module, configured to scan the Androi d installation package, and extract the specified feature information from the Androi d installation package;

An uploading module, configured to upload the specified feature information to a server, and search for a feature record matching the specified single feature information or a combination thereof in a server-predefined security identification library; wherein, the server preset security Identifying the security level corresponding to the signature record and the feature record in the library, and each feature record includes a combination of single feature information or feature information;

The display module is configured to receive the security detection result of the Android installation package returned by the server, and display the security level in the client user interface, where the security detection result matches the security level corresponding to the feature record found by the server.

17. The system of claim 16, further comprising:

a local detection module, configured to search, in a locally preset security identification library, a feature record that matches a specified single feature information or a combination thereof; wherein the local preset security identification library includes a feature record and a feature record Corresponding security level, each feature record includes a combination of single feature information or feature information;

It is also used to package the security level corresponding to the locally found feature record in the local security detection result of the Android installation package.

18. The system of claim 17, further comprising:

The merging module is configured to merge the security detection result returned by the server with the local security detection result, and then merge and display the same on the client user interface through the display module.

19. The system of claim 17, further comprising:

And canceling the uploading module, when the local detecting module searches for a feature record matching all the specified single feature information or a combination thereof in the locally preset security identification library, canceling uploading the specified feature information to And displaying, by the display module, the local security detection result on the client user interface.

20. The system of claim 18, further comprising: When the local detecting module finds a feature record matching a partially specified single feature information or a combination thereof in a locally preset security identification library, the uploading module uploads all or the remaining part of the specified feature information to the a server search, where the specified feature information of the remaining part is feature information that does not locally find a matching feature record;

The merging module merges the security detection result returned by the server with the local security detection result, and then displays the result through the display module on the client user interface.

21. The system according to claim 17, further comprising:

The mode selection module is configured to: before the local detection module searches in the locally preset security identification database, determine, according to the preset configuration information, directly upload the specified feature information to the server for searching, or directly search for the locality, Or prompt the user to choose to find locally or upload to the server to find.

22. A security detection system for an Android application library, comprising:

a receiving module, configured to receive the uploaded specified feature information, where the specified feature information is extracted from an Android installation package;

And a network module for searching for a feature record matching the specified single feature information or a combination thereof in the security identification library preset by the server; wherein the security identification library has a security corresponding to the feature record and the feature record Level, a combination of individual feature information or feature information in each feature record;

The sending module is configured to send the security level corresponding to the found feature record to the security detection result of the Android installation package.

23. The system of claim 22, further comprising:

a feature identification module, configured to: when the network detection module does not find a matching feature record in a server-preset security identification library, identify the specified feature information, and determine, according to the recognition result, the specified The feature level corresponding to the single feature information or a combination thereof and the security level corresponding to the feature record;

And an update module, configured to update the security level corresponding to the feature record and the feature record to the security identifier library preset by the server.

The system of claim 22, wherein the network detection module comprises:

The system according to claim 21, wherein the uploaded specified feature information comprises one or a combination of the following:

The feature information in the security identification library includes one or a combination of the following:

26. A security detection method for an Android application, comprising:

Searching for a feature record matching the specified single feature information or a combination thereof in the preset security identification library; wherein the security identification library includes a security level corresponding to the feature record and the feature record, and each feature record is included in the package Separate a single feature information or a combination of feature information; The security level package corresponding to the found feature record is displayed in the security detection result of the Android installation package.

The method according to claim 26, wherein the specified feature information extracted from the Android installation package includes one or a combination of the following:

28. The method according to claim 26, wherein the feature information in the security identification library comprises one or a combination of the following:

The method according to any one of claims 26 to 28, wherein the searching for a feature record matching the specified single feature information or a combination thereof in the security identification library comprises:

The method according to claim 27, wherein the extracting the specified feature information from the Android installation package comprises:

Extract one or more of the following from the AndroidManifest.xml file of the Android installation package: package name, version number, characteristics of the Android component receiver, characteristics of the Android component service, characteristics of the Android component activity;

and / or,

The method according to claim 26, wherein the security detection result further comprises at least one of the following:

32. A security detection system for an Android application, comprising: a feature extraction module, configured to scan an Androi d installation package, and extract specified feature information from the Androi d installation package;

a detection module, configured to search, in a preset security identification library, a feature record that matches a specified single feature information or a combination thereof; wherein, the security identification library includes a security level corresponding to the feature record and the feature record, A combination of single feature information or feature information is included in the feature record;

The display module is configured to display the security level corresponding to the found feature record in the security detection result of the Android installation package.

33. A computer program comprising computer readable code, when said computer readable code is run on a server, causing said server to perform security of an Android application library according to any of claims 1-15 Detection method.

A computer readable medium storing the computer program of claim 29.