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

Abstract

The present application relates to the field of computer technology, and in particular to a terminal software protection method, device, terminal equipment and computer storage medium. When a power-on instruction is detected, it is first determined whether it is the first power-on. If it is not the first power-on, the check code and the number of power-ons of each module in the logic code module string are obtained. When it is detected that the check code of any module is not the initial check code, the module string is cyclically checked according to the number of power-ons and the check sequence. The power-on operation is performed only when all module checks are passed. If any module fails to pass the check, the power-on is stopped. The present application effectively prevents the terminal software from being tampered with through a cyclic check mechanism, ensures that the device operates in a safe and reliable software state, enhances the security and reliability of the terminal device, and avoids the risks of data leakage, equipment failure, etc. caused by software problems.

Description

Technical Field

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

[0002] In today's digital age, terminal devices such as portable Wi-Fi are widely used in people's daily lives and work. However, with the continuous advancement of technology and the increasing sophistication of hacker attack methods, hackers are not only able to crack terminal software but may also expand their attack range by disseminating cracking methods, posing a serious threat to the secure operation of terminal devices. Specifically, among the various chips used in certain terminal devices, such as portable Wi-Fi, only the CPU can provide a unique machine ID, which is used to strictly bind to the hardware. In contrast, Wi-Fi chips, flash chips, and charging chips do not have such unique identifiers. Therefore, when hackers attempt to crack terminal software, they often use the CPU ID as an attack point, exploiting the binding relationship between this unique identifier and the hardware to carry out targeted cracking activities.

[0003] Traditional terminal software protection methods primarily focus on protecting the image file burning process to ensure proper software installation and operation on terminal devices. However, hackers can exploit software vulnerabilities to gain access to the operating system's shell, bypassing these protections and directly replacing operating system programs. This not only compromises the integrity of the terminal software but can also lead to serious consequences such as user data leakage and device failure. Summary of the Invention

[0004] In order to overcome the shortcomings of the existing technology, the present invention provides a terminal software protection method, device, terminal equipment and computer storage medium. By using a cyclic verification mechanism and a dynamic boot number, the reliability of the terminal equipment is improved and the normal operation of the equipment during the boot process is ensured.

[0005] A first aspect of the present application provides a terminal software protection method, the method comprising:

[0006] When a power-on instruction is detected, determining whether the power-on instruction is a first power-on instruction;

[0007] When it is determined that the power-on instruction is not the first power-on instruction, obtaining a check code and a power-on count corresponding to each logic code module in the logic code module string;

[0008] When it is detected that the check code of any one of the logic code modules in the logic code module string is not the initial check code, performing a cyclic check on the logic code module string according to the number of power-on times and the check sequence;

[0009] When it is determined that the verification results of each logic code module in the logic code module string are all verified to pass, executing the power-on operation corresponding to the power-on instruction;

[0010] When it is determined that the verification result of any one logic code module in the logic code module string is verification failure, the boot operation corresponding to the boot instruction is stopped.

[0011] In an optional embodiment, the cyclically checking the logic code module string according to the number of power-on times and the check sequence includes:

[0012] Obtaining a first power-on count corresponding to a first module and an Nth power-on count of an Nth module in the logic code module string, where N is an integer greater than 1;

[0013] When it is determined that the Nth number of power-on times is less than the first number of power-on times by 1, performing a verification code verification on the first module according to the first verification code of the first module to obtain a first verification result;

[0014] When it is determined that the first verification result is verification passed, determining whether a second startup count of a second module is consistent with the first startup count, wherein the second module is a logic code module whose logic code module string is adjacent to the first module and is sequenced after the first module;

[0015] When it is determined that the second number of power-on times is consistent with the first number of power-on times, calculating a second verification code corresponding to the second module according to the first verification code, and performing a verification code verification on the second module according to the second verification code to obtain a second verification result;

[0016] When it is determined that the second verification result is verification passed, the above operations are repeatedly performed according to the verification order until each logic code module in the logic code module string is verified, or the verification result of any logic code module in the logic code module string is verification failed.

[0017] In an optional embodiment, the method further comprises:

[0018] When it is detected that the check code of each logic code module in the logic code module string is an initial check code and the number of startup times of each logic code module in the logic code module string is an initial number of startup times, controlling the first startup module in the logic code module string to enter Fastboot mode;

[0019] Obtaining bad block information and a CPU identifier of each logic code module in the logic code module string in the Fastboot mode;

[0020] Generate a combined key according to the bad block information and the CPU identifier;

[0021] Returning the combined key to the external production tool, so that the external production tool calculates a 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;

[0022] When the check code sequence is received, recalculating the second target check code of each logic code module in the logic code module string according to the combination key;

[0023] comparing the first target check code and the second target check code;

[0024] When it is determined that the first target check code and the second target check code of each logic code module in the logic code module string match, the check code sequence is stored.

[0025] In an optional embodiment, the method further comprises:

[0026] Obtaining a CPU identifier, and determining a target bad block sequence number and a target bad block type of the current module according to the bad block information;

[0027] Generate a target combination Key using the CPU identifier, the target bad block sequence number, and the target bad block type;

[0028] The current module check code of the current module is calculated according to the previous module check code and the target combination Key.

[0029] In an optional embodiment, the method further comprises:

[0030] determining the number of bad blocks of the logic code module string according to the bad block information;

[0031] When it is determined that the number of bad blocks does not meet a preset number threshold, a target number of good blocks are randomly selected from the logic code module string and marked as bad blocks, where the target number is determined according to the number of bad blocks and the preset number threshold.

[0032] In an optional embodiment, the method further comprises:

[0033] When it is determined that the bad block type of the first target bad block is the first bad block type, performing a first erase / write operation on the first target bad block, the first target bad block being any bad block in the logical code module string;

[0034] When it is determined that the erasing result is a success, performing a second erasing operation on the first target bad block until a preset erasing number of times is met, or any erasing result is an erasing failure;

[0035] When it is determined that the bad block type of the first target bad block is the second bad block type, obtaining a spare area of ​​a first page of the first target bad block;

[0036] Check whether the data in the spare area of ​​the first page is 0xFF;

