Code protection method, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a code protection method, electronic equipment and a storage medium, and the method comprises the steps: analyzing a preset program, and determining a target code in the preset program; designing a custom instruction based on the target code; and adjusting a tool chain based on the custom instruction, and generating an executable file corresponding to the target code based on the adjusted tool chain. According to the embodiment of the invention, by designing the custom instruction of the key code, the difficulty of reverse engineering of the code is increased, so that the source code is effectively protected, and key confidential information in the code is prevented from being leaked.

Description

Technical Field

[0001] This application relates to the field of embedded technology, and more particularly to a code protection method, electronic device, and storage medium. Background Technology

[0002] With the development of embedded technology, embedded systems can perform an increasing number of functions and are widely used in fields such as vehicle control, industrial control, and IoT devices. The critical code of embedded systems often contains core functions, algorithms, or trade secrets. After the code is released, hackers can easily obtain core source code details through reverse engineering operations such as disassembly, leading to the leakage of critical confidential information. Summary of the Invention

[0003] In view of the above, it is necessary to provide a code protection method, electronic device and storage medium to solve the problem that after the embedded system code is released, the core source code details are easily obtained by reverse operations such as disassembly, which leads to the leakage of critical confidential information in the code.

[0004] In a first aspect, embodiments of this application provide a code protection method, the method comprising: Analyze the preset program to determine the target code in the preset program; Design custom instructions based on the target code; The toolchain is adjusted based on the custom instructions, and an executable file corresponding to the target code is generated based on the adjusted toolchain.

[0005] In one possible implementation, analyzing the preset program and determining the target code within the preset program includes: Static analysis tools are used to identify preset algorithms or preset logic in the preset program, and the code corresponding to the preset algorithm or preset logic is identified as the target code and marked.

[0006] In one possible implementation, the step of designing custom instructions based on the target code includes: Based on the functionality of the target code, the custom instruction's function and data path are designed using an extensible instruction set architecture. The special-purpose registers and control registers are planned, and the functional units that execute the custom instructions are described using a hardware description language.

[0007] In one possible implementation, the method further includes: Based on the storage state of each storage cell in the static random access memory, a key is generated using a physically non-coclone function, and the key is used to encrypt the custom instruction.

[0008] In one possible implementation, adjusting the toolchain based on the custom instructions and generating the executable file corresponding to the target code based on the adjusted toolchain includes: The syntax of the compiler in the toolchain is modified or extended, the target code is compiled using the compiler to obtain the custom instructions, and the executable file corresponding to the target code is generated using the linker of the toolchain.

[0009] In one possible implementation, the method further includes: Modify the decoder logic by adding the state machine and control signal generation logic corresponding to the custom instruction.

[0010] In one possible implementation, the method further includes: By running the executable file, the custom instructions are executed, including: The decoder is used to parse the custom instructions in the executable file, extract the opcode and operands of the custom instructions, generate corresponding control signals, and execute the corresponding operations through the functional units in the processor in response to the control signals.

[0011] In one possible implementation, the step of executing the corresponding operation in response to the control signal by a functional unit in the processor includes: The target functional unit of the custom instruction is determined based on the dynamic mapping table and the opcode of the custom instruction, and the corresponding operation is executed by the target functional unit in response to the control signal.

[0012] Secondly, embodiments of this application provide an electronic device, the electronic device including a memory and a processor: wherein the memory is used to store program instructions; the processor is used to read and execute the program instructions stored in the memory, and when the program instructions are executed by the processor, the electronic device performs the above-described code protection method.

[0013] Thirdly, embodiments of this application provide a computer storage medium storing program instructions that, when executed on an electronic device, cause the processor of the electronic device to perform the aforementioned code protection method.

[0014] The code protection method, electronic device, and storage medium provided in this application analyze the code of a preset program to identify key code, design custom instructions for the key code, make adaptive adjustments to the toolchain logic based on the custom instructions, and generate an executable file corresponding to the target code based on the adjusted toolchain. This increases the difficulty of reverse engineering the code, and even after reverse engineering and disassembly, the code function cannot be understood, thereby effectively protecting the source code and preventing the leakage of key confidential information in the code. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0016] Figure 1 This is a flowchart of a code protection method provided in an embodiment of this application.

