Terminal software protection method and device, terminal equipment and computer storage medium

Abstract

The invention relates to the technical field of computers, in particular to a terminal software protection method and device, terminal equipment and a computer storage medium, when a startup instruction is detected, whether startup is performed for the first time or not is judged firstly, if not, a check code and startup times of each module in a logic code module string are obtained, and the check code and the startup times are stored; and when detecting that the check code of any module is not the initial check code, performing cyclic check on the module string according to the startup times and the check sequence. Only when all the modules pass the verification, the startup operation is executed, and if any module does not pass the verification, the startup is stopped. According to the method, terminal software is effectively prevented from being tampered through a cyclic verification mechanism, it is ensured that equipment runs in the safe and reliable state of the software, the safety and reliability of the terminal equipment are enhanced, and risks such as data leakage and equipment failure caused by software problems are avoided.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a method and apparatus for protecting terminal software, a terminal device, and a computer storage medium. Background Art

[0002] In today's digital age, terminal devices such as portable WIFI are widely used in people's daily lives and work. However, with the continuous development of technology and the increasing sophistication of hacker attack methods, hackers not only have the ability to crack terminal software, but may also spread cracking methods to expand their attack scope, posing a serious threat to the secure operation of terminal devices. Specifically, among the various chips used inside certain terminal devices, such as portable WIFI, only the CPU can provide a unique machine ID for strict binding with the hardware. In contrast, WIFI chips, FLASH chips, charging chips, etc. do not have such a unique identifier. Therefore, when hackers attempt to crack terminal software, they often use the CPU ID as the entry point for the attack and carry out targeted cracking activities by leveraging the binding relationship between this unique identifier and the hardware.

[0003] Traditional methods for protecting terminal software mainly focus on protecting the burning process of the image file to ensure the correct installation and operation of the software on the terminal device. However, hackers may obtain the shell permission of the operating system by exploiting software vulnerabilities, and then bypass the protection measures for the burning process and directly replace the programs of the operating system, which not only destroys the integrity of the terminal software, but may also lead to serious consequences such as user data leakage and device function failure. Summary of the Invention

[0004] To overcome the deficiencies of the prior art, the present invention provides a method and apparatus for protecting terminal software, a terminal device, and a computer storage medium. By using a cyclic verification mechanism and the number of dynamic boot-ups, the reliability of the terminal device is improved, and the normal operation of the device during the boot-up process is ensured.

[0005] The first aspect of this application provides a method for protecting terminal software, the method including: When a boot instruction is detected, determine whether the boot instruction belongs to the first boot instruction; When it is determined that the boot instruction does not belong to the first boot instruction, obtain the verification code and the number of boot-ups corresponding to each logical code module in the logical code module string; When it is detected that the verification code of any one logical code module in the logical code module string is not the initial verification code, perform a cyclic verification on the logical code module string according to the number of boot-ups and the verification order; When it is determined that the verification results of each logic code module in the logic code module string are all verified successfully, perform the startup operation corresponding to the startup instruction; When it is determined that there is any logic code module in the logic code module string whose verification result is verification failed, stop executing the startup operation corresponding to the startup instruction.

[0006] In an alternative embodiment, the cyclic verification of the logic code module string according to the startup times and verification order includes: Obtain the first startup time corresponding to the first module and the Nth startup time of the Nth module in the logic code module string, where N is an integer greater than 1; When it is determined that the Nth startup time is 1 less than the first startup time, perform a verification code verification on the first module according to the first verification code of the first module to obtain a first verification result; When it is determined that the first verification result is verification passed, determine whether the second startup time of the second module is the same as the first startup time, where the second module is the logic code module adjacent to the first module in the logic code module string and is sorted after the first module; When it is determined that the second startup time is the same as the first startup time, calculate the second verification code corresponding to the second module according to the first verification code, and perform a verification code verification on the second module according to the second verification code to obtain a second verification result; When it is determined that the second verification result is verification passed, repeat the above operations according to the verification order until each logic code module in the logic code module string is verified, or there is any logic code module in the logic code module string whose verification result is verification failed.

[0007] In an alternative embodiment, the method further includes: When it is detected that the verification codes of each logic code module in the logic code module string are initial verification codes and the startup times of each logic code module in the logic code module string are initial startup times, control the first startup module in the logic code module string to enter the Fastboot mode; Obtain the bad block information of each logic code module in the logic code module string and the CPU identifier in the Fastboot mode; Generate a combined Key according to the bad block information and the CPU identifier; Return the combined Key to an external production tool so that the external production tool calculates the first target verification code of each logic code module in the logic code module string based on the combined Key and returns a verification code sequence; When receiving the check code sequence, recalculate the second target check code of each logic code module in the logic code module string according to the combined Key. Compare the first target check code with the second target check code. When it is determined that the first target check code of each logic code module in the logic code module string matches the second target check code, store the check code sequence.

[0008] In an optional embodiment, the method further includes: Obtain the CPU identifier, and determine the target bad block number and target bad block type of the current module according to the bad block information. Generate a target combined Key from the CPU identifier, the target bad block number, and the target bad block type. Calculate the current module check code of the current module according to the previous module check code and the target combined Key.

[0009] In an optional embodiment, the method further includes: Determine the number of bad blocks in the logic code module string according to the bad block information. When it is determined that the number of bad blocks does not meet the preset quantity threshold, randomly select a target number of good blocks from the logic code module string, and mark the good blocks as bad blocks, where the target number is determined according to the number of bad blocks and the preset quantity threshold.

[0010] In an optional embodiment, the method further includes: When it is determined that the bad block type of the first target bad block is the first bad block type, perform a first erasure operation on the first target bad block, where the first target bad block is any bad block in the logic code module string. When it is determined that the erasure result is successful, perform a second erasure operation on the first target bad block until the preset number of erasure times is satisfied, or there is any erasure result that is a failure. When it is determined that the bad block type of the first target bad block is the second bad block type, obtain the spare area of the first page of the first target bad block. Check whether the data in the spare area of the first page is 0xFF. When it is determined that the data in the spare area of the first page is not 0xFF, determine that the detection result of the first target bad block is passed. When it is determined that the data in the spare area of the first page is 0xFF, determine that the detection result of the first target bad block is failed, and terminate the power-on instruction.

[0011] In an optional implementation, the method further includes: When it is determined that the erasure results corresponding to the preset number of erasures of the first target bad block are all successful erasures, obtain the bad block type of the second target bad block; Perform an erasure operation on the second target bad block according to the bad block type of the second target bad block.