[0037] When it is determined that the data of the spare area of ​​the first page is not 0xFF, determining that the detection result of the first target bad block is a pass;

[0038] When it is determined that the data in the spare area of ​​the first page is 0xFF, the detection result of the first target bad block is determined to be a detection failure, and the boot instruction is terminated.

[0039] In an optional embodiment, the method further comprises:

[0040] When it is determined that the erasure results corresponding to the preset erasure times of the first target bad block are all successful, obtaining the bad block type of the second target bad block;

[0041] An erase / write operation is performed on the second target bad block according to the bad block type of the second target bad block.

[0042] A second aspect of the present application provides a terminal software protection method and apparatus, the apparatus comprising:

[0043] The command detection module is used to determine whether the power-on command is a first power-on command when a power-on command is detected;

[0044] a data acquisition module, configured to acquire a check code and a number of startup times corresponding to each logic code module in the logic code module string when it is determined that the startup instruction is not the first startup instruction;

[0045] a cyclic verification module, configured to perform cyclic verification on the logic code module string according to the number of power-on times and the verification sequence when detecting that the verification code of any logic code module in the logic code module string is not the initial verification code;

[0046] a power-on execution module, configured to execute a power-on operation corresponding to the power-on instruction when it is determined that the verification results of each logic code module in the logic code module string are all verified to be passed;

[0047] The power-on stop module is configured to stop executing the power-on operation corresponding to the power-on instruction when it is determined that the verification result of any logic code module in the logic code module string is failure to pass the verification.

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

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

[0050] In summary, the terminal software protection method, device, terminal equipment and computer storage medium provided by the present application, through the present application, when a power-on instruction is detected, first determine whether it is the first power-on. When it is not the first power-on, obtain the check code and the power-on count of each module in the logic code module string. 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, trigger the cyclic check mechanism, and perform a cyclic check on the logic code module string according to the power-on count and the preset check sequence. By verifying the correlation and correctness of the power-on count and the check code module by module, ensure that the module has not been tampered with. Only when all logic code modules pass the check, the power-on operation is performed. When any module fails the check, the power-on is stopped to prevent the device from running in an incomplete or tampered state. Through the cyclic check mechanism, the present application effectively prevents hackers from bypassing traditional protection measures by tampering with software modules, protects the integrity of terminal software, and can accurately identify and locate tampered logic code modules, providing convenience for subsequent maintenance and repair. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a flow chart of a terminal software protection method shown in an embodiment of the present application;

[0052] Figure 2 This is a functional module diagram of a terminal software protection device shown in an embodiment of the present application;

[0053] Figure 3 It is a structural diagram of a terminal device shown in an embodiment of the present application. DETAILED DESCRIPTION

[0054] The present invention will be further described below with reference to the accompanying drawings and examples.

[0055] The following will clearly and completely describe the concept, specific structure and technical effects of the present invention in combination with the embodiments and drawings, so as to fully understand the purpose, characteristics and effects of the present invention. Obviously, the described embodiments are only 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 work are within the scope of protection of the present invention. In addition, all the connection / connection relationships involved in the patent do not refer to the direct connection of components, but refer to the fact that a better connection structure can be formed by adding or reducing connection accessories according to the specific implementation situation. The various technical features in the invention can be combined interactively without conflicting with each other.

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

[0057] In some embodiments, at the initial stage of software development, a Nand Flash partition is added. Specifically, three dedicated partitions are created within the Nand Flash: a bad block information partition, a module checksum partition, and a boot count partition. The bad block information partition is used to record bad block information in 5-byte increments. This bad block information may include a bad block sequence number and bad block type. In the embodiments of the present application, bad blocks are defined into two categories: bad blocks that can fail reliably (referred to as bad block type 1) and bad blocks that cannot fail reliably (referred to as bad block type 0). Bad blocks represented by bad block type 0 can be true bad blocks or good blocks specifically marked as bad blocks for enhanced security in this application. Bad blocks are stored in a format where every five bytes correspond to one bad block. The first four bytes store the bad block sequence number, and the fifth byte identifies the bad block type. It should be noted that the above bad block storage method is only one example; other storage methods are also possible and are not specifically limited. The module verification partition is used to store the verification code for each logic code module in the verification logic code module string and the corresponding boot count. This logic code module string can be represented as an image, such as a Linux kernel image, a Qualcomm platform SBL image, an ASR OBM image, or a U-Boot image. It can also be represented as a Linux program, such as a post-boot dialer or a program responsible for UI processing. Modules are cyclically verified according to a string sequence. For example, during startup, the module string might be arranged as follows: SBL → LK → Boot → Dialer → HTTP server program. Each member of the module string has a verification code. The verification code of the previous module is used as input to calculate the corresponding verification code and store it in the module verification partition for access by the next module. Each module also needs to calculate the verification code of the previous module based on the verification code of the previous module to verify the previous module. The boot count partition is used to record the current boot count and the boot count corresponding to each module's verification information. During each boot, a value is retrieved from Flash, incremented by 1, and then written back. That is, the update logic of the power-on count is the power-on count of the current module = the power-on count of the previous module + 1, and the difference between the power-on counts of the last module and the first module is 1.

[0058] Reference Figure 1 1 is a flow chart of a terminal software protection method according to an embodiment of the present application, and the terminal software protection method includes the following steps.

[0059] S11, when a power-on instruction is detected, determining whether the power-on instruction is a first power-on instruction.

[0060] In some embodiments, when a terminal device receives a power-on command from a user, it first determines whether the received power-on command is a first-time power-on command, that is, whether the terminal device is being powered on for the first time. Before the first power-on, the terminal device can pre-set the check code corresponding to each logic code module in the logic code module string to be empty or a fixed value, such as 0xFFFFFFF, and also set the power-on count corresponding to each logic code module in the logic code module string 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 (e.g., 0xFFFFFFF) and the power-on count is the initial power-on count (e.g., 0xFFFFFFF), it can be determined that the terminal device is being powered on for the first time.