[0017] Figure 2 This is a schematic diagram of the processing logic of a custom instruction provided in an embodiment of this application.

[0018] Figure 3 This is a schematic diagram of the structure of a code protection device provided in an embodiment of this application.

[0019] Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used in this application's specification is for the purpose of describing particular embodiments only and is not intended to limit the application. It should be understood that, unless otherwise stated, " / " in this application means "or". For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. "At least one" refers to one or more. "More than one" refers to two or more. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, and a, b, and c. Where there is no conflict, the following embodiments and features described herein can be combined with each other.

[0022] With the development of embedded technology, embedded systems can perform an increasing number of functions and are widely used in fields such as vehicle control, industrial control, and IoT devices. The critical code of embedded systems often contains core functions, algorithms, or trade secrets. After the code is released, hackers can easily obtain core source code details through reverse engineering operations such as disassembly, leading to the leakage of critical confidential information within the code.

[0023] Related technologies typically employ the following methods to protect critical code: code obfuscation and encryption methods, such as renaming variables and functions, inserting useless code, modifying control flow, and dynamically interfering with behavior, making the reverse-engineered code difficult to understand, thereby protecting the core code. Encryption involves storing the core code in an encrypted manner and dynamically decrypting and executing it at runtime, effectively preventing static analysis; dynamic loading and execution methods divide the core code into multiple modules, dynamically loading and executing them as needed, effectively reducing the attack surface and improving system security; white-box encryption technology mixes the key and algorithm logic together, making it difficult for attackers to extract the key or understand the algorithm logic even if they obtain the binary code; secure boot and firmware protection methods ensure the system starts running from a trusted initial state, preventing the loading of malicious firmware, and also prevent firmware tampering or replacement by encrypting firmware storage and performing integrity checks and signature verification during updates. To further enhance code security, a multi-layered defense strategy can be adopted, combining various technical means to form a multi-layered security protection system. For example, combining hardware security features, code obfuscation, and dynamic loading methods can provide comprehensive code protection.

[0024] To address the issue that after the embedded system code is released, core source code details are easily obtained through reverse engineering operations such as disassembly, leading to the leakage of critical confidential information, this application provides a code protection method. This method analyzes the code of a preset program to identify key code, designs custom instructions for the key code, adaptively adjusts the toolchain logic based on these custom instructions, and generates an executable file corresponding to the target code based on the adjusted toolchain. This increases the difficulty of reverse engineering the code, making it impossible to understand the code's functionality even after reverse engineering and disassembly, thus effectively protecting the source code and preventing the leakage of critical confidential information.

[0025] See Figure 1 The diagram shown is a flowchart of a code protection method provided in an embodiment of this application. The code protection method is applied to an electronic device and includes: S101, Analyze the preset program and determine the target code in the preset program.

[0026] In one embodiment of this application, a static analysis tool is used to identify preset algorithms or preset logic in a preset program, and the code corresponding to the preset algorithms or preset logic is identified as target code and marked. For example, the preset algorithm is a target detection and tracking algorithm or a vehicle body control algorithm used for autonomous driving. For example, the static analysis tool is LLVM (Low-Level Virtual Machine) PASS. LLVM PASS is a working unit for the compiler to perform code analysis, optimization, and transformation, and it completes the task by traversing and manipulating the LLVM intermediate representation (IR).

[0027] In one embodiment of this application, LLVM PASS compiles the source code into an LLVM IR file, uses the opt tool provided by LLVM to load a pre-written PASS shared library (.so file), and analyzes or transforms the IR code. It traverses different hierarchical structures within the IR code, such as modules, functions, basic blocks, and instructions, and identifies key code using pre-defined rules. After identifying key code, it can record, insert marker code, or generate an analysis report. The pre-defined rules can be the functions of the key code, such as target detection and tracking, vehicle body control, etc.

[0028] S102, custom instructions designed based on target code.