[0012] A second aspect of the present application provides a terminal software protection method device, the device includes: An instruction detection module, configured to, when detecting a boot instruction, determine whether the boot instruction belongs to a first boot instruction; A data acquisition module, configured to, when it is determined that the boot instruction does not belong to a first boot instruction, obtain the check code and the number of boot times corresponding to each logic code module in the logic code module string; A cyclic verification module, configured to, when it is detected that the check code of any one logic code module in the logic code module string is not the initial check code, perform cyclic verification on the logic code module string according to the number of boot times and the verification order; A boot execution module, configured to, when it is determined that the verification results of each logic code module in the logic code module string are all verification passed, execute the boot operation corresponding to the boot instruction; A boot stop module, configured to, when it is determined that there is any one logic code module in the logic code module string whose verification result is verification failed, stop executing the boot operation corresponding to the boot instruction.

[0013] A third aspect of the present application provides a terminal device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the steps of the terminal software protection method when executing the computer program.

[0014] A fourth aspect of the present application provides a computer-readable storage medium, on which a computer program is stored, and the computer program implements the steps of the above terminal software protection method when executed by a processor.

[0015] In summary, for the terminal software protection method, device, terminal device, and computer storage medium provided by the present application, when the power-on instruction is detected, it is first determined whether it is the first power-on. When it is not the first power-on, the checksum and the number of power-on times of each module in the logical code module string are obtained. When the checksum of any logical code module in the logical code module string is not the initial checksum, the loop verification mechanism is triggered, and the logical code module string is loop-verified according to the number of power-on times and the preset verification order. By verifying the relevance and correctness of the number of power-on times and the checksum module by module, it is ensured that the module has not been tampered with. Only when all logical code module verifications pass, the power-on operation is performed. When any module verification fails, the power-on is stopped to prevent the device from running in a state where the software is incomplete or tampered with. Through the loop verification mechanism, the present application effectively prevents hackers from bypassing traditional protection measures by tampering with software modules, protects the integrity of the terminal software, and can accurately identify and locate the tampered logical code module, facilitating subsequent maintenance and repair. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 FIG. is a flowchart showing a terminal software protection method according to an embodiment of the present application; Figure 2 FIG. is a functional module diagram of a terminal software protection device according to an embodiment of the present application; Figure 3 FIG. is a structural diagram of a terminal device according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] The present invention will be further described below in conjunction with the drawings and embodiments.

[0018] The concept, specific structure, and technical effects of the present invention will be clearly and completely described below in conjunction with the embodiments and the drawings to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, other embodiments obtained by those skilled in the art without creative efforts shall fall within the scope of protection of the present invention. In addition, all the connection / connection relationships involved in the patent do not refer only to the direct connection of components, but refer to the more optimal connection structure that can be formed by adding or reducing connection accessories according to the specific implementation situation. The various technical features in the present invention can be combined with each other without conflicting with each other.

[0019] In the embodiment of the present application, the terminal software protection method is described from the terminal device, and the terminal device uses Nand flash for storage.

[0020] In some embodiments, at the beginning stage of software development, the Nand Flash partition is increased, that is, three dedicated partitions are created in the Nand Flash, namely the bad block information partition, the module verification partition, and the boot count partition. Among them, the bad block information partition is used to record bad block information at 5 bytes per entry. That is, the bad block information may include the bad block serial number and the bad block type. In the embodiments of the present application, the bad blocks are defined into two categories. One category is the bad blocks that can stably fail (referred to as bad block type 1), and the other category is the bad blocks that will not stably fail (referred to as bad block type 0). Among them, the bad blocks represented by bad block type 0 may refer to real bad blocks, or may be good blocks specially marked as bad blocks in the present application for enhancing security. The storage method of bad blocks is in the format of every five bytes corresponding to one bad block. Among them, the first four bytes are used to store the bad block serial number of the bad block, and the fifth byte is used to identify the bad block type of the bad block. It should be noted that the above storage method of bad blocks is only one of the storage methods, and it can also be stored in other ways, which is not specifically limited. The module verification partition is used to store the verification code of each logical code module in the verification logic code module string and the corresponding boot times. Among them, the logical code module string can be represented as an image, such as a linux kernel image, an sbl image of a Qualcomm platform, an obm image of asr, a u-boot image, etc., or can be represented as a program under linux, such as a dialing program after booting, a program responsible for processing the UI. The modules are cyclically verified in a string sequence. Taking Qualcomm as an example, such a module string sbl→lk→boot→dialing program→http server program can be arranged at startup. Each member of each module string has a verification code, which is calculated by using the verification code of the previous module as the input, and the corresponding verification code is obtained and filled into the module verification partition for storage, for the next module to obtain. At the same time, each module needs to calculate the verification code of the previous module according to the verification code of the module before the previous one to verify the previous module. The boot count partition is used to record the current boot count and the boot counts corresponding to the verification information of each module. Each time the device boots, a value is obtained from the Flash, incremented by 1, and then written back. That is, the update logic of the boot count is the current boot count of the current module = the boot count of the previous module + 1, and the difference between the boot counts of the last module and the first module is 1.

[0021] Refer to Figure 1 As shown, it is a schematic flowchart of a terminal software protection method shown in the embodiments of the present application. The terminal software protection method includes the following steps.

[0022] S11, when a boot instruction is detected, determine whether the boot instruction belongs to the first boot instruction.

[0023] In some embodiments, when the terminal device receives a power-on instruction operated by the user, it first determines whether the received power-on instruction is a first-time power-on instruction, that is, whether the terminal device is powered on for the first time. Before the first power-on, the terminal device can preset that the check code corresponding to each logic code module in the logic code module string is set to be empty or a fixed value, such as 0xFFFFFFF. At the same time, the power-on times corresponding to each logic code module in the logic code module string are also set to 0xFFFFFFF. That is, when the check code corresponding to each logic code module in the logic code module string is the initial check code (such as 0xFFFFFFF) and the power-on times are all the initial power-on times (such as 0xFFFFFFF), it can be determined that the terminal device is powered on for the first time.

[0024] When it is determined that the terminal device is powered on for the first time, if the first module in the logic code module string reads that the check information and power-on times of other modules are both 0xFFFFFFF, it is determined that the power-on instruction is a first-time power-on instruction. Herein, the first module refers to the logic code module ranked first in the logic code module string, and other modules refer to the remaining logic code modules in the logic code module string except the first module. When it is determined that the power-on instruction is a first-time power-on instruction, the terminal device controls the first module to enter the Fastboot mode, and the correct check code is input through the Fastboot interface by an external production tool for initialization.

[0025] It should be noted that the module that needs to be protected is added to the logic code module string.

[0026] S12. When it is determined that the power-on instruction is not a first-time power-on instruction, obtain the check code and power-on times corresponding to each logic code module in the logic code module string.