[0061] When it is determined that the terminal device is being powered on for the first time, the first module in the logic code module string reads the verification information and power-on count of other modules as 0xFFFFFFF, and the power-on instruction is determined to be a first-time power-on instruction. The first module refers to the logic code module that is ranked first in the logic code module string, and the other modules refer to the logic code modules in the logic code module string that process the remaining modules after the first module. When the power-on instruction is determined to be a first-time power-on instruction, the terminal device controls the first module to enter Fastboot mode, which is initialized by an external production tool by inputting the correct verification code through the Fastboot interface.

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

[0063] S12, when it is determined that the power-on instruction is not the first power-on instruction, obtaining a check code and a power-on count corresponding to each logic code module in the logic code module string.

[0064] When it is determined that the power-on instruction is not the first 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 checked according to the check code and power-on times.

[0065] In an optional embodiment, the method further comprises:

[0066] Obtaining a CPU identifier, and determining a target bad block sequence number and a target bad block type of the current module according to the bad block information;

[0067] Generate a target combination Key using the CPU identifier, the target bad block sequence number, and the target bad block type;

[0068] The current module check code of the current module is calculated according to the previous module check code and the target combination Key.

[0069] 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 is obtained by directly querying the bad block table to determine which logical code modules in the logical code module string are bad blocks.

[0070] In terminal devices such as Nand Flash, each block typically contains multiple pages. In addition to the data area, each page also has an additional area called a Spare Area (or OOB, Out-Of-Band). The Spare Area typically contains metadata such as ECC checksums and bad block markers. When it is determined that the terminal device does not have a bad block table, or when verifying the accuracy of the bad block table, the bad block markers in the Spare Area of ​​the first page of each logical code module in the logical code module string are traversed to determine the bad block. 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 bad block marker values ​​based on the specific device specifications), the block is considered a bad block.

