WO2014000696A1 - 一种Android应用程序的安全检测方法及系统 - Google Patents

一种Android应用程序的安全检测方法及系统 Download PDF

Info

Publication number
WO2014000696A1
WO2014000696A1 PCT/CN2013/078425 CN2013078425W WO2014000696A1 WO 2014000696 A1 WO2014000696 A1 WO 2014000696A1 CN 2013078425 W CN2013078425 W CN 2013078425W WO 2014000696 A1 WO2014000696 A1 WO 2014000696A1
Authority
WO
WIPO (PCT)
Prior art keywords
feature
android
security
file
combination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2013/078425
Other languages
English (en)
French (fr)
Inventor
李涛
张旭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
Original Assignee
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN201210221959.9A external-priority patent/CN102779257B/zh
Priority claimed from CN201210218971.4A external-priority patent/CN102831338B/zh
Application filed by Beijing Qihoo Technology Co Ltd, Qizhi Software Beijing Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Publication of WO2014000696A1 publication Critical patent/WO2014000696A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection

Definitions

  • 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.
  • 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.
  • a security detection method for an Android application 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.
  • a security detection method for an Android application 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.
  • a security detection system for an Android application library 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.
  • a security detection system for an Android application library 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.
  • a computer program 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 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.
  • a computer readable medium storing the same as claimed in claim 29 Computer program.
  • the security detection of the Android 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.
  • 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.
  • the specified feature such as the package name, version number, digital signature, information of the Android component receiver, service, activity, etc.
  • 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.
  • 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.
  • 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.
  • the method of combining and querying various features is used to further improve the detection efficiency and the accuracy of the detection.
  • FIG. 2 is a flowchart of a security detection method of an Android application library according to an embodiment of the present application
  • FIG. 3 is a flowchart of a method for detecting security of an Android application according to another embodiment of the present application
  • FIG. 4 is a flowchart of a method for detecting security of an Android application according to another embodiment of the present application.
  • FIG. 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
  • FIG. 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.
  • 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 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
  • 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.
  • 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.
  • the Android system requires that each APK be digitally signed.
  • 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.
  • 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,
  • 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.
  • Android system provides a set of running environment (Android Framework), Android application calling system. Each function is realized by tuning the Android Framework library.
  • the Android system also supports applications running directly through JNI or native executable.
  • 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.
  • 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) .
  • 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.
  • 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.
  • FIG. 2 a flowchart of a security detection method for an Android application according to an embodiment of the present application is shown.
  • the client such as a mobile phone
  • 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 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.
  • 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;
  • 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.
  • 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.
  • the executable file includes a Dex file
  • 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.
  • 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.
  • the Dex file may also include other files in the Dex format.
  • 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.
  • 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:
  • 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. .
  • 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.
  • 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.
  • 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 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.
  • the feature information collected in the security identifier library preset by the server may include the following:
  • 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.
  • Security The application is a normal application, without any behavior that threatens the security of the user's mobile phone;
  • 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.
  • 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.
  • the security levels corresponding to the first feature record and the fourth feature record are all Trojan levels
  • the security levels corresponding to the second feature record and the third feature record are security levels.
  • 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".
  • 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.
  • 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.
  • 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.”
  • 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.
  • 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.
  • the server 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • steps 302 and 303 may be performed in steps 304 and 305, or may be performed in parallel at the same time.
  • Step 41 The client scans the Android installation package, and extracts the specified feature information from the Android installation package.
  • 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.
  • Step 442 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.
  • the server needs to be uploaded to the server for detection.
  • 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.
  • 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:
  • the security identification library is not allowed to be set on the client.
  • the client extracts the feature information, it can directly upload it to the server for detection.
  • the client 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.
  • the client can also set two situations in the configuration information:
  • the client 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.
  • 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.
  • 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.
  • the client'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.
  • any combination of any one or several of the above implementations can be flexibly selected, and this application is not enumerated.
  • the security detection process uploaded to the server can refer to the process shown in Figure 5 below.
  • 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.
  • 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.
  • 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.
  • the following steps may also be included:
  • the identification process may involve manual identification to help accurately locate the recognition result.
  • 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.” ".
  • 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. .
  • 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.
  • 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.
  • FIG. 6 a flowchart of performing a search in a security identification library according to an embodiment of the present application is shown.
  • feature 1 feature 1
  • feature two feature two
  • feature three do not specifically refer to a certain feature, but can be set according to actual conditions.
  • the features used in the actual situation are not limited to three types, here Used as an example only.
  • 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;
  • 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.
  • the feature record of the second feature and the feature three cannot be obviously detected in practical applications, the feature record is deleted here.
  • some of the feature records given above may also be omitted depending on the needs of the actual application.
  • Step 601 Determine whether the feature record of the package feature 1, the feature 2, and the feature 3 are found;
  • 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.
  • 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;
  • 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
  • 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.
  • 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.
  • the matching feature record is not necessarily a record of malware, but also a record of normal software.
  • the MD5 eigenvalue of an APK's digital signature for a security product is always
  • the dialing keyboard provided in the mobile phone system
  • a mobile phone security product comprising
  • Feature 2 APK version number, versionCode ⁇ 8;
  • Feature 2 APK version number, versionCode ⁇ l37;
  • Table 5 Feature 2
  • Table 6 Feature 3
  • each table may contain multiple feature records, not just the above enumerated cases.
  • Table 6 it is also possible to include the feature record of the key of the feature three and the value of other values.
  • Table 6 is queried, and the result is "safe" query to the east, return the result.
  • Table 3 The query is completed, and the result is "safe" query tie, return results.
  • Table 1 The query is made, the result is "trojan", the query is east, and the result is returned.
  • value is another value, such as "critical” or “cautious”, then and so on.
  • FIG. 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.
  • 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.
  • 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;
  • 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;
  • 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.
  • 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.
  • the single feature information can also be searched in a predetermined order.
  • 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.
  • 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 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;
  • 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.
  • this search order can detect almost all Android applications
  • a Trojan can be detected, and a security software can also obtain a "safe" identification result by detecting.
  • each feature 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
  • the “feature one” is defined as the APK version number.
  • “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.
  • the features extracted in this example include:
  • 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.
  • receiver android:name 3 ⁇ 4om,ger?imL ⁇ dSer iceRecei
  • 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.
  • MAIN_LAUNCHER com.geinimi. custom. Ad0000_00000006.
  • 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.
  • 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.
  • 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.
  • 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].
  • the above segments can be extracted as features for detection recognition.
  • 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
  • the sample does not contain the ELF file, so the ELF feature is not extracted.
  • 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.
  • 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.
  • 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.
  • _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.
  • the foregoing embodiment is described by taking an application in a mobile phone as an example.
  • 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.
  • 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).
  • a security detection system shown in FIG. 8 to FIG. 10 set on the client
  • a security detection system disposed on the server (FIG. 11).
  • Figure 12 shows). The details are explained below.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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;
  • 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
  • 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.
  • 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.
  • 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
  • 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 includes one or a combination of the following:
  • 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.
  • 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).
  • DSP digital signal processor
  • 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.
  • 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.
  • 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.
  • Such 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.
  • 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.
  • 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 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:
  • 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.
  • 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.
  • the Android system requires that each APK be digitally signed.
  • 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.
  • AndroidManifest.xml is a required global description file for each APK file, which lists the Android installation package.
  • 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.
  • Android system provides a set of running environment (Android Framework), Android application calling system. Each function is realized by tuning the Android Framework library.
  • the Android system also supports applications running directly through JNI or native executable.
  • 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.
  • the version number of the Android installation package can also be used as an important feature for identifying malware.
  • 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) .
  • 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.
  • 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,
  • 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.
  • 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;
  • 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.
  • 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.
  • 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 executable file includes a Dex file
  • the Dex file is mainly
  • 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.
  • 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.
  • the Dex file may also include other files in the Dex format.
  • 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.
  • 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:
  • 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. .
  • 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.
  • 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 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.
  • the feature information collected in the security identification library may include the following:
  • 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.
  • Security The application is a normal application, without any behavior that threatens the security of the user's mobile phone;
  • 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;
  • 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.
  • 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.
  • the security levels corresponding to the first feature record and the fourth feature record are all Trojan levels
  • the security levels corresponding to the second feature record and the third feature record are security levels.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.”
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • FIG. 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.
  • feature 1 feature 1
  • feature two feature two
  • feature three do not specifically refer to a certain feature, but can be set according to actual conditions.
  • the features used in the actual situation are not limited to three types, here Used as an example only.
  • the security identification library is provided with feature records composed of a single feature and a combination of features, and the feature records include:
  • 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.
  • the feature record of the second feature and the feature three cannot be obviously detected in practical applications, the feature record is deleted here.
  • some of the feature records given above may also be omitted depending on the needs of the actual application.
  • Step 1701 determining whether the feature record of the package feature 1, the feature 2, and the feature 3 are found;
  • 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
  • Step 1703 determining whether the feature record of the first feature and the feature three are found.
  • 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
  • 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
  • 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 matching feature record is not necessarily a record of malware, but also a record of normal software.
  • the MD5 eigenvalue of an APK's digital signature for a security product is always
  • a mobile phone security product comprising
  • Feature 2 APK version number, versionCode ⁇ 8;
  • Feature 2 APK version number, versionCode ⁇ l37;
  • Feature 2 APK version number, versionCode ⁇ l;
  • Table 5 Feature 2
  • Table 6 Feature 3
  • each table may contain multiple feature records, not just the above enumerated cases.
  • Table 6 it is also possible to include the feature record of the key of the feature three and the value of other values.
  • Table 6 Queryed, the result is "safe" query knot, return results.
  • Table 3 The query is completed, the result is "safe" query knot, return the result.
  • Table 1 The query is made, the result is "trojan", return 1SJ result.
  • FIG. 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.
  • 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.
  • 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.
  • 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;
  • 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;
  • 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.
  • 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 1804 searching for the feature record matching the single feature information in the security identification library.
  • the single feature information can also be searched in a predetermined order.
  • 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 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 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;
  • 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.
  • this search order can detect almost all Android applications
  • a Trojan can be detected, and a security software can also obtain a "safe" identification result by detecting.
  • feature one refers to the APK package name
  • feature two refers to the APK version number
  • the order of the search in the process of Figure 16 is determined.
  • the second is defined as the APK package name
  • feature one is defined as the APK version number.
  • “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.
  • the features extracted in this example include:
  • 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.
  • Ociion android ame- ! androi>d.intentact n. A! f! />
  • 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.
  • 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.
  • 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.
  • 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].
  • the above segments can be extracted as features for detection recognition.
  • 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
  • the sample does not contain the ELF file, so the ELF feature is not extracted.
  • 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.
  • 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.
  • 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.
  • _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.
  • the foregoing embodiment is described by taking an application in a mobile phone as an example.
  • 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.
  • the present application also provides a corresponding system embodiment.
  • 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:
  • 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 security level includes four levels: security, criticality, caution, and Trojan.
  • 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.
  • 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.
  • 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.
  • the security detection system can detect it and give corresponding prompts to mention the security of the terminal.
  • 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 .
  • 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.
  • 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;
  • 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;
  • 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.
  • 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.
  • 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).
  • DSP digital signal processor
  • 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.
  • 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.
  • 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.
  • Such 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Description