[0027] When it is determined that the power-on instruction is not a first-time power-on instruction, that is, the terminal device is not powered on for the first time, the check code and power-on times corresponding to each logic code module in the logic code module string are also obtained, and the corresponding logic code module is verified according to the check code and power-on times.

[0028] In an optional embodiment, the method further includes: Obtain the CPU identifier, and determine the target bad block number and target bad block type of the current module according to the bad block information; Generate a target combination Key from the CPU identifier, the target bad block number, and the target bad block type; Calculate the current module check code of the current module according to the previous module check code and the target combination Key.

[0029] In some embodiments, the terminal device may maintain a Bad Block Table (BBT) that records all known bad block information. By querying the bad block table, the bad block information can be obtained through direct querying of the bad block table, and it can be determined which logical code modules in the logical code module string belong to bad blocks.

[0030] In terminal devices such as Nand Flash, each block usually contains multiple pages, and in addition to the data area, each page also has an additional area called the Spare Area (or OOB, Out-Of-Band), and the Spare Area usually contains some metadata, such as ECC check codes, bad block markers, etc. When it is determined that there is no bad block table in the terminal device, or when verifying the accuracy of the bad block table, the bad block markers in the spare area (Spare Area) of the first page of each logical code module in the logical code module string are traversed to determine bad blocks. Specifically, for each block, the Spare Area of its first page is obtained, and the value of a specific byte is checked. If the value is not equal to 0xFF (or other marker values representing bad blocks according to the specifications of the specific device), then the block is considered a bad block.

[0031] The terminal device can perform continuous erasure operations on each bad block module in the logical code module string in advance according to a preset number threshold (for example, 3 times). If the erasure result of each erasure operation is an erasure failure, the module type of the logical code module is determined as bad block type 1; otherwise, it is marked as bad block type 0. Since the bad block information includes the bad block serial number and the bad block type, for the convenience of understanding and distinction, the module serial number of the current module is called the target bad block serial number, and the module type of the current module is called the target bad block type. In the current module, when it is necessary to perform checksum verification on the current module, the terminal device can combine the bad block information and the CPU identifier (hereinafter simply referred to as CPU ID) as a combined Key, and select any one of the encryption algorithms to calculate the checksum, that is, generate the target combined Key according to the target bad block serial number, the target bad block type, and the CPU ID. In the embodiments of the present application, for the convenience of understanding the inventive concept of the present application, the encryption algorithm is described by taking HmacSHA1 as an example. Among them, the combined Key refers to splicing multiple information fields into a continuous binary data stream according to a preset format as the input key of the encryption algorithm HmacSHA1 to ensure the uniqueness and non-tampering of the generated checksum. The preset format includes the bad block serial number, the bad block type, and the CPU ID. The bad block serial number occupies 4 bytes, the bad block type occupies 1 byte, and the length of the CPU ID is adjusted according to the actual CPU ID. Specifically, the terminal device can splice the bad block serial number, the bad block type, and the CPU ID according to the data type as the combined Key, that is, convert the bad block serial number into a 4-byte big-endian binary data (such as to_bytes(4, 'big') in Python), and convert the bad block type into a 1-byte binary data (such as to_bytes(1, 'big')), and then directly splice them with the CPU ID; or directly connect all the fields of the bad block serial number, the bad block type, and the CPU ID in sequence to form a continuous binary data stream as the combined Key, that is, bad block 1 → bad block 2 →... → CPU ID.

[0032] It should be noted that the number of bad blocks needs to meet the preset number threshold. For the convenience of understanding the inventive concept of the present application, the preset number threshold in the embodiments of the present application is described by taking 4 as an example. The combined Key is specifically the bad block 1 serial number (4 bytes) + the bad block 1 type (1 byte) + the bad block 2 serial number (4 bytes) + the bad block 2 type (1 byte) + the bad block 3 serial number (4 bytes) + the bad block 3 type (1 byte) + the bad block 4 serial number (4 bytes) + the bad block 4 type (1 byte) + the CPU ID.

[0033] Further, the terminal device can obtain the verification code of the previous module (referred to as the previous module verification code), and calculate the verification code of the current module according to the previous module verification code and the target combination Key, which is called the current module verification code. Herein, the previous module is the previous logic code module adjacent to the current module in the logical code module string. Specifically, inputting the previous module verification code and the target combination Key into HmacSHA1 can output the current module verification code corresponding to the current module. It should be noted that the length of the verification code will be determined by the selected encryption algorithm. For example, the verification code generated by HmacSHA1 is 20 bytes in length.

[0034] According to the above embodiments where the verification codes are the same, the terminal device can calculate the previous module verification code. When the first module in the logical code module string needs to calculate the corresponding verification code, the verification code corresponding to the last module in the logical code module string is obtained for calculation. When the terminal device is powered on for the first time, that is, when calculating the verification code for the first time, the verification values of all modules are a predefined initial value, such as 0xFFFFFFFF or a certain specific fixed value. Direct verification will fail because the verification code has not been generated yet.

[0035] Through the above optional implementation methods, by utilizing the characteristic of the Nand Flash having a random number of bad blocks and combining it with other hardware IDs such as the CPU ID, the complexity and uniqueness of the device's hardware characteristic information are increased, greatly enhancing the overall security protection of the device. Compared with the traditional method that only relies on a single hardware ID for security protection, it can effectively resist more types of security attacks, provide a more reliable security guarantee for the terminal device, and reduce the risk of the device being illegally invaded due to the imitation or tampering of the hardware information.

[0036] In an optional implementation method, the method further includes: Determining the number of bad blocks in the logical code module string according to the bad block information; When it is determined that the number of bad blocks does not meet the preset number threshold, randomly select a target number of good blocks from the logical code module string, and mark the good blocks as bad blocks, where the target number is determined according to the number of bad blocks and the preset number threshold.

[0037] In some embodiments, the number of bad blocks needs to meet a preset number threshold, such as 4. The terminal device can obtain the number of bad blocks of the bad blocks existing in the logical code module string according to the bad block information. When it is determined that the number of bad blocks meets the preset number threshold, each logical code module in the logical code module string is directly verified. When it is determined that the number of bad blocks does not meet the preset number threshold, a target number of good blocks are randomly selected from the logical code module string, and these good blocks are marked as bad blocks and added to the bad block table, or the Spare Area of the first page of this block is written as non-0xFF. The above marking method is only for illustration and cannot be used as a limitation. The marking methods of different platforms may be different.