[0029] In one embodiment of this application, a custom instruction's function and data path are designed based on the target code using an Instruction Set Architecture (ISA). Dedicated-purpose registers and control registers are planned, and a hardware description language is used to describe the functional units that execute the custom instruction. For example, the function of a custom instruction may include encryption, decryption, or acceleration of a specific algorithm. A suitable opcode is selected within the ISA to ensure no conflict with existing instructions. The use of dedicated-purpose registers and control registers in the processor is planned, and a hardware description language such as Verilog is used to describe the functional units that implement the custom instruction. The data path of the custom instruction includes the functional units and paths through which data travels from source to destination during instruction execution.

[0030] For example, extensible instruction set architectures such as RISC-V (RV32IMC+Custom) or ARMv8-M CustomInstructions support instruction extensions and define custom instructions using a private code space (opcodes not used by the standard ISA). The core code is implemented using these custom instructions. Thus, even after disassembly, the code is unreadable; understanding the custom instruction set is required to comprehend the core code logic, thereby achieving core code protection.

[0031] In one embodiment of this application, a custom instruction is designed for each function in the target code, including: determining the standard instruction corresponding to each function and converting the standard instruction into a custom instruction. Specifically, a custom opcode and a refined opcode (funct3, funct7) are determined based on the opcode of the standard instruction, and a custom instruction is generated based on the custom opcode, the refined opcode, and the operands in the standard instruction. For example, for the immediate addition function in the target code, the default standard instruction is ADDI rd, rs1, imm, and the corresponding custom instruction is imm[11:0] | rs1 |funct3(000) | rd | opcode(0010011).

[0032] In one embodiment of this application, the method further includes: generating a key based on the storage state of each storage cell in the static random access memory (SRAM) using a physically unclonable function (PUF), and encrypting a custom instruction using the key.

[0033] Specifically, the PUF (Physical Fingerprint Unit) plays a crucial role in custom command processing and security systems. The PUF module leverages the inherent randomness of physical devices to generate unique, unpredictable keys that can be used for various security applications, such as encryption, authentication, and key management.

[0034] In one embodiment of this application, the static random access memory (SRAM) can be a cache in the processor or a separate memory used to store a preset program. When powered on, each memory cell of the SRAM randomly enters a 0 or 1 state. By reading the initial state of the memory cell, a unique key is generated for instruction stream encryption. Specifically, the states of all memory cells are arranged sequentially to generate the corresponding key. For example, the key K_ref = 101...0 (31 bits).

[0035] In one embodiment of this application, a BCH (Bose-Chaudhuri-Hocquenghem, error-correcting code) is used to encode the key and generate corresponding auxiliary data to ensure response stability. Specifically, the domain structure of the BCH is based on the finite field GF(2). m ), where m determines the encoding length, and the generator polynomial is g(x) = LCM[m1(x), m3(x), ... , m 2t−1 (x)],m i (x) is the minimal polynomial, and t is the maximum number of correctable error bits. The core parameters of the BCH include code length n, information bits k, and error correction capability t, where n=2. m-1 Let k ≥ n - mt, where t is the target number of error bits. Typical configurations (n, k, t) triples include: (63, 36, 5) which corrects 5 errors; and (127, 64, 10) which corrects 10 errors. After encoding the key using BCH to obtain auxiliary data, the auxiliary data is used to encrypt the custom instruction. For example, a hash algorithm is used to operate on the encoded auxiliary data and the custom instruction to obtain a hash value. During decryption, the key to be verified is encoded using BCH to obtain the auxiliary data to be verified. If the auxiliary data to be verified is the same as the auxiliary data, the hash value is decrypted using the auxiliary data to obtain the encoded custom instruction.

[0036] S103 adjusts the toolchain based on custom instructions and generates an executable file corresponding to the target code based on the adjusted toolchain.

[0037] In one embodiment of this application, the toolchain includes a preprocessor, a compiler, an assembler, and a linker. The preprocessor preprocesses the source code, the compiler translates the preprocessed high-level language code (e.g., C / C++) into assembly language code, the assembler translates the assembly language code into machine instructions, outputting an object file, and the linker links multiple object files and library files together to generate an executable file. By modifying or extending the syntax of the toolchain's compiler, object code can be compiled into assembly language code corresponding to custom instructions, instead of assembly language code corresponding to standard instructions. The toolchain's linker then links the object files corresponding to the custom instructions, other object files, and library files to generate a predefined program, i.e., the executable file corresponding to the object code.