[0071] The terminal device can perform continuous erase and write operations on each bad block module in the logic code module string in advance according to a preset number threshold (for example, 3 times). If the erase result of each erase and write operation is an erase failure, the module type of the logic code module is determined to be bad block type 1, otherwise it is marked as bad block type 0. Since the bad block information includes the bad block sequence number and the bad block type, in order to facilitate understanding and distinction, the module sequence number of the current module is referred to as the target bad block sequence number, and the module type of the current module is referred to as the target bad block type. In the current module, when it is necessary to perform a check code check on the current module, the terminal device can combine the bad block information and the CPU identifier (hereinafter referred to as CPU ID) as a combination key, and select any one of them to calculate the check code for the encryption algorithm, that is, generate the target combination key according to the target bad block sequence number, the target bad block type and the CPU ID. In the embodiment of the present application, in order to facilitate understanding of the inventive concept of the present application, the encryption algorithm is explained using HmacSHA1 as an example. The combined key refers to concatenating multiple information fields into a continuous binary data stream according to a preset format. This serves as the input key for the HmacSHA1 encryption algorithm, ensuring the uniqueness and tamper-proof nature of the generated checksum. The preset format includes the bad block number, bad block type, and CPU ID. The bad block number occupies 4 bytes, the bad block type occupies 1 byte, and the CPU ID length is adjusted based on the actual CPU ID. Specifically, the terminal device can concatenate the bad block number, bad block type, and CPU ID based on the data type to form the combined key. This can be done by converting the bad block number into 4-byte big-endian binary data (e.g., Python's to_bytes(4, 'big')) and the bad block type into 1-byte binary data (e.g., to_bytes(1, 'big')), and then directly concatenating them with the CPU ID. Alternatively, the terminal device can concatenate the bad block number, bad block type, and CPU ID fields sequentially to form a continuous binary data stream as the combined key, i.e., bad block 1 → bad block 2 → ... → CPU ID.

[0072] It should be noted that the number of bad blocks must meet a preset threshold. To facilitate understanding of the inventive concept of this application, the preset threshold in the embodiments of this application is described using 4 as an example. The combination key is specifically bad block 1 sequence number (4 bytes) + bad block 1 type (1 byte) + bad block 2 sequence number (4 bytes) + bad block 2 type (1 byte) + bad block 3 sequence number (4 bytes) + bad block 3 type (1 byte) + bad block 4 sequence number (4 bytes) + bad block 4 type (1 byte) + CPU ID.

[0073] Furthermore, the terminal device can obtain the checksum of the previous module (referred to as the previous module checksum) and calculate the checksum of the current module based on the previous module checksum and the target combination key, referred to as the current module checksum. The previous module is the logical code module immediately preceding the current module in the logical code module string. Specifically, the previous module checksum and the target combination key are input into HmacSHA1 to output the current module checksum corresponding to the current module. It should be noted that the length of the checksum is determined by the selected encryption algorithm. For example, the checksum generated by HmacSHA1 is 20 bytes long.

[0074] According to the same embodiment as the above verification code, the terminal device can calculate the verification code of the previous module. 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 the verification code is calculated for the first time, the verification value of all modules is a predefined initial value, such as 0xFFFFFFFF or a specific fixed value. Direct verification will result in failure because the verification code has not yet been generated.

[0075] This optional implementation leverages the random number of bad blocks inherent in Nand Flash and combines this with other hardware IDs, such as the CPU ID, to increase the complexity and uniqueness of the device's hardware signature information, significantly enhancing overall device security. Compared to traditional security methods that rely solely on a single hardware ID, this approach effectively protects against a wider range of security attacks, providing more reliable security for terminal devices and reducing the risk of unauthorized intrusion due to counterfeit or tampered hardware information.

[0076] In an optional embodiment, the method further comprises:

[0077] determining the number of bad blocks of the logic code module string according to the bad block information;

[0078] When it is determined that the number of bad blocks does not meet a preset number threshold, a target number of good blocks are randomly selected from the logic code module string and marked as bad blocks, where the target number is determined according to the number of bad blocks and the preset number threshold.

[0079] In some embodiments, the number of bad blocks needs to meet a preset threshold, such as 4. The terminal device can obtain the number of bad blocks in the logical code module string based on the bad block information. When it is determined that the number of bad blocks meets the preset 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 threshold, a target number of good blocks are randomly selected from the logical code module string and marked as bad blocks. These good blocks are added to the bad block table, or the Spare Area of ​​the first page of this block is written to non-0xFF. The above marking method is for illustration only and is not intended to be limiting. The marking method may vary on different platforms.

[0080] It should be noted that the bad block count is set to 4 because it is relatively secure and does not occupy a large number of blocks. However, Nand Flash memory with typical specifications may have a total of 512, 1024, or 2048 blocks. Taking 1024 blocks as an example, the bad block count is equivalent to taking a certain number of blocks from the 1024 blocks. This allows for more complex and secure combinations. Therefore, the bad block count can be set to other preset thresholds.

[0081] S13 , 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, performing a cyclic check on the logic code module string according to the number of power-on times and the check sequence.

[0082] In some embodiments, when the terminal device is powered on for the first time, any logic code module in the logic code module string should be an initial check code, i.e., 0xFFFFFFF, and the corresponding power-on counts should also be the initial power-on counts, i.e., 0xFFFFFFF. For further verification, the terminal device can traverse each logic code module in the logic code module string and obtain the corresponding check code and compare it with the initial check code. If the check code of any logic code module is not the initial check code, the terminal device is allowed to perform a cyclic check on the logic code module string.

[0083] In an optional embodiment, the cyclically checking the logic code module string according to the number of power-on times and the check sequence includes:

[0084] Obtaining a first power-on count corresponding to a first module and an Nth power-on count of an Nth module in the logic code module string, where N is an integer greater than 1;

[0085] When it is determined that the Nth number of power-on times is less than the first number of power-on times by 1, performing a verification code verification on the first module according to the first verification code of the first module to obtain a first verification result;

[0086] When it is determined that the first verification result is verification passed, determining whether a second startup count of a second module is consistent with the first startup count, wherein the second module is a logic code module whose logic code module string is adjacent to the first module and is sequenced after the first module;

[0087] When it is determined that the second number of power-on times is consistent with the first number of power-on times, calculating a second verification code corresponding to the second module according to the first verification code, and performing a verification code verification on the second module according to the second verification code to obtain a second verification result;

[0088] When it is determined that the second verification result is verification passed, the above operations are repeatedly performed according to the verification order until each logic code module in the logic code module string is verified, or the verification result of any logic code module in the logic code module string is verification failed.

[0089] In some embodiments, when it is determined that the terminal device is not being powered on for the first time, the number of logic code modules in the logic code module string is determined. Assuming there are N logic code modules, the first logic code module, i.e., the first logic code module, is referred to as the first module according to the module order in the logic code module string. The logic code modules following the first module are referred to as the second module, the third module, ..., the Nth module, respectively. To protect bad block information from malicious tampering, the first module in the logic code module string is first verified. The first module obtains its own corresponding boot count (called the first boot count) and verification code (called the first verification code), obtains the second boot count and second verification code corresponding to the second module, obtains the third boot count and third verification code corresponding to the third module, ..., obtains the N-1th boot count and N-1th verification code corresponding to the N-1th module, and obtains the Nth boot count and Nth verification code corresponding to the Nth module. 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-1th verification code. Regarding whether each logic code module in the logic code module string operates according to the predetermined logic during normal operation, for a single boot, the boot counts of the logic code modules in a logic code module string should be completely consistent. When verifying the first module, the first power-on count is compared with the Nth power-on count. Under normal operation, the first power-on count should be one greater than the Nth power-on count. If it is determined that the first power-on count is one greater than the Nth power-on count, the first module's first check code is checked to determine whether the obtained check code (i.e., a self-determined check code calculated by the first module) is consistent with the first check code calculated by the second module based on the Nth check code. If they are consistent, the first verification result is a passed verification, indicating that the first module has not been tampered with. Next, the second module is verified by comparing the first power-on module with the second power-on module. Under normal operation, the second power-on count should be consistent with the first power-on count. If it is determined that the second power-on count is consistent with the first power-on count, the second module's second check code is checked to determine whether the obtained check code (i.e., a self-determined check code calculated by the second module) is consistent with the second check code calculated by the third module based on the first check code. If they are consistent, the second verification result is a passed verification, indicating that 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 results of each module are all verified, 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 logic code module is verified to be failed, it means that the corresponding logic code module has been tampered with, and the power-on operation is stopped. In addition, when the first power-on number is not greater than the Nth power-on number by 1, it means that the first module has been tampered with, and the power-on operation is stopped; or if the first check code verification fails, it also means that the first module has been tampered with, and the power-on operation is stopped. Or if the second power-on number is inconsistent with the first power-on number, it means that the second module has been tampered with, and the power-on operation is stopped. By analogy, if the power-on number verification of any module fails, or the check code verification of any module fails, the power-on operation corresponding to the power-on instruction is stopped.

[0090] 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, and at the beginning of the terminal device, that is, when the terminal device is turned on for the first time, the verification data needs a reasonable initial value. Without any processing, the verification value of each logic code module is the initial verification value 0xFFFFFFFF at the beginning, which will fail the verification directly.

[0091] To facilitate understanding of the inventive concept of this application, a specific example is provided below to illustrate the verification of the check code for each logic code module in a logic code module string. Assume that 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 check code of module D, and calculates a self-considered check code of module E based on the check code of module D. Then, the calculated check code of module E is compared with the stored check code of module E (calculated by module E according to the same check code calculation method as above). If the check code of module E calculated by A is consistent with the check code calculated by module E, it means that module E has passed the verification. When module A needs to be verified, module B reads the verification code of module E and calculates a verification code of module A based on the verification code of module E. The calculated verification code of module A is compared with the stored verification code of module A. If the verification code calculated by module B is consistent with the verification code calculated by module A itself, it means that the algorithm of A is consistent with the algorithm of B, and the verification of module A passes. Similarly, the logical code module string is verified consistently to prevent any module from being tampered with.

[0092] Through the above optional implementation, when the device is turned on for the first time, the initial verification code and the number of times the device is turned on are used to trigger a cyclic verification process. When the device is not turned on for the first time, each module is verified in turn according to the number of times the device is turned on and the verification order. The correlation between the number of times the device is turned on and the recursive verification of the verification code can be used to accurately identify whether the module has been tampered with. Once it is found that any module fails the verification, the startup operation is stopped immediately to prevent potential risks. At the same time, by checking between logical code modules, protection from the image level to the program level is provided, and secretly changing an image or replacing a program can be easily discovered. It not only enhances the security of the device, but also accurately locates the problem module, facilitates subsequent maintenance and repair, and ensures that the device operates in a safe and reliable state.

[0093] S14 , when it is determined that the verification result of each logic code module in the logic code module string is verified to be passed, executing the power-on operation corresponding to the power-on instruction.

[0094] S15 , when it is determined that the verification result of any logic code module in the logic code module string is verification failure, stopping the execution of the power-on operation corresponding to the power-on instruction.

[0095] After verifying all logic modules in the logic module string, a comprehensive assessment is performed. If every logic module in the string passes verification, it indicates that all critical boot codes are normal and reliable, and the system can safely and stably execute subsequent operations based on these codes. At this point, the terminal device officially enters normal operation, providing a usable operating environment for the user.

[0096] It should be noted that the terminal device performs verification of the logic code module string while executing the boot operation. During the boot period, each logic code module will be verified in turn. When a logic code module is verified, it will verify the previous logic code module. If the verification passes, the program will continue to run normally. If any logic code module fails the verification, the terminal device will be reset.

[0097] Similarly, if during the verification process, it is found that the verification result of any logic code module in the logic code module string is verification failure, it means that the module has been tampered with, or there are serious problems such as code damage, version mismatch, or incompatibility with the current system architecture. Any abnormality in the logic code module may pose a potential threat to the stability and security of the entire system, such as causing the terminal device to crash, data loss, security attacks, etc. In order 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 power-on operation originally corresponding to the power-on instruction. In other words, 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 problem investigation, or entering safe mode to wait for further processing by the user.

[0098] In an optional embodiment, the method further comprises:

[0099] When it is detected that the check code of each logic code module in the logic code module string is an initial check code and the number of startup times of each logic code module in the logic code module string is an initial number of startup times, controlling the first startup module in the logic code module string to enter Fastboot mode;

[0100] Obtaining bad block information and a CPU identifier of each logic code module in the logic code module string in the Fastboot mode;

[0101] Generate a combined key according to the bad block information and the CPU identifier;

[0102] Returning the combined key to the external production tool, so that the external production tool calculates a 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;

[0103] When the check code sequence is received, recalculating the second target check code of each logic code module in the logic code module string according to the combination key;

[0104] comparing the first target check code and the second target check code;

[0105] When it is determined that the first target check code and the second target check code of each logic code module in the logic code module string match, the check code sequence is stored.

[0106] In some embodiments, when a terminal device power-on instruction is detected, each logic code module in the logic code module string needs to be verified. When it is determined that the verification code of each logic code module in the logic code module string is the initial verification code, it is also detected whether the power-on times of each logic code module in the logic code module string are the initial power-on times. When it is determined that the power-on times are also the initial power-on times, it can be determined that the terminal device is powered on for the first time, and the terminal device will control the first boot module in the logic code module string to enter Fastboot mode. Among them, Fastboot mode is a low-level boot mode, which is usually used for operations such as device debugging, firmware flashing or system recovery. In Fastboot mode, the terminal device needs to obtain bad block information for each logic code module in the logic code module string. Bad block information usually refers to unavailable or damaged blocks in the storage medium. This information is crucial to ensuring the integrity and reliability of the data. At the same time, the terminal device also needs to obtain the CPU identifier. The CPU identifier is used to uniquely identify the processor of the device and is usually used to verify the legitimacy and uniqueness of the device. A combined key is then generated based on the acquired 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. The generated combined key is then sent to an external production tool. Based on the received combined key, the external production tool calculates the first target checksum for each logic code module in the logic code module string. These checksums are then sequentially combined into a checksum sequence and returned to the terminal device. The external production tool is typically a secure server or dedicated device that performs complex calculations and verification operations. After receiving the checksum sequence, the terminal device uses the same combined key to recalculate the second target checksum for each logic code module in the logic code module string and compares the first and second target checksums to ensure they match. If the first and second target checksums for 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 boot processes, thereby ensuring the integrity and security of the terminal device.

[0107] Through the above optional implementation methods, the integrity and legitimacy of the logic code module can be ensured when the device is started for the first time or under specific conditions, and unauthorized code modification or tampering can be prevented, thereby enhancing the security and reliability of the terminal device.

[0108] In an optional embodiment, a specific error handling mechanism is added to the code to control the terminal device to enter Fastboot mode when the verification code does not match. In Fastboot mode, a read interface is added to return the combined key required to generate the verification code. Specifically, a new command (e.g., fastboot oem get_key) is added to the Fastboot command processing function. Upon receiving this command, the system calculates and returns the combined key. A new command (e.g., fastboot oem verify_checksum) is also added to the Fastboot command processing function. This command receives the verification code entered by the user and compares it with the verification code calculated by the terminal device using the same algorithm. In Fastboot mode, the terminal device needs to be able to regenerate the verification code for each logical code module. It obtains the combined key through the read interface, calculates the verification code according to the same verification code calculation formula as in the above embodiment, and sends the calculated verification code to the device through the input interface. The terminal device also calculates the verification code using the same verification code calculation method and key as in the above embodiment and compares it with the verification code entered through the input interface. If the verification codes match, the device regenerates the verification code and stores it in Flash. If the verification code does not match, the device can remain in Fastboot mode and wait for further instructions or retry. After the verification is passed, the system stores the generated verification code in a specific location of the Flash memory so that it can be used for verification during subsequent boot processes.

[0109] Through the above optional implementation methods, the terminal device can provide a secure authentication interface in Fastboot mode, ensuring that the generation and verification process of the verification code is safe and reliable, thereby enhancing the security and reliability of the system.

[0110] In an optional embodiment, the method further comprises:

[0111] When it is determined that the bad block type of the first target bad block is the first bad block type, performing a first erase / write operation on the first target bad block, the first target bad block being any bad block in the logical code module string;

[0112] When it is determined that the erasing result is a success, performing a second erasing operation on the first target bad block until a preset erasing number of times is met, or any erasing result is an erasing failure;

[0113] When it is determined that the bad block type of the first target bad block is the second bad block type, obtaining a spare area of ​​a first page of the first target bad block;

[0114] Check whether the data in the spare area of ​​the first page is 0xFF;

[0115] When it is determined that the data of the spare area of ​​the first page is not 0xFF, determining that the detection result of the first target bad block is a pass;

[0116] When it is determined that the data in the spare area of ​​the first page is 0xFF, the detection result of the first target bad block is determined to be a detection failure, and the boot instruction is terminated.

[0117] In some embodiments, each time a terminal device is powered on, the first module in the logic code module string needs to verify the bad blocks in the logic code module string. Specifically, bad block information is obtained for each bad block in the logic code module string, the bad block type is determined based on the bad block information, and different bad block tests are performed based on the bad block type. First, the first bad block (referred to as the first target bad block) is tested. Specifically, the bad block type of the first target bad block is first obtained, and it is determined whether the bad block type of the first target bad block is the first bad block type (i.e., bad block type 1) or the second bad block type (i.e., bad block type 0).

[0118] When it is determined that the bad block type of the first target bad block belongs to bad block type 1, an erase operation is performed on the first target bad block. If the erase fails, it is passed. If the erase succeeds, it is retried. After several retries, if all are successful, it is determined to be FAIL and the boot is terminated. Specifically, the maximum number of attempts for the erase operation is first defined, that is, the preset number of erases (for example, 3 times). Then, the first erase operation is performed on the first target bad block, and the erase result of the first erase operation is obtained. When the erase result of the first erase operation is a success, the second erase operation is continued on the first target bad block, and the erase result of the second erase operation is obtained. When the erase result of the second erase operation is a success, the third erase operation is continued on the first target bad block, and so on, until the preset erase execution is completed on the first target bad block. When the erase operation of the number of erase operations or any erase result is erase failure, and the erase results of the preset number of erase operations are all erase successes, the bad block type of the second bad block (called the second target bad block) is obtained. When the bad block type of the second target bad block is bad block type 1, the first erase operation is performed on the second target bad block, and the same embodiment is used as above, until the erase operation of the second target is completed for the preset number of erase operations or any erase result is erase failure, and then the third bad block, the fourth bad block and other bad blocks are erased. When it is determined that the erase is completed for each bad block and the erase results are all erase successes, the power-on operation corresponding to the power-on instruction is terminated. When the bad block type of the first target bad block is bad block type 0, the Spare Area of ​​the first page is read to check whether the data in the Spare Area of ​​the first page is 0xFF. If it is not 0xFF, then PASS, then the bad block type of the second target bad block is obtained, and the second target bad block is tested. If the value is 0xFF, then FAIL, and the boot operation corresponding to the boot instruction is terminated. When the bad block type of the second target bad block belongs to bad block type 0, detection is performed according to the same embodiment as the first target bad block, and so on, the third bad block, the fourth bad block, and so on are detected.

[0119] In some embodiments, since Nand Flash bad blocks do not automatically become good, that is, bad blocks with bad block type 1 will always be bad blocks, the terminal device can obtain bad blocks with bad block type 1 in real time and determine whether the bad block type has changed. If the bad block type changes to a good block, it indicates that the Flash device has been replaced. At the same time, bad blocks with bad block type 0 can also be recorded in real time. If it is not in the bad block table or the spare area of ​​its first page is found to be all FFs, it indicates that someone has maliciously erased the software.

[0120] With this optional implementation, for the first bad block type, multiple erase and write operations are performed to determine the bad block status. If all erase and write operations succeed, an abnormality is detected and the boot is terminated, preventing potential risks. For the second bad block type, the data in the first page's spare area is checked to see if it is 0xFF. If so, the detection is considered a failure and the boot is terminated. This type-based, multi-step detection method accurately identifies bad block issues, preventing system failures or data errors caused by bad blocks. This ensures the stability and security of the terminal device during the boot process, laying a solid foundation for normal operation. Furthermore, the Flash bad block information is converted into Nand Flash identification information and encrypted, providing excellent confidentiality.

[0121] This application establishes a rigorous and efficient program protection mechanism through a cyclical verification process between modules. During the operation of the operating system, each module collaborates to continuously and dynamically verify the programs involved in other modules. This cyclical verification mechanism accurately detects any illegal program replacements, making it difficult for tampering with either the operating system's core programs or key functional modules to escape detection. Once an illegal replacement is detected, the system can quickly respond and take appropriate security measures, such as terminating the illegal program and triggering a security alert. This effectively prevents illegal programs from causing damage to the system and ensures the stability and security of the operating system. The random number and distribution of Nand Flash bad blocks, combined with their use in conjunction with hardware IDs such as the CPU ID, makes it difficult for attackers to obtain complete hardware feature information through conventional means, thereby increasing the difficulty and cost of attacks. Furthermore, the cyclical verification mechanism between modules makes it difficult for attackers to bypass verification in other modules, even if they successfully tamper with a portion of the program, thereby significantly reducing the likelihood of a successful system attack. This multi-layered, comprehensive security protection mechanism provides strong support for the stable operation of the operating system in a complex and ever-changing security environment, ensuring the security and integrity of device data.

[0122] In order to facilitate understanding of the inventive concept of the present application, an example is given below to describe the practical application of the embodiment of the present application. Taking Qualcomm, if the logic code module string is sbl→lk→kernel→dial-up process→…→http process as an example, it will be explained. When the terminal device is turned on for the first time, the check code of each logic code module in the logic code module string is the initial check code 0xFFFFFFF, and the corresponding number of startups is generally 0xFFFFFF. The first module of the logic code module string, that is, sbl, first reads the number of startups corresponding to the check information of other modules. If it is 0xFFFFFFF, it directly passes, that is, passes the verification. Then, lk reads the number of startups corresponding to the check information of other modules. If it is 0xFFFFFFFF, it enters fastboot mode, waits for production tool authentication, and triggers the device to generate initial authentication information. After obtaining the initial authentication information, the terminal device restarts or restarts. Sbl checks for bad blocks using the same verification method described above (that is, each module in the logic code module string has a checksum. This is calculated using the checksum of the previous module as input, and then stored in the module checksum partition for the next module to read. Each module also verifies the previous module by calculating the checksum of the previous module based on the checksum of the previous module). If a checksum passes, it passes; otherwise, the boot process is aborted. Sbl then reads the boot count of the last module, the HTTP process, and compares it with its own. If the HTTP process's boot count is one less than its own, it checks the "end" marker module using the verification method described above. If the check fails, the boot process is aborted. If the check passes, the boot count and its own checksum are updated to flash memory. If the HTTP process's boot count is not one less than its own, the boot process is aborted. lk checks Sbl using the same verification method described above. If a checksum passes, it updates its own boot count and checksum and proceeds to the next step; otherwise, the boot process is aborted. Next, the kernel reads the boot counts from the sbl and lk verification information. If they are not equal, the kernel stops booting. If they are equal, the kernel checks the lk using the same verification method described above. If the verification succeeds, the kernel updates its own boot count and verification code. Finally, the dialing process reads the boot counts from the verification information of the previous modules (including sbl, lk, and kernel). If the verification succeeds, the kernel checks the kernel using the same verification method described above. If the verification succeeds, the kernel updates its own boot count and verification code. This process continues until the last module in the logic code string completes verification.

[0123] Reference Figure 2 , which is a functional module diagram of a terminal software protection device according to an embodiment of the present application.

[0124] In some embodiments, the terminal software protection device 20 may include multiple functional modules composed of computer program segments. The computer programs of the various program segments 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 The terminal software protection function (described in detail) can be divided into multiple functional modules based on the functions they perform. These functional modules may include: an instruction detection module 201, a data acquisition module 202, a cyclic verification module 203, a startup execution module 204, a startup stop module 205, and a bad block processing module 206. A module, as referred to herein, refers to a series of computer program segments that can be executed by at least one processor and perform fixed functions, and is stored in a memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0125] The instruction detection module 201 is configured to determine whether a power-on instruction is a first power-on instruction when a power-on instruction is detected.