[0038] It should be noted that the number of bad blocks is set to 4 because 4 is relatively safe and does not occupy many blocks. However, for a Nand Flash of a common specification, it may have a total of 512, 1024, or 2048 blocks. Taking 1024 blocks as an example, the number of bad blocks is equivalent to taking several from 1024 blocks, and there can be other more complex and safe combinations. Therefore, the number of bad blocks can be set to other preset number thresholds.

[0039] S13. When it is detected that the verification code of any one logical code module in the logical code module string is not the initial verification code, the logical code module string is cyclically verified according to the number of boot-ups and the verification order.

[0040] In some embodiments, when the terminal device is powered on for the first time, any one logical code module in the logical code module string should be the initial verification code, that is, 0xFFFFFFF, and the corresponding number of boot-ups should also be the initial number of boot-ups, that is, 0xFFFFFFF. For further verification, the terminal device can traverse each logical code module in the logical code module string and obtain the corresponding verification code for comparison with the initial verification code. As long as there is any logical code module whose verification code is not the initial verification code, the terminal device is allowed to perform cyclic verification on the logical code module string.

[0041] In an alternative embodiment, the cyclically verifying the logical code module string according to the number of boot-ups and the verification order includes: Obtain the first number of boot-ups corresponding to the first module and the Nth number of boot-ups of the Nth module in the logical code module string, where N is an integer greater than 1; When it is determined that the Nth number of boot-ups is 1 less than the first number of boot-ups, verify the verification code of the first module according to the first verification code of the first module to obtain a first verification result; When it is determined that the first verification result is verification passed, determine whether the second boot count of the second module is the same as the first boot count, where the second module is the logic code module adjacent to the first module in the logic code module string and is sorted after the first module; When it is determined that the second boot count is the same as the first boot count, calculate the second verification code corresponding to the second module according to the first verification code, and perform verification code verification on the second module according to the second verification code to obtain a second verification result; When it is determined that the second verification result is verification passed, repeat the above operations according to the verification order until each logic code module in the logic code module string has been verified, or the verification result of any one logic code module in the logic code module string is verification failed.

[0042] In some embodiments, when it is determined that the terminal device is not powered on for the first time, the number of logic code modules in the logic code module string is determined. Suppose there are N logic code modules. According to the module order in the logic code module string, the first logic code module, that is, the first logic code module, is called the first module, and the logic code modules sorted after the first module are called the second module, the third module, …, the Nth module respectively. To protect the bad block information from being maliciously tampered with, the first module in the logic code module string is first verified. The first module obtains its corresponding number of power - on times (referred to as the first power - on times) and verification code (referred to as the first verification code), and obtains the second power - on times and the second verification code corresponding to the second module, and obtains the third power - on times and the third verification code corresponding to the third module, …, the (N - 1)th power - on times and the (N - 1)th verification code corresponding to the (N - 1)th module, and the Nth power - on times and the Nth verification code corresponding to the Nth module. Among them, the first verification code is calculated based on the Nth verification code corresponding to the Nth module, the second verification code is calculated based on the first verification code, the third verification code is calculated based on the second verification code, and so on. The Nth verification code is calculated based on the (N - 1)th verification code. Regarding whether each logic code module in the logic code module string operates according to a predetermined logic during normal operation, for one power - on, the number of power - on times of the logic code modules that have run on a logic code module string should be exactly the same. When verifying the first module, the first power - on times and the Nth power - on times are compared. Under normal operating conditions, the first power - on times should be 1 greater than the Nth power - on times. When it is determined that the first power - on times should be 1 greater than the Nth power - on times, the first verification code of the first module is further verified, and it is determined whether the obtained verification code (that is, a self - considered verification code calculated by the first module itself) is consistent with the first verification code calculated by the second module based on the Nth verification code. If they are consistent, it means that the first verification result is verification passed and the first module has not been tampered with. Then, the second module is verified. The first power - on module and the second power - on module are compared. Under normal operating conditions, the second power - on times should be the same as the first power - on times. When it is determined that the second power - on times are the same as the first power - on times, the second verification code of the second module is further verified, and it is determined whether the obtained verification code (which is also a self - considered verification code calculated by the second module itself) is consistent with the second verification code calculated by the third module based on the first verification code. If they are consistent, it means that the second verification result is verification passed and the second module has not been tampered with.By analogy, the third module, the fourth module, …, the Nth module are verified. When it is determined that the verification result of each module is verification passed, it means that each logic code module in the logic code module string has not been tampered with. However, if the verification result of any one logic code module is verification failed, it means that the corresponding logic code module has been tampered with, and the boot operation is stopped. In addition, when the first boot count is not 1 greater than the Nth boot count, it means that the first module has been tampered with, and the boot is stopped; or when the verification of the first verification code fails, it also means that the first module has been tampered with, and the boot is stopped. Or when the second boot count is inconsistent with the first boot count, it means that the second module has been tampered with, and the boot is stopped. By analogy, as long as the boot count verification of any one module fails, or the verification code verification of any one module fails, the boot operation corresponding to the boot instruction is stopped.

[0043] It should be noted that because it is a cyclic verification, the first module of the logic code module string needs to verify the last module. At the beginning of the terminal device, that is, when the terminal device is powered on for the first time, the verification data needs a reasonable initial value. Without any processing, the verification values of each logic code module are initially the initial verification value 0xFFFFFFFF, and the verification will directly fail.

[0044] To facilitate the understanding of the inventive concept of the present application, the following provides a specific example to elaborate on the verification code verification of each logic code module in the logic code module string. Suppose there is a logic code module string, and the arrangement order of the logic code module string is A→B→C→D→E, that is, the verification order is A→B→C→D→E. First, module A starts to verify module E. Module A obtains the verification code of module D, calculates a supposed verification code of module E based on the verification code of module D, and then compares the calculated verification code of module E with the verification code of the stored module E (calculated by module E itself according to the same verification code calculation method). If the verification code of module E calculated by A is the same as the verification code calculated by E itself, it means that module E passes the verification. When it is necessary to verify module A, module B reads the verification code of module E, calculates a supposed verification code of module A based on the verification code of module E, and compares the calculated verification code of module A with the verification of the stored module A. If the verification code calculated by module B is the same as the verification code calculated by module A itself, it means that the algorithms of A and B are the same, and module A passes the verification. By analogy, the logic code module string is verified all the time to prevent any module from being tampered with.

[0045] Through the above optional implementation manners, when powering on the device for the first time, the cyclic verification process is triggered by using the initial verification code and the power-on times. When not powering on for the first time, each module is verified in sequence according to the power-on times and the verification order. Through the correlation of the power-on times and the recursive verification of the verification code, it can accurately identify whether the module has been tampered with. Once it is found that the verification of any module fails, the power-on operation is immediately stopped to prevent potential risks. At the same time, by checking between the logic code modules, protection from the mirror level to the program level is provided. If a certain mirror or program is secretly replaced, it can be easily detected. This not only enhances the security of the device, but also can accurately locate the problem module, facilitating subsequent maintenance and repair, and ensuring that the device runs in a safe and reliable state.

