CN110263545A - An Android system-based startup process integrity measurement method - Google Patents

Abstract

The start-up course integrity measurement detection method based on android system that the invention discloses a kind of, since power-up, credible measurement root CRTM guides Bootloader and verifies its integrality, using secure hash algorithm SHA-1 to Bootloader operation, obtained actual metrics value is compared with the RIM value in RIM certificate, it, will be in result deposit platform configuration register storage trusted root if comparing result is consistent；Then CRTM transfers control to Bootloader；In Bootloader measurement Kernel-Process, the comprehensive measurement value TValue for kernel is obtained using trust metrics model, is finally reached the credible of entire android system.The present invention solves the problems, such as in trust computing existing in the prior art that integrity measurement framework is excessively complicated, is difficult to extend and credible without embodiment behavior.

Description

An Android system-based startup process integrity measurement method

technical field

The invention belongs to the technical field of mobile intelligent terminals, and in particular relates to an Android system-based startup process integrity measurement method.

Background technique

Android system is currently the most widely used mobile operating system. The biggest feature of the Android system is its strong openness, and each manufacturer can customize the system according to their own needs; the installation of third-party applications is relatively convenient and there are not too many restrictions, which is also the core factor that promotes the continuous development of the Android system. While Android mobile smart terminals provide users with convenience, they also cause serious security risks. For example, personal information and passwords stored in the terminal have become the main targets of attackers, and information such as text message content, contact list, call records, etc. easy to steal. Android applications are driven by messages, and the driven applications are inseparable from the cooperation of the touch mechanism. It can be seen that the touch mechanism plays an important role in the Android system. Since the first Android Trojan was discovered in 2010, the amount of malware under Android has grown rapidly, bringing unpredictable risks to users' data security. With the increase of malicious code in the Android system, the touch mechanism has become the object of choice for attackers. The touch mechanism is the premise of operating all client applications. Therefore, detecting the integrity of the core code of the touch mechanism can effectively prevent malicious code from being implanted in the touch mechanism and ensure the security of user data. The malicious code in the Android system is often not easily discovered by users. Usually, the malicious code is implanted into the system layer, which is more subtle than the malware running at the application layer. More serious calls will be made to the hardware devices of the mobile phone, secret photography, audio recording and so on. Therefore, it is of great significance to improve the security of the Android system and prevent the leakage of private information to users.

Trusted Computing is a trusted computing platform that is widely used in computing and communication systems based on the support of hardware security modules to improve the overall security of the system. The concept of trusted computing first appeared in the Rainbow series of information system security related documents in the United States. The world's leading IT giants IBM, Hewlett-Packard, Intel and Microsoft jointly initiated and established the Trusted Computing Platform Alliance (Trusted Computing Platform Alliance for short). For TCPA), the establishment of the Trusted Computing Platform Alliance also marks that the basic research and industrialization of trusted computing technology has entered a new stage of development. In 2003, the Trusted Computing Platform Alliance was renamed and reorganized into the Trusted Computing Group (TCG for short). The Trusted Computing Platform Alliance and the Trusted Computing Organization have researched and determined a variety of trusted computing technical specifications on trusted computing platforms, trusted storage, and trusted network connections since their establishment.

Trusted computing technology belongs to a brand-new information system security technology. The principle applied in Android mobile intelligent terminals is to introduce the security chip architecture into the hardware platform of mobile terminals, thereby improving the security and reliability of Android terminals. It just makes up for the defects brought by the open nature of the Android system. A large number of application examples show that the research and development of trusted mobile platforms is a milestone in the development of trusted computing technology. Intel and IBM proposed the research and development of trusted mobile platforms in 2004, and established corresponding protocols, which greatly improved the security of mobile smart terminals. sex. In terms of its structural characteristics, the trusted mobile platform is a system with cryptographic computing capabilities and storage functions. It further ensures the security of mobile smart terminals through systems such as encryption, authentication, and keys, which can effectively solve the problem of Android mobile smart terminals. facing security issues.

SUMMARY OF THE INVENTION