[0126] The data acquisition module 202 is configured to acquire a check code and a number of startup times corresponding to each logic code module in the logic code module string when it is determined that the startup instruction is not the first startup instruction.

[0127] The cyclic verification module 203 is configured to perform cyclic verification on the logic code module string according to the number of power-on times and the verification sequence when it is detected that the verification code of any logic code module in the logic code module string is not the initial verification code.

[0128] The startup execution module 204 is configured to execute the startup operation corresponding to the startup instruction when it is determined that the verification result of each logic code module in the logic code module string is passed.

[0129] The startup stop module 205 is configured to stop executing the startup operation corresponding to the startup instruction when it is determined that the verification result of any logic code module in the logic code module string is verification failure.

[0130] The cyclic verification module 203 is further specifically configured to: obtain a first power-on count corresponding to a first module and an Nth power-on count of an 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 count is less than the first power-on count by 1, perform a check code check on the first module according to the first check code of the first module to obtain a first check result; when it is determined that the first check result is a pass, determine whether a second power-on count of a second module is consistent with the first power-on count, wherein the second module is a logic code module in the logic code module string that is adjacent to the first module and is sequenced after the first module; when it is determined that the second power-on count is consistent with the first power-on count, calculate a second check code corresponding to the second module according to the first check code, and perform a check code check on the second module according to the second check code to obtain a second check result; when it is determined that the second check result is a pass, repeatedly perform the above operations according to the check order until each logic code module in the logic code module string is checked, or the check result of any logic code module in the logic code module string is a fail.