[0046] S14. When it is determined that the verification result of each logic code module in the logic code module string is verification passed, execute the power-on operation corresponding to the power-on instruction.

[0047] S15. When it is determined that there is any logic code module in the logic code module string whose verification result is verification failed, stop executing the power-on operation corresponding to the power-on instruction.

[0048] After completing the verification of all logic code modules in the logic code module string, a comprehensive judgment will be made. If it is determined that the verification result of each logic code module in the logic code module string is verification passed, it indicates that all the key codes for power-on are in a normal and trustworthy state, and the system can execute subsequent operations safely and stably based on these codes. At this time, the terminal device officially enters the normal operation state, providing a usable operation environment for the user.

[0049] It should be noted that the terminal device performs the verification of the logic code module string while executing the power-on operation. During the power-on period, each logic code module will perform verification in sequence. When a logic code module performs verification, it verifies the previous logic code module. If the verification is passed, the program continues to run normally. If any logic code module fails the verification, the terminal device is reset.

[0050] Similarly, if during the verification process, it is found that the verification result of any one of the logic code modules in the logic code module string fails the verification, it indicates that the module has been tampered with, or there are serious problems such as code corruption, version mismatch, or incompatibility with the current system architecture. Anomaly in any one of the logic code modules may pose a potential threat to the stability and security of the entire system, such as causing the terminal device to crash, data loss, being subjected to security attacks, etc. To ensure the security and stability of the terminal device and avoid subsequent unforeseen failures or risks caused by problematic logic code modules, the system will immediately stop executing the boot operation originally corresponding to the power-on instruction. That is, the terminal device will not continue with subsequent steps such as hardware initialization and operating system loading, but will take corresponding measures, such as displaying an error prompt message, recording an error log for subsequent troubleshooting, or entering the safe mode waiting for the user to further process.

[0051] In an optional implementation manner, the method further includes: When it is detected that the checksum of each logic code module in the logic code module string is the initial checksum, and the boot count of each logic code module in the logic code module string is the initial boot count, control the first startup module in the logic code module string to enter the Fastboot mode; Obtain the bad block information of each logic code module in the logic code module string and the CPU identifier in the Fastboot mode; Generate a combined Key based on the bad block information and the CPU identifier; Return the combined Key to the external production tool, so that the external production tool calculates the first target checksum of each logic code module in the logic code module string based on the combined Key and returns a checksum sequence; When receiving the checksum sequence, recalculate the second target checksum of each logic code module in the logic code module string according to the combined Key; Compare the first target checksum and the second target checksum; When it is determined that the first target checksum and the second target checksum of each logic code module in the logic code module string match, store the checksum sequence.

[0052] In some embodiments, when a boot instruction of the terminal device is detected, it is necessary to verify each logic code module in the logic code module string. When it is determined that the checksum of each logic code module in the logic code module string is the initial checksum, it is also necessary to detect whether the boot count of each logic code module in the logic code module string is the initial boot count. When it is determined that the boot counts are also the initial boot counts, it can be determined that the terminal device is booting for the first time, and the terminal device will control the first startup module in the logic code module string to enter the Fastboot mode. Among them, the Fastboot mode is a low-level boot mode, usually used for device debugging, firmware flashing, or system recovery operations. In the Fastboot mode, the terminal device needs to obtain the bad block information of each logic code module in the logic code module string. Bad block information usually refers to the unavailable or damaged blocks in the storage medium, and this information is crucial for ensuring data integrity and reliability. At the same time, the terminal device also needs to obtain the identifier of the CPU. The CPU identifier is used to uniquely identify the device's processor and is usually used to verify the legitimacy and uniqueness of the device. Then, a combined Key is generated based on the obtained bad block information and CPU identifier. This combined Key is a unique identifier that combines the device's hardware characteristics and storage status information and is used for subsequent checksum calculation and verification. Then, the generated combined Key is sent to an external production tool. Based on the received combined Key, the external production tool calculates the first target checksum of each logic code module in the logic code module string and returns these checksums in sequence to form a checksum sequence to the terminal device. Among them, the external production tool is usually a secure server or a dedicated device used to perform complex calculation and verification operations. After receiving the checksum sequence, the terminal device recalculates the second target checksum of each logic code module in the logic code module string using the same combined Key and compares the first target checksum with the second target checksum to ensure that they match exactly. If the first target checksum and the second target checksum of each logic code module in the logic code module string match, the terminal device stores the checksum sequence to ensure that these checksums are used for further verification during subsequent startup processes, guaranteeing the integrity and security of the terminal device.

[0053] Through the above optional implementation manners, it is possible to ensure the integrity and legality of the logic code module when the device is started for the first time or under specific conditions, prevent unauthorized code modification or tampering, and thus enhance the security and reliability of the terminal device.

[0054] In an alternative embodiment, by adding a specific error handling mechanism to the code, when the checksum does not match, the control terminal device is controlled to enter the Fastboot mode. In the Fastboot mode, a read interface is added to return the combined Key required to generate the checksum. Specifically, in the command processing function of Fastboot, a new command (such as fastboot oem get_key) is added. When this command is received, the system will calculate and return the combined Key. And in the command processing function of Fastboot, a new command (such as fastboot oem verify_checksum) is added. This command receives the checksum input by the user and compares it with the checksum calculated by the terminal device using the same algorithm. In the Fastboot mode, the terminal device needs to be able to regenerate the checksum for each logical code module, obtain the combined Key through the read interface, calculate the checksum according to the same checksum calculation formula in the above embodiment, send the calculated checksum to the device through the input interface. The terminal device also calculates the checksum according to the same checksum calculation method and Key in the above embodiment and compares it with the checksum input through the input interface. If the checksums match, the device will regenerate the checksum and store it on the Flash. If the checksums do not match, the device can remain in the Fastboot mode, waiting for further instructions or retrying. After the verification passes, the system stores the generated checksum in a specific location in the Flash memory for using these checksums for verification during subsequent startup processes.

[0055] Through the above alternative embodiment, the terminal device can provide a secure authentication interface in the Fastboot mode, ensuring the security and reliability of the checksum generation and verification processes, thereby enhancing the security and reliability of the system.