The purpose of the present invention is to provide an Android system-based startup process integrity measurement method, which solves the problems in the prior art that the integrity measurement architecture in trusted computing is too complex, difficult to expand, and does not reflect behavior credibility.

The technical solution adopted by the present invention is that a method for detecting the integrity of a startup process based on an Android system comprises the following steps:

From power-on, the root of trust measurement CRTM boots the Bootloader and verifies its integrity, the Bootloader is the bootloader before the system starts;

Use the secure hash algorithm SHA-1 to calculate the actual metric value from the Bootloader, and compare the obtained actual metric value with the RIM value in the RIM certificate. If the comparison result is consistent, store the result in the platform configuration register to store the root of trust ;

Then the CRTM transfers the control to the Bootloader; if the comparison results are different, the boot fails and the inspection report is sent to the user.

In the process of measuring the kernel by the Bootloader, the trust measurement model is used to obtain the comprehensive measurement value TValue for the kernel, and the corresponding trust decision is made according to the credibility threshold Tm. The credibility threshold Tm is used as the judgment of the trust decision. Standard, if the system kernel is credible, then TValue>Tm, then store the result in the platform configuration register to store the root of trust, and then hand over control to the system kernel, otherwise the system cannot continue to start, and the test report is sent to Users, according to the same method as above, measure the Android operating system and third-party applications, and finally achieve the credibility of the entire Android system.

The present invention is also characterized in that,

The mobile trusted module MTM standardizes several trusted roots, including measuring the trusted root RTM, storing the trusted root RTS, and reporting the trusted root RTR. The RTM is stored in the read-only ROM as a software module, and the first time after the system is powered on. One that is executed and cannot be modified, used by the MTM as a starting point for trust measurement and verification, storing the Root of Trust RTS and reporting the Root of Trust RTR as a hardware module included in the MTM for integrity storage and reporting, The reference integrity metric value RIM and RIM certificate are also defined in the MTM. The value of RIM is the metric summary for the entity, the secure storage area written to the root of trust in advance, and the benchmark value that the entity meets the expectations. Integrity verification provides reference. RIM certificate is a digitally signed integrity protection structure, which contains RIM value, digital signature and some related additional information.

The storage trusted root RTS consists of the trusted platform metric configuration register PCR. The PCR is a 160-bit storage location, and the number of registers is at least 16, which are all stored in the mobile trusted module. It allows to store an unlimited number of metric values. The order of measurements is also maintained, and the PCR stores the cumulative hash value of all currently generated measurement values SHA-1, and the 160-bit cumulative HASH value represents the integrity status of all measured components.

The trust measurement model is expressed as {V, E}, where V represents the node set, E represents the edge set, the node set V is a finite set {rt, T}, rt represents the root target, that is, rt is represented as {TValue, TCount}, TValue Indicates the comprehensive measurement value obtained after the measurement of each sub-goal is completed, TCount indicates the number of sub-goals, and TCount is {0...m}. When TCount=0, it is the minimum target that needs to be measured. Set T={t1,t2,...tn},t={Name,Type,TValue,TCount}, Name represents the name of the target, Type represents the target type, the edge set E is the combination relationship, the edge set E represents the weight value, the weight The value ranges from [0, 1] and satisfies the normalization condition.

The measurements in step 1 are as follows:

During the running process of the Bootloader, the Bootloader reads the system kernel image ZImage and the root file system image Ramdisk.img from the flash to the ARM, the current control is in the Bootloader, and measures the kernel: set the system kernel to be measured as the root target rt , After the Android source code is compiled, ZImage, System.img, Ramdisk.img, Userdata.img, Recovery.img images are generated. The above images contain the files and related libraries required for Android to start and run. Therefore, the system kernel is measured, that is It is to measure all the generated images. In the process of measuring the system kernel, the images of System.img, Ramdisk.img, ZImage, Recovery.img and Userdata.img are used as sub-targets of the root target;