[0131] The cyclic check module 203 is further configured to: when it is detected that the check code of each logic code module in the logic code module string is an initial check code and the number of startup times of each logic code module in the logic code module string is the initial startup time, control the first boot module in the logic code module string to enter Fastboot mode; obtain bad block information and a CPU identifier of each logic code module in the logic code module string in the Fastboot mode; generate a combination key based on the bad block information and the CPU identifier; return the combination key to an external production tool so that the external production tool calculates a first target check code of each logic code module in the logic code module string based on the combination key and returns a check code sequence; when the check code sequence is received, recalculate a second target check code of each logic code module in the logic code module string according to the combination key; compare the first target check code with the second target check code; and when it is determined that the first target check code and the second target check code of each logic code module in the logic code module string match, store the check code sequence.

[0132] The cyclic check module 203 is also used to: obtain a CPU identifier, and determine the target bad block sequence number and target bad block type of the current module based on the bad block information; generate a target combination key using the CPU identifier, the target bad block sequence number and the target bad block type; and calculate the current module check code of the current module based on the previous module check code and the target combination key.

[0133] The bad block processing module 206 is used to: determine the number of bad blocks in the logic code module string based on 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 based on the number of bad blocks and the preset number threshold.

[0134] The bad block processing module 206 is also used for: when it is determined that the bad block type of the first target bad block is the first bad block type, performing a first erase and write operation on the first target bad block, the first target bad block being any bad block in the logic code module string; when it is determined that the erase result is a successful erase, performing a second erase operation on the first target bad block until the preset erase times are met, or any erase result is an erase failure; when it is determined that the bad block type of the first target bad block is the second bad block type, obtaining the spare area of ​​the first page of the first target bad block; checking 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, determining that the detection result of the first target bad block is a passed detection; when it is determined that the data in the spare area of ​​the first page is 0xFF, determining that the detection result of the first target bad block is a failed detection, and terminating the power-on instruction.

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