[0056] In an alternative embodiment, the method further includes: When it is determined that the bad block type of the first target bad block is the first bad block type, a first erase operation is performed on the first target bad block, where the first target bad block is any bad block in the logical code module string; When it is determined that the erase result is a successful erase, a second erase operation is performed on the first target bad block until a preset number of erase times is satisfied, or there is any erase result that is a failed erase; When it is determined that the bad block type of the first target bad block is the second bad block type, the spare area of the first page of the first target bad block is obtained; Check whether the data in the spare area of the first page is 0xFF; When it is determined that the data in the spare area of the first page is not 0xFF, it is determined that the detection result of the first target bad block passes the detection; When it is determined that the data in the spare area of the first page is 0xFF, it is determined that the detection result of the first target bad block fails the detection, and the power-on instruction is terminated.

[0057] In some embodiments, each time the terminal device is powered on, the first module in the logical code module string needs to check the bad blocks in the logical code module string. Specifically, the bad block information of each bad block in the logical code module string is obtained, the bad block type of the bad block is determined according to the bad block information, and different detections are performed on the bad blocks based on the bad block type. First, the first bad block (referred to as the first target bad block) is detected, that is, first, the bad block type of the first target bad block is obtained, and it is determined whether the bad block type of the first target bad block belongs to the first bad block type (that is, bad block type 1) or the second bad block type (that is, bad block type 0).

[0058] When it is determined that the bad block type of the first target bad block belongs to bad block type 1, a rewrite operation is performed on the first target bad block. If the rewrite fails, pass; if the rewrite is successful, retry. After retrying several times, if all are successful, then determine FAIL and terminate the boot. Specifically, first define the maximum number of attempts for the erase operation, that is, the preset rewrite times (for example, 3 times). Then perform the first rewrite operation on the first target bad block and obtain the rewrite result of the first rewrite operation. When the rewrite result of the first rewrite operation is successful, continue to perform the second rewrite operation on the first target bad block and obtain the rewrite result of the second rewrite operation. When the rewrite result of the second rewrite operation is successful, continue to perform the third rewrite operation on the first target bad block, and so on, until the rewrite operation of the preset rewrite times is completed for the first target rewrite or there is any rewrite result that is a rewrite failure, and when the rewrite results of the preset rewrite times are all successful, then obtain the bad block type of the second bad block (referred to as the second target bad block). When the bad block type of the second target bad block is bad block type 1, perform the first rewrite operation on the second target bad block. Similarly, according to the same embodiment method above, until the rewrite operation of the preset rewrite times is completed for the second target rewrite or there is any rewrite result that is a rewrite failure, and then perform the rewrite operation on the third bad block, the fourth bad block, etc. When it is determined that the rewrite is completed for each bad block and the rewrite results are all successful, then terminate the boot operation corresponding to the boot instruction. When the bad block type of the first target bad block belongs to bad block type 0, read the Spare Area of the first page and check whether the data in the Spare Area of the first page is 0xFF. If it is not 0xFF, then PASS. Then obtain the bad block type of the second target bad block and perform detection on the second target bad block. If it is 0xFF, then FAIL, and terminate the boot operation corresponding to the boot instruction. When the bad block type of the second target bad block belongs to bad block type 0, perform detection according to the same embodiment method as the first target bad block above, and so on, perform detection on the third bad block, the fourth bad block...

[0059] In some embodiments, since Nand Flash bad blocks do not automatically become good, that is, bad blocks of bad block type 1 will always be bad blocks, the terminal device can obtain in real time the bad blocks with bad block type 1 and determine whether the bad block type has changed. If it is checked that it has become a good block, it means that the Flash device has been replaced. At the same time, it can also record in real time the bad blocks of bad block type 0. If it is not in the bad block table or it is checked that the Spare Area of its first page has become all FF, it means that someone has maliciously rewritten the software.

[0060] Through the above optional implementation manners, for the first type of bad block, the bad block status is determined through multiple erase operations. If multiple erase operations are all successful, it is determined as abnormal and the power-on is terminated to prevent potential risks. For the second type of bad block, it is determined by checking whether the data in the first page spare area is 0xFF. If it is 0xFF, it is determined that the detection fails and the power-on is terminated. This detection method of classifying and taking multiple steps can accurately identify bad block problems, avoid system failures or data errors caused by bad blocks, ensure the stability and security of the terminal device during the power-on process, and lay a solid foundation for the normal operation of the device. At the same time, the Flash bad block information is changed into the identification information of the Nand Flash and participates in encryption, which has good confidentiality.

[0061] This application constructs a set of strict and efficient program protection mechanisms through the way of cyclic verification between modules. During the operation of the operating system, each module cooperates with each other to continuously and dynamically verify the programs involved in other modules. This cyclic verification mechanism can accurately detect any illegal program replacement actions. Whether it is the tampering behavior of the operating system core program or the key function module, it is difficult to escape the monitoring of this mechanism. Once an illegal replacement is detected, the system can quickly respond and take corresponding security measures in a timely manner, such as terminating the operation of the illegal program, triggering a security alarm, etc., so as to effectively prevent the illegal program from damaging the system and ensure the stability and security of the operating system. Due to the randomness of the number and distribution of Nand Flash bad blocks, and the combined use with hardware IDs such as CPU ID, it is difficult for attackers to obtain complete hardware feature information through conventional means, thereby increasing the difficulty and cost of the attack. At the same time, the cyclic verification mechanism between modules makes it difficult for attackers to bypass the verification of other modules even if they successfully tamper with some programs, thus greatly reducing the possibility of the system being successfully attacked. This multi-level and all-round security protection mechanism provides strong support for the stable operation of the operating system in a complex and changeable security environment, ensuring the security and integrity of device data.