The importance of different images and the possibility of being invaded are different, so different weights should be given to different images. ZImage is the kernel image, and System.img is the system image, which is used to store important files of the Android system, including packages and files. The library file, the memory disk file Ramdisk.img stores the files to be loaded when the Linux kernel is started. The Recovery.img image is only used for flashing the machine. Bootloader enters the corresponding mode according to the user's choice. Different modes include ZImage and Ramdisk.img files, Userdata.img It is a user data mirror, which stores user-related data and determines the size of the Android device memory;

According to the importance of the above-mentioned images and the degree of risk, let the weight allocated by ZImage be w1, the weight allocated by System.img to be w2, the weight allocated by Ramdisk.img to be w3, and the weight allocated by Recovery.img The value is w4, and if the weight assigned by Userdata.img is w5, the relationship between the corresponding weights should be:

w1+w2+w3+w4+w5=1;

w1>w2>w3>w4>w5;

The sub-files contained in the described kernel image ZImage are all system core files, so the overall ZImage image is measured when measuring;

The System.img image contains the following subdirectory files: app, bin, etc, fonts, framework, lib, media, priv-app, tts, usr and vendor, and the weight distribution of these directories is analyzed during measurement:

The weight distribution order of each directory is:

framework>priv-app>app>xbin=bin=lib>etc>fonts=tts=media=user=vendor

Ramdisk.img contains some very important configuration files and the first process init loaded after the kernel is started. Init will parse the init.rc and init.goldfish.rc configuration files to initialize and load system libraries and programs until the boot is completed. The init process is also responsible for creating several child processes in the system, including the Zygote process. The Zygote process is the parent process of all JAVA processes. The init action execution is divided into four time periods: early-init, init, early-boot, boot, according to The order in which the configuration file is parsed during the startup process is assigned its weight value. The order of assignment is:

init.rc>init.goldfish.rc>ueventd.rc>init.environ.rc>init.usb.rc>init.trace.rc

Because Recovery.img is composed of ZImage and Ramdisk.img, the ZImage part is the same as the normally booted kernel image, so it only needs to measure its own Ramdisk.img image, and the measurement weight distribution is consistent with the above. For Userdata.img, Just measure the nativebenchmark file unrelated to the user application as the measure of Userdata.img;

After assigning the weights of the subdirectories corresponding to each image, measure the first-level subdirectories separately. The measurement result is represented by e _i , where i represents the number of first-level subdirectories. If the subdirectory measurement result is the same as the reference integrity measurement value, Then the measurement result of the corresponding sub-directory is 1, otherwise the result is 0, and the weight corresponding to the sub-directory is expressed as a _i , where i represents the number of first-level sub-directories, then the comprehensive measurement value TValue:

TValue=∑e _i *a _i

For the case of secondary directories, a method similar to that described above is used for measurement.

The beneficial effect of the present invention is that a method for measuring the integrity of the startup process based on the Android system combines the credibility measurement mechanism with the Android platform, and on the basis of analyzing the integrity measurement mechanism, the concept of credibility is expanded, A trust measurement mechanism is introduced, a security chip is added as a root of trust in the system, and a chain of trust is constructed by a step-by-step measurement method, and then this trust is extended to the entire Android terminal to ensure the security of the information system. In the process of step-by-step measurement, the comprehensive trust degree of the measurement target is calculated according to the model, and the comprehensive trust degree is compared with the reliability threshold value. If it is higher than the reliability threshold value, the control power is given to the measurement target, otherwise the system fails to start, and informs the user of the detection report result. Compared with the binary measurement result of the TCG integrity measurement model, it has better scalability and applicability.

Description of drawings

Fig. 1 is the Android startup process flow chart in a kind of Android system-based startup process integrity metric detection method of the present invention;

Fig. 2 is the trust chain transfer process based on trusted mobile module in a kind of Android system-based startup process integrity measurement method of the present invention;

FIG. 3 is an improved metric model proposed in an Android system-based startup process integrity metric detection method of the present invention.

Detailed ways

The present invention will be described in detail below with reference to specific embodiments.

The present invention is a startup process integrity measurement method based on the Android system, which combines the trusted measurement mechanism with the Android platform, and can effectively judge the integrity and security of the Android code. Next, a detailed description will be made:

At present, the security factor of Android smart terminals is relatively low. In order to use trusted computing technology for security reinforcement, it is necessary to add MTM (Mobile Trusted Module) trusted modules to Android smart terminals. Because the Android system generally has the characteristics of small size and low energy consumption, Therefore, when the MTM trusted service system is added, the storage processing can be extended through the TF card, and the MTM based on the TF interface can be used to carry out trusted computing transformation of the Android intelligent mobile terminal system to meet the needs of security reinforcement.

A large number of examples show that the trust chain transfer technology based on MTM (as shown in Figure 2) is the main technology of trusted computing technology to ensure the integrity and security of the Android system. Reasonable use of the trust chain technology can make the trust relationship of the trusted computing platform. From the root of trust measurement to the entire Android terminal system. The mobile trust chain is based on the MTM mobile trusted module, and the starting point is the core root of trust module CRTM (core root of trust moudle). CRTM is the first program that runs after the system is powered on, and is a simple and controllable code module , that it is completely credible.

An Android system-based startup process integrity measurement detection method of the present invention includes the following steps:

As shown in Figure 1, starting from power-on, the trusted measurement root CRTM boots the Bootloader and verifies its integrity. The Bootloader is the bootloader before the system starts;

Use the secure hash algorithm SHA-1 to calculate the actual metric value from the Bootloader, and compare the obtained actual metric value with the RIM value in the RIM certificate. If the comparison result is consistent, store the result in the platform configuration register to store the root of trust ;

Then the CRTM transfers the control to the Bootloader; if the comparison results are different, the boot fails and the inspection report is sent to the user.

In the process of measuring the kernel by the Bootloader, the trust measurement model is used to obtain the comprehensive measurement value TValue for the kernel, and the corresponding trust decision is made according to the credibility threshold Tm. The credibility threshold Tm is used as the judgment of the trust decision. Standard, if the system kernel is credible, then TValue>Tm, then store the result in the platform configuration register to store the root of trust, and then hand over control to the system kernel, otherwise the system cannot continue to start, and the test report is sent to Users, according to the same method as above, measure the Android operating system and third-party applications, and finally achieve the credibility of the entire Android system.

Among them, the mobile trusted module MTM standardizes several trusted roots, including measuring the trusted root RTM, storing the trusted root RTS, and reporting the trusted root RTR. The RTM is stored in the read-only ROM as a software module, and the system is powered on. After the first one is executed and cannot be modified, it is used for the MTM as the starting point of trust measurement and verification, storing the root of trust RTS and reporting the root of trust RTR as a hardware module included in the MTM for integrity storage and In the report, the referential integrity metric value RIM and RIM certificate are also defined in the MTM. The value of RIM is the metric summary for the entity, the secure storage area written to the root of trust in advance, and the benchmark value that the entity meets expectations. The sub-system integrity verification provides a reference. The RIM certificate is a digitally signed integrity protection structure, which contains the RIM value, digital signature and some related additional information.

The storage trusted root RTS consists of the trusted platform metric configuration register PCR. The PCR is a 160-bit storage location, and the number of registers is at least 16, which are all stored in the mobile trusted module. It allows to store an unlimited number of metric values. The order of measurements is also maintained, and the PCR stores the cumulative hash value of all currently generated measurement values SHA-1, and the 160-bit cumulative HASH value represents the integrity status of all measured components.

However, due to the large number of Android system files, the purpose of Android's Hardware Abstraction Layer (HAL) is to abstract the hardware. In order to protect the intellectual property rights of hardware manufacturers, the hardware interface details of a specific platform are hidden. It can be seen that different hardware manufacturers have different relevant file codes for the hardware abstraction layer, and the reference integrity measurement values required for Android mobile terminals of different hardware manufacturers are different, which makes the original trusted measurement mechanism feasible. Weak scalability. Similarly, the logo.c under the source code /system/core/init and the bootanimation under framworks/base/cmds are used to set the boot animation. The boot animations corresponding to different mobile terminal devices are also different. For these changes of the manufacturer , we still believe that the mobile terminal is credible.