一种 Android应用程序的安全检 al方法及系统
技术领城
本发明涉及软件安全技术领城， 特别是涉及一种 Android应用程序的安全检测方法及系统。 背景技术
Android是一种以 Linux为基础的开放源码操作系统， 主要使用于手机等移动终端， 目前尚 未有统一中文名称。 Android平台由操作系统、 中间件、 用户界面和应用软件组成， Android应 01程库即指 Android平台下的应用软件。
随着 Android智能手机的普及， 逐渐形成了一条钎对 Android系统的恶意软件的产业链。 这些恶 意软件通常伪装成正常的应用软件或者游戏欺骗用户安装， 一旦进入用户手机， 就在后台 定制 SP服务或拔打付费电话吸取用户话费， 或者收集用户的隐私， 或者窃取用户的网银和第三方支付密 码以实施进一步的盗窃。 据统计， 目前已有超过 8000种 Android恶意软件， 超过 500万部 Android 手机遭到了感染。
钎对这些众多的 Android恶意软件， 各个致力于软件杀毒的公司相继推出了 Android平台的杀毒 软件。 但是， 它们的杀毒引擎主要移植自 PC上的杀毒引擎， 采用传统 PC杀毒的思路， 按照文件进 行查杀， 甚至对在 Android手机上根本无法运行的文件都会进行扫描， 导致扫描速度慢、 扫描效率低 的问题； 而且， 扫描算法采用提取文件片段计算 CRC ( Cyclic Redundancy Check, 循环冗余校验码 ) 和 MD5 ( Message Digest Algorithm, 消息摘要算法第五版）再在本地数据库中查找的方法， 通用性不 S, 容易导致误报， 误报率较髙。
发明内容
于上述问题， 提出了本发明以便提供一种克服上述问题或者至少部分地解决或者减緩上 述问题的 Android应用程库的安全检测方法及系统。
根据本发明的一个方面，提供了一种 Android应用程序的安全检测方法，其包括：扫描 Android 安装包， 并从所述 Android安装包中提取出指定的特征信息； 将所述指定的特征信息上传到服务 U, 在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录； 其中， 所 述服务器预置的安全识别库中包舍特征记录及特征记录对应的安全级别 ,每条特征记录中包舍单个特 征信息或特征信息的组合； 接收服务器返回的钎对所述 Android 安装包的安全检测结果， 并在客户 端用户界面显示， 所述安全检测结果中包舍服务器查找到的特征记录对应的安全级别。
根据本发明的另一个方面， 提供了一种 Android应用程序的安全检测方法， 其包括： 接收上传 的指定的特征信息， 所述指定的特征信息是从 Android安装包中提取而出； 在服务器预置的安全识 别库中查找与指定的单个特征信息或其组合相匹配的特征记录； 其中， 所述安全识别库中包舍特征记 录及特征记录对应的安全级别，每条特征记录中包舍单个特征信息或特征信息的组合； 将查找到的特 征记录对应的安全级别包舍在所述 Android安装包的安全检测结果中发送。
根据本发明的一个方面， 提供了一种 Android应用程库的安全检测系统， 设置在客户端， 其包 括： 特征提取模块， 用于扫描 Android安装包， 并从所述 Android安装包中提取出指定的特征信 息； 上传模块， 用于将所述指定的特征信息上传到服务器， 在服务器预置的安全识别库中查找与指定 的单个特征信息或其组合相匹配的特征记录； 其中， 所述服务器预置的安全识别库中包舍特征记录及 特征记录对应的安全级别， 每条特征记录中包舍单个特征信息或特征信息的组合； 显示模块， 用于接 收服务器返回的钎对所述 Android 安装包的安全检测结果， 并在客户端用户界面显示， 所述安全检 测结果中包舍服务器查找到的特征记录对应的安全级别。
根据本发明的另一个方面， 提供了一种 Android应用程库的安全检测系统， 设置在服务器， 其包 括： 接收模块， 用于接收上传的指定的特征信息， 所述指定的特征信息是从 Android安装包中提取 而出； 网 棰测模块，用于在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配 的特征记录； 其中， 所述安全识别库中包舍特征记录及特征记录对应的安全级别， 每条特征记录中包 舍单个特征信息或特征信息的组合； 发送模块， 用于将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结果中发送。
根据本发明的又一个方面， 提供了一种计算机程序， 其包括计算机可读代码， 当所述计算 机可读代码在服务器上运行时， 导致所述服务器执行根据权利要 1-15 中任一个所述的 Android 应用程库的安全检测方法。
根据本发明的再一个方面， 提供了一种计算机可读介质， 其中存储了如权利要求 29所述的 计算机程序。
本发明的有益效果为：
首先， 本申请提供的钎对 Android应用程序的安全检测， 并不是对 Android系统中的所有文件进 行扫描， 而是通过扫描 Android安装包来进行安全检测。 由于 Android上的病毒、 木马和其他恶意软 件想要进入用户的手机，需要打包成 Android安装包的形式。反过来说，如果不是一个合法的 Android 安装包， 它就无法安装到用户手机上， 也就不会对用户产生危害。 基于这一点， 杀毒引擎可以把查杀 的目标集中到对 Android安装包的扫描上， 从而大大提髙扫描的效率。
其次， 本申请从 Android安装包中提取出指定的特征进行检测， 如将包名、 版本号、 数字签名、 Android组件 receiver, service, activity中的信息等作为指定的特征， 这些指定的特征对于检测 最具代表性， 因此与移植自 PC上的传统杀毒引擎相比， 本申请准确抓住了 Android平台下应用 的几大关键特征， 使得扫描速度快、 查杀准确率髙。
再次， 本申请将客户端检测与服务器检测相结合， 不仅可以在客户端本地对 Android应用程 序进行安全检测， 还可以将提取的特征上传到服务器检测。 由于服务器设置的安全识别库时常 保持更新， 无论哪个客户端或人工识别出新的或变种的病毒、 木马等特征， 都会立即更新到该 库中， 所以该库中的特征更大、 更全， 可以检测出客户端本地检测不到的特征， 因此对各种恶 意软件的变种识别能力大大增强。
再次， 本申请进行的检测提供了安全、 危睑、 谨慎和木马四个安全级别， 不仅可以检测出 病毒、 木马和其他恶意软件， 还可以将正常的应用、 存在安全风睑的应用和虽然正常但存在一 些问题的应用全部检测出来。因此，本申请对 Android应用程库的检测不局限于传统的查毒检测 , 而是可以为用户提供安全、 危睑、 谨慎等更多的提示。
最后， 本申请对提取出的各项特征进行安全检测时， 采用对各项特征进行组合查询的方式， 进一步提 S了检测效率和检测的准确率。
当然， 实施本申请的任一产品不一定需要同时达到以上所述的所有优点。
上述说明仅是本发明技术方案的概述， 为了能够更清楚了解本发明的技术手段， 而可依照 说明书的内容予以实施， 并且为了让本发明的上述和其它目的、 特征和优点能够更明显易懂， 以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述， 各种其他的优点和益处对于本领城普通技术人员 将变得清楚明了。 附图仅用于示出优选实施方式的目的， 而并不认为是对本发明的限制。 而且 在整个附图中， 用相同的参考符号表示相同的部件。 在附图中：
图 1是是本申请实施例中 Android系统的架构设计图；
图 2是本申请实施例所述一种 Android应用程库的安全检测方法流程图；
图 3是本申请另一实施例所述一种 Android应用程序的安全检测方法流程图；
图 4是本申请另一实施例所述一种 Android应用程序的安全检测方法流程图；
图 5是本申请另一实施例所述一种钎对 Android应用程库的服务器侧的安全检测流程图； 图 6是本申请实施例所述在安全识别库中进行查找的流程图；
图 7是本申请另一实施例所述在安全识别库中进行查找的流程图；
图 8是本申请实施例所述一种设在客户端钎对 Android应用程库的安全检测系统的结构图； 图 9是本申请另一实施例所述一种设在客户端钎对 Android应用程库的安全检测系统的结构图； 图 10是本申请另一实施例所述一种设在客户端钎对 Android应用程库的安全检测系统的结构图； 图 11是本申请实施例所述一种设在服务器钎对 Android应用程库的安全检测系统的结构图； 图 12是本申请另一实施例所述一种设在服务器钎对 Android应用程库的安全检测系统的结构图； 图 13示意性地示出了用于执行根据本发明的方法的服务器的框图； 以及
图 14示意性地示出了用于保持或者携带实现根据本发明的方法的程序代码的存储单元。 图 15示意性示出了根据本发明一个实施例的 Android系统的架构设计图；
图 16示意性示出了根据本发明一个实施例的 Android应用程库的安全检测方法流程图； 图 17示意性示出了根据本发明一个实施例的在安全识别库中进行查找的流程图；
图 18示意性示出了根据本发明另一实施例的所述在安全识别库中进行查找的流程图； 图 19示意性示出了根据本发明一个实施例的 Android应用程序的安全检测系统的结构图； 图 20示意性地示出了根据本发明一个实施例的安全检测系统中检测模块的结构图； 图 21示意性地示出了用于执行根据本发明的方法的服务器的框图； 以及
图 22示意性地示出了用于保持或者携带实现根据本发明的方法的程序代码的存储单元。 具体实施例
下面结合附图和具体的实施方式对本发明作进一步的描述。
分析现有技术中的各种杀毒引擎， 由于移植自 PC上的杀毒引擎， 主要钎对的是 PC系统的特性 而设计， 而 PC系统与 Android系统既有相同的特性， 也有不同的特性，但现有技术并没有深入理解 Android系统本身的特点， 因此并不完全适合于 Android系统的杀毒， 存在着扫描速度慢、 误报 率 s的问题。
基于此， 本申请结合 Android系统本身的特点， 提出一种专门钎对 Android系统特性而设计 的杀毒方法， 下面先介绍设计思路。
在 Android系统上，一个可以安装、 运行的应用， 需要打包成 Android系统的 APK文件格 式。 APK是 Android application package file的缩写， 简称 APK文件， 即 Android安装包， 也可 以理解为 Android终端上安装的应用软件。 APK文件其实是 ZIP文件格式， 但后缀名被修改为
Figure imgf000005_0001
表 1
Android安装包（ APK文件）一般通过 Android应用市场下载、 安装到手机上， 也可以通过 USB 数据线等数据线接口或无线数据传输的方式从 PC安装。 Android上的病毒、 木马和其他恶意软件想 要进入用户的手机， 也必须打包成 APK的形式。 反过来说， 如果不是一个合法的 APK文件， 它就无 法安装到用户手机上， 也就不会对用户产生危害。 基于这一点， 杀毒引擎就可以把查杀的目标集中到 对 APK文件的扫描上， 从而大大提髙扫描的效率。
那么， Android安装包 （ APK文件） 中的哪些信息可以作为扫描的重点， 钎对此问题本申请进 行了分析， 具体如下：
1 ) 包名
Android操作系统通过 APK的包名（ package name )对各个安装的 APK进行管理。 "包名 "源自于 Java 的 package 的概念， 按照 Java的 package的命名风格， 例如某个 Android安装包的包名是 com.qihoo360.mobilesafe. Android系统要求每个应用都声明一个唯一的包名。 如果要安装的 APK的 包名和当前手机上某个已有的应用的包名重复了， 那么 Android系统会拒绝安装。 Android平台下的 恶意软件也需要声明一个包名， 因此， 包名就可以作为识别恶意软件的一个重要特征。
2 )数字签名
出于安全性的目的， Android系统要求每个 APK都要包舍数字签名 ( digital signature )。 Android 系统在安装 APK文件的时候会检查 APK内部各文件的数字签名是否与其预先设定的数字签名一致， 如果不一致， 或者没有数字签名， 则认为文件已被墓改， 拒绝该 APK的安装和运行。 Android平台下 的恶意软件也不例外， 所以 APK文件的数字签名也可以作为识别恶意软件的一个重要特征。
3 ) AndroidManifestxml中列出的各模块的入口信息
AndroidManifest.xml是每个 APK文件所必需的全局描述文件， 里面列出了 Android安装包中应 用的每个模块的入口信息。 在 Android系统中， 只有在 AndroidManifestxml中列出了的模块， 才能够 被系统调用。 Android平台下的木马， 往往会伪装成正常的应用或游戏来诱骗用户安装， 其中有很多 木马就是寄生在一个正常的应用或游戏中， 用户运行它的时候， 看上去是原来的软件或游戏， 但寄生 在其中的木马模块在合适的时机就被激活， 从而感染用户的手机。 而因为 Android系統要求所有的模 块都要在 AndroidManifest.xml中列出， 这就为寻找寄生的木马提髙了重要线索。 因此，
AndroidManifestxml中列出的各模块的信息， 也是识别恶意软件的重要特征。
4 ) Dex文件和 ELF文件
在 Android系统的架构设计中， Android应用与整个系统平台之间的关系如图 1所示。 Android 应用通常是用 Java语 t开发的，它用 Android开发工具编译之后变成了二进制的字节码（byte code ) , 这些字节码被打包成 classes.dex文件， 由 Android平台的 Dalvik虛拟机来解释执行。 为了能够调用 Android系统功能 , Android系统提供了一套运行环境 ( Android Framework ) , Android应用调用系统 各功能都是通过调 Android Framework的库来实现的。
另一方面， Android系统也支持应 程序通过 JNI或者 native executable直接运行。 此时应用执行 的是直接在 CPU上运行的二进制机器码， 不需要经过虛扭机解释， 可以直接调用 Android库如 libc、 WebKit, SQLite, OpenGL ES等来调用系統各功能。如果 Android应用要通过 JNI或者 native executable 运行， 就需要将要执行的代码编译成 ELF文件格式。 ELF是 Executable and Linkable Format的缩写， 是 Android/Linux操作系统中可执行程序、 共享库的文件格式。
Android上的恶意软件要想在 Android系统中运行起来， 也要遵循上述架构规范。 因此， 在识别 恶意软件的过程中， 可以分别从 Dex文件 （即字节码文件）和 ELF文件提取相应的特征。
此外， 除上述列举之外， Android安装包的版本号、 Android安装包目录下各文件的 MD5值等 信息， 也可以作为识别恶意软件的重要特征。 上述的恶意软件包括病毒、 木马和其他恶意软件。
本申请实施例综合了以上各个重要特征， 提出一种钎对 Android应用程序的安全检测方法， 可 以对 APK的上述各项特征进行扫描、 鉴 最终识别出各种恶意软件（包括病毒、 木马和其他恶意 软件） 。 而且， 本申请实施例的安全检测方法， 识别结果不局限于此， 还可以将正常的应用、 存在 安全风睑的应用和虽然正常但存在一些问题的应用全部检测出来， 以提示用户。
本申请实施例提供的安全检测方法， 将客户端检测与服务器检测相结合， 在各种不同的应 用场景下， 可灵活选择。
总体而 t , 本申请实施例提供了两种检测方式： 一种是直接将客户端提取的特征上传到服 务器检测； 另一种是犹先在本地检测， 然后再上传服务器检测。
下面通过实施例对本申请提供的各种检测方法进行详细说明。
参照图 2, 其示出了本申请实施例所述一种 Android应用程序的安全检测方法流程图。 本实施例中， 客户端（如手机）直接从本地的 Android安装包中提取特征， 并上传到服务器 检测。 客户端的处理过程如下：
步骤 201 ,客户端扫描 Android安装包，并从所述 Android安装包中提取出指定的特征信息； 所述指定的特征信息即指上述列举的各项重要特征， 如包名、 版本号、 数字签名、
AndroidManifestxml中列出的各模块的入口信息、 Dex文件和 ELF文件、 Android安装包目录下各 文件的 MD5值等。 这些指定的特征信息对于安全检测最具代表性， 因此也是用于检测的关键特征。
其中 , AndroidManifest.xml中列出的各模块的入口信息包括 Android组件中的特征。 Android开 发的四大组件分别是： 活动 (Activity), 用于表现功能； 服务 (Service), 后台运行服务， 不提供界面呈 现； 广播接收器 (Broadcas tReceiver), 用于接收广播； 内容提供商 （ Content Provider ) , 支持在多个 应用中存储和读取数据， 相当于数据库。
因此， 所述从 Android安装包中提取出的指定的特征信息可以包括：
Android安装包的包名， 和 /或， 版本号， 和 /或， 数字签名， 和 /或， Android组件 receiver 的特征， 和 /或， Android组件 service的特征， 和 /或， Android组件 activity的特征， 和 /或， 可 执行文件中的指令或字符串， 和 /或， Android安装包目录下各文件的 MD5值；
需要说明的是， 所述"和 /或"是指从 Android安装包中可以单独提取出其中任意一项特征信息 用作安全检测 , 也可以提取出多项特征信息的组合用作安全检测。 当然， 同时提取多项特征进行检测 的效果要明显优于单项特征， 这在后面图 3所示的实施例中将进行详细说明， 所以此处略。
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件。
具体地， 在本申请的一种优选实施列中， 所述可执行文件包括 Dex文件， Dex文件主要是 APK中的 classes.dex文件，即 Dalvik Executable ( Dalvik虛拟机可执行文件 )。公知的是， Dalvik 是用于 Android平台的 Java虛拟机。 Dalvik虛拟机 ( Dalvik VM )是 Android移动设备平台的核 心组成部分之一。 它可以支持已转换为 .dex (即 Dalvik Executable ) 格式的 Java应用程序的运 行， . dex格式是专为 Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。 Dalvik 经 过优化， 允许在有限的内存中同时运行多个虛拟机的实例， 并且每一个 Dalvik应用作为一个独 立的 Linux 进程执行。 独立的进程可以防止在虛拟机崩溃的时候所有程序都被关闭。
更为优选的是， 所述可执行文件还可以包括扩展名为. jar的文件。 Android安装包中的 JAR 文件其实就是 Dex文件， 只不过其扩展名为. jar, 对于 APK中除 classes.dex之外的其他文件， 只要判定其为 Dex文件即可决定是否进行扫描。
在实际应用中， 所述 Dex文件还可以包括其它 Dex格式的文件。
此外， 上述 Android安装包目录下各文件的 MD5值可以是数字签名的 MD5值， 也可以是 表 1中 res\、 assets\, lib\ 目录下各文件的 MD5值。
基于以上列举的指定特征， 可通过以下方式从 Android安装包中提取出各项指定的特征信 息， 参照表 1可知：
从所述 Android安装包的 AndroidManifest.xml文件中提取出以下信息中的一种或几种组合：： 包名，版本号， Android组件 receiver的特征， Android组件 service的特征， Android组件 activity 的特征； 和 /或，
从所述 Android安装包的 META-INF\ 目录下的 .RSA文件中提取出所述 Android安装包的数 字签名； 和 /或，
从所述 Android安装包的 classes. dex文件中提取出可执行指令； 和 /或，
从所述 Android安装包的 lib\ 目录下提取出 ELF文件的指令或字符串。
其中， 所述"和 /或' '的理解与上相同， 即可以从 Android安装包中单独提取出其中任意一项特征 信息用作安全检测， 也可以提取出多项特征信息都用作安全检测。
关于具体的特征提取方法， 将在后面的举例说明中进行解释。
步骤 202, 客户端将所述指定的特征信息上传到服务器， 在服务器预置的安全识别库中查找与指 定的单个特征信息或其组合相匹配的特征记录； 其中， 所述服务器预置的安全识别库中包舍特征记录 及特征记录对应的安全级别， 每条特征记录中包舍单个特征信息或特征信息的组合；
步骤 203, 客户端接收服务器返回的钎对所述 Android安装包的安全检测结果， 并在客户端用户 界面显示， 所述安全检测结果中包舍服务器查找到的特征记录对应的安全级别。
上述过程中， 对特征的识别主要由服务器完成， 服务器的介绍如下：
所述服务器预置的安全识别库中预置了多条特征记录， 其中， 单个特征信息可以构成一条特征记 录， 多个特征信息的组合也可以构成一条特征记录。例如，一个安全识别库中预置了几十条特征记录， 其中， 第一条特征记录中列出了某种病毒的 Android安装包包名， 第二条特征记录中列出了某个正 常应用的 Android安装包版本号及其数字签名的 MD5值， 第三条特征记录中列出了某个正常应 用的 Android安装包包名及其 receiver特征， 第四条特征记录中列出了某种木马的 Android安装 包包名、 版本号及其 ELF文件中的特定字符串， 等等。
总之， 服务器预置的安全识别库中既收集了识别病毒、 木马等各种恶意软件的特征信息， 也收集了识别正常应用的特征信息， 而不同于很多仅仅用于识别恶意软件的数据库。
因此， 所述服务器预置的安全识别库中收集的特征信息可以包括以下列举的：
各种样本 Android安装包的包名， 和 /或， 版本号， 和 /或， 数字签名， 和 /或， Android组件 receiver的特征， ： ί。/或， Android组件 service的特征， ： ί。/或， Android组件 activity的特征， 或， 可执行文件中的指令或字符串， 和 /或， Android安装包目录下各文件的 MD5值；
如前所述，所述"和 /或"也是指从各种样本的 Android安装包中可以单独提取出其中任意一项 特征信息用作安全检测， 也可以提取出多项特征信息的组合用作安全检测。
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述样本 Android安装包包括各种安全级别下的 Android安装包。
本申请实施例列举出安全、 危睑、 谨慎和木马四个安全级别。 其中， 各种安全级别的定义如下： 安全： 该应用是一个正常的应用， 没有任何威胁用户手机安全的行为；
危睑： 该应用存在安全风睑， 有可能该应用本身就是恶意软件； 也有可能该应用本来是正视 >公司 发布的正常软件， 但是因为存在安全漏洞， 导致用户的隐私、 手机安全受到威胁； 谨慎： 该应用是一个正常的应用， 但是存在一些问题， 例如会让用户不小心被扣费， 或者有不友 好的广告遭到投诉等； 当发现这类应用之后， 会提示用户谨慎使用并告知该应用可能的行为， 但是由 用户自行决定是否清除该应用；
木马： 该应用是病毒、 木马或者其他恶意软件， 此处为了简单统称为木马， 但并不表示该应用仅 仅^马。
所以， 在服务器设置安全识别库时， 可以将安全、 危睑、 谨慎和木马四个级别下的 Android 安装包都作为样本 Android安装包，从而由样本中的单个特征或特征组合得到的特征记录可分别 对应着一种安全级别及相关的行为和描述等信息。
例如， 上述的第一条特征记录和第四条特征记录分别对应的安全级别均为木马级别， 上述 的第二条特征记录和第三条特征记录分别对应的安全级别均为安全级别。
当然， 服务器预置的安全识别库中还可以设置一条特征记录， 列出某种木马的 Android安装 包版本号及其数字签名的 MD5值， 虽然这条特征记录使用的特征组合与上述第二条特征记录相 同 ,都使用了版本号与数字签名 MD5值的组合，但是这条特征记录对应的安全级别则为"木马"。
所以， 安全级别并不与某一种特定的特征或特征组合相对应， 而是与具体的特征或特征组 合的取值相对应。 因此， 如上所述， 对于相同的特征或特征组合， 具体取值不同， 对应的安全 级别也是不同的。
而且， 上述安全、 危睑、 谨慎和木马四个级别的定义仅作为举例说明， 根据实际应用， 当然也 可以有其他的安全级别分类及定义， 本申请的保护范围并不限定于此。
那么， 在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录， 并将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结果的步骤， 可以理 解为：
在服务器预置的安全识别库中查找特征记录，如果提取出的指定单个特征与第一条特征记录相 匹配， 则可以判定当前的 Android安装包为木马级别； 如果提取出的指定特征进行组合后与第二 条特征记录或者第三条特征记录相匹配， 则可以判定当前的 Android安装包为安全级别； 如果提 取出的指定特征进行组合后与第四条特征记录相匹配，则可以判定当前的 Android安装包也为木 马级别。
所以钎对某个 Android安装包的安全检测结果可以是包舍安全、 危睑、 谨慎或木马四个表示 安全级别的信息， 此外所述安全检测结果中还可以包括与安全级别相关的行为描述、 软件描述、 时间 戳等至少一项提示信息，如对应 "谨慎 "级别的提示信息可以是"可能造成扣费，是否选择删除该应用"。
更具体地， 在一犹选实施例中， 所述安全检测结果可以包舍安全级别、 行为描述信息、 软件描述 信息和时间戳信息。 其中：
安全级别： 可以用 32位整数表示， 可表示安全、 危睑、 谨慎或木马四个安全级别， 每个安全级 别的定义如上所述。
行为描述信息： 也可以用 32位（0~31 ) 整数表示， 可以表示出各个安全级别的软件行为描述。 其中， 可以选取一位表示标志位， 标志位为 0表示没有恶意行为， 如果有恶意行为， 则可以定义： 第 1位代表 "后台偷偷下载"， 第 2位代表"私自发送短信 "， 第 3位代表 "包舍广告 "， 等等。 即， 每一位 都可以单独表示一种软件的行为描述。
例如， 对于检测为"木马级别' '的 Android应用程序， 如果恶意行为 = 3, 翻译成二进制就是 11 , 第 1位 = 1 , 第 2位 = 1 , 表示的恶意行为是： 同时具有后台偷偷下载和私自发送短信的行为。
再例如，对于检测为"谨慎级别' '的 Android应用程库，如果行为描述 = 4,翻译成二进制就是 100, 第 1位 = 0, 第 2位 = 0, 第 2位 = 1 , 表示的行为是： 包舍广告。 由于这个广告可能是用户允许的， 也可能是用户不允许的， 所以会提示用户谨慎使用， 由用户自行决定是否清除。
软件描述信息： 通常表示为字符串， 是对 Android应用程序的说明， 如发布者、发布时间等信息。 时间戳信息： 表明 Android应用程序的特征信息（如正常特征、木马特征等）是什么时候入库的。 实际应用中，客户端用户界面显示安全检测结果时，可以先弹出安全级别信息，如果用户点击 "查 看详情"按钮， 再为用户展示行为描述信息、 软件描述信息和时间戳信息。
服务器完成特征识别后， 会将最终的安全检测结果返回给对应的客户端， 由客户端在客户端用户 界面中显示， 以提醒用户。
综上所述， 上述图 2实施例提供的钎对 Android应用程序的安全检测方法， 主要在服务器上进行 特征识别， 具有以下特点：
首先， 该方法并不是对 Android系统中的所有文件进行扫描， 而是通过扫描 Android安装包来进 行安全检测。 这种把查杀的目标集中到 Android安装包扫描的方式， 可以大大提髙扫描的效率。 其次， 该方法从 Android安装包中提取出指定的特征进行检测， 如将包名、 版本号、 数字签名、 等作为指定的特征， 这些指定的特征对于检测最具代表性， 因此与移植自 PC上的传统杀毒引擎 相比， 该方法能够准确抓住 Android平台下应用的几大关键特征， 使得扫描速度快、 查杀准确率 髙。
再次， 该方法将提取的特征上传到服务器检测。 由于服务器设置的安全识别库时常保持更 新， 无论哪个客户端或人工识别出新的病毒、 木马等特征， 都会立即更新到该库中， 所以该库 中的特征更大、 更全， 可以检测出客户端本地检测不到的特征， 因此对各种恶意软件的变种识 别能力大大增强。
再次， 该方法进行的检测提供了安全、 危睑、 谨慎和木马四个安全级别， 不仅可以检测出 病毒、 木马和其他恶意软件， 还可以将正常的应用、 存在安全风睑的应用和虽然正常但存在一 些问题的应用全部检测出来。因此，本申请对 Android应用程序的检测不局限于传统的查毒检测 , 而是可以为用户提供安全、 危睑、 谨慎等更多的提示。
基于以上内容， 下面通过实施例说明优先在本地检测， 然后再上传服务器检测的情况。 此时， 本申请实施例又提供了两种情况： 一种是本地优先检测完后， 无论检测结果如何， 都上传到服务器重新检测， 然后将两种检测结果合并， 具体如图 3实施例所述； 另一种是本地 优先检测， 如果对提取的特征全部检测出结果， 则无需上传服务器再检测， 但如果本地有无法 识别的特征， 则再上传服务器检测， 最后将两种检测结果合并， 具体如图 4实施例所述。
下面分别详细说明。
参照图 3, 其示出了本申请另一实施例所述一种 Android应用程序的安全检测方法流程图。 步骤 301 ,客户端扫描 Android安装包，并从所述 Android安装包中提取出指定的特征信息； 步骤 302,客户端在本地预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的 特征记录； 其中， 所述本地预置的安全识别库中包舍特征记录及特征记录对应的安全级别， 每 条特征记录中包舍单个特征信息或特征信息的组合；
步骤 303 ,客户端将本地查找到的特征记录对应的安全级别包舍在所述 Android安装包的本 地安全检测结果中；
步骤 304,客户端将所述指定的特征信息上传到服务器， 在服务器预置的安全识别库中查找 与指定的单个特征信息或其组合相匹配的特征记录； 其中， 所述服务器预置的安全识别库中包 舍特征记录及特征记录对应的安全级别， 每条特征记录中包舍单个特征信息或特征信息的组合； 其中， 客户端通常将全部的指定特征都上传到服务器进行再次检测；
步骤 305, 客户端接收服务器返回的钎对所述 Android安装包的安全检测结果， 所述安全检 测结果中包舍服务器查找到的特征记录对应的安全级别；
步骤 306,客户端将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后在客 户端用户界面显示。
其中， 所述合并是指： 将服务器返回的安全检测结果与本地安全检测结果逐条对比， 如果 两者相同， 则合并成一条结果； 如果两者不同， 则以服务器的安全检测结果为准。
需要说明的是， 上述客户端本地预置的安全识别库与上述服务器预置的安全识别库类似， 因此对本地预置的安全识别库的介绍可参照上述服务器预置的安全识别库的说明。
但是， 两者的不同之处在于： 服务器设置的安全识别库时常保持更新， 无论哪个客户端或 人工识别出新或变种的病毒、 木马等特征， 都会立即更新到该库中， 所以该库中的特征更大、 更全， 可以检测出客户端本地检测不到的特征， 因此对各种恶意软件的变种识别能力大大增强。 这也是在本地检测完之后， 再次上传到服务器进行检测的主要原因， 可以避免客户端本地漏检。
而且， 还需要说明的是， 上述过程中， 步骤 302、 303既可以与步骤 304、 305先后执行， 也可以同时并行执行。
参照图 4, 其示出了本申请另一实施例所述一种 Android应用程序的安全检测方法流程图。 步骤 41 , 客户端扫描 Android安装包， 并从所述 Android安装包中提取出指定的特征信息； 步骤 42, 客户端在本地预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的 特征记录； 其中， 所述本地预置的安全识别库中包舍特征记录及特征记录对应的安全级别， 每 条特征记录中包舍单个特征信息或特征信息的组合；
其中， 客户端可能查找到与所有指定的单个特征信息或其组合相匹配的特征记录， 也可能 只查找到与部分指定的单个特征信息或其组合相匹配的特征记录； 步骤 43, 客户端将本地查找到的特征记录对应的安全级别包舍在所述 Android安装包的本 地安全检测结果中；
其中， 所述本地安全检测结果中包舍所有能够查找到的特征记录对应的安全级别； 步骤 441 ,如果客户端在本地预置的安全识别库中查找到与所有指定的单个特征信息或其组 合相匹配的特征记录， 则取消将所述指定的特征信息上传到服务器， 并将所述本地安全检测结 果在客户端用户界面显示， 流程结東。
换而 t之， 如果所有的指定特征， 无论以单个特征的形式， 还是以组合的形式， 都能在客 户端本地的安全识别库中找到相匹配的特征记录， 那么将结東流程， 不再上传到服务器检测； 步骤 442,如果客户端在本地预置的安全识别库中查找到与部分指定的单个特征信息或其组 合相匹配的特征记录， 则将全部或剩余部分的指定的特征信息上传到服务器查找， 其中， 所述 剩余部分的指定的特征信息为未在本地查找到相匹配的特征记录的特征信息；
换而 t之， 如果客户端在本地的安全识别库中查找后还存在不能识别的单个特征或特征组 合， 即本地不能最终确认所述 Android安装包的安全性， 此时需要上传到服务器进行检测； 上传 时， 可以将剩余部分的指定特征 （即不能识别的特征） 上传， 也可以将全部的指定特征上传， 这样可以对本地识别出的特征在服务器上进行复查；
具体的， 指定特征上传后， 在服务器预置的安全识别库中查找与指定的单个特征信息或其 组合相匹配的特征记录； 其中， 所述服务器预置的安全识别库中包舍特征记录及特征记录对应 的安全级别， 每条特征记录中包舍单个特征信息或特征信息的组合；
步骤 452, 客户端接收服务器返回的钎对所述 Android安装包的安全检测结果， 所述安全检 测结果中包舍服务器查找到的特征记录对应的安全级别；
步骤 462,客户端将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后在客 户端用户界面显示。
基于上述图 2、 图 3和图 4实施例的内容， 下面通过本申请提供的另一实施例， 说明上述各 实施例的应用场景。 具体如下：
客户端在本地预置的安全识别库中查找之前， 还可包括以下处理步骤：
依据预设的配置信息， 确定直接将所述指定的特征信息上传到服务器查找， 或者直接在本 地查找， 或者提示用户选择在本地查找还是上传到服务器查找。
其中， 所述预设的配置信息可包括以下几种：
1 ) 当所述配置信息表示不允许提供本地预置的安全识别库时， 确定直接将所述指定的特征 信息上传到服务器查找；
根据实际应用的需要， 可能存在不允许在客户端设置安全识别库的情况， 此时， 客户端提 取出特征信息后， 可以直接上传到服务器检测。
2 ) 当所述配置信息表示优先在本地查找时， 确定直接在本地查找；
这种情况下， 客户端提取特征信息后， 会自动在本地查找。 这是一种实际应用中普遍使用 的模式， 因为客户端通常会从服务器下载或从 PC机安装安全识别库， 所以可以优先使用本地安 全识别库进行查找。
进一步地， 客户端还可以在配置信息中设置两种情况：
其一， 如图 3实施例所述， 本地查找完后， 全部上传服务器再次复查；
其二， 如图 4实施例所述， 本地查找完后， 依据本地查找结果确定是否需要上传服务器查 找。
实际应用中，一款手机中可能安装上百个软件应用程序， 但是由于客户端本地容量有限， 一般只能识别出 20个左右的应用程序， 对于剩余的将近 80款软件应用程序未能识别， 此时的 配置可以是在本地查找完后， 全部上传服务器再次复查， 也可以配置成将本地未能识别的特征 上传服务器继续查找。 实际情况下， 将全部特征都上传复查是一种比较简便、 能够保证识别准 确度的方式。
3 ) 当所述配置信息表示优先由用户选择时， 确定提示用户选择在本地查找还是上传到服务 器查找。
这种情况下， 需要由用户参与选择， 客户端提取出特征信息后， 在客户端用户界面显示提 示信息， 提示用户选择在本地查找还是上传到服务器查找。 通常， 如果用户手机有包月的上网 流量， 则可以选择上传服务器查找， 因为这样查找的准确率更 S; 如果上网流量用完， 又不想 额外耗费更多流量， 则可以选择仅在本地查找， 或者优先在本地查找， 如果本地查找结果不全， 再将剩余未识别的特征上传服务器查找。
总之， 实际应用中的很多场景下， 都可灵活选择以上任意一种或几种实现方式的组合， 本 申请不再 列举。
而无论上述的哪种应用情况， 上传到服务器的安全检测过程都可参照下图 5所示的流程。 参照图 5 ,其示出了本申请另一实施例所述一种钎对 Android应用程序的服务器侧的安全检 测流程图。
无论客户端本地是否对提取的特征进行检测， 只要客户端将特征上传到服务器， 服务器就 会按照以下流程进行检测：
步骤 501 , 服务器接收客户端上传的指定的特征信息， 所述指定的特征信息是客户端从 Android安装包中提取而出；
步骤 502,在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征 记录； 其中， 所述服务器预置的安全识别库中包舍特征记录及特征记录对应的安全级别， 每条 特征记录中包舍单个特征信息或特征信息的组合；
步骤 503 ,服务器将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检 测结果中发送给对应的客户端。
优选地， 当在服务器预置的安全识别库中未查找到相匹配的特征记录时， 还可以包括以下 步骤：
识别所述指定的特征信息， 并根据识别结果确定与所述指定的单个特征信息或其组合相匹 配的特征记录及特征记录对应的安全级别；
将所述特征记录及特征记录对应的安全级别更新到所述服务器预置的安全识别库中。
其中， 所述识别过程中可以介入人工识别， 帮助准确定位识别结果。 例如， 目前的病毒、 木马和其他恶意软件都是产业化运作， 甚至有商业公司参与其中， 它们制作、 发布恶意软件形 成了正规化、 流程化的链条， 其中一个环节就是"杀毒软件免杀测试"。
简单地说， 就是这些专业的制作者， 在散发自已的恶意软件之前， 都会先用几大杀毒软件 公司的杀毒软件更新到最新的病毒库之后扫描一遍， 如果被杀毒软件报告为病毒， 那么它们就 会尝试去修改自已的恶意软件， 直到杀毒软件最终扫不出来为止。
理论上讲， 如果只考虑一对一的情况， 无论设计什么样的查杀逻辑， 终归能被对手分析出 规律， 从而找出绕过的方法。 一般地查杀， 对于某个应用， 如果本地查杀引擎穷举所有的特征 记录之后， 仍没有匹配的记录， 那么扫描就结東了。
而本申请实施例中服务器查杀的优势就在于： 穷举已知的所有特征记录都没有匹配， 那么 就将该应用的特征信息归档， 交给检测中心分析处理。 检测中心通过人工介入分析之后， 是安全或者恶意软件， 都会更新服务器的安全识别库， 这样， 下一次服务器杀查询相同的应用 特征的时候， 就能即时返回结果。 因此， 即便恶意软件的制作者暂时找到了绕过当前查杀的方 法， 通过了 "免杀 "的测试， 但等这个恶意软件真正发布到市场上之后， 还是很快会被服务器查 杀识别定位。
综上所述， 上述各实施例中， 钎对 Android应用程序的安全检测既可以在客户端本地完成， 也可以在服务器完成， 还可以将本地检测与服务器检测相结合。 无论哪种检测模式， 都可通过 下面的详细过程实现。
在查询安全识别库的过程中， 本申请实施例提供了一种犹化的查询方法， 这种查询采用对各项 特征进行组合查询的方式， 可进一步提髙检测效率和检测的准确率。 其中， 所述安全识别库可 以是客户端本地设置的安全识别库， 也可以是服务器设置的安全识别库。
所述查询的基本思路是：对提取的 Android安装包的几项关键特征，在安全识别库中进行组 合查询， 当发现匹配的特征记录时， 返回该特征记录所对应的安全信息。 其中， 所述安全信息 可以包括安全级别的描述， 以及与安全级别相对应的提示信息。
下面结合图 6所示的流程， 通过具体举例说明这种查询过程。
参照图 6, 其示出了本申请实施例所述在安全识别库中进行查找的流程图。
首先， 假设安全识别库中采用了三种特征信息， 分别是特征一、 特征二和特征三。 所述"特征 一"、 "特征二' '和"特征三"并不特指某项特征， 而是可根据实际情况来设定。 当然， 实际情况中 采用的特征不限于三种， 此处仅用作举例说明。
基于这三种特征， 所述安全识别库中设定了由其中的单个特征和特征组合构成的特征记录， 这些特征记录包括： 包舍特征一、 特征二、 特征三的特征记录；
包舍特征一、 特征二的特征记录；
包舍特征一、 特征三的特征记录；
包舍特征一的特征记录， 是指仅包舍特征一；
包舍特征二的特征记录， 是指仅包舍特征二；
包舍特征三的特征记录， 是指仅包舍特征三。
由于包舍特征二、 特征三的特征记录在实际应用中无法起到明显的检测作用， 所以此处删 除该条特征记录。 当然， 根据实际应用的需要， 也可能将上述给出的某些特征记录省略。
基于上述设定的安全识别库， 下面通过步骤 301至步骤 306来说明查询安全识别库的过程。 具体 如下：
步骤 601 , 判断是否找到包舍特征一、 特征二、 特征三的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 602;
步骤 602, 判断是否找到包舍特征一、 特征二的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 603;
步骤 603, 判断是否找到包舍特征一、 特征三的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 604;
步骤 604, 判断是否找到包舍特征一的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 605;
步骤 605, 判断是否找到包舍特征二的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 606;
步骤 606, 判断是否找到包舍特征三的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 则扫描结東。
上述流程中， 需要注意的是， 匹配的特征记录不一定是恶意软件的记录， 也可以是正常软 件的记录。 例如， 某安全产品的 APK数字签名的 MD5特征值始终为
dc6dbd6e49682a57a8b82889043b93a8, 假设上图中的 "特征一"就是指 APK数字签名的 MD5 , 那 么当棰索到 MD5 值 =dc6dbd6e49682a57a8b82889043b93a8 的特征记录时， 该特征记录对应的返 1SJ结果应该为"安全 "， 因而就不用进行下面的步骤了， 直接识别为安全的软件。
下面通过一个具体的例子说明上述流程。
假设某手机上有 3款应用 （实际手机至少有几十款应用， 此处为说明方便而简化了） ：
1. 手机系统自带的拔号键盘；
2. 某款手机安全产品；
3. 木马 Pico。
首先分别提取所述 3款应用的特征信息， 具体如下：
1. 手机系统自带的拔号键盘
特征一： APK包名, packageName = com. android. phone;
特征二： APK版本号， versionCode^8;
特征三： APK数字签名的 MD5值，
sigHash= 8ddb342f2da5408402d7568af21 e29f9;
2. 某款手机安全产品
特征一： APK包名, ackageName = com.qihoo360.mobilesafe;
特征二： APK版本号， versionCode^l37;
特征三： APK数字签名的 MD5值，
sigHash= dc6dbd6e49682a57a8b82889043b93a8;
3. 木马 Pico
特征一： APK包名, ackageName = com.svox.pico; 特征二： APK版本号， versionCode^l ;
特征三： APK数字签名的 MD5值，
sigHash= e89bl 58e4bcf988ebd09eb83f5378e87。
假设安全识别库中有以下特征记录， 特征记录以数据表的形式保存：
表 1: 特征一 +特征二 +特征三
Key com.svox.pico— 1— e89bl58e4bcf988ebd09eb83f5378e87； value- -木马; 表 2: 特征一 +特征二 表 3: 特征一 +特征三
Key- com. qihoo360.mobilesafe_ dc6dbd6e49682a57a8b82889043b93a8;
value- -安全;
表 4: 特征一
表 5: 特征二 表 6: 特征三
Key 8ddb342f2da5408402d7568af21 e29f9;
Value 安全。
需要说明的是， 上述不为空的表 1、 表 3和表 6中， 每个表都可能包舍多条特征记录， 而不 仅仅是上述列举出来的情况。 例如， 表 6中， 还可以包括特征三的 Key和 Value为其他值的特 征记录。
查询时， 分别将 3款应用的特征在安全识别库中按照表 1->表 2->.…的顺序查询， 得到以下 查询结果：
对于应用 1 : 手机系统自带的拔号键盘
表 1 没有查询到
表 2 没有查询到
表 3 没有查询到
表 4 没有查询到
表 5 没有查询到
表 6 查询到了， 结果是 "安全 ' 查询结東， 返 结果。
对于应用 2: 某款手机安全产^
表 1: 没有查询到
表 2: 没有查询到
表 3: 查询到了， 结果是"安全' 查询结東， 返回结果。
对于应用 3: 木马 Pico
表 1: 查询到了， 结果是 "木马 "， 查询结東， 返 结果。
假设有一款应用， 表 1 ~表6都没有查询到： 那么返回结果为"未知"。
如果 value是其它的值， 如"危睑 "、 "谨慎 "， 则按照上述方式依此类推。
上面图 6所示的流程仅是举例说明， 用于通过一个具体的例子使本领城技术人员方便了解 查询过程， 但由上面的例子可以总结出这种查询的本质过程， 如图 7所示。
参照图 7, 其示出了本申请另一实施例所述在安全识别库中进行查找的流程图。
步骤 701 , 将所述指定的特征信息进行组合， 得到至少包舍两个特征的各项特征组合； 所述指定的特征信息是指从待检测的 Android安装包中提取出的指定的特征信息。
所述组合是指各种可能的组合， 例如， 将上述从某个应用中提取出的特征一、 特征二、 特征 三进行三个特征的组合和两两组合， 可得到包舍特征一、 特征二、 特征三的特征组合， 包舍特 征一、 特征二的特征组合， 包舍特征一、 特征三的特征组合， 以及包舍特征二、 特征三的特征 组合， 共四项特征组合。 但是， 上例中根据实际应用的需要没有使用包舍特征二、 特征三的特 征组合。
步骤 702, 从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组合相匹配的 特征记录， 如果未查找到， 则继续步骤 703;
例如， 从包舍特征一、 特征二、 特征三的特征组合开始查询， 钎对上述的应用 1和应用 2, 均没有在安全识别库中查找到相匹配的特征记录， 则继续步骤 703; 但是对于应用 3 , 则在表 1 中查询到了匹配的特征记录， 则直接返回相应结果。
步骤 703, 逐个减少特征组合中的特征个数， 钎对减少了特征个数的特征组合， 继续在所述安全 识别库中查找与所述特征组合相匹配的特征记录， 如果未查找到， 则继续步骤 704;
如果查找到， 则返回相应结果。
例如， 对于最多包舍三个特征的特征组合， 减少一个特征后的特征组合包舍两个特征， 那么对这 些包舍两个特征的特征组合进行查找。
在查找过程中， 钎对特征个数相同的多项特征组合， 可以按照预先设定的先后顺序进行查找。 例如， 图 6所示流程中， 包舍两个特征的特征组合一共有 3个， 去除不使用的一个特征组合， 剩 下的两个特征组合的查找顺序是： 先对包舍特征一、 特征二的特征组合进行查找， 然后再对包舍 特征一、 特征三的特征组合进行查找。
需要说明的是， 所述预先设定的先后顺序需要根据实际情况下的特征定义、 特征组合情况 来设定， 而不局限于某种设定情况。 实际应用中， 可能有很多种设定情况， 在此不——列举。
步骤 704, 在所述安全识别库中查找与单个特征信息相匹配的特征记录。
在查找过程中， 钎对单个特征信息， 也可以按照预先设定的先后顺序进行查找。
例如， 图 6所示流程中， 先查找包舍特征一的特征记录， 然后查找包舍特征二的特征记录， 最后 查找包舍特征三的特征记录。
如前所述， 所述预先设定的先后顺序需要根据实际情况下的特征定义、 特征组合情况来设 定， 而不局限于某种设定情况。 实际应用中， 可能有很多种设定情况， 在此不——列举。
图 7所示的这种查找的先后顺序， 具有以下特点：
第一， 这种查找顺序是按照检测精度从 s到低的顺序设置的， 可以最大程度地避免恶意软件的漏 检、 错检；
如果包舍最多特征的一项特征组合能够与安全识别库中包舍最多特征的一条特征记录相匹配，那 么得到的查找结果是精确的；
反之， 按照流程从上到下的顺序， 随着查找条件的放宽， 检测精度也逐渐在降低。
基于此， 一个待检测的 Android应用程序可能同时匹配上安全识别库中的两条特征记录， 但是 它在检测精度较 S的查找条件时就会被检测出来， 因此该流程很好地保证了检测的准确度。
第二， 这种查找顺序几乎可以对所有的 Android应用程序进行检测；
换而 t之， 按照这个流程， 一个木马可以被检测出来，一个安全软件通过检测也可以得到"安全" 的识别结果。
第三， 特征一、 特征二、 …的定义顺序会影响整个流程的查找顺序；
对每个特征的定义确定后 （如"特征一 "指 APK包名， "特征二' '指 APK版本号， 等等） ， 图 4流 程中查找的先后顺序也就确定了。如果将 "特征二"定义为 APK包名，将"特征一"定义为 APK版本号， 那么图 4的流程中， "查找包舍特征一、 特征三的特征记录"修改为 "查找包舍特征二、 特征三的特征 记录 "； 并且， 后面的流程中， 查找特征一和查找特征二的先后顺序也要互换一下， 即先查找特征二， 再查找特征一， 最后查找特征三。
综上所述， 由以上几点可以看出， 在实际设计安全识别库的时候， 选取的特征信息不同， 由这些 特征组合出来的特征记录也会有很大差别，而且特征的组合还会影响特征个数相同的特征记录的先后 查询顺序。 由此设计出来的检测流程可能有很多种， 但是， 所有各种可能的流程都是基于上述图 4所 述的过程得出来的， 因此均在本申请的保护范围之内。
基于上述内容， 为了使本领城技术人员更加了解本申请的内容， 下面将通过举例说明特征提取过 程。
本例中提取的特征包括：
1 ) Android安装包包名： ackageName
2 ) Android安装包版本号： versionCode
3 ) Android安装包的数字签名的 MD5： signature[0]
4 ) Android组件 receiver
5 ) classes. dex 中的指令
6 ) ELF 文件中的字符串
7 ) assets, res, lib 等目录下各文件的 MD5
8 ) Android组件 service, activity 下面以几个恶意软件的实例， 来说明上面几项特征的含义和检测的整个过程。
1、 从 Android安装包的 AndroidManifest.xml文件中提取出包名， 版本号， Android组件 receiver ^ service、 activity的特征；
按照 Android 系统的设计要求， 所有的应用程序， 包括木马， 其模块（如 receiver, service, activity 等）要想被 Android 系统所执行， 需要在 AndroidManifest.xml文件中声明其模块的类 名。 特别是很多木马， 都是把自己的代码模块嵌入到正常软件中， 而显然， 正常的软件的代码 是不会主动去调用木马的代码模块的， 那么木马要想让自己的代码被执行， 就必须去修改正常 软件的 AndroidManifest.xml 文件， 在其中加入自己的类名， 从而就暴露了自己的踪迹， 可以作 为识别的特征。
样本一： Android. Geinimi 魔音
Android.Geinimi 木马通常寄生在正常的 Android应用里面， 例如， 在这个样本中， 它是寄 生在一款叫做 "魔音 "的应用中。 解压缩样本的 Android安装包， 可以得到根目录下的
AndroidManifest.xml 文件。 这个文件是 Android Binary XML ( AXML )格式的， 可以用
AXMLPrinter2 工具解码成文本 XML 格式。
解码的结杲如下：
Figure imgf000015_0001
<caiegory android:name= drokl」nfe ，C tegoy, LAUNCHER" I>
<inteni-fi!fer
<activiiy
； receiver android:name=¾om,ger?imL^dSer iceRecei
intent-fifter>
Figure imgf000015_0002
/receiver
^service a n dro id： enabl ed^^rue" androki:name="ccT g r¾in ci fem，GoogteKeybo n a ndro id； lie be! ="G oogfe 键盘"
^activity a ctrokHheme="@a dr k±s¾ife/The e.Bfecl<. oT¾eBa 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=¾nlro jnienicat¾ory. LAUNCHER" I>
/inient-fiif.er>
Figure imgf000015_0003
<uses-permission
android:name="com.andro?d. launcher, perm issfon. i STAL L..SHORTCUT5 >
<uses-permission
android:name=: drodp^' isskm，AGCESS...F E.. LOCATION" /
uses-permission andr。id:name=¾ndr d,p ;rnfesk> ACCESS„LOCATiO r /> < manfest>
1 )其中， package="com.wbs"中的 com.wbs 就是该 Android安装包的 ackageName, android:versionCode="l"中的 "1"就是 versionCode。 2 ) receiver 的特征从下面这段提取：
receiver android:name^"com.geinimi.AdServiceReceiver">
<intent-filter>
<action android:name^"android.intent.action.BOOT_COMPLETED" />
<category an droid:name^" android. intent. cat egory.LAUNCHER" />
</inteot-filter>
</receiver>
这段代码的舍义是，当 Android 系统 android. intent. action.BOOT_COMPLETED(即手机开机启动） 事件发生之后， 调用名为 com.geinimi.AdServiceReceiver 的类。
下文把这条特征写成：
android.intent. action.BOOT— COMPLETED=comgeinimi.AdServiceReceiver。
3 ) service的特征从下面这段提取：
<service android: enabled- 'true" android:name^"com.geinimi. custom. GoogleKeyboard" 中间略) /> 这段代码的舍义是， 本 APK应用中提供了一个 Android服务程库 , 名为
com.geinimi.custom.GoogleKeyboard。
下文把这条特征写成：
service^comgeinimi. custom. GoogleKeyboard。
4 ) activity的特征从下面这段提取：
<activity android:theme^"@android:style Theme.Black.NoTitleBar"
android:label- '@string/app_name" an droid:name^"com.geinimi. custom. Ad0000_00000006">
<intent-filter>
<action android:name^" android, intent, action. MAIN" />
category an droid:name^" android. intent. cat egory.LAUNCHER" />
</inteot-filter>
</activity>
这段代码的舍义是， 用户在 Android 系统的应用列表界面点击"魔音' '的图标的时候， 调用名为 com.geinimi.custom. Ad0000_00000006的类。
下文把这条特征写成：―
MAIN_LAUNCHER=com.geinimi. custom. Ad0000_00000006.
此外， 可以注意到前面的 XML 中， activit 其实有两个， 除了上面所述的以外， 还有一个， 如 下：
<activity android:label- '@string/app_name" android:name^".MagicVoiceActivity">
<intent-filter>
category an droid:name^" android. intent. cat egory.LAUNCHER" />
</inteot-filter>
</activity>
其实， 这才是真正的"魔音"应用的主程库入口。 AndroidGeinimi木马为了寄生到正常的应用中， 采用了修改宿主应用的主程库入口指到自已，等木马被启动之后，再跳回宿主应用主程库入口的方法。 不过本申请实施例所述的检测方法最初并不对此进行分析，而是先提取、记录特征，到最后统一判断。
所以这个 activity也提取特征， 下文记为：
LAUNCHER=. MagicVoiceActivity
需要指出的是， 上文为了便于理解， 介绍的是"手工"从 AndroidManifest.xml 中提取特征的步骤。 而实际应用中， 为了提 S特征提取的效率， 可以通过调用 Android Framework的相应 API来完成的， 例如，对于已经安装到手机上的 APK文件，直接用 PackageManager.getlnstalledPackagesO方法就可以 查询到所有已安装的 APK文件的 packageName, versionCode等特征。 显然， 提取特征有多种办法， 而整个检测遝辑不受具体的提取特征的方法的影响。
2、 从 Android安装包的 META-INF\ 目录下的. RSA文件中提取出所述 Android安装包的数 字签名；
关于 META-INF 目录， 里面有个 .SF 文件， 内容类似为：
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— arrows— 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=
其中， 每一项都是一个文件的校验信息， 例如 res/raw/ic_menu_gallery.png 的校验信息是 d0vnA3rU6DlMuGhA3nzu5FtXaXQ=, 如果文件被墓改， 就^ ^与校验信息不匹配， Android 系统就能 发现文件被墓改， 从而拒绝安装。
所述校验信息的生成， 是用数字证书的私钥生成的， 所以无法伪造。 META-INF 目录下面有个 公钼文件， 扩展名为 .RSA, Android 系统用公钼来验证校验信息是否是伪造的。 而提取特征， 就是 去检查 .RSA文件的公钼信息， 因为私钥和公钼是配对的， 所以只要提取了公钼的特征， 就能对应上 唯一的私钥, 而私钥是由应用的开发者自行保管的， 所以可以用来区别木马和正常软件的开发者。
前文已经提到， Android 系統要求每个 APK都要包舍数字签名。 这个数字签名的信息可以通过 Android的 API来完成， 例如， 已安装到手机上的 APK文件， 可以通过
PackageManager.getlnstalledPackagesO方法查询每个 APK 包舍的数字签名。
一个 Android安装包可以被多次签名，最终以最后一次签名为准。如果是通过 API获取的数字签 名， 那么得到的是一个数组， 变量名为 signature, 最后一次签名的数据是 signature[0]。
此外， 还有其它 API也可以查询 APK包中的数字签名， 这里不——列举。 而且， 手工提取 signature[0]特征也可以， 解压缩样本的 Android安装包， 在 META- F/目录下会看到 CERT.RSA 文 件， 这就是签名证书。 用 ke tool-printcert-file CERT.RSA命令可以查看其中的详细信息， 如下： 所有者: CN=Android Debug, 0= Android, C=US
签发人: CN=Android Debug, 0= Android, C=US
序列号 :4ccd020e
有效期： Sun Oct 31 13:43:42 CST 2010 - Mon Oct 31 13:43:42 CST 2011
证书指纹：
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
签名算法名称: SHAlwithRSA
版本： 3
3、 从 Android安装包的 classes. dex文件中提取出可执行指令；
前文已经提到， 大部分 Android应用都主要是由 Java语 t编写， 编译之后生成了 Dalvik虛拟机 的字节码（byte code ) , 打包成了 classes.dex 文件。 解析 classes.dex文件， 反编译其字节码， 就可 以得到应用程序所要执行的指令。
可以挑选指令中能代表恶意软件特征的指 为特征码，当发现 classes.dex 文件中包舍这样的特 征码时， 就作为一个特征。 例如， Android. Geinimi木马为了隐藏自已， 将一些关键数据 （如木马服 务器信息）加密之后写入代码中， 这些被加密的数据反而成为了检测识别它的特征。 用 dexdump 工 具分析 classes.dex 文件可看到输出中包舍以下片段：
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)
上述片段就可以提取作为检测识别的特征。
当然， dexdump 工具只是显示这些特征数据的手段之一， 也可以通过其他方式自行实现解析、反 编译和识别 classes. dex 文件的功能。
综上所述， 样本一不包舍 ELF 文件， 所以没有提取到 ELF特征。
从样本一中提取了上述特征之后， 假设安全识别库中存在以下特征记录：
特征一： ackageName^com.wbs
特征二： 无
特征三： MD5(signature[0])= 294f08ae04307a649322524713318543 特征一 +特征三： 安全级别为"木马"
当检测流程走到"找到包舍特征一、 特征三的木马？ "时， 找到记录， 返回结果为"木马"。
4、 从 Android安装包的 lib\ 目录下提取出 ELF文件的指令或字符串。
样本二： Androi DroidKungFu功夫木马
功夫木马有数十种变种， 它一般伪装成一个正常的应用 （例如 "图库锁"之类） ， 诱骗用户安装、 运行之后， 运行 native executable文件， 在用户手机上安装后门， 使得木马制作者可以远程操纵用户 手机。
对功夫木马各 APK的 packageName等特征的提取， 与样本 致， 在此不再赘述。
下面主要介绍 ELF特征的提取：
在功夫木马的 Android安装包的 lib/armeabi 目录下， 有一个 libxxx.so 文件， 文件名随着功夫木 马各变种有所变化， 例如 Hbadv3.so, libdl.so等。 这是一个 Linux ELF 文件， 可以用 readelf等工具 读取其信息， 下面是摘取的片段：
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
... (中间略）
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
这个片段是 libadv3.so 文件导出的符号表，其中 Type 为 OBJECT的符号是关注的重点，其中的 — bindata 实际 ϋ马子包， 所以可以提取出来作为特征。
当然， ELF 文件是灵活多变的， 恶意软件的 ELF 文件也不仅仅表现为这种形式， 所以 ELF 文 件的特征提取可以有多种方式， 除了直接从符号表提取特征外， 还可以提取代码段的片段、 字符串等 作为特征。
本实施例提取的特征记为： _bindata CONTAINS ELF chown unlink /system¾in; 其舍义是， 在. so 文件的符号表中查询 _bindata的符号，其指向的数据中包舍 "ELF'、 "chown", "unlink", '7system¾in"4 组字符串。
假设这条特征在安全识别库中记录为：
特征四： _ bindata CONTAINS ELF chown unlink /system/bin
安全级别： 木马
当检测流程走到"找到包舍特征四的木马？ "时， 找到记录， 返回结果为"木马"。
上述实施例是以手机中的应用为例进行说明，但具体应用中也可以应用到等其他基于 Android平 台的移动终端的应用检测中， 其实施原理与上述实施例相似， 故不再赘述。
需要说明的是， 对于前述的各方法实施例， 为了简单描述， 故将其都表述为一系列的动作组合， 但是本领城技术人员应该知悉， 本申请并不受所描述的动作顺序的限制， 因为依据本申请， 某些步骤 可以采用其他顺序或者同时进行。 其次， 本领城技术人员也应该知悉， 说明书中所描述的实施例均属 于优选实施例， 所涉及的动作并不一定是本申请所必需的。
基于上述方法实施例的说明， 本申请还提供了相应的系统实施例， 包括设置在客户端的安全检测 系统（如图 8至图 10所示） ， 以及设置在服务器的安全检测系统（如图 11、 图 12所示） 。 下面分 别详细说明。
参照图 8 ,其示出了本申请实施例所述一种设在客户端钎对 Android应用程库的安全检测系统的 结构图。
所述钎对 Android应用程库的安全检测系統设置在客户端， 可以包括以下模块：
特征提取模块 81 , 用于扫描 Android安装包， 并从所述 Android安装包中提取出指定的特征 信息；
上传模块 82, 用于将所述指定的特征信息上传到服务器， 在服务器预置的安全识别库中查找与 指定的单个特征信息或其组合相匹配的特征记录； 其中， 所述服务器预置的安全识别库中包舍特征记 录及特征记录对应的安全级别， 每条特征记录中包舍单个特征信息或特征信息的组合；
显示模块 83, 用于接收服务器返回的钎对所述 Android安装包的安全检测结果， 并在客户端用 户界面显示， 所述安全检测结果中包舍服务器查找到的特征记录对应的安全级别。
对于上述图 8所示系统实施例而 t , 由于其与方法实施例基本相似， 所以描述的比较简单， 相关 之处参见图 2所示方法实施例的部分说明即可。
优选地， 在本申请的另一实施例中， 如图 9所示， 所述设在客户端的安全检测系统除包括特征 提取模块 81、 上传模块 82和显示模块 83外， 还可以包括：
本地检测模块 84, 01于在本地预置的安全识别库中查找与指定的单个特征信息或其组合相匹配 的特征记录； 其中， 所述本地预置的安全识别库中包舍特征记录及特征记录对应的安全级别， 每条特 征记录中包舍单个特征信息或特征信息的组合；
所述本地检测模块 84还用于将本地查找到的特征记录对应的安全级别包舍在所述 Android安装 包的本地安全检测结果中。
优选地， 所述系统还可以包括：
合并模块 85 ,用于将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后通过所 述显示模块 83在客户端用户界面显示。
优选地， 所述本地检测模块 84具体可以包括以下子模块：
特征组合子模块， 于将所述指定的特征信息进行组合，得到至少包舍两个特征的各项特征组合； 第一查找子模块， 用于从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组 合相匹配的特征记录；
第二查找子模块， 用于当第一查找子模块未查找到时， 逐个减少特征组合中的特征个数， 钎对减 少了特征个数的特征组合， 继续在所述安全识别库中查找与所述特征组合相匹配的特征记录；
第三查找子模块， 用于当第二查找子模块未查找到时， 在所述安全识别库中查找与单个特征信息 相匹配的特征记录。
优选地， 所述第二查找子模块在查找过程中， 钎对特征个数相同的多项特征组合， 按照预先设定 的先后顺序进行查找； 所述第三查找子模块钎对单个特征信息， 按照预先设定的先后顺序进行查找。
对于上述图 9所示系统实施例而 t , 由于其与方法实施例基本相似， 所以描述的比较简单， 相关 之处参见图 3所示方法实施例的部分说明即可。
优选地， 在本申请的另一实施例中， 如图 10所示， 所述设在客户端的安全检测系统除包括特征 提取模块 81、 上传模块 82、 显示模块 83和本地检测模块 84外， 还可以包括：
取消上传模块 86, 用于当所述本地检测模块 84在本地预置的安全识别库中查找到与所有指定的 单个特征信息或其组合相匹配的特征记录时，取消将所述指定的特征信息上传到服务器， 并通过所述 显示模块 83将所述本地安全检测结果在客户端用户界面显示。
优选地， 当所述本地检测模块 84在本地预置的安全识别库中查找到与部分指定的单个特征信息 或其组合相匹配的特征记录， 则所述上传模块 82将全部或剩余部分的指定的特征信息上传到服务器 查找， 其中， 所述剩余部分的指定的特征信息为未在本地查找到相匹配的特征记录的特征信息； 所述合并模块 85将服务器返回的安全检测结果与所述本地安全检测结果合并， 合并后通过所 述显示模块 83在客户端用户界面显示。
对于上述图 10所示系统实施例而 t , 由于其与方法实施例基本相似， 所以描述的比较简单， 相 关之处参见图 4所示方法实施例的部分说明即可。
优选地， 在本申请的另一实施例中， 基于图 8、 图 9、 图 10各实施例的内容， 所述设在客户端的 安全检测系统还可以包括：
模式选择模块， 用于所述本地检测模块 84在本地预置的安全识别库中查找之前， 依据预设的配 置信息， 确定直接将所述指定的特征信息上传到服务器查找， 或者直接在本地查找， 或者提示用户选 择在本地查找还是上传到服务器查找。
其中， 当所述配置信息表示不允许提供本地预置的安全识别库时，确定直接将所述指定的特征信息上传 到服务器查找；
当所述配置信息表示优先在本地查找时， 确定直接在本地查找；
当所述配置信息表示优先由用户选择时， 确定提示用户选择在本地查找还是上传到服务器查找。 参照图 11 , 其示出了本申请实施例所述一种设在服务器钎对 Android应用程库的安全检测系统 的结构图。
所述钎对 Android应用程库的安全检测系統设置在服务器上， 可以包括以下模块：
接收模块 91 , 于接收上传的指定的特征信息， 所述指定的特征信息是从 Android安装包中提 取而出；
网 棰测模块 92, 用于在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹 配的特征记录； 其中， 所述安全识别库中包舍特征记录及特征记录对应的安全级别， 每条特征记录中 包舍单个特征信息或特征信息的组合；
发送模块 93, 用于将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测 结果中发送。
对于上述图 11所示系统实施例而 t , 由于其与方法实施例基本相似， 所以描述的比较简单， 相 关之处参见图 5所示方法实施例的部分说明即可。
优选地， 在本申请的另一实施例中， 如图 12所示， 所述设在客户端的安全检测系统除包括接收 模块 91、 网 棰测模块 92和发送模块 93外， 还可以包括：
特征识别模块 94, 用于当所述网 棰测模块在预置的安全识别库中未查找到相匹配的特征记录 时， 识别所述指定的特征信息， 并根据识别结果确定与所述指定的单个特征信息或其组合相匹配的特 征记录及特征记录对应的安全级别；
更新模块 95 , 用于将所述特征记录及特征记录对应的安全级别更新到所述安全识别库中。
优选地， 在本申请的另一实施例中， 基于图 11和图 12所示的各实施例， 其中的网 棰测模块 93具体可以包括以下子模块：
特征组合子模块，用于将所述指定的特征信息进行组合，得到至少包舍两个特征的各项特征组合； 第一查找子模块， 用于从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组 合相匹配的特征记录；
第二查找子模块， 用于当第一查找子模块未查找到时， 逐个减少特征组合中的特征个数， 钎对减 少了特征个数的特征组合， 继续在所述安全识别库中查找与所述特征组合相匹配的特征记录；
第三查找子模块， 用于当第二查找子模块未查找到时， 在所述安全识别库中查找与单个特征信息 相匹配的特征记录。
优选地， 所述第二查找子模块在查找过程中，钎对特征个数相同的多项特征纽合 , 按照预先设定 的先后顺序进行查找； 所述第三查找子模块钎对单个特征信息， 按照预先设定的先后顺序进行查找。
优选地， 所述上传的指定的特征信息包括以下中的一种或几种组合：
Android安装包的包名 ,版本号,数字签名 , Android组件 receiver的特征， Android组件 service 的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安装包目录下 各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件。
优选地， 所述安全识别库中的特征信息包括以下中的一种或几种组合：
各种样本 Android安装包的包名 ,版本号，数字签名 , Android组件 receiver的特征， Android 组件 service的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安 装包目录下各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述样本 Android安装包包括各种安全级别下的 Android安装包。
对于上述系统装置实施例而 t , 由于其与方法实施例基本相似， 所以描述的比较简单， 相关之处 参见图 6、 图 7所示方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不 同之处， 各个实施例之间相同相似的部分互相参见即可。
本发明的各个部件实施例可以以硬件实现， 或者以在一个或者多个处理器上运行的软件模 块实现， 或者以它们的组合实现。 本领城的技术人员应当理解， 可以在实践中使用微处理器或 者数字信号处理器（ DSP )来实现根据本发明实施例的 Android应用程库的安全检测系统中的一些 或者全部部件的一些或者全部功能。 本发明还可以实现为用于执行这里所描述的方法的一部分 或者全部的设备或者装置程序 （例如， 计算机程序和计算机程序产品） 。 这样的实现本发明的 程序可以存储在计算机可读介质上， 或者可以具有一个或者多个信号的形式。 这样的信号可以 从因特网网站上下载得到， 或者在载体信号上提供， 或者以任何其他形式提供。
例如， 图 13示出了可以实现根据本发明的 Android应用程库的安全检测方法的服务器， 例如 应用服务器。 该服务器传统上包括处理器 1310和以存储器 1320形式的计算机程序产品或者计 算机可读介质。存储器 1320可以是诸如闪存、 EEPROM(电可檫除可编程只读存储器）、 EPROM、 硬盘或者 ROM之类的电子存储器。 存储器 1320具有用于执行上述方法中的任何方法步骤的程 序代码 1331的存储空间 1330。 例如， 用于程序代码的存储空间 1330可以包括分别用于实现上 面的方法中的各种步骤的各个程序代码 1331。 这些程序代码可以从一个或者多个计算机程序产 品中读出或者写入到这一个或者多个计算机程序产品中。 这些计算机程序产品包括诸如硬盘， 紧致盘 （CD ) 、 存储卡或者软盘之类的程序代码载体。 这样的计算机程序产品通常为如参考图 14所述的便携式或者固定存储单元。 该存储单元可以具有与图 13的服务器中的存储器 1320类 似布置的存储段、 存储空间等。 程序代码可以例如以适当形式进行压缩。 通常， 存储单元包括 计算机可读代码 133Γ , 即可以由例如诸如 1310之类的处理器读取的代码， 这些代码当由服务 器运行时， 导致该服务器执行上面所描述的方法中的各个步骤。 下面结合附图和具体的实施方式对本发明作进一步的描述。
分析现有技术中的各种杀毒引擎， 由于移植自 PC上的杀毒引擎， 主要钎对的是 PC系统的特性 而设计， 而 PC系统与 Android系统既有相同的特性， 也有不同的特性，但现有技术并没有深入理解 Android系统本身的特点， 因此并不完全适合于 Android系统的杀毒， 存在着扫描速度慢、 误报 率 S的问题。
基于此， 本申请结合 Android系统本身的特点， 提出一种专门钎对 Android系统特性而设计 的杀毒方法， 下面先介绍设计思路。
在 Android系统上，一个可以安装、 运行的应用， 需要打包成 Android系统的 APK文件格 式。 APK是 Android application package file的缩写， 简称 APK文件， 即 Android安装包， 也可 以理解为 Android终端上安装的应用软件。 APK文件其实是 ZIP文件格式， 但后缀名被修改为 apk, 通过 Unzip等工具解压可以看到其内部的文件结构， 如下表所示:
Figure imgf000021_0001
表 1 Android安装包（ APK文件）一般通过 Android应用市场下载、 安装到手机上， 也可以通过 USB 数据线等数据线接口或无线数据传输的方式从 PC安装。 Android上的病毒、 木马和其他恶意软件想 要进入用户的手机， 也必须打包成 APK的形式。 反过来说， 如果不是一个合法的 APK文件， 它就无 法安装到用户手机上， 也就不会对用户产生危害。 基于这一点， 杀毒引擎就可以把查杀的目标集中到 对 APK文件的扫描上， 从而大大提髙扫描的效率。
那么， Android安装包 （ APK文件） 中的哪些信息可以作为扫描的重点， 钎对此问题本申请进 行了分析， 具体如下：
1 ) 包名
Android操作系统通过 APK的包名（ package name )对各个安装的 APK进行管理。 "包名 "源自于 Java 的 package 的概念， 按照 Java的 package的命名风格， 例如某个 Android安装包的包名是 com.qihoo360.mobilesafe. Android系统要求每个应用都声明一个唯一的包名。 如果要安装的 APK的 包名和当前手机上某个已有的应用的包名重复了， 那么 Android系统会拒绝安装。 Android平台下的 恶意软件也需要声明一个包名， 因此， 包名就可以作为识别恶意软件的一个重要特征。
2 )数字签名
出于安全性的目的， Android系统要求每个 APK都要包舍数字签名 ( digital signature )。 Android 系统在安装 APK文件的时候会检查 APK内部各文件的数字签名是否与其预先设定的数字签名一致， 如果不一致， 或者没有数字签名， 则认为文件已被墓改， 拒绝该 APK的安装和运行。 Android平台下 的恶意软件也不例外， 所以 APK文件的数字签名也可以作为识别恶意软件的一个重要特征。
3 ) AndroidManifestxml中列出的各模块的入口信息
AndroidManifest.xml是每个 APK文件所必需的全局描述文件， 里面列出了 Android安装包中应
01的每个模块的入口信息。 在 Android系统中， 只有在 AndroidManifestxml中列出了的模块， 才能够 被系统调用。 Android平台下的木马， 往往会伪装成正常的应用或游戏来诱骗用户安装， 其中有很多 木马就是寄生在一个正常的应用或游戏中， 用户运行它的时候， 看上去是原来的软件或游戏， 但寄生 在其中的木马模块在合适的时机就被激活， 从而感染用户的手机。 而因为 Android系統要求所有的模 块都要在 AndroidManifest.xml中列出， 这就为寻找寄生的木马提 ¾了重要线索。 因此，
AndroidManifestxml中列出的各模块的信息， 也是识别恶意软件的重要特征。
4 ) Dex文件和 ELF文件
在 Android系统的架构设计中， Android应用与整个系统平台之间的关系如图 15所示。 Android 应用通常是用 Java语 t开发的，它用 Android开发工具编译之后变成了二进制的字节码（byte code ) , 这些字节码被打包成 classes.dex文件， 由 Android平台的 Dalvik虛拟机来解释执行。 为了能够调用 Android系统功能 , Android系统提供了一套运行环境 ( Android Framework ) , Android应用调用系统 各功能都是通过调 Android Framework的库来实现的。
另一方面， Android系统也支持应 程序通过 JNI或者 native executable直接运行。 此时应用执行 的是直接在 CPU上运行的二进制机器码， 不需要经过虛扭机解释， 可以直接调用 Android库如 libc、 WebKit, SQLite, OpenGL ES等来调用系統各功能。如果 Android应用要通过 JNI或者 native executable 运行， 就需要将要执行的代码编译成 ELF文件格式。 ELF是 Executable and Linkable Format的缩写， 是 Android/Linux操作系统中可执行程序、 共享库的文件格式。
Android上的恶意软件要想在 Android系统中运行起来， 也要遵循上述架构规范。 因此， 在识别 恶意软件的过程中， 可以分别从 Dex文件 （即字节码文件）和 ELF文件提取相应的特征。
此外， 除上述列举之外， Android安装包的版本号、 Android安装包目录下各文件的 MD5值等 信息， 也可以作为识别恶意软件的重要特征。 其中， 上述的恶意软件包括病毒、 木马和其他恶意软 件。
本申请实施例综合了以上各个重要特征， 提出一种钎对 Android应用程序的安全检测方法， 可 以对 APK的上述各项特征进行扫描、 , 最终识别出各种恶意软件（包括病毒、 木马和其他恶意 软件） 。 而且， 本申请实施例的安全检测方法， 识别结果不局限于此， 还可以将正常的应用、 存在 安全风睑的应用和虽然正常但存在一些问题的应用全部检测出来， 以提示用户。
下面通过实施例对本申请所述方法的实现流程进行详细说明。
参照图 16, 其示出了本申请实施例所述一种 Android应用程序的安全检测方法流程图。
步骤 1601 , 扫描 Android安装包， 并从所述 Android安装包中提取出指定的特征信息； 所述指定的特征信息即指上述列举的各项重要特征， 如包名、 版本号、 数字签名、
AndroidManifestxml中列出的各模块的入口信息、 Dex文件和 ELF文件、 Android安装包目录下各 文件的 MD5值等。 这些指定的特征信息对于安全检测最具代表性， 因此也是用于检测的关键特征。
其中 , AndroidManifest.xml中列出的各模块的入口信息包括 Android组件中的特征。 Android开 发的四大组件分别是： 活动 (Activity), 用于表现功能； 服务 (Service), 后台运行服务， 不提供界面呈 现； 广播接收器 (Broadcas tReceiver), 用于接收广播； 内容提供商 ( Content Provider ) , 支持在多个 应用中存储和读取数据， 相当于数据库。
因此， 所述从 Android安装包中提取出的指定的特征信息可以包括：
Android安装包的包名， 和 /或， 版本号， 和 /或， 数字签名， 和 /或， Android组件 receiver 的特征， 和 /或， Android组件 service的特征， 和 /或， Android组件 activity的特征， 和 /或， 可 执行文件中的指令或字符串， 和 /或， Android安装包目录下各文件的 MD5值；
需要说明的是， 所述"和 /或"是指从 Android安装包中可以单独提取出其中任意一项特征信息 用作安全检测 , 也可以提取出多项特征信息的组合用作安全检测。 当然， 同时提取多项特征进行检测 的效果要明显优于单项特征， 这在后面图 15所示的实施例中将进行详细说明， 所以此处略。
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件。
具体地， 在本申请的一种优选实施列中， 所述可执行文件包括 Dex文件， Dex文件主要是
APK中的 classes.dex文件，即 Dalvik Executable ( Dalvik虛拟机可执行文件 )。公知的是， Dalvik 是用于 Android平台的 Java虛拟机。 Dalvik虛拟机 ( Dalvik VM )是 Android移动设备平台的核 心组成部分之一。 它可以支持已转换为 .dex (即 Dalvik Executable ) 格式的 Java应用程序的运 行， . dex格式是专为 Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。 Dalvik 经 过优化， 允许在有限的内存中同时运行多个虛拟机的实例， 并且每一个 Dalvik应用作为一个独 立的 Linux 进程执行。 独立的进程可以防止在虛拟机崩溃的时候所有程序都被关闭。
更为优选的是， 所述可执行文件还可以包括扩展名为. jar的文件。 Android安装包中的 JAR 文件其实就是 Dex文件， 只不过其扩展名为. jar, 对于 APK中除 classes.dex之外的其他文件， 只要判定其为 Dex文件即可决定是否进行扫描。
在实际应用中， 所述 Dex文件还可以包括其它 Dex格式的文件。
此外， 上述 Android安装包目录下各文件的 MD5值可以是数字签名的 MD5值， 也可以是 表 1中 res\、 assets\, lib\ 目录下各文件的 MD5值。
基于以上列举的指定特征， 可通过以下方式从 Android安装包中提取出各项指定的特征信 息， 参照表 1可知：
从所述 Android安装包的 AndroidManifest.xml文件中提取出以下信息中的一种或几种组合：： 包名，版本号， Android组件 receiver的特征， Android组件 service的特征， Android组件 activity 的特征；
和 /或，
从所述 Android安装包的 META-INF\ 目录下的 .RSA文件中提取出所述 Android安装包的数 字签名；
和 /或 ,
从所述 Android安装包的 classes. dex文件中提取出可执行指令；
和 /或，
从所述 Android安装包的 lib\ 目录下提取出 ELF文件的指令或字符串。
其中， 所述"和 /或' '的理解与上相同， 即可以从 Android安装包中单独提取出其中任意一项特征 信息用作安全检测， 也可以提取出多项特征信息都用作安全检测。
关于具体的特征提取方法， 将在后面的举例说明中进行解释。
步骤 1602, 在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录； 其 中， 所述安全识别库中包舍特征记录及特征记录对应的安全级别 ,每条特征记录中包舍单个特征信息 或特征信息的组合；
步骤 1603,将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结果中 显 。
所述安全识别库通常需要预先设置在客户端本地， 如手机文件系统中， 安全识别库中预置了多条 特征记录， 其中， 单个特征信息可以构成一条特征记录， 多个特征信息的组合也可以构成一条特征记 录。 例如，一个安全识别库中预置了几十条特征记录， 其中， 第一条特征记录中列出了某种病毒的 Android安装包包名， 第二条特征记录中列出了某个正常应用的 Android安装包版本号及其数字 签名的 MD5值， 第三条特征记录中列出了某个正常应用的 Android安装包包名及其 receiver特 征， 第四条特征记录中列出了某种木马的 Android安装包包名、 版本号及其 ELF文件中的特定 字符串， 等等。
总之， 安全识别库中既收集了识别病毒、 木马等各种恶意软件的特征信息， 也收集了识别 正常应用的特征信息， 而不同于很多仅仅用于识别恶意软件的数据库。
因此， 所述安全识别库中收集的特征信息可以包括以下列举的：
各种样本 Android安装包的包名， 和 /或， 版本号， 和 /或， 数字签名， 和 /或， Android组件 receiver的特征， ： ί。/或， Android组件 service的特征， ： ί。/或， Android组件 activity的特征， 或， 可执行文件中的指令或字符串， 和 /或， Android安装包目录下各文件的 MD5值；
如前所述，所述"和 /或"也是指从各种样本的 Android安装包中可以单独提取出其中任意一项 特征信息用作安全检测， 也可以提取出多项特征信息的组合用作安全检测。
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述样本 Android安装包包括各种安全级别下的 Android安装包。
本申请实施例列举出安全、 危睑、 谨慎和木马四个安全级别。 其中， 各种安全级别的定义如下： 安全： 该应用是一个正常的应用， 没有任何威胁用户手机安全的行为；
危睑： 该应用存在安全风睑， 有可能该应用本身就是恶意软件； 也有可能该应用本来是正规公司 发布的正常软件， 但是因为存在安全漏洞， 导致用户的隐私、 手机安全受到威胁；
谨慎： 该应用是一个正常的应用， 但是存在一些问题， 例如会让用户不小心被扣费， 或者有不友 好的广告遭到投诉等； 当发现这类应用之后， 会提示用户谨慎使用并告知该应用可能的行为， 但是由 用户自行决定是否清除该应用； 木马： 该应用是病毒、 木马或者其他恶意软件， 此处为了简单统称为木马， 但并不表示该应用仅 仅是木马。
所以， 在设置安全识别库时， 可以将安全、 危睑、 谨慎和木马四个级别下的 Android安装包 都作为样本 Android安装包，从而由样本中的单个特征或特征组合得到的特征记录可分别对应着 一种安全级别及相关的行为和描述等信息。
例如， 上述的第一条特征记录和第四条特征记录分别对应的安全级别均为木马级别， 上述 的第二条特征记录和第三条特征记录分别对应的安全级别均为安全级别。
当然， 安全识别库中还可以设置一条特征记录， 列出某种木马的 Android安装包版本号及其 数字签名的 MD5值， 虽然这条特征记录使用的特征组合与上述第二条特征记录相同， 都使用了 版本号与数字签名 MD5值的组合， 但是这条特征记录对应的安全级别则为"木马"。
所以， 安全级别并不与某一种特定的特征或特征组合相对应， 而是与具体的特征或特征组 合的取值相对应。 因此， 如上所述， 对于相同的特征或特征组合， 具体取值不同， 对应的安全 级别也是不同的。
而且， 上述安全、 危睑、 谨慎和木马四个级别的定义仅作为举例说明， 根据实际应用， 当然也 可以有其他的安全级别分类及定义， 本申请的保护范围并不限定于此。
那么， 所述在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录， 并 将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结果的步骤， 可以理解 为：
在安全识别库中查找特征记录， 如果提取出的指定单个特征与第一条特征记录相匹配， 则可 以判定当前的 Android安装包为木马级别；如果提取出的指定特征进行组合后与第二条特征记录 或者第三条特征记录相匹配， 则可以判定当前的 Android安装包为安全级别； 如果提取出的指定 特征进行组合后与第四条特征记录相匹配， 则可以判定当前的 Android安装包也为木马级别。
所以， 钎对某个 Android安装包的安全检测结果可以是包舍安全、 危睑、 谨慎或木马四个表 示安全级别的信息， 此外所述安全检测结果中还可以包括与安全级别相关的行为描述、 软件描述、 时 间戳等至少一项提示信息， 如对应 "谨慎 "级别的提示信息可以是"可能造成扣费， 是否选择删除该应 用"。
更具体地， 在一犹选实施例中， 所述安全检测结果可以包舍安全级别、 行为描述信息、 软件描述 信息和时间戳信息。 其中：
安全级别： 可以用 32位整数表示， 可表示安全、 危睑、 谨慎或木马四个安全级别， 每个安全级 别的定义如上所述。
行为描述信息： 也可以用 32位（0~31 ) 整数表示， 可以表示出各个安全级别的软件行为描述。 其中， 可以选取一位表示标志位， 标志位为 0表示没有恶意行为， 如果有恶意行为， 则可以定义： 第 1位代表 "后台偷偷下载"， 第 2位代表"私自发送短信 "， 第 3位代表 "包舍广告 "， 等等。 即， 每一位 都可以单独表示一种软件的行为描述。
例如， 对于检测为"木马级别' '的 Android应用程序， 如果恶意行为 = 3 , 翻译成二进制就是 11 , 第 1位 = 1 , 第 2位 = 1 , 表示的恶意行为是： 同时具有后台偷偷下载和私自发送短信的行为。
再例如，对于检测为"谨慎级别' '的 Android应用程库，如果行为描述 = 4,翻译成二进制就是 100, 第 1位 = 0, 第 2位 = 0, 第 2位 = 1 , 表示的行为是： 包舍广告。 由于这个广告可能是用户允许的， 也可能是用户不允许的， 所以会提示用户谨慎使用， 由用户自行决定是否清除。
软件描述信息： 通常表示为字符串， 是对 Android应用程序的说明， 如发布者、发布时间等信息。 时间戳信息： 表明 Android应用程序的特征信息（如正常特征、木马特征等）是什么时候入库的。 实际应用中，客户端用户界面显示安全检测结果时，可以先弹出安全级别信息，如果用户点击 "查 看详情"按钮， 再为用户展示行为描述信息、 软件描述信息和时间戳信息。
综上所述， 上述图 16实施例提供的钎对 Android应用程库的安全检测方法， 首先， 该方法并不 是对 Android系统中的所有文件进行扫描， 而是通过扫描 Android安装包来进行安全检测。 这种把查 杀的目标集中到 Android安装包扫描的方式， 可以大大提髙扫描的效率。
其次， 该方法从 Android安装包中提取出指定的特征进行检测， 如将包名、 版本号、 数字签名、 等作为指定的特征， 这些指定的特征对于检测最具代表性， 因此与移植自 PC上的传统杀毒引擎 相比， 该方法能够准确抓住 Android平台下应用的几大关键特征， 使得扫描速度快、 查杀准确率 髙。
再次， 该方法进行的检测提供了安全、 危睑、 谨慎和木马四个安全级别， 不仅可以检测出 病毒、 木马和其他恶意软件， 还可以将正常的应用、 存在安全风睑的应用和虽然正常但存在一 些问题的应用全部检测出来。因此，本申请对 Android应用程序的检测不局限于传统的查毒检测 , 而是可以为用户提供安全、 危睑、 谨慎等更多的提示。
基于上述内容， 在查询安全识别库的过程中， 本申请另一实施例还提供了一种犹化的查询方法， 这种查询采用对各项特征进行组合查询的方式， 可进一步提髙检测效率和检测的准确率。
所述查询的基本思路是：对提取的 Android安装包的几项关键特征，在安全识别库中进行组 合查询， 当发现匹配的特征记录时， 返回该特征记录所对应的安全信息。 其中， 所述安全信息 可以包括安全级别的描述， 以及与安全级别相对应的提示信息。
下面结合图 17所示的流程， 通过具体举例说明这种查询过程。
参照图 17, 其示出了本申请实施例所述在安全识别库中进行查找的流程图。
首先， 假设安全识别库中采用了三种特征信息， 分别是特征一、 特征二和特征三。 所述"特征 一"、 "特征二' '和"特征三"并不特指某项特征， 而是可根据实际情况来设定。 当然， 实际情况中 采用的特征不限于三种， 此处仅用作举例说明。
基于这三种特征， 所述安全识别库中设定了由其中的单个特征和特征组合构成的特征记录， 这些特征记录包括：
包舍特征一、 特征二、 特征三的特征记录；
包舍特征一、 特征二的特征记录；
包舍特征一、 特征三的特征记录；
包舍特征一的特征记录， 是指仅包舍特征一；
包舍特征二的特征记录， 是指仅包舍特征二；
包舍特征三的特征记录， 是指仅包舍特征三。
由于包舍特征二、 特征三的特征记录在实际应用中无法起到明显的检测作用， 所以此处删 除该条特征记录。 当然， 根据实际应用的需要， 也可能将上述给出的某些特征记录省略。
基于上述设定的安全识别库， 下面通过步骤 1501至步骤 1506来说明查询安全识别库的过程。 具 体如下：
步骤 1701 , 判断是否找到包舍特征一、 特征二、 特征三的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 1702;
步骤 1702, 判断是否找到包舍特征一、 特征二的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 1703; 步骤 1703 , 判断是否找到包舍特征一、 特征三的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 1704;
步骤 1704, 判断是否找到包舍特征一的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 1705;
步骤 1705 , 判断是否找到包舍特征二的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 继续步骤 1706;
步骤 1706, 判断是否找到包舍特征三的特征记录；
如果找到， 则返回结果， 所述结果包舍了与该条特征记录相对应的安全级别信息； 如果未找到， 则扫描结東。
上述流程中， 需要注意的是， 匹配的特征记录不一定是恶意软件的记录， 也可以是正常软 件的记录。 例如， 某安全产品的 APK数字签名的 MD5特征值始终为
dc6dbd6e49682a57a8b82889043b93a8, 假设上图中的 "特征一"就是指 APK数字签名的 MD5 , 那 么当棰索到 MD5 值 =dc6dbd6e49682a57a8b82889043b93a8 的特征记录时， 该特征记录对应的返 1SJ结果应该为"安全 "， 因而就不用进行下面的步骤了， 直接识别为安全的软件。
下面通过一个具体的例子说明上述流程。
假设某手机上有 3款应用 （实际手机至少有几十款应用， 此处为说明方便而简化了） ： 1. 手机系统自带的拔号键盘；
2. 某款手机安全产品；
3. 木马 Pico。
首先分别提取所述 3款应用的特征信息， 具体如下：
1. 手机系统自带的拔号键盘
特征一： APK包名, packageName = com. android. phone;
特征二： APK版本号， versionCode^8;
特征三： APK数字签名的 MD5值，
sigHash= 8ddb342f2da5408402d7568af21 e29f9;
2. 某款手机安全产品
特征一： APK包名, ackageName = com.qihoo360.mobilesafe;
特征二： APK版本号， versionCode^l37;
特征三： APK数字签名的 MD5值，
sigHash= dc6dbd6e49682a57a8b82889043b93a8;
3. 木马 Pico
特征一： APK包名, ackageName = com.svox.pico;
特征二： APK版本号， versionCode^l ;
特征三： APK数字签名的 MD5值，
sigHash= e89bl 58e4bcf988ebd09eb83f5378e87。
假设安全识别库中有以下特征记录， 特征记录以数据表的形式保存：
表 1: 特征一 +特征二 +特征三
Key com.svox.pico— 1— e89bl58e4bcf988ebd09eb83f5378e87； value 木马； 表 2: 特征一 +特征二
空；
表 3: 特征一 +特征三
Key
com. qihoo360.mobilesafe_ dc6dbd6e49682a57a8b82889043b93a8;
value 安全；
表 4: 特征一
空；
表 5: 特征二 表 6: 特征三
Key 8ddb342f2da5408402d7568af21 e29f9;
Value 安全。
需要说明的是， 上述不为空的表 1、 表 3和表 6中， 每个表都可能包舍多条特征记录， 而不 仅仅是上述列举出来的情况。 例如， 表 6中， 还可以包括特征三的 Key和 Value为其他值的特 征记录。
查询时， 分别将 3款应用的特征在安全识别库中按照表 1->表 2->.…的顺序查询， 得到以下 查询结果：
对于应用 1 : 手机系统自带的拔号键盘
表 1: 没有查询到
表 2: 没有查询到
表 3: 没有查询到
表 4: 没有查询到
表 5: 没有查询到
表 6: 查询到了， 结果是"安全" 查询结東， 返回结果。
对于应用 2: 某款手机安全产品
表 1: 没有查询到
表 2: 没有查询到
表 3: 查询到了， 结果是"安全" 查询结東， 返回结果。
对于应用 3: 木马 Pico
表 1: 查询到了， 结果是"木马" , 返 1SJ结果。
假设有一款应用 , 表 1 表 6都没有查询到 那么返回结果为"未知"。
如果 value是其它的值 如"危睑 "、 "谨慎 则按照上述方式依此类推。
上面图 17所示的流程仅是举例说明， 用于通过一个具体的例子使本领城技术人员方便了解 查询过程， 但由上面的例子可以总结出这种查询的本质过程， 如图 18所示。
参照图 18, 其示出了本申请另一实施例所述在安全识别库中进行查找的流程图。
步骤 1801 , 将所述指定的特征信息进行组合， 得到至少包舍两个特征的各项特征组合； 所述指定的特征信息是指从待检测的 Android安装包中提取出的指定的特征信息。
所述组合是指各种可能的组合， 例如， 将上述从某个应用中提取出的特征一、 特征二、 特征 三进行三个特征的组合和两两组合， 可得到包舍特征一、 特征二、 特征三的特征组合， 包舍特 征一、 特征二的特征组合， 包舍特征一、 特征三的特征组合， 以及包舍特征二、 特征三的特征 组合， 共四项特征组合。 但是， 上例中根据实际应用的需要没有使用包舍特征二、 特征三的特 征组合。
步骤 1802, 从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组合相匹配 的特征记录， 如果未查找到， 则继续步骤 1803;
例如， 从包舍特征一、 特征二、 特征三的特征组合开始查询， 钎对上述的应用 1和应用 2, 均没有在安全识别库中查找到相匹配的特征记录， 则继续步骤 1803; 但是对于应用 3, 则在表 1 中查询到了匹配的特征记录， 则直接返回相应结果。
步骤 1803, 逐个减少特征组合中的特征个数， 钎对减少了特征个数的特征组合， 继续在所述安 全识别库中查找与所述特征组合相匹配的特征记录， 如果未查找到， 则继续步骤 1804;
如果查找到， 则返回相应结果。
例如， 对于最多包舍三个特征的特征组合， 减少一个特征后的特征组合包舍两个特征， 那么对这 些包舍两个特征的特征组合进行查找。
在查找过程中， 钎对特征个数相同的多项特征组合， 可以按照预先设定的先后顺序进行查找。 例如， 图 18所示流程中， 包舍两个特征的特征组合一共有 3个， 去除不使用的一个特征组合， 剩下的两个特征组合的查找顺序是： 先对包舍特征一、 特征二的特征组合进行查找， 然后再对包 舍特征一、 特征三的特征组合进行查找。
需要说明的是， 所述预先设定的先后顺序需要根据实际情况下的特征定义、 特征组合情况 来设定， 而不局限于某种设定情况。 实际应用中， 可能有很多种设定情况， 在此不——列举。
步骤 1804, 在所述安全识别库中查找与单个特征信息相匹配的特征记录。
在查找过程中， 钎对单个特征信息， 也可以按照预先设定的先后顺序进行查找。
例如， 图 17所示流程中， 先查找包舍特征一的特征记录， 然后查找包舍特征二的特征记录， 最 后查找包舍特征三的特征记录。
如前所述， 所述预先设定的先后顺序需要根据实际情况下的特征定义、 特征组合情况来设 定， 而不局限于某种设定情况。 实际应用中， 可能有很多种设定情况， 在此不——列举。
图 18所示的这种查找的先后顺序， 具有以下特点：
第一， 这种查找顺序是按照检测精度从 s到低的顺序设置的， 可以最大程度地避免恶意软件的漏 检、 错检；
如果包舍最多特征的一项特征组合能够与安全识别库中包舍最多特征的一条特征记录相匹配，那 么得到的查找结果是精确的；
反之， 按照流程从上到下的顺序， 随着查找条件的放宽， 检测精度也逐渐在降低。
基于此， 一个待检测的 Android应用程序可能同时匹配上安全识别库中的两条特征记录， 但是 它在检测精度较 S的查找条件时就会被检测出来， 因此该流程很好地保证了检测的准确度。
第二， 这种查找顺序几乎可以对所有的 Android应用程序进行检测；
换而 t之， 按照这个流程， 一个木马可以被检测出来，一个安全软件通过检测也可以得到"安全" 的识别结果。
第三， 特征一、 特征二、 …的定义顺序会影响整个流程的查找顺序；
对每个特征的定义确定后 （如"特征一 "指 APK包名， "特征二' '指 APK版本号， 等等） ， 图 16 流程中查找的先后顺序也就确定了。 如果将 "特征二"定义为 APK包名， 将"特征一"定义为 APK版本 号， 那么图 18的流程中， "查找包舍特征一、 特征三的特征记录"修改为 "查找包舍特征二、 特征三的 特征记录 "； 并且， 后面的流程中， 查找特征一和查找特征二的先后顺序也要互换一下， 即先查找特 征二， 再查找特征一， 最后查找特征三。 综上所述， 由以上几点可以看出， 在实际设计安全识别库的时候， 选取的特征信息不同， 由这些 特征组合出来的特征记录也会有很大差别，而且特征的组合还会影响特征个数相同的特征记录的先后 查询顺序。 由此设计出来的检测流程可能有很多种， 但是， 所有各种可能的流程都是基于上述图 4所 述的过程得出来的， 因此均在本申请的保护范围之内。
基于上述内容， 为了使本领城技术人员更加了解本申请的内容， 下面将通过举例说明特征提取过 程。
本例中提取的特征包括：
1 ) Android安装包包名： ackageName
2 ) Android安装包版本号： versionCode
3 ) Android安装包的数字签名的 MD5： signature[0]
4 ) Android组件 receiver
5 ) classes. dex 中的指令
6 ) ELF 文件中的字符串
7 ) assets, res, lib 等目录下各文件的 MD5
8 ) Android组件 service, activity
下面以几个恶意软件的实例， 来说明上面几项特征的舍义和检测的整个过程。
1、 从 Android安装包的 AndroidManifest.xml文件中提取出包名， 版本号， Android组件 receiver, service, activity的特征；
按照 Android 系统的设计要求， 所有的应用程序， 包括木马， 其模块（如 receiver, service, activity等）要想被 Android 系统所执行， 需要在 AndroidManifest.xml文件中声明其模块的类 名。 特别是很多木马， 都是把自已的代码模块嵌入到正常软件中， 而显然， 正常的软件的代码 是不会主动去调用木马的代码模块的， 那么木马要想让自已的代码被执行， 就必须去修改正常 软件的 AndroidManifest.xml 文件， 在其中加入自已的类名， 从而就暴露了 自已的踪迹， 可以作 为识别的特征。
样本一： Android.Geinimi魔音
Android. Geinimi木马通常寄生在正常的 Android应用里面， 例如， 在这个样本中， 它是寄 生在一款叫傲 "魔音 "的应用中。 解压缩样本的 Android安装包， 可以得到根目录下的
AndroidManifestxml 文件。 这个文件是 Android Binary XML ( AXML ) 格式的， 可以用
AXMLPrinter2 工具解码成文本 XML 格式。
解码的结果如下：
encod;ng=i'UTF-S,7>
manifest android:versiooCode- Ί " an:droid:versioriName=t!1.0" package=!!com.A¥bs1! 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>
<receiver android:name=¾om„geinlmLAlServiceReceiver!t>
<intent-fifter
oction
androd:name='8ndro ,nlent ;:fk>:n, BOOT— COMPLETED" >
■(category androidrname- 'andro Id. Inilent.calegory. LAUNCHER" /> </intent-filter
<^eceiver>
<service android:ena led=! rye" 3ndroid:name-"co:m.gelnimlxusto?^.Go ge e^boarcl" android:labei=<<Goog;e 一 " android^fftiiss H-'androld.permsssionJ TER ET' />
octivity android:i eme=[,@andrQid:st le/T eme.Back.. oTi!fe8a androsd:ia ef=!:@sfrIng/a p_nameil
andtO:id:na:me= oni.geinimLcusto .— ½000...000000}8''>
<iHtent-fiiler>
ociion android: ame-!androi>d.intentact n. A! f! />
<category android:name-!an:droldjn;tenf.cafegor . LAUNCHER" /> </intent-filter>
<;¾ctivity>
<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!ONi! />
<uses-permissio-n androtd:name-sa:ndrGid. rmssion,ACCESS LOC TIONi" i> <imatitfest ' ―.
1 )其中， package="com.wbs"中的 com.wbs 就是该 Android安装包的 ackageName,
android:versionCode="l"中的 "1"就是 versionCode。
2) receiver 的特征从下面这段提取：
<receiver android:name="com.geinimi.AdService eceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT— COMPLETED" />
<category android:name=Mandroidintent ategory AUNCHERM />
</intent-filter>
</receiver>
这段代码的含义是，当 Android 系统 android.intent.action.BOOT— COMPLETED(即手机开机启动） 事件发生之后， 调用名为 com.geinimi.AdServiceReceiver 的类。 下文把这条特征写成：
android.intent. action.BOOT— COMPLETED=comgeinimi.AdServiceReceiver。
3 ) service的特征从下面这段提取：
<service android: enabled- 'true" android:name^"com.geinimi. custom. GoogleKeyboard" 中间略) /> 这段代码的舍义是， 本 APK应用中提供了一个 Android服务程序 , 名为
com.geinimi.custom.GoogleKeyboard。
下文把这条特征写成：
service^comgeinimi. custom. GoogleKeyboard。
4 ) activity的特征从下面这段提取：
<activity android:theme^"@android:style Theme.Black.NoTitleBar"
android:label- '@string/app_name" an droid:name^"com.geinimi. custom. Ad0000_00000006"> <intent-filter>
<action android:name^" android, intent, action. MAIN" />
category an droid:name^" android. intent. cat egory.LAUNCHER" />
</inteot-filter>
</activity>
这段代码的舍义是， 用户在 Android 系统的应用列表界面点击"魔音' '的图标的时候， 调用名为 com.geinimi.custom. Ad0000_00000006的类。
下文把这条特征写成：
MAIN L AUNCHER=com. geinimi. custom. Ad0000_00000006.
此外， 可以注意到前面的 XML 中， activit 其实有两个， 除了上面所述的以外， 还有一个， 如 下：
<activity android:label- '@string/app_name" android:name^".MagicVoiceActivity">
<intent-filter>
<category an droid:name^" android. intent. cat egory.LAUNCHER" />
</inteot-filter>
</activity>
其实， 这才是真正的"魔音"应用的主程库入口。 AndroidGeinimi木马为了寄生到正常的应用中， 采用了修改宿主应用的主程库入口指到自已，等木马被启动之后，再跳回宿主应用主程库入口的方法。 不过本申请实施例所述的检测方法最初并不对此进行分析，而是先提取、记录特征，到最后统一判断。
所以这个 activity也提取特征， 下文记为：
LAUNCHER=. MagicVoiceActivity
需要指出的是， 上文为了便于理解， 介绍的是"手工"从 AndroidManifest.xml 中提取特征的步骤。 而实际应用中， 为了提 S特征提取的效率， 可以通过调用 Android Framework的相应 API来完成的， 例如，对于已经安装到手机上的 APK文件，直接用 PackageManager.getlnstalledPackagesO方法就可以 查询到所有已安装的 APK文件的 packageName, versionCode等特征。 显然， 提取特征有多种办法， 而整个检测遝辑不受具体的提取特征的方法的影响。
2、 从 Android安装包的 META-INF\ 目录下的. RSA文件中提取出所述 Android安装包的数 字签名；
关于 META-INF 目录， 里面有个 .SF 文件， 内容类似为：
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— arrows— 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= 其中， 每一项都是一个文件的校验信息， 例如 res/raw/ic_menu_gallery.png 的校验信息是 d0vnA3rU6DlMuGhA3nzu5FtXaXQ=, 如果文件被墓改， 就会与校 1言息不匹配， Android 系统就能 发现文件被墓改， 从而拒绝安装。
所述校验信息的生成， 是用数字证书的私钥生成的， 所以无法伪造。 META-INF 目录下面有个 公钼文件， 扩展名为 .RSA, Android 系统用公钼来验证校验信息是否是伪造的。 而提取特征， 就是 去检查 .RSA文件的公钼信息， 因为私钥和公钼是配对的， 所以只要提取了公钼的特征， 就能对应上 唯一的私钥, 而私钥是由应用的开发者自行保管的， 所以可以用来区别木马和正常软件的开发者。
前文已经提到， Android 系統要求每个 APK都要包舍数字签名。 这个数字签名的信息可以通过 Android的 API来完成， 例如， 已安装到手机上的 APK文件， 可以通过
PackageManager.getlnstalledPackagesO方法查询每个 APK 包舍的数字签名。
一个 Android安装包可以被多次签名，最终以最后一次签名为准。如果是通过 API获取的数字签 名， 那么得到的是一个数组， 变量名为 signature, 最后一次签名的数据是 signature[0]。
此外， 还有其它 API也可以查询 APK包中的数字签名， 这里不——列举。 而且， 手工提取 signature[0]特征也可以， 解压缩样本的 Android安装包， 在 META- F/目录下会看到 CERT.RSA 文 件， 这就是签名证书。 用 ke tool-printcert-file CERT.RSA命令可以查看其中的详细信息， 如下： 所有者: CN=Android Debug, 0= Android, C=US
签发人: CN=Android Debug, 0= Android, C=US
序列号 :4ccd020e
有效期： Sun Oct 31 13:43:42 CST 2010 - Mon Oct 31 13:43:42 CST 2011
证书指纹：
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
签名算法名称: SHAlwithRSA
版本： 3
3、 从 Android安装包的 classes. dex文件中提取出可执行指令； 前文已经提到， 大部分 Android应用都主要是由 Java语 t编写， 编译之后生成了 Dalvik虛拟机 的字节码（byte code ) , 打包成了 classes.dex 文件。 解析 classes, dex文件， 反编译其字节码， 就可 以得到应用程序所要执行的指令。
可以 4 选指令中能代表恶意软件特征的指 为特征码，当发现 classes.dex 文件中包舍这样的特 征码时， 就作为一个特征。 例如， Android. Geinimi木马为了隐藏自已， 将一些关键数据 （如木马服 务器信息）加密之后写入代码中， 这些被加密的数据反而成为了检测识别它的特征。 用 dexdump 工 具分析 classes.dex 文件可看到输出中包舍以下片段：
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)
上述片段就可以提取作为检测识别的特征。
当然， dexdump 工具只是显示这些特征数据的手段之一， 也可以通过其他方式自行实现解析、反 编译和识别 classes. dex 文件的功能。
综上所述， 样本一不包舍 ELF 文件， 所以没有提取到 ELF特征。
从样本一中提取了上述特征之后， 假设安全识别库中存在以下特征记录：
特征一： ackageName^com.wbs
特征二： 无
特征三： MD5(signature[0])= 294f08ae04307a649322524713318543
特征一 +特征三： 安全级别为"木马"
当检测流程走到"找到包舍特征一、 特征三的木马？ "时， 找到记录， 返回结果为"木马"。
4、 从 Android安装包的 lib\ 目录下提取出 ELF文件的指令或字符串。
样本二： Androi DroidKungFu功夫木马
功夫木马有数十种变种， 它一般伪装成一个正常的应用 （例如 "图库锁"之类） ， 诱骗用户安装、 运行之后， 运行 native executable文件， 在用户手机上安装后门， 使得木马制作者可以远程操纵用户 手机。
对功夫木马各 APK的 packageName等特征的提取， 与样本 致， 在此不再赘述。
下面主要介绍 ELF特征的提取：
在功夫木马的 Android安装包的 lib/armeabi 目录下， 有一个 libxxx.so 文件， 文件名随着功夫木 马各变种有所变化， 例如 libadv3.so, libdl.so等。 这是一个 Linux ELF 文件， 可以用 readelf等工具 读取其信息， 下面是摘取的片段：
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
... (中间略）
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
这个片段是 libadv3.so 文件导出的符号表，其中 Type 为 OBJECT的符号是关注的重点，其中的 —bindata 实际是木马子包， 所以可以提取出来作为特征。
当然， ELF 文件是灵活多变的， 恶意软件的 ELF 文件也不仅仅表现为这种形式， 所以 ELF 文 件的特征提取可以有多种方式， 除了直接从符号表提取特征外， 还可以提取代码段的片段、 字符串等 作为特征。
本实施例提取的特征记为： _bindata CONTAINS ELF chown unlink /system¾in; 其舍义是， 在. so 文件的符号表中查询 _bindata的符号，其指向的数据中包舍 "ELF'、 "chown", "unlink", '7systen^in"4 组字符串。
假设这条特征在安全识别库中记录为：
特征四： _ bindata CONTAINS ELF chown unlink /system/bin
安全级别： 木马
当检测流程走到"找到包舍特征四的木马？ "时， 找到记录， 返回结果为"木马"。
上述实施例是以手机中的应用为例进行说明，但具体应用中也可以应用到等其他基于 Android平 台的移动终端的应用检测中， 其实施原理与上述实施例相似， 故不再赘述。
需要说明的是， 对于前述的各方法实施例， 为了简单描述， 故将其都表述为一系列的动作组合， 但是本领城技术人员应该知悉， 本申请并不受所描述的动作顺序的限制， 因为依据本申请， 某些步骤 可以采用其他顺序或者同时进行。 其次， 本领城技术人员也应该知悉， 说明书中所描述的实施例均属 于优选实施例， 所涉及的动作并不一定是本申请所必需的。
基于上述方法实施例的说明， 本申请还提供了相应的系统实施例。
参照图 19, 其示出了本申请实施例所述一种 Android应用程库的安全检测系统的结构图。
所述钎对 Android应用程库的安全检测系统可以包括： 特征提取模块 10, 检测模块 20, 以及， 结果返回模块 30。 其中，
特征提取模块 10, 1于扫描 Android安装包， 并从所述 Android安装包中提取出指定的特征 信息；
检测模块 20, 01于在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记 录； 其中， 所述安全识别库中包舍特征记录及特征记录对应的安全级别， 每条特征记录中包舍单个特 征信息或特征信息的组合；
显示模块 30, 用于将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测 结果中显示。
所述从 Android安装包中提取出的指定的特征信息可以包括以下信息中的一种或几种组合： Android安装包的包名 ,版本号,数字签名 , Android组件 receiver的特征， Android组件 service 的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安装包目录下 各文件的 MD5值。 其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件。
所述安全识别库中的特征信息可以包括以下信息中的一种或几种组合：
各种样本 Android安装包的包名 ,版本号，数字签名 , Android组件 receiver的特征， Android 组件 service的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安 装包目录下各文件的 MD5值。
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述样本 Android安装包包括各种安全级别下的 Android安装包。
其中， 所述安全级别包括安全、 危睑、 谨慎和木马四个级别。
综上所述， 上述实施例提供的钎对 Android应用程序的安全检测系统具有以下优点； 首先， 本申请实施例提供的钎对 Android应用程序的安全检测， 并不是对 Android系统中的所有 文件进行扫描， 而是通过扫描 Android安装包来进行安全检测。 由于 Android上的病毒、 木马和其他 恶意软件想要进入用户的手机， 需要打包成 Android安装包的形式。 反过来说， 如果不是一个合法的 Android安装包， 它就无法安装到用户手机上， 也就不会对用户产生危害。 基于这一点， 可以把查杀 的目标集中到对 Android安装包的扫描上， 从而大大提髙扫描的效率。
其次， 本申请实施例从 Android安装包中提取出指定的特征进行检测， 如将包名、 版本号、 数 字签名、 Android组件 receiver, service, activity中的信息等作为指定的特征， 这些指定的特征 对于检测最具代表性， 因此与移植自 PC上的传统杀毒引擎相比， 本申请实施例准确抓住了 Android平台下应用的几大关键特征， 使得扫描速度快、 查杀准确率髙。
再次， 本申请实施例进行的检测提供了安全、 危睑、 谨慎和木马四个安全级别， 不仅可以 检测出病毒、 木马和其他恶意软件， 还可以将正常的应用、 存在安全风睑的应用和虽然正常但 存在一些问题的应用全部检测出来。 因此， 本申请实施例对 Android应用程序的检测不局限于传 统的查毒检测， 而是可以为用户提供安全、 危睑、 谨慎等更多的提示。
上述安全检测系统可以安装在手机等终端设备中， 当用户需要安装一款 Android应用程序时， 所述安全检测系统可以对其进行检测， 并给出相应的提示， 提 s终端使用的安全性。
基于以上系统实施例的内容， 在本申请的另一犹选实施例中， 参照图 20所示， 所述检测模块 20 可以包括以下子模块：
特征组合子模块 21 , 用于将所述指定的特征信息进行组合， 得到至少包舍两个特征的各项特征 组合；
第一查找子模块 22, 用于从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特 征组合相匹配的特征记录；
第二查找子模块 23, 用于当第一查找子模块 22未查找到时， 逐个减少特征组合中的特征个数， 钎对减少了特征个数的特征组合， 继续在所述安全识别库中查找与所述特征组合相匹配的特征记录； 第三查找子模块 24, 用于当第二查找子模块 23未查找到时， 在所述安全识别库中查找与单个特 征信息相匹配的特征记录。
优选地， 所述第二查找子模块 23在查找过程中， 钎对特征个数相同的多项特征组合 , 按照预先 设定的先后顺序进行查找； 所述第三查找子模块 24钎对单个特征信息， 按照预先设定的先后顺序进 行查找。
图 20所示的检测模块 20对提取出的各项特征进行安全检测时， 采用对各项特征进行组合查 询的方式， 进一步提 s了检测效率和检测的准确率。 基于以上系统实施例的内容， 在本申请的另一犹选实施例中， 所述特征提取模块 10可以包括以 下子模块：
第一提取子模块， 用于从所述 Android安装包的 AndroidManifest.xml文件中提取出以下中的 一种或几种组合： 包名, 版本号, Android组件 receiver的特征， Android组件 service的特征, Android ίί件 activity的特征；
和 /或，
第二提取子模块， 用于从所述 Android安装包的 META-INF\ 目录下的. RSA文件中提取出所 述 Android安装包的数字签名；
和 /或，
第三提取子模块， 用于从所述 Android安装包的 classes.dex文件中提取出可执行指令； 和 /或，
第四提取子模块， 用于从所述 Android安装包的 lib\ 目录下提取出 ELF文件的指令或字符 串。
对于上述安全检测系统实施例而 t , 由于其与方法实施例基本相似， 所以描述的比较简单， 相关 之处参见图 16至图 18所示方法实施例的部分说明即可。 本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不 同之处， 各个实施例之间相同相似的部分互相参见即可。
本领城技术人员易于想到的是： 上述各个实施例的任意组合应用都是可行的， 故上述各个 实施例之间的任意组合都是本申请的实施方案， 但是由于篇幅限制， 本说明书在此就不一一详 述了。
在本文中， 诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体 或操作区分开来 , 而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺 序。 而且， 术语"包括"、 "包舍 "， 不仅包括那些要素， 而且还包括没有明确列出的其他要素， 或 者是还包括为这种过程、 方法、 物品或者设备所固有的要素。 在没有更多限制的情况下， 由语 句"包括 ...... "限定的要素， 并不排除在包括所述要素的过程、 方法、 物品或者设备中还存在另外 的相同要素。
而且， 上文中的"和 /或"表示本文既包舍了"和' '的关系， 也包舍了"或' '的关系， 其中： 如果 方案 A与方案 B是"和' '的关系， 则表示某实施例中可以同时包括方案 A和方案 B; 如果方案 A 与方案 B是"或' '的关系， 则表示某实施例中可以单独包括方案 A, 或者单独包括方案 B。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模 块实现， 或者以它们的组合实现。 本领城的技术人员应当理解， 可以在实践中使用微处理器或 者数字信号处理器 ( DSP )来实现根据本发明实施例的 Android应用程序的安全检测系统中的一 些或者全部部件的一些或者全部功能。 本发明还可以实现为用于执行这里所描述的方法的一部 分或者全部的设备或者装置程序 （例如， 计算机程序和计算机程序产品） 。 这样的实现本发明 的程序可以存储在计算机可读介质上， 或者可以具有一个或者多个信号的形式。 这样的信号可 以从因特网网站上下载得到， 或者在载体信号上提供， 或者以任何其他形式提供。
例如， 图 21示出了可以实现根据本发明的 Android应用程序的安全检测方法的服务器， 例如应用服务器。 该服务器传统上包括处理器 710和以存储器 720形式的计算机程序产品或者 计算机可读介质。存储器 720可以是诸如闪存、 EEPROM(电可檫除可编程只读存储器）、EPROM、 硬盘或者 ROM之类的电子存储器。存储器 720具有用于执行上述方法中的任何方法步骤的程序 代码 731的存储空间 730。 例如， 用于程序代码的存储空间 730可以包括分别用于实现上面的方 法中的各种步骤的各个程序代码 731。这些程序代码可以从一个或者多个计算机程序产品中读出 或者写入到这一个或者多个计算机程序产品中。 这些计算机程序产品包括诸如硬盘， 紧致盘 ( CD ) 、 存储卡或者软盘之类的程序代码载体。 这样的计算机程序产品通常为如参考图 8所述 的便携式或者固定存储单元。 该存储单元可以具有与图 7的服务器中的存储器 720类似布置的 存储段、 存储空间等。 程序代码可以例如以适当形式进行压缩。 通常， 存储单元包括计算机可 读代码 73Γ , 即可以由例如诸如 710之类的处理器读取的代码， 这些代码当由服务器运行时， 导致该服务器执行上面所描述的方法中的各个步骤。
本文中所称的"一个实施例"、 "实施例"或者"一个或者多个实施例 "意味着， 结合实施例描述 的特定特征、 结构或者特性包括在本发明的至少一个实施例中。 此外， 请注意， 这里"在一个实 施例中"的词语例子不一定全指同一个实施例。
在此处所提供的说明书中， 说明了大量具体细节。 然而， 能够理解， 本发明的实施例可以 在没有这些具体细节的情况下被实践。 在一些实例中， 并未详细示出公知的方法、 结构和技术， 以便不模糊对本说明书的理解。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制， 并且本领城技术人 员在不脱离所附权利要求的范围的情况下可设计出替换实施例。 在权利要求中， 不应将位于括 号之间的任何参考符号构造成对权利要求的限制。 单词"包舍' '不排除存在未列在权利要求中的 元件或步骤。位于元件之前的单词 "一' '或"一个' '不排除存在多个这样的元件。本发明可以借助于 包括有若千不同元件的硬件以及借助于适当编程的计算机来实现。 在列举了若千装置的单元权 利要求中， 这些装置中的若千个可以是通过同一个硬件项来具体体现。 单词第一、 第二、 以及 第三等的使用不表示任何顺序。 可将这些单词解释为名称。
此外， 还应当注意， 本说明书中使用的语 t主要是为了可读性和教导的目的而选择的， 而 不是为了解释或者限定本发明的主题而选择的。 因此， 在不偏离所附权利要求书的范围和精神 的情况下， 对于本技术领城的普通技术人员来说许多修改和变更都是显而 见的。 对于本发明 的范围， 对本发明所傲的公开是说明性的， 而非限制性的， 本发明的范围由所附权利要求书限 定。

Claims

权 利 要 求
1、 一种 Android应用程序的安全检测方法， 其包括：
扫描 Android安装包， 并从所述 Android安装包中提取出指定的特征信息；
将所述指定的特征信息上传到服务器，在服务器预置的安全识别库中查找与指定的单个特征信息 或其组合相匹配的特征记录； 其中， 所述服务器预置的安全识别库中包舍特征记录及特征记录对应的 安全级别， 每条特征记录中包舍单个特征信息或特征信息的组合；
接收服务器返回的钎对所述 Android安装包的安全检测结果， 并在客户端用户界面显示， 所述 安全检测结果中包舍服务器查找到的特征记录对应的安全级别。
2、 根据权利要求 1所述的方法， 其中， 还包括：
在本地预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录； 其中， 所述 本地预置的安全识别库中包舍特征记录及特征记录对应的安全级别 ,每条特征记录中包舍单个特征信 息或特征信息的组合；
将本地查找到的特征记录对应的安全级别包舍在所述 Android安装包的本地安全检测结果中。
3、 根据权利要求 2所述的方法， 其中， 还包括：
将服务器返回的安全检测结果与所述本地安全检测结果合并， 合并后在客户端用户界面显示。
4、 根据权利要求 2所述的方法， 其中，
如果在本地预置的安全识别库中查找到与所有指定的单个特征信息或其组合相匹配的特征记录， 则还包括：
取消将所述指定的特征信息上传到服务器，并将所述本地安全检测结果在客户端用户界面显示。
5、 根据权利要求 2所述的方法， 其中，
如果在本地预置的安全识别库中查找到与部分指定的单个特征信息或其组合相匹配的特征记录， 则将全部或剩余部分的指定的特征信息上传到服务器查找， 其中， 所述剩余部分的指定的特征信息为 未在本地查找到相匹配的特征记录的特征信息；
将服务器返回的安全检测结果与所述本地安全检测结果合并， 合并后在客户端用户界面显示。
6、 根据权利要求 2所述的方法， 其中， 所述在本地预置的安全识别库中查找之前， 还包括： 依据预设的配置信息，确定直接将所述指定的特征信息上传到服务器查找，或者直接在本地查找， 或者提示用户选择在本地查找还是上传到服务器查找。
7、 根据权利要求 6所述的方法， 其中：
当所述配置信息表示不允许提供本地预置的安全识别库时，确定直接将所述指定的特征信息上传 到服务器查找；
当所述配置信息表示优先在本地查找时， 确定直接在本地查找；
当所述配置信息表示优先由用户选择时， 确定提示用户选择在本地查找还是上传到服务器查找。
8、 根据权利要求 2所述的方法， 其中， 所述在本地预置的或服务器预置的安全识别库中查找与 指定的单个特征信息或其组合相匹配的特征记录， 包括：
将所述指定的特征信息进行组合， 得到至少包舍两个特征的各项特征组合；
从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组合相匹配的特征记录， 如果未查找到， 则
逐个减少特征组合中的特征个数， 钎对减少了特征个数的特征组合， 继续在所述安全识别库中查 找与所述特征组合相匹配的特征记录， 如果未查找到， 则
在所述安全识别库中查找与单个特征信息相匹配的特征记录。
9、 根据权利要求 1所述的方法， 其中， 所述安全检测结果还包括以下至少一项：
行为描述信息， 软件描述信息， 时间戳信息。
10、 一种 Android应用程序的安全检测方法， 其包括：
接收上传的指定的特征信息， 所述指定的特征信息是从 Android安装包中提取而出； 在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录； 其中， 所 述安全识别库中包舍特征记录及特征记录对应的安全级别 ,每条特征记录中包舍单个特征信息或特征 信息的组合；
将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结果中发送。
11、 根据权利要求 10所述的方法， 其中， 当在服务器预置的安全识别库中未查找到相匹配的特 征记录时， 还包括： 识别所述指定的特征信息，并根据识别结果确定与所述指定的单个特征信息或其组合相匹配的特 征记录及特征记录对应的安全级别；
将所述特征记录及特征记录对应的安全级别更新到所述服务器预置的安全识别库中。
12、 根据权利要求 10所述的方法， 其中， 所述在服务器预置的安全识别库中查找与指定的单个 特征信息或其组合相匹配的特征记录， 包括：
将所述指定的特征信息进行组合， 得到至少包舍两个特征的各项特征组合；
从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组合相匹配的特征记录， 如果未查找到， 则
逐个减少特征组合中的特征个数， 钎对减少了特征个数的特征组合， 继续在所述安全识别库中查 找与所述特征组合相匹配的特征记录， 如果未查找到， 则
在所述安全识别库中查找与单个特征信息相匹配的特征记录。
13、 根据权利要求 12所述的方法， 其中：
在查找过程中， 钎对特征个数相同的多项特征组合， 按照预先设定的先后顺序进行查找； 钎对单个特征信息， 按照预先设定的先后顺序进行查找。
14、 根据权利要求 10所述的方法， 其中， 所述上传的指定的特征信息包括以下中的一种或几种 组合：
Android安装包的包名 '版本号,数字签名 ' Android组件 receiver的特征， Android组件 service 的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安装包目录下 各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件。
15、 根据权利要求 10所述的方法， 其中， 所述安全识别库中的特征信息包括以下中的一种或几 种组合：
各种样本 Android安装包的包名 ,版本号，数字签名 , Android组件 receiver的特征， Android 组件 service的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安 装包目录下各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述样本 Android安装包包括各种安全级别下的 Android安装包。
16、 一种 Android应用程库的安全检测系统， 其包括：
特征提取模块， 用于扫描 Androi d安装包， 并从所述 Androi d安装包中提取出指定的特征信 息；
上传模块， 用于将所述指定的特征信息上传到服务器， 在服务器预置的安全识别库中查找与指定 的单个特征信息或其组合相匹配的特征记录； 其中， 所述服务器预置的安全识别库中包舍特征记录及 特征记录对应的安全级别， 每条特征记录中包舍单个特征信息或特征信息的组合；
显示模块， 用于接收服务器返回的钎对所述 Android安装包的安全检测结果， 并在客户端用户 界面显示， 所述安全检测结果中包舍服务器查找到的特征记录对应的安全级别。
17、 根据权利要求 16所述的系统， 其中， 还包括：
本地检测模块，用于在本地预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特 征记录； 其中， 所述本地预置的安全识别库中包舍特征记录及特征记录对应的安全级别， 每条特征记 录中包舍单个特征信息或特征信息的组合；
还用于将本地查找到的特征记录对应的安全级别包舍在所述 Android安装包的本地安全检测结 果中。
18、 4据权利要求 17所述的系统， 其中， 还包括：
合并模块， 用于将服务器返回的安全检测结果与所述本地安全检测结果合并， 合并后通过所述 显示模块在客户端用户界面显示。
19、 4据权利要求 17所述的系统， 其中， 还包括：
取消上传模块，用于当所述本地检测模块在本地预置的安全识别库中查找到与所有指定的单个特 征信息或其组合相匹配的特征记录时，取消将所述指定的特征信息上传到服务器， 并通过所述显示模 块将所述本地安全检测结果在客户端用户界面显示。
20、 根据权利要求 18所述的系统， 其中， 还包括： 当所述本地检测模块在本地预置的安全识别库中查找到与部分指定的单个特征信息或其组合相 匹配的特征记录， 则所述上传模块将全部或剩余部分的指定的特征信息上传到服务器查找， 其中， 所 述剩余部分的指定的特征信息为未在本地查找到相匹配的特征记录的特征信息；
所述合并模块将服务器返回的安全检测结果与所述本地安全检测结果合并，合并后通过所述显 示模块在客户端用户界面显示。
21、 根据权利要求 17所述的系统， 其中， 还包括：
模式选择模块， 用于所述本地检测模块在本地预置的安全识别库中查找之前，依据预设的配置信 息， 确定直接将所述指定的特征信息上传到服务器查找， 或者直接在本地查找， 或者提示用户选择在 本地查找还是上传到服务器查找。
22、 一种 Android应用程库的安全检测系统， 其包括：
接收模块， 用于接收上传的指定的特征信息， 所述指定的特征信息是从 Android安装包中提取 而出；
网 ^测模块，用于在服务器预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的 特征记录； 其中， 所述安全识别库中包舍特征记录及特征记录对应的安全级别， 每条特征记录中包舍 单个特征信息或特征信息的组合；
发送模块， 用于将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结 果中发送。
23、 4据权利要求 22所述的系统， 其中， 还包括：
特征识别模块，用于当所述网 棰测模块在服务器预置的安全识别库中未查找到相匹配的特征记 录时， 识别所述指定的特征信息， 并根据识别结果确定与所述指定的单个特征信息或其组合相匹配的 特征记录及特征记录对应的安全级别；
更新模块，用于将所述特征记录及特征记录对应的安全级别更新到所述服务器预置的安全识别库 中。
24、 根据权利要求 22所述的系统， 其中， 所述网络检测模块包括：
特征组合子模块，用于将所述指定的特征信息进行组合，得到至少包舍两个特征的各项特征组合； 第一查找子模块， 用于从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组 合相匹配的特征记录；
第二查找子模块， 用于当第一查找子模块未查找到时， 逐个减少特征组合中的特征个数， 钎对减 少了特征个数的特征组合， 继续在所述安全识别库中查找与所述特征组合相匹配的特征记录；
第三查找子模块， 用于当第二查找子模块未查找到时， 在所述安全识别库中查找与单个特征信息 相匹配的特征记录。
25、 根据权利要求 21所述的系统， 其中， 所述上传的指定的特征信息包括以下中的一种或几种 组合：
Android安装包的包名 '版本号,数字签名 ' Android组件 receiver的特征， Android组件 service 的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安装包目录下 各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述安全识别库中的特征信息包括以下中的一种或几种组合：
各种样本 Android安装包的包名，版本号，数字签名， Android组件 receiver的特征， Android 组件 service的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安 装包目录下各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述样本 Android安装包包括各种安全级别下的 Android安装包。
26、 一种 Android应用程序的安全检测方法， 其包括：
扫描 Android安装包， 并从所述 Android安装包中提取出指定的特征信息；
在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录； 其中， 所述安全 识别库中包舍特征记录及特征记录对应的安全级别 ,每条特征记录中包舍单个特征信息或特征信息的 组合； 将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结果中显示。
27、根据权利要求 26所述的方法， 其中， 所述从 Android安装包中提取出的指定的特征信息包 括以下中的一种或几种组合：
Android安装包的包名 ,版本号,数字签名 , Android组件 receiver的特征， Android组件 service 的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安装包目录下 各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件。
28、 根据权利要求 26所述的方法， 其中， 所述安全识别库中的特征信息包括以下中的一种或 几种组合：
各种样本 Android安装包的包名，版本号，数字签名， Android组件 receiver的特征， Android 组件 service的特征， Android组件 activity的特征， 可执行文件中的指令或字符串， Android安 装包目录下各文件的 MD5值；
其中， 所述可执行文件包括 Dex文件， 和 /或， ELF文件； 所述 Dex文件包括 classes. dex文 件， 扩展名为. jar的文件， 以及， Dex格式的文件；
其中， 所述样本 Android安装包包括各种安全级别下的 Android安装包。
29、根据权利要求 26至 28中任一项所述的方法， 其中， 所述在安全识别库中查找与指定的单个 特征信息或其组合相匹配的特征记录， 包括：
将所述指定的特征信息进行组合， 得到至少包舍两个特征的各项特征组合；
从包舍最多特征的特征组合开始， 在所述安全识别库中查找与所述特征组合相匹配的特征记录， 如果未查找到， 则
逐个减少特征组合中的特征个数， 钎对减少了特征个数的特征组合， 继续在所述安全识别库中查 找与所述特征组合相匹配的特征记录， 如果未查找到， 则
在所述安全识别库中查找与单个特征信息相匹配的特征记录。
30、 根据权利要求 27所述的方法， 其中， 所述从 Android安装包中提取出指定的特征信息， 包括：
从所述 Android安装包的 AndroidManifest.xml文件中提取出以下中的一种或几种组合：包名 , 版本号， Android组件 receiver的特征， Android组件 service的特征， Android组件 activity的特 征；
和 /或，
从所述 Android安装包的 META-INF\ 目录下的 .RSA文件中提取出所述 Android安装包的数 字签名；
和 /或，
从所述 Android安装包的 classes. dex文件中提取出可执行指令；
和 /或，
从所述 Android安装包的 lib\ 目录下提取出 ELF文件的指令或字符串。
31、 根据权利要求 26所述的方法， 其中， 所述安全检测结果还包括以下至少一项：
行为描述信息， 软件描述信息， 时间戳信息。
32、 一种 Android应用的安全检测系统， 其包括： 特征提取模块， 用于扫描 Androi d安装包， 并从所述 Androi d安装包中提取出指定的特征信 息；
检测模块， 用于在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录； 其中， 所述安全识别库中包舍特征记录及特征记录对应的安全级别 ,每条特征记录中包舍单个特征信 息或特征信息的组合；
显示模块， 用于将查找到的特征记录对应的安全级别包舍在所述 Android安装包的安全检测结 果中显示。
33、 一种计算机程序， 包括计算机可读代码， 当所述计算机可读代码在服务器上运行时， 导致所述服务器执行根据权利要求 1-15中的任一个所述的 Android应用程库的安全检测方法。
34、一种计算机可读介质， 其中存储了如权利要求 29所述的计算机程序。
PCT/CN2013/078425 2012-06-28 2013-06-28 一种Android应用程序的安全检测方法及系统 Ceased WO2014000696A1 (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201210218971.4 2012-06-28
CN201210221959.9A CN102779257B (zh) 2012-06-28 2012-06-28 一种Android应用程序的安全检测方法及系统
CN201210218971.4A CN102831338B (zh) 2012-06-28 2012-06-28 一种Android应用程序的安全检测方法及系统
CN201210221959.9 2012-06-28

Publications (1)

Publication Number Publication Date
WO2014000696A1 true WO2014000696A1 (zh) 2014-01-03

Family

ID=49782277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/078425 Ceased WO2014000696A1 (zh) 2012-06-28 2013-06-28 一种Android应用程序的安全检测方法及系统

Country Status (1)

Country Link
WO (1) WO2014000696A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017221091A1 (en) * 2016-06-23 2017-12-28 International Business Machines Corporation Detecting vulnerable applications
CN108063972A (zh) * 2017-12-20 2018-05-22 深圳市康冠技术有限公司 一种tv界面优化方法及系统
US10873466B2 (en) 2015-11-06 2020-12-22 Huawei International Pte. Ltd. System and method for managing installation of an application package requiring high-risk permission access
US11470113B1 (en) 2018-02-15 2022-10-11 Comodo Security Solutions, Inc. Method to eliminate data theft through a phishing website

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101287227A (zh) * 2008-05-22 2008-10-15 德信无线通讯科技（北京）有限公司 移动通信终端及其防止软件安全级别回退的方法
JP2009069959A (ja) * 2007-09-11 2009-04-02 Hitachi Information Systems Ltd ソフトウェア管理システムと方法およびプログラム
CN101513008A (zh) * 2006-07-31 2009-08-19 意大利电信股份公司 在电信终端上实现安全性的系统
CN102200922A (zh) * 2011-04-06 2011-09-28 宇龙计算机通信科技(深圳)有限公司 应用程序安装方法和终端
CN102779257A (zh) * 2012-06-28 2012-11-14 奇智软件（北京）有限公司 一种Android应用程序的安全检测方法及系统
CN102831338A (zh) * 2012-06-28 2012-12-19 北京奇虎科技有限公司 一种Android应用程序的安全检测方法及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101513008A (zh) * 2006-07-31 2009-08-19 意大利电信股份公司 在电信终端上实现安全性的系统
JP2009069959A (ja) * 2007-09-11 2009-04-02 Hitachi Information Systems Ltd ソフトウェア管理システムと方法およびプログラム
CN101287227A (zh) * 2008-05-22 2008-10-15 德信无线通讯科技（北京）有限公司 移动通信终端及其防止软件安全级别回退的方法
CN102200922A (zh) * 2011-04-06 2011-09-28 宇龙计算机通信科技(深圳)有限公司 应用程序安装方法和终端
CN102779257A (zh) * 2012-06-28 2012-11-14 奇智软件（北京）有限公司 一种Android应用程序的安全检测方法及系统
CN102831338A (zh) * 2012-06-28 2012-12-19 北京奇虎科技有限公司 一种Android应用程序的安全检测方法及系统

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10873466B2 (en) 2015-11-06 2020-12-22 Huawei International Pte. Ltd. System and method for managing installation of an application package requiring high-risk permission access
US11637707B2 (en) 2015-11-06 2023-04-25 Huawei International Pte. Ltd. System and method for managing installation of an application package requiring high-risk permission access
WO2017221091A1 (en) * 2016-06-23 2017-12-28 International Business Machines Corporation Detecting vulnerable applications
GB2568410A (en) * 2016-06-23 2019-05-15 Ibm Detecting vulnerable applications
GB2568410B (en) * 2016-06-23 2019-11-20 Ibm Detecting vulnerable applications
CN108063972A (zh) * 2017-12-20 2018-05-22 深圳市康冠技术有限公司 一种tv界面优化方法及系统
US11470113B1 (en) 2018-02-15 2022-10-11 Comodo Security Solutions, Inc. Method to eliminate data theft through a phishing website

Similar Documents

Publication Publication Date Title
CN102831338B (zh) 一种Android应用程序的安全检测方法及系统
CN102779257B (zh) 一种Android应用程序的安全检测方法及系统
US10152594B2 (en) Method and device for identifying virus APK
CN104008340B (zh) 病毒查杀方法及装置
US10114946B2 (en) Method and device for detecting malicious code in an intelligent terminal
CN104317599B (zh) 检测安装包是否被二次打包的方法和装置
CN104715196B (zh) 智能手机应用程序的静态分析方法及系统
CN103761475B (zh) 检测智能终端中恶意代码的方法及装置
JP5690689B2 (ja) アプリケーション解析装置およびプログラム
WO2013139216A1 (zh) 一种apk病毒特征码的提取方法及装置
CN104462971B (zh) 根据应用程序声明特征识别恶意应用程序的方法和装置
WO2015101043A1 (zh) 检测智能终端中恶意代码的方法及装置
CN115062309B (zh) 一种新型电力系统下基于设备固件仿真的漏洞挖掘方法及存储介质
WO2014166312A1 (zh) 一种广告插件识别的方法和系统
CN104392176A (zh) 移动终端及其设备管理器权限的拦截方法
CN103632096A (zh) 一种对设备进行安全检测方法和装置
WO2015192637A1 (zh) 软件安装包的加固保护方法和装置
Yang et al. APKLancet: tumor payload diagnosis and purification for android applications
CN104318161A (zh) 一种安卓样本的病毒检测方法及装置
CN104715199A (zh) 一种病毒apk的识别方法及装置
CN114282212A (zh) 流氓软件识别方法、装置、电子设备及存储介质
Alfalqi et al. Android platform malware analysis
CN105205398B (zh) 一种基于apk加壳软件动态行为的查壳方法
Zhang et al. PITracker: Detecting Android pendingintent vulnerabilities through intent flow analysis
CN104715200A (zh) 一种病毒apk的识别方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13809651

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13809651

Country of ref document: EP

Kind code of ref document: A1