[0062] To facilitate the understanding of the inventive concept of the present application, an example is given below to describe the practical application of the embodiments of the present application. Taking Qualcomm as an example, the logic code module string is sbl→lk→kernel→dialing process→…→http process for illustration. When the terminal device is powered on for the first time, the checksum of each logic code module in the logic code module string is the initial checksum 0xFFFFFFF, and the corresponding number of power-on times is generally 0xFFFFFF. The first module of the logic code module string, that is, sbl, first reads the power-on times corresponding to the checksum information of each other module. If it is 0xFFFFFFF, it directly passes, that is, passes the verification. Then, lk reads the power-on times corresponding to the checksum information of each other module. If it is 0xFFFFFFFF, it enters the fastboot mode, waits for the production tool to authenticate, and triggers the device to generate the initial authentication information. After obtaining the initial authentication information, the terminal device restarts or powers on again. Sbl checks the bad block information according to the same verification method as above (that is, each module in the logic code module string has a checksum, which takes the checksum of the previous module as input to calculate the current module's own checksum and fills it into the module checksum partition for storage, for the next module to read. At the same time, each module needs to calculate the checksum of the previous module according to the checksum of the module before the previous one to verify the previous module). If it passes, it passes; otherwise, it stops powering on. Then, Sbl reads the power-on times of the checksum information of the last module, that is, the http process, and compares it with itself. If the power-on times of the http process are 1 less than itself, it checks the "end" marker module according to the above verification method. If the check fails, it stops powering on; if the check passes, it updates the power-on times and its own checksum information to the flash. If the power-on times of the http process are not 1 less than itself, it stops powering on. Lk checks sbl according to the same verification method as above. If it passes, it updates its own power-on times and its own checksum, and continues to the next step; otherwise, it stops powering on. Further, kernel reads the power-on times in the checksum information of sbl and lk. If they are not equal, it stops powering on; if they are equal, it checks lk according to the same verification method as above. If it passes, it updates its own power-on times and checksum. Finally, the dialing process reads the power-on times of the checksum information of its previous modules (including sbl, lk, kernel). If they are equal, it checks kernel according to the same verification method as above. If it passes, it updates its own power-on times and checksum. And so on, until the verification of the last module in the logic code module string is completed.

[0063] Refer to Figure 2 As shown, it is the functional module diagram of the terminal software protection device shown in the embodiments of the present application.

[0064] In some embodiments, the terminal software protection device 20 may include a plurality of functional modules composed of computer program segments. The computer programs of each program segment of the terminal software protection device 20 may be stored in the memory of the terminal device and executed by at least one processor to perform (see Figure 1 description) the functions of terminal software protection. According to the functions it performs, it can be divided into a plurality of functional modules. The functional modules may include: an instruction detection module 201, a data acquisition module 202, a cyclic check module 203, a boot execution module 204, a boot stop module 205, and a bad block processing module 206. As used in this application, a module refers to a series of computer program segments that can be executed by at least one processor and can complete fixed functions, and are stored in the memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0065] The instruction detection module 201 is configured to, when detecting a boot instruction, determine whether the boot instruction belongs to the first boot instruction.

[0066] The data acquisition module 202 is configured to, when determining that the boot instruction does not belong to the first boot instruction, acquire the check code and the number of boot times corresponding to each logic code module in the logic code module string.

[0067] The cyclic check module 203 is configured to, when detecting that the check code of any one logic code module in the logic code module string is not the initial check code, perform a cyclic check on the logic code module string according to the number of boot times and the check order.

[0068] The boot execution module 204 is configured to, when determining that the check result of each logic code module in the logic code module string is passed, execute the boot operation corresponding to the boot instruction.

[0069] The boot stop module 205 is configured to, when determining that there is any logic code module in the logic code module string whose check result is not passed, stop executing the boot operation corresponding to the boot instruction.

[0070] The cyclic verification module 203 is further specifically configured to: obtain the first boot count corresponding to the first module and the Nth boot count of the Nth module in the logical code module string, where N is an integer greater than 1; when it is determined that the Nth boot count is 1 less than the first boot count, perform a checksum verification on the first module according to the first checksum of the first module to obtain a first verification result; when it is determined that the first verification result is a pass, determine whether the second boot count of the second module is the same as the first boot count, where the second module is the logical code module adjacent to the first module in the logical code module string and is sorted after the first module; when it is determined that the second boot count is the same as the first boot count, calculate the second checksum corresponding to the second module according to the first checksum, and perform a checksum verification on the second module according to the second checksum to obtain a second verification result; when it is determined that the second verification result is a pass, repeat the above operations according to the verification order until each logical code module in the logical code module string is verified, or the verification result of any logical code module in the logical code module string is a fail.

[0071] The cyclic verification module 203 is further configured to: when it is detected that the checksum of each logical code module in the logical code module string is the initial checksum and the boot count of each logical code module in the logical code module string is the initial boot count, control the first startup module in the logical code module string to enter the Fastboot mode; obtain the bad block information and the CPU identifier of each logical code module in the Fastboot mode; generate a combined Key according to the bad block information and the CPU identifier; return the combined Key to an external production tool, so that the external production tool calculates the first target checksum of each logical code module in the logical code module string based on the combined Key and returns a checksum sequence; when receiving the checksum sequence, recalculate the second target checksum of each logical code module in the logical code module string according to the combined Key; compare the first target checksum and the second target checksum; when it is determined that the first target checksum and the second target checksum of each logical code module in the logical code module string match, store the checksum sequence.

[0072] The cyclic verification module 203 is further configured to: obtain the CPU identifier, and determine the target bad block number and the target bad block type of the current module according to the bad block information; generate a target combined Key from the CPU identifier, the target bad block number, and the target bad block type; calculate the current module checksum of the current module according to the previous module checksum and the target combined Key.

[0073] The bad block processing module 206 is configured to: determine the number of bad blocks in the logical code module string according to the bad block information; when it is determined that the number of bad blocks does not meet a preset number threshold, randomly select a target number of good blocks from the logical code module string, and mark the good blocks as bad blocks, where the target number is determined according to the number of bad blocks and the preset number threshold.

[0074] The bad block processing module 206 is further configured to: when it is determined that the bad block type of the first target bad block is the first bad block type, perform a first erasing operation on the first target bad block, where the first target bad block is any bad block in the logical code module string; when it is determined that the erasing result is successful, perform a second erasing operation on the first target bad block until a preset number of erasing times is satisfied, or there is any erasing result that is a failure; when it is determined that the bad block type of the first target bad block is the second bad block type, obtain the spare area of the first page of the first target bad block; check whether the data in the spare area of the first page is 0xFF; when it is determined that the data in the spare area of the first page is not 0xFF, determine that the detection result of the first target bad block is a pass; when it is determined that the data in the spare area of the first page is 0xFF, determine that the detection result of the first target bad block is a failure, and terminate the power-on instruction.

[0075] The bad block processing module 206 is further configured to: when it is determined that the erasing results corresponding to the preset number of erasing times of the first target bad block are all successful, obtain the bad block type of the second target bad block; perform an erasing operation on the second target bad block according to the bad block type of the second target bad block.

[0076] It should be understood that the various change modes and specific embodiments in the terminal software protection method provided in the foregoing embodiments are equally applicable to the terminal software protection device in this embodiment. Through the foregoing detailed description of the terminal software protection method, those skilled in the art can clearly know the implementation method of the terminal software protection device in this embodiment. For the sake of simplicity of the specification, it will not be elaborated herein.

[0077] Refer to Figure 3 As shown in the structure schematic diagram of the terminal device shown in the embodiment of the present application. In a preferred embodiment of the present application, the terminal device 3 includes a memory 31, at least one processor 32, and at least one communication bus 33.