[0038] Specifically, hardware development, compiler modification, and software development are all based on custom instructions. If the custom instructions are complex, microcode writing is required. In hardware development, the decoder logic is modified, new state machines and control signal generation logic are added, and the custom instructions are integrated into the processor pipeline to ensure they work in coordination with other instructions. The state machine defines the timing and steps of instruction execution, and the control signal generation logic generates signals to control various components of the processor based on the decoding results and the current state. Simultaneously, the compiler syntax is modified or extended to support new assembly syntax and inline assembly. Optimization passes are written to optimize for custom instructions. For software development, custom instructions are used to implement critical algorithms, improving performance and security. Application programming interfaces (APIs) are also written to enable the invocation of custom instructions.

[0039] S104 executes custom instructions by running an executable file.

[0040] In one embodiment of this application, a decoder is used to parse the custom instructions in the executable file, extract the opcode and operands of the custom instructions, generate corresponding control signals, and execute the corresponding operations through the functional units in the processor in response to the control signals.

[0041] In one embodiment of this application, a dedicated decoding unit is used to modify the decoder logic. This unit parses the encrypted custom instructions, extracts the opcode and operands, and generates corresponding control signals, enabling the hardware acceleration unit to correctly execute the custom instructions. The custom instruction identification mechanism includes opcode prefix identification: marking custom instructions with specific bit patterns; function code expansion: defining new instructions using reserved opcode space; and multi-level decoding: decomposing complex custom instructions into micro-operation sequences. Simultaneously, it supports multiple custom instruction sets, using a dynamic mapping table to determine the hardware function corresponding to each opcode. Newly added custom instructions can be added to the mapping table without redesigning the entire decoding circuit, exhibiting good scalability. This embodiment is implemented based on hardware expansion, modifying the processor core design, including the ALU (Arithmetic and Logic Unit), register file, and instruction cache.

[0042] In one embodiment of this application, the target functional unit of a custom instruction is determined based on a Dynamic Mapping Table (DMT), the opcode of the custom instruction, and its operands. The target functional unit then executes the corresponding operation in response to a control signal. This embodiment introduces randomness and unpredictability by dynamically adjusting the mapping relationship between instructions and hardware functions, making it difficult for attackers to predict and exploit fixed mapping relationships. Regular or on-demand updates enhance system security. Since system requirements and configurations may change over time, the dynamic mapping table can flexibly adapt to these changes without requiring hardware or firmware redesign, giving the system good flexibility and scalability. Simultaneously, by dynamically adjusting the mapping relationship, hardware resources can be managed and allocated more effectively, avoiding resource waste, achieving load balancing, and improving overall system performance.