[0136] It should be understood that the various variations and specific embodiments of the terminal software protection method provided in the above embodiments are also applicable to the terminal software protection device of this embodiment. Through the above detailed description of the terminal software protection method, those skilled in the art can clearly understand the implementation method of the terminal software protection device in this embodiment. For the sake of brevity of the specification, it will not be described in detail here.

[0137] See Figure 3 FIG. 1 is a schematic diagram of the structure of a terminal device according to an 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 .

[0138] Those skilled in the art should understand that Figure 3The structure of the terminal device shown does not constitute a limitation of the embodiments of the present application. It can be either a bus structure or a star structure. The terminal device 3 can also include more or less other hardware or software than shown in the figure, or a different component arrangement.

[0139] 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, and its hardware includes but is not limited to microprocessors, application-specific integrated circuits, programmable gate arrays, digital processors, and embedded devices. The terminal device 3 may also include user equipment, which includes but is not limited to any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice-controlled device, such as a personal computer, tablet computer, smartphone, digital camera, etc.

[0140] In the above embodiments provided in 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 schematic. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices, components, or modules, which can be electrical, mechanical, or other forms.

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

[0142] In addition, the functional modules in various embodiments of the present invention may be integrated into a single processing module, or each component may exist physically separately, or two or more modules may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or software functional modules.