[0078] Those skilled in the art should understand, Figure 3The structure of the terminal device shown does not constitute a limitation on the embodiments of the present application. It can be a bus structure or a star structure. The terminal device 3 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0079] In some embodiments, the terminal device 3 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes but is not limited to microprocessors, application-specific integrated circuits, programmable gate arrays, digital signal processors, and embedded devices, etc. The terminal device 3 may also include user equipment, which includes but is not limited to any electronic product that can interact with the user through means such as a keyboard, mouse, remote control, touchpad, or voice control device. For example, personal computers, tablet computers, smart phones, digital cameras, etc.

[0080] In the above embodiments provided by the present application, it should be understood that the disclosed methods, devices, computer-readable storage media, and terminal devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple components or modules can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or components or modules can be in electrical, mechanical, or other forms.

[0081] The components described as separate components may or may not be physically separated. The components shown as components may or may not be physical modules, that is, they can be located in one place or distributed to multiple network modules. Some or all of the components can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0082] In addition, in each embodiment of the present invention, the functional modules can be integrated in a processing module, or each component can exist physically alone, or two or more modules can be integrated in one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules.

[0083] When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs.

[0084] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0085] In the above embodiments, the descriptions of each embodiment have their own focuses. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0086] The above is a specific description of the preferred embodiments of the present invention. However, the present invention is not limited to the described embodiments. Those skilled in the art can also make various equivalent deformations or substitutions without departing from the spirit of the present invention. These equivalent deformations or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for protecting terminal software, characterized in that, The method includes: When a power-on instruction is detected, determine whether the power-on instruction belongs to the first power-on instruction; When it is determined that the power-on instruction does not belong to the first power-on instruction, obtain the check code and the number of power-on times corresponding to each logic code module in the logic code module string; When it is detected that the check code of any one logic code module in the logic code module string is not the initial check code, perform cyclic verification on the logic code module string according to the number of power-on times and the verification order; When it is determined that the verification result of each logic code module in the logic code module string is verification passed, execute the power-on operation corresponding to the power-on instruction; When it is determined that there is any one logic code module in the logic code module string whose verification result is verification failed, stop executing the power-on operation corresponding to the power-on instruction.

2. The terminal software protection method according to claim 1, wherein The performing cyclic verification on the logic code module string according to the number of power-on times and the verification order includes: Obtain the first power-on time corresponding to the first module, and the Nth power-on time of the Nth module in the logic code module string, where N is an integer greater than 1; When it is determined that the Nth power-on time is 1 less than the first power-on time, perform check code verification on the first module according to the first check code of the first module to obtain a first verification result; When it is determined that the first verification result is verification passed, determine whether the second power-on time of the second module is the same as the first power-on time, where the second module is the logic code module adjacent to the first module in the logic code module string and is sorted behind the first module; When it is determined that the second power-on time is the same as the first power-on time, calculate the second check code corresponding to the second module according to the first check code, and perform check code verification on the second module according to the second check code to obtain a second verification result; When it is determined that the second verification result is verification passed, repeat the above operations according to the verification order until each logic code module in the logic code module string is verified, or there is any one logic code module in the logic code module string whose verification result is verification failed.

3. The terminal software protection method according to claim 1, characterized in that The method further includes: When it is detected that the check code of each logic code module in the logic code module string is the initial check code, and the number of power-on times of each logic code module in the logic code module string is the initial power-on time, control the first startup module in the logic code module string to enter the Fastboot mode; Obtain the bad block information of each logic code module in the logic code module string and the CPU identifier in the Fastboot mode; Generate a combined Key according to the bad block information and the CPU identifier; Return the combined Key to an external production tool, so that the external production tool calculates the first target check code of each logic code module in the logic code module string based on the combined Key and returns a check code sequence; When receiving the check code sequence, recalculate the second target check code of each logic code module in the logic code module string according to the combined Key; Compare the first target check code and the second target check code; When it is determined that the first target check code of each logic code module in the logic code module string matches the second target check code, store the check code sequence.

4. The terminal software protection method according to claim 3, wherein The method further includes: Obtain the CPU identifier, and determine the target bad block number and target bad block type of the current module according to the bad block information; Generate a target combination Key from the CPU identifier, the target bad block number, and the target bad block type; Calculate the current module check code of the current module according to the previous module check code and the target combination Key.

5. The terminal software protection method according to claim 3, characterized in that, The method further includes: Determine the number of bad blocks in the logic code module string according to the bad block information; When it is determined that the number of bad blocks does not meet the preset number threshold, randomly select a target number of good blocks from the logic code module string and mark the good blocks as bad blocks, where the target number is determined according to the number of bad blocks and the preset number threshold.

6. The terminal software protection method according to claim 1, characterized in that The method further includes: When it is determined that the bad block type of the first target bad block is the first bad block type, perform a first erasing operation on the first target bad block, where the first target bad block is any bad block in the logic code module string; When it is determined that the erasing result is successful, perform a second erasing operation on the first target bad block until the preset number of erasing times is met, or there is any erasing result that is a failure; When it is determined that the bad block type of the first target bad block is the second bad block type, obtain the spare area of the first page of the first target bad block; Check whether the data in the spare area of the first page is 0xFF; When it is determined that the data in the spare area of the first page is not 0xFF, determine that the detection result of the first target bad block is passed; When it is determined that the data in the spare area of the first page is 0xFF, determine that the detection result of the first target bad block is a failure, and terminate the boot instruction.

7. The terminal software protection method according to claim 6, wherein The method further includes: When it is determined that the erasing results corresponding to the preset number of erasing times of the first target bad block are all successful, obtain the bad block type of the second target bad block; Perform an erasing operation on the second target bad block according to the bad block type of the second target bad block.

8. A terminal software protection device, characterized in that, The device includes: An instruction detection module, configured to determine whether the boot instruction belongs to the first boot instruction when detecting the boot instruction; A data acquisition module, configured to obtain the check code and the boot count corresponding to each logic code module in the logic code module string when it is determined that the boot instruction does not belong to the first boot instruction; A cyclic verification module, configured to perform cyclic verification on the logic code module string according to the boot count and the verification order when it is detected that the check code of any logic code module in the logic code module string is not the initial check code; A boot execution module, configured to execute the boot operation corresponding to the boot instruction when it is determined that the verification result of each logic code module in the logic code module string is passed; The power-on stop module is used to stop the power-on operation corresponding to the power-on instruction when it is determined that the verification result of any one of the logic code modules in the logic code module string fails the verification.

9. A terminal device, characterized in that, It includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of the terminal software protection method described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the steps of the terminal software protection method described in any one of claims 1 to 7 are implemented.

Images