[0043] In one embodiment of this application, the dynamic mapping table employs a tri-state obfuscation mechanism, which includes dynamic opcode permutation, register alias randomization, and immediate data stream encryption. Performing the tri-state obfuscation mechanism on each custom instruction in the static instruction set yields a dynamic instruction instance. Specifically, dynamic opcode permutation involves extending the 8-bit original opcode to 128 bits through repeated concatenation and XOR perturbation (extension bits = original code ^ (original code << 3)). "Original code ^" refers to performing a bitwise XOR operation on the original code, and "original code << 3" refers to shifting the original code left by 3 bits and inserting a 4-bit random filler character generated by the hardware random number generator TRNG to add randomness. Then, a Feistel permutation network is used for encrypted permutation. The Feistel permutation network consists of three independent cascaded operation units: the first stage is a 32-bit block permutation (implemented through a hardware lookup table LUT); the second stage is byte-by-byte cyclic shift (the shift amount is determined by the round key); and the third stage is S-Box replacement (implemented through a custom DPA-resistant S-box). Each stage uses AES-CTR (Advanced Encryption Standard-Counter) to generate an independent 128-bit key. The opcode obtained from the encrypted permutation is then subjected to a nonlinear transformation, mathematically based on the finite field GF(2... 8 The affine transformation of A is given by the formula y = (Ax + b) mod 256, where y is the opcode after the affine transformation, x is the opcode before the affine transformation, A is an invertible matrix (updated at regular intervals), and b is the TRNG generation offset. The confusion strength can reach a Hamming distance deviation of <0.5%. Finally, the Jenkins hash algorithm is used to compress the 128-bit intermediate result into an 8-bit output, completing the dynamic permutation of the opcode.

[0044] Register alias randomization breaks the predictability of registers during program execution by periodically changing the mapping between logical register numbers and physical register files. For example, the register alias randomization round-robin algorithm is as follows: Physical Address = (Logical Address ⊕ RoundKey) mod Nphys, where the logical address is the logical register number, the physical address is the hardware physical register index or memory address, RoundKey is a 128-bit key slice generated using AES-CTR, and Nphys is the total number of physical registers (usually twice the number of logical registers). The conditions for triggering the round-robin include at least one of the following: a forced refresh after every 1000 instructions executed, branch prediction errors exceeding a threshold (e.g., 10 times / ms), or the TRNG entropy pool reaching the NIST SP800-90B standard.

[0045] Immediate number stream encryption involves static bit scrambling of the immediate number, using the formula: Scrambling value = (Original value ⊕ Mask) + Bias, where Mask is the XOR mask generated by a 32-bit TRNG (updated periodically), and Bias is a 16-bit pseudo-random offset generated by an LFSR (linear feedback shift register), from which the scrambling value is derived. The scrambling value is then transformed using a finite field GF(2...)... 8 Invertible polynomial transformation on y= mod P(x), where P(x) is an irreducible polynomial x 8 +x 4 +x 3 +x+1, The key stream is refreshed by TRNG every 256 cycles, and then the transformed scrambled value is encrypted in real time. The key stream is generated in AES-CTR mode, and bit XORed in 32-bit blocks. The integrity check value of CBC-MAC (CipherBlock Chaining-Message Authentication Code) is embedded in the low bit.

[0046] For example, the data structure of a dynamic mapping table is as follows: struct dyn_insn_map { uint32_t opcode_mask; / / Opcode mask uint32_t opcode_match; / / Matching value void (*handler)(void); / / Handler function pointer uint8_t cycles; / / Number of execution cycles uint8_t priv_level; / / Privilege level requirement uint16_t feature_flags; / / Dependent functional units }

[0047] The functions of the aforementioned dynamic mapping table include: instruction function redirection, mapping existing instructions to optimized hardware implementations; virtual instruction support, mapping high-level abstract instructions to low-level hardware sequences; and security instruction isolation, dynamically enabling / disabling specific instructions based on permissions.

[0048] Dynamic mapping tables are used in simulators, interpreters, or JIT compilers to map machine instructions to corresponding processing functions. Specifically, `uint32_t opcode_mask` extracts the bits to be matched in the instruction; `uint32_t opcode_match` is the target value to compare with the masked instruction; if `opcode_mask` and `opcode_match` are the same, it points to the C function that actually executes the machine instruction; `uint8_t cycles` simulates the clock cycles required for the machine instruction to execute; `uint8_t priv_level` is the minimum privilege level required to execute the machine instruction (0 for user level, 1 for kernel level); and `uint16_t feature_flags` identifies the hardware functional units required to execute the machine instruction. For example, the dynamic mapping table for the `ADD` instruction is as follows: struct dyn_insn_map add_instruction = { .opcode_mask = 0xFE000000, / / Focus on the high 7 bits .opcode_match = 0x10000000, / / Characteristic value of the ADD instruction .handler =&handle_add, / / ADD processing function .cycles = 1, / / Requires 1 cycle .priv_level = 0, / / This allows execution at the user level. .feature_flags = 0x0001 / / Requires ALU units }; Based on the dynamic mapping table of the ADD instruction, if the high 7 bits of the opcode are 0x10000000, which matches the characteristic value, and the current privilege level matches priv_level, then the ADD processing function is called to process the ADD instruction using the ALU unit.

[0049] In one embodiment of this application, by running an executable file and executing custom instructions, the custom instructions can be functionally verified, performance tested, and power consumption analyzed. This verifies the functional correctness of the custom instructions, measures the execution time and throughput of the custom instructions, and assesses the power consumption impact of the custom instructions.

[0050] See Figure 2The diagram illustrates the processing logic of a custom instruction provided in an embodiment of this application. After designing the custom instruction based on the target code, a unique key for each custom instruction is generated using a PUF physical fingerprint unit. The instruction stream is encrypted during the instruction fetching stage using a key management engine. During the instruction fetching stage, the current instruction is read from memory. First, the address of the current instruction is obtained from the PC register. Then, the instruction at that address is read from memory. Finally, the PC register is updated to the address of the next instruction. During the decoding stage, the opcode and operands of the instruction are parsed using a dedicated decoding unit to determine the instruction type and mode. If it is a mode switching instruction, the mode bit in the status register is updated. The parsed opcode is matched using a dynamic mapping table, and the functional unit for executing the instruction is determined based on semantic pointers, such as an AES unit or a SHA unit. During the execution stage, the current mode is first determined based on the mode bit in the status register. Then, the corresponding execution unit is called based on the current mode and opcode. If it is a standard mode, a standard execution unit is called; if it is a custom mode, a custom execution unit or a dedicated hardware unit is called. During the memory access stage, it is determined whether memory access is needed based on the execution result. If memory access is needed, data is read from memory or written to memory. During the write-back phase, the execution result of the instruction is written to the target register.

[0051] This application embodiment employs PUF for custom instruction stream encryption and data encryption, obfuscating the custom instruction stream from the standard instruction stream, increasing the difficulty of reverse engineering, and effectively preventing attackers from parsing sensitive information through reverse engineering. The electronic device in this application embodiment pre-stores a dynamic permission table, recording the execution permissions of each instruction. Before instruction execution, it checks the current context, such as user identity and environment variables, to determine whether to execute the instruction, achieving dynamic permission adjustment and fine-grained permission control. The electronic device in this application embodiment can also pre-store a resource manager, dynamically adjusting resource allocation based on system load, rationally allocating processor, memory, and other resources to improve resource utilization.

[0052] This application's embodiments ensure that custom instructions meet security performance requirements by executing them. When applied to the field of autonomous driving, this application's embodiments can protect autonomous driving-related algorithms from hijacking and tampering, such as path planning algorithms and sensor data processing algorithms, ensuring the reliable execution of core modules. When applied to industrial control systems, which are core components ensuring the operation of critical industries such as manufacturing, energy facilities, and infrastructure, the introduction of a custom instruction mechanism can effectively address threats such as physical tampering, malicious firmware updates, and remote intrusion. When applied to financial transaction terminals, this application's embodiments can prevent payment algorithms from being replaced with malicious code, ensuring risk-free transaction signatures.

[0053] See Figure 3The diagram shown is a structural schematic of a code protection device provided in one embodiment of this application. In one embodiment of this application, the code protection device 200 may include multiple functional modules composed of computer program segments. The computer program segments in the code protection device 200 may be stored in the memory of an electronic device and executed by at least one processor to perform code protection functions.

[0054] In one embodiment of this application, the code protection device 200 can be divided into multiple functional modules according to the functions it performs. The functional modules of the code protection device 200 may include: a determination module 201, a design module 202, a generation module 203, and an execution module 204. In this embodiment, a module refers to a series of computer program segments that can be executed by at least one processor and perform a fixed function, and which are stored in memory.

[0055] The determination module 201 is used to analyze the preset program and determine the target code in the preset program.

[0056] Design module 202 is used to design custom instructions based on the target code.

[0057] The generation module 203 is used to adjust the toolchain based on the custom instructions, and generate the executable file corresponding to the target code based on the adjusted toolchain.

[0058] The execution module 204 is used to execute the custom instructions by running the executable file.

[0059] This application also provides an electronic device 10, see reference. Figure 4 The diagram shown is a hardware structure schematic of an electronic device provided in an embodiment of this application. The code protection method provided in this embodiment is applied to an electronic device 10, which includes, but is not limited to, a processor 110 and a memory 120 connected via a communication bus 130. Figure 4 This is merely an example of an electronic device and does not constitute a limitation thereof. In other embodiments, the electronic device may include more components than those shown in the figure.

[0060] The memory 120 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM). The RAM can be directly read and written by the processor 110 and can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data. The RAM may include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), etc.