[0143] If the integrated module is implemented as 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, or the portion that contributes to the prior art, or all or part of the 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 for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0144] It should be noted that for the aforementioned method embodiments, for ease of description, they are all expressed as a series of action combinations. However, those skilled in the art should be aware that the present invention is not limited by the order of the actions described, because according to the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0145] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0146] The above is a specific description of the preferred implementation of the present invention, but the invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A terminal software protection method, characterized in that: The method comprises: When a power-on instruction is detected, determining whether the power-on instruction is a first power-on instruction; When it is determined that the power-on instruction is not the first power-on instruction, obtaining a check code and a power-on count corresponding to each logic code module in the logic code module string; When it is detected that the check code of any one of the logic code modules in the logic code module string is not the initial check code, the logic code module string is cyclically checked according to the power-on times and the check sequence, including: obtaining a first power-on time corresponding to the first module and an N-th power-on time of the N-th module in the logic code module string, where N is an integer greater than 1; when it is determined that the N-th power-on time is less than the first power-on time by 1, checking the check code of the first module according to the first check code of the first module to obtain a first check result; when it is determined that the first check result is a pass, determining whether a second power-on time of the second module is the same as the first power-on time wherein the second module is a logic code module adjacent to the first module in the logic code module string and is arranged after the first module; when it is determined that the second number of startups is consistent with the first number of startups, calculating a second verification code corresponding to the second module according to the first verification code, and performing 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, repeatedly performing the above operations according to the verification order until each logic code module in the logic code module string is verified, or the verification result of any logic code module in the logic code module string is verification failed; When it is determined that the verification results of each logic code module in the logic code module string are all verified to pass, executing the power-on operation corresponding to the power-on instruction; When it is determined that the verification result of any one logic code module in the logic code module string is verification failure, the boot operation corresponding to the boot instruction is stopped.

2. The terminal software protection method according to claim 1, characterized in that: The method further comprises: When it is detected that the check code of each logic code module in the logic code module string is an initial check code and the number of startup times of each logic code module in the logic code module string is an initial number of startup times, controlling the first startup module in the logic code module string to enter Fastboot mode; Obtaining bad block information and a CPU identifier of each logic code module in the logic code module string in the Fastboot mode; Generate a combined key according to the bad block information and the CPU identifier; Returning the combined key to the external production tool, so that the external production tool calculates a 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 the check code sequence is received, recalculating the second target check code of each logic code module in the logic code module string according to the combination key; comparing the first target check code and the second target check code; When it is determined that the first target check code and the second target check code of each logic code module in the logic code module string match, the check code sequence is stored.

3. The terminal software protection method according to claim 2, characterized in that: The method further comprises: Obtaining a CPU identifier, and determining a target bad block sequence number and a target bad block type of the current module according to the bad block information; Generate a target combination Key using the CPU identifier, the target bad block sequence number, and the target bad block type; The current module check code of the current module is calculated according to the previous module check code and the target combination Key.

4. The terminal software protection method according to claim 2, characterized in that: The method further comprises: determining the number of bad blocks of the logic 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, a target number of good blocks are randomly selected from the logic code module string and marked as bad blocks, where the target number is determined according to the number of bad blocks and the preset number threshold.

5. The terminal software protection method according to claim 1, characterized in that: The method further comprises: When it is determined that the bad block type of the first target bad block is the first bad block type, performing a first erase / write operation on the first target bad block, the first target bad block being any bad block in the logical code module string; When it is determined that the erasing result is a success, performing a second erasing operation on the first target bad block until a preset erasing number of times is met, or any erasing result is an erasing failure; When it is determined that the bad block type of the first target bad block is the second bad block type, obtaining a spare area of ​​a 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 of the spare area of ​​the first page is not 0xFF, determining 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, the detection result of the first target bad block is determined to be a detection failure, and the boot instruction is terminated.

6. The terminal software protection method according to claim 5, characterized in that: The method further comprises: When it is determined that the erasure results corresponding to the preset erasure times of the first target bad block are all successful, obtaining the bad block type of the second target bad block; An erase / write operation is performed on the second target bad block according to the bad block type of the second target bad block.

7. A terminal software protection device, characterized in that: The device comprises: The command detection module is used to determine whether the power-on command is a first power-on command when a power-on command is detected; a data acquisition module, configured to acquire a check code and a number of startup times corresponding to each logic code module in the logic code module string when it is determined that the startup instruction is not the first startup instruction; A cyclic verification module is used to perform cyclic verification on the logic code module string according to the power-on times and the verification order when it is detected that the verification code of any logic code module in the logic code module string is not the initial verification code, including: obtaining a first power-on number corresponding to the first module and an N-th power-on number of the N-th module in the logic code module string, where N is an integer greater than 1; when it is determined that the N-th power-on number is less than 1 by 1, performing 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 a verification pass, determining whether the second power-on number of the second module is equal to the first power-on number. whether the number of startup times is consistent, wherein the second module is a 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 number is consistent with the first startup number, calculating a second check code corresponding to the second module according to the first check code, and performing a check code check on the second module according to the second check code to obtain a second check result; when it is determined that the second check result is a pass, repeating the above operations according to the check order until each logic code module in the logic code module string is checked, or the check result of any logic code module in the logic code module string is a fail check; a power-on execution module, configured to execute a power-on operation corresponding to the power-on instruction when it is determined that the verification results of each logic code module in the logic code module string are all verified to be passed; The power-on stop module is configured to stop executing the power-on operation corresponding to the power-on instruction when it is determined that the verification result of any logic code module in the logic code module string is failure to pass the verification.

8. A terminal device, characterized in that: The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the terminal software protection method according to any one of claims 1 to 6 when executing the computer program.

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

Images