As shown in Figure 3, the trust metric model is represented as {V, E}, where V represents the node set, E represents the edge set, the node set V is a finite set {rt, T}, rt represents the root target, that is, rt is represented as { TValue, TCount}, TValue represents the comprehensive measurement value obtained after each sub-target measurement is completed, TCount represents the number of sub-targets, TCount is {0...m}, when TCount=0, it is the minimum target that needs to be measured , cannot be further divided, the target set T={t1,t2,...tn},t={Name,Type,TValue,TCount}, Name represents the name of the target, Type represents the target type, the edge set E is a combination relationship, and the edge set E represents the weight value, the value range of the weight value is [0, 1], and the normalization condition is satisfied.

The measurements in step 1 are as follows:

During the running process of the Bootloader, the Bootloader reads the system kernel image ZImage and the root file system image Ramdisk.img from the flash to the ARM, the current control is in the Bootloader, and measures the kernel: set the system kernel to be measured as the root target rt , After the Android source code is compiled, ZImage, System.img, Ramdisk.img, Userdata.img, Recovery.img images are generated. The above images contain the files and related libraries required for Android to start and run. Therefore, the system kernel is measured, that is It is to measure all the generated images. In the process of measuring the system kernel, the images of System.img, Ramdisk.img, ZImage, Recovery.img and Userdata.img are used as sub-targets of the root target;

The importance of different images and the possibility of being invaded are different, so different weights should be given to different images. ZImage is the kernel image, and System.img is the system image, which is used to store important files of the Android system, including packages and files. The library file, the memory disk file Ramdisk.img stores the files to be loaded when the Linux kernel is started. The Recovery.img image is only used for flashing the machine. Bootloader enters the corresponding mode according to the user's choice. Different modes include ZImage and Ramdisk.img files, Userdata.img It is a user data mirror, which stores user-related data and determines the size of the Android device memory;

According to the importance of the above-mentioned images and the degree of risk, let the weight allocated by ZImage be w1, the weight allocated by System.img to be w2, the weight allocated by Ramdisk.img to be w3, and the weight allocated by Recovery.img The value is w4, and if the weight assigned by Userdata.img is w5, the relationship between the corresponding weights should be:

w1+w2+w3+w4+w5=1;

w1>w2>w3>w4>w5;

Each image contains various file directories. Different directories correspond to different functions in Android. When determining the weight value, the following two factors should be considered:

One is the importance of judging the credibility of the system, the higher the importance, the greater the weight.

The second is to judge its independence. The greater the independence, and other files have dependencies on it, the greater the weight.

The sub-files contained in the described kernel image ZImage are all system core files, so the overall ZImage image is measured when measuring;

The System.img image contains the following subdirectory files: app, bin, etc, fonts, framework, lib, media, priv-app, tts, usr, and vendor. The weight distribution of these directories is analyzed when measuring:

A large number of low-level attacks occur in the Android Framework layer, such as the privacy acquisition of touch events. By modifying the source code of the Framework layer, the purpose of privacy theft is achieved. These changes will cause changes to the framework.jar file in the Framework directory of the System.img mirror, so we should assign a high weight to the Framework directory under the System.img file. priv-app and app store the core apk files and applications of the system respectively, and malware will be installed in these two file directories to become system-level applications. In addition, the Root virus will inject elf files into the xbin, bin, and lib directories of the mobile phone, causing the mobile phone to deduct fees without permission and malicious pop-up windows. Therefore, these directories are the directories we need to focus on. On the contrary, the Vendor directory stores the configuration files of third-party manufacturers, so we can give it a relatively low weight. Therefore, the weight distribution order of each directory is:

framework>priv-app>app>xbin=bin=lib>etc>fonts=tts=media=user=vendor

Ramdisk.img contains some very important configuration files and the first process init loaded after the kernel is started. Init will parse the init.rc and init.goldfish.rc configuration files to initialize and load system libraries and programs until the boot is completed. The init process is also responsible for creating several child processes in the system, including the Zygote process. The Zygote process is the parent process of all JAVA processes. The init action execution is divided into four time periods: early-init, init, early-boot, boot, according to The order in which the configuration file is parsed during the startup process is assigned its weight value. The order of assignment is:

init.rc>init.goldfish.rc>ueventd.rc>init.environ.rc>init.usb.rc>init.trace.rc

Because Recovery.img is composed of ZImage and Ramdisk.img, the ZImage part is the same as the normally booted kernel image, so it only needs to measure its own Ramdisk.img image, and the measurement weight distribution is consistent with the above. For Userdata.img, Just measure the nativebenchmark file unrelated to the user application as the measure of Userdata.img;

After assigning the weights of the subdirectories corresponding to each image, measure the first-level subdirectories separately. The measurement result is represented by e _i , where i represents the number of first-level subdirectories. If the subdirectory measurement result is the same as the reference integrity measurement value, Then the measurement result of the corresponding sub-directory is 1, otherwise the result is 0, and the weight corresponding to the sub-directory is expressed as a _i , where i represents the number of first-level sub-directories, then the comprehensive measurement value TValue:

TValue=∑e _i *a _i

For the case of secondary directories, a method similar to that described above is used for measurement.

The improved measurement model aggregates the measurement results of leaf nodes to each sub-target according to different weights, and then aggregates to the total target to obtain the final credibility. The TCG integrity measurement model obtains binary results, and the improved measurement model obtains the comprehensive trust degree. Compared with the original model, the improved measurement model has higher scalability and applicability.

Claims (5)