[0061] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct reading and writing by the processor 110. Non-volatile memory can include disk storage devices and flash memory.

[0062] The memory 120 is used to store one or more computer programs. The one or more computer programs are configured to be executed by the processor 110. The one or more computer programs include multiple instructions that, when executed by the processor 110, enable code protection methods that can be executed on the electronic device 10.

[0063] In other embodiments, the electronic device 10 further includes an external memory interface for connecting to an external memory to expand the storage capacity of the electronic device 10.

[0064] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0065] The processor 110 provides computing and control capabilities, for example, the processor 110 is used to execute computer programs stored in the memory 120 to implement the code protection method described above.

[0066] The communication bus 130 is used to provide a channel for communication between the memory 120 and the processor 110 in the electronic device 10.

[0067] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 10. In other embodiments of this application, the electronic device 10 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0068] This application also provides a computer storage medium storing computer instructions. When the computer instructions are executed on the electronic device 10, the electronic device 10 performs the above-mentioned related method steps to implement the code protection method in the above embodiments.

[0069] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the code protection method described above.

[0070] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the code protection methods in the above-described method embodiments.

[0071] In this application, the electronic devices, computer storage media, computer program products or chips provided in the embodiments are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0072] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0073] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0074] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0075] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0076] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts or all or part of the technical solutions that contribute to the prior art, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0077] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A code protection method, characterized in that, The method includes: Analyze the preset program to determine the target code in the preset program; Design custom instructions based on the target code; The toolchain is adjusted based on the custom instructions, and an executable file corresponding to the target code is generated based on the adjusted toolchain.

2. The code protection method as described in claim 1, characterized in that, The step of analyzing the preset program and determining the target code in the preset program includes: Static analysis tools are used to identify preset algorithms or preset logic in the preset program, and the code corresponding to the preset algorithm or preset logic is identified as the target code and marked.

3. The code protection method as described in claim 1, characterized in that, The design of custom instructions based on the target code includes: Based on the functionality of the target code, the custom instruction's function and data path are designed using an extensible instruction set architecture. The special-purpose registers and control registers are planned, and the functional units that execute the custom instructions are described using a hardware description language.

4. The code protection method as described in claim 1, characterized in that, The method further includes: Based on the storage state of each storage cell in the static random access memory, a key is generated using a physically non-coclone function, and the key is used to encrypt the custom instruction.

5. The code protection method as described in claim 1, characterized in that, The step of adjusting the toolchain based on the custom instructions and generating the executable file corresponding to the target code based on the adjusted toolchain includes: The syntax of the compiler in the toolchain is modified or extended, the target code is compiled using the compiler to obtain the custom instructions, and the executable file corresponding to the target code is generated using the linker of the toolchain.

6. The code protection method as described in claim 1, characterized in that, The method further includes: Modify the decoder logic by adding the state machine and control signal generation logic corresponding to the custom instruction.

7. The code protection method as described in claim 6, characterized in that, The method further includes: By running the executable file, the custom instructions are executed, including: The decoder is used to parse the custom instructions in the executable file, extract the opcode and operands of the custom instructions, generate corresponding control signals, and execute the corresponding operations through the functional units in the processor in response to the control signals.

8. The code protection method as described in claim 7, characterized in that, The step of executing the corresponding operation in response to the control signal by the functional unit in the processor includes: The target functional unit of the custom instruction is determined based on the dynamic mapping table and the opcode of the custom instruction, and the corresponding operation is executed by the target functional unit in response to the control signal.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor: The memory is used to store program instructions; The processor is configured to read and execute the program instructions stored in the memory, and when the program instructions are executed by the processor, cause the electronic device to perform the code protection method as described in any one of claims 1 to 8.

10. A computer storage medium, characterized in that, The computer storage medium stores program instructions that, when executed on an electronic device, cause the processor of the electronic device to perform the code protection method as described in any one of claims 1 to 8.

Images