1. a startup process integrity measurement method based on Android system, is characterized in that, comprises the following steps: From power-on, the root of trust measurement CRTM boots the Bootloader and verifies its integrity, the Bootloader is the bootloader before the system starts; Use the secure hash algorithm SHA-1 to calculate the actual metric value from the Bootloader, and compare the obtained actual metric value with the RIM value in the RIM certificate. If the comparison result is consistent, store the result in the platform configuration register to store the root of trust ; Then the CRTM transfers the control to the Bootloader; if the comparison results are different, the startup fails, and the inspection report is sent to the user; In the process of measuring the kernel by the Bootloader, the trust measurement model is used to obtain the comprehensive measurement value TValue for the kernel, and the corresponding trust decision is made according to the credibility threshold Tm. The credibility threshold Tm is used as the judgment of the trust decision. Standard, if the system kernel is credible, then TValue>Tm, then store the result in the platform configuration register to store the root of trust, and then hand over control to the system kernel, otherwise the system cannot continue to start, and the test report is sent to Users, according to the same method as above, measure the Android operating system and third-party applications, and finally achieve the credibility of the entire Android system. 2. a kind of starting process integrity measurement method based on Android system according to claim 1 is characterized in that, mobile trusted module MTM has standardized some trusted roots, including measuring trusted root RTM, storage trusted root RTS, reporting root of trust RTR, in which RTM is stored as a software module in read-only ROM, the first to be executed after the system is powered on and cannot be modified, used for MTM as a starting point for trust measurement and verification, storage Trusted Root RTS and Reporting Trusted Root RTR are included in MTM as hardware modules for integrity storage and reporting. Reference integrity metrics RIM and RIM certificates are also defined in MTM. The value of RIM is to be used for entities. The metric summary is a secure storage area written into the trust root in advance. It is the benchmark value that the entity meets the expectations, and provides a reference for each system integrity verification. The RIM certificate is a digitally signed integrity protection structure, which contains With the value of RIM, digital signature and some related additional information. 3. a kind of start-up process integrity measurement method based on Android system according to claim 2, is characterized in that, storage Trusted Root RTS is made up of Trusted Platform Measurement Configuration Register PCR, and PCR is the storage position of 160 bits, The number of registers is at least 16, and they are all stored in the mobile trusted module. It allows to store an unlimited number of metric values, and also maintains the order of metrics. PCR saves the cumulative hash of all currently generated metric values SHA-1. Hash value, a 160-bit cumulative HASH value that represents the status of the integrity of all measured components. 4. The Android system-based startup process integrity metric detection method according to any one of claims 1 to 3, wherein the trust metric model is represented as {V, E}, where V represents a node set, and E Represents the edge set, the node set V is a finite set {rt, T}, rt represents the root target, that is, rt is represented as {TValue, TCount}, TValue represents the comprehensive measurement value obtained after completing the measurement of each sub-target, and TCount represents the sub-target The number of , TCount is {0...m}, when TCount=0, it is the minimum target that needs to be measured, which cannot be further divided, the target set T={t1,t2,...tn}, t={Name,Type ,TValue,TCount}, Name represents the name of the target, Type represents the target type, the edge set E is the combination relationship, the edge set E represents the weight value, the value range of the weight value is [0, 1], and the normalization condition is satisfied. 5. a kind of starting process integrity measurement method based on Android system according to claim 4, is characterized in that, in described step 1, measurement is specifically as follows: During the running process of the Bootloader, the Bootloader reads the system kernel image ZImage and the root file system image Ramdisk.img from the flash to the ARM, the current control is in the Bootloader, and measures the kernel: set the system kernel to be measured as the root target rt , After the Android source code is compiled, ZImage, System.img, Ramdisk.img, Userdata.img, Recovery.img images are generated. The above images contain the files and related libraries required for Android to start and run. Therefore, the system kernel is measured, that is It is to measure all the generated images. In the process of measuring the system kernel, the images of System.img, Ramdisk.img, ZImage, Recovery.img and Userdata.img are used as sub-targets of the root target; The importance of different images and the possibility of being invaded are different, so different weights should be given to different images. ZImage is the kernel image, and System.img is the system image, which is used to store important files of the Android system, including packages and files. The library file, the memory disk file Ramdisk.img stores the files to be loaded when the Linux kernel is started. The Recovery.img image is only used for flashing the machine. Bootloader enters the corresponding mode according to the user's choice. Different modes include ZImage and Ramdisk.img files, Userdata.img It is a user data mirror, which stores user-related data and determines the size of the Android device memory; According to the importance of the above-mentioned images and the degree of risk, let the weight allocated by ZImage be w1, the weight allocated by System.img to be w2, the weight allocated by Ramdisk.img to be w3, and the weight allocated by Recovery.img The value is w4, and if the weight assigned by Userdata.img is w5, the relationship between the corresponding weights should be: w1+w2+w3+w4+w5=1; w1>w2>w3>w4>w5; The sub-files contained in the described kernel image ZImage are all system core files, so the overall ZImage image is measured when measuring; The System.img image contains the following subdirectory files: app, bin, etc, fonts, framework, lib, media, priv-app, tts, usr and vendor, and the weight distribution of these directories is analyzed during measurement: The weight distribution order of each directory is: framework>priv-app>app>xbin=bin=lib>etc>fonts=tts=media=user=vendor Ramdisk.img contains some very important configuration files and the first process init loaded after the kernel is started. Init will parse the init.rc and init.goldfish.rc configuration files to initialize and load the system library and program until the boot is completed. The init process is also responsible for creating several child processes in the system, including the Zygote process. The Zygote process is the parent process of all JAVA processes. The init action execution is divided into four time periods: early-init, init, early-boot, boot, according to The order in which the configuration file is parsed during the startup process is assigned its weight value. The order of assignment is: init.rc>init.goldfish.rc>ueventd.rc>init.environ.rc>init.usb.rc>init.trace.rc Because Recovery.img is composed of ZImage and Ramdisk.img, the ZImage part is the same as the normally booted kernel image, so it only needs to measure its own Ramdisk.img image, and the measurement weight distribution is consistent with the above. For Userdata.img, Just measure the nativebenchmark file unrelated to the user application as the measure of Userdata.img; After assigning the weights of the subdirectories corresponding to each image, measure the first-level subdirectories separately. The measurement result is represented by e _i , where i represents the number of first-level subdirectories. If the subdirectory measurement result is the same as the reference integrity measurement value, Then the measurement result of the corresponding sub-directory is 1, otherwise the result is 0, and the weight corresponding to the sub-directory is expressed as a _i , where i represents the number of first-level sub-directories, then the comprehensive measurement value TValue: TValue=∑e _i *a _i For the case of secondary directories, a method similar to that described above is used for measurement.