A method and device for protecting a two-wheeled vehicle embedded toolkit SDK, and a two-wheeled vehicle

Abstract

This application discloses a security protection method, device, and two-wheeled vehicle for an embedded toolkit SDK (Software-Defined Kit), which is applied to the embedded SDK in the electronic control unit (ECU) of a two-wheeled vehicle. Specifically, the obfuscated core algorithm code is encrypted to obtain encrypted core algorithm code. During the runtime phase of the embedded SDK, in response to calls to the target SDK interface from external applications, the unique identifier of the microcontroller (MCU) in the ECU is verified based on a preset authorization list to obtain the MCU's authorization verification result. If the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain obfuscated core algorithm code, which is then loaded into the runtime memory (RAM) for execution. This provides effective security protection for the two-wheeled vehicle embedded toolkit SDK.

Description

Technical Field

[0001] This application relates to the field of two-wheeled vehicle technology, and in particular to a security protection method, device, and two-wheeled vehicle for an embedded toolkit SDK for two-wheeled vehicles. Background Technology

[0002] With the development of intelligent two-wheeled vehicles, OEMs typically provide embedded toolkits (SDKs) to suppliers of motors, batteries, and instruments to achieve functional integration. However, current SDKs face serious security challenges during supply chain distribution and integration. For example, suppliers or third parties may extract SDK binary code by reading ECU Flash (electronic control unit non-volatile memory); they may also use disassemblers to reverse engineer the SDK, obtaining its internal data structures, control flow, and core algorithm logic.

[0003] Therefore, how to better protect the security of the embedded toolkit SDK for two-wheeled vehicles is a key issue of concern for those skilled in the art. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method, apparatus, and two-wheeled vehicle for the security protection of a two-wheeled vehicle embedded toolkit SDK, thereby providing better security protection for the two-wheeled vehicle embedded toolkit SDK.

[0005] The embodiments of this application disclose the following technical solutions: The first aspect of this application provides a security protection method for an embedded toolkit SDK for two-wheeled vehicles, applied to the embedded SDK in the electronic control unit (ECU) of a two-wheeled vehicle, including: During the compilation phase of the embedded SDK, the embedded SDK undergoes interface abstraction to obtain a target SDK interface provided to external applications, wherein the target SDK interface has hidden the internal data structure and implementation logic of the embedded SDK; During the compilation phase of the embedded SDK, the core algorithm functions in multiple functions of the embedded SDK are obfuscated to obtain obfuscated core algorithm code. The core algorithm functions include at least the algorithm functions related to the two-wheeled vehicle motor control and battery state estimation. During the compilation phase of the embedded SDK, the obfuscated core algorithm code is encrypted to obtain the encrypted core algorithm code. During the runtime phase of the embedded SDK, in response to the external application's call to the target SDK interface, the unique identifier of the microcontroller (MCU) in the ECU is verified based on a preset authorization list to obtain the authorization verification result of the MCU. If the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain the obfuscated core algorithm code, and the obfuscated core algorithm code is loaded into the runtime memory RAM for execution.

[0006] In one feasible implementation, before obfuscating the core algorithm functions among the multiple functions of the embedded SDK to obtain the obfuscated core algorithm code, the method further includes: From the multiple functions of the embedded SDK, core algorithm functions and non-core functions related to the operation control of the two-wheeled vehicle are determined, wherein the non-core functions include at least communication protocol functions, and the non-core functions are in a non-obfuscated state; The code obfuscation process includes at least one of structure transformation processing, jump insertion processing, and instruction substitution processing; the code obfuscation process performed on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: If the microcontroller (MCU) in the ECU is a first-level MCU, then the core algorithm function in the multiple functions of the embedded SDK is subjected to jump insertion processing to obtain the obfuscated core algorithm code; If the microcontroller (MCU) in the ECU is a second-level MCU, then the core algorithm functions in the multiple functions of the embedded SDK are subjected to structural transformation and jump insertion processing to obtain obfuscated core algorithm code, wherein the performance information corresponding to the first-level MCU is lower than the performance information corresponding to the second-level MCU; If the microcontroller (MCU) in the ECU is a third-level MCU, then the core algorithm functions in the multiple functions of the embedded SDK are subjected to structural conversion processing, jump insertion processing, and instruction replacement processing to obtain obfuscated core algorithm code, wherein the performance information corresponding to the second-level MCU is lower than the performance information corresponding to the third-level MCU.

[0007] In one feasible implementation, the step of performing jump insertion processing on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: Invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function to obtain obfuscated core algorithm code; The process of performing structural transformation and jump insertion processing on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: The conditional branch structure and / or loop structure in the core algorithm function are converted into a state machine scheduling structure, and invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function to obtain the obfuscated core algorithm code. The process of performing structural transformation, jump insertion, and instruction substitution on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: The conditional branch structure and / or loop structure in the core algorithm function are converted into a state machine scheduling structure, and invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function. The target instruction in the core algorithm function is replaced with an equivalent instruction sequence that has the same execution result as the target instruction, thus obtaining the obfuscated core algorithm code.

[0008] In one feasible implementation, encrypting the obfuscated core algorithm code to obtain encrypted core algorithm code includes: Obtain the base key and the unique identifier of the microcontroller (MCU) in the ECU; Based on the base key and the unique identifier of the MCU, a device binding key corresponding to the MCU is generated; Based on the device binding key, the obfuscated core algorithm code is symmetrically encrypted to obtain the encrypted core algorithm code, wherein the encrypted core algorithm code is stored in the non-volatile memory of the ECU.

[0009] In one feasible implementation, after performing authorization verification processing on the unique identifier of the microcontroller (MCU) in the ECU based on a preset authorization list to obtain the authorization verification result of the MCU, the method further includes: If the authorization verification result indicates that the MCU authorization verification has failed, a restricted operation mode is initiated, wherein the restricted operation mode includes at least limiting the maximum output speed of the motor and the communication frequency of the two-wheeled vehicle.

[0010] In one feasible implementation, during the runtime phase of the embedded SDK, in response to the external application's call to the target SDK interface, based on a preset authorization list, the unique identifier of the microcontroller (MCU) in the ECU is subjected to authorization verification processing. Before obtaining the authorization verification result of the MCU, the method further includes: During the compilation phase of the embedded SDK, a unique digital watermark is generated based on supplier information, project identification information, and compilation time information. The unique digital watermark is linked to the firmware image of the ECU corresponding to the embedded SDK, wherein the unique digital watermark is used to identify the supplier and project source of the embedded SDK.

[0011] In one feasible implementation, the method further includes: Obtain the firmware image to be tested, wherein the firmware image to be tested is the firmware image read from the ECU to be tested; Extract the target digital watermark from the firmware image to be detected; The target digital watermark is compared with the digital watermarks in the preset watermark database to obtain the watermark comparison result. Based on the watermark comparison results, the supplier information, project identification information, and compilation time information corresponding to the firmware image to be detected are determined.

[0012] In one feasible implementation, after the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain the obfuscated core algorithm code, and the obfuscated core algorithm code is loaded into runtime memory (RAM) for execution, the method further includes: Write the unique digital watermark corresponding to the embedded SDK into the log and start the runtime detection task; The runtime detection task detects the debug interface connection status and / or the integrity of the operating environment of the ECU, and obtains the runtime detection results. If the runtime detection results indicate that the ECU has a debug interface connection abnormality and / or an operating environment integrity abnormality, then the abnormal event is recorded.

[0013] The second aspect of this application provides a safety protection device for an embedded toolkit SDK for two-wheeled vehicles, applied to the embedded SDK in the electronic control unit (ECU) of a two-wheeled vehicle, including: An interface abstraction processing unit is used to perform interface abstraction processing on the embedded SDK during the compilation phase of the embedded SDK to obtain a target SDK interface provided to external applications, wherein the target SDK interface has hidden the internal data structure and implementation logic of the embedded SDK; The code obfuscation processing unit is used to perform code obfuscation processing on the core algorithm functions among multiple functions of the embedded SDK during the compilation stage of the embedded SDK to obtain obfuscated core algorithm code, wherein the core algorithm functions include at least the algorithm functions related to two-wheeled vehicle motor control and battery state estimation. The core code encryption unit is used to encrypt the obfuscated core algorithm code during the compilation phase of the embedded SDK to obtain the encrypted core algorithm code. The authorization verification processing unit is used to, during the runtime phase of the embedded SDK, respond to the call of the target SDK interface by the external application, perform authorization verification processing on the unique identifier of the microcontroller MCU in the ECU based on a preset authorization list, and obtain the authorization verification result of the MCU; The core code decryption unit is used to decrypt the encrypted core algorithm code if the authorization verification result indicates that the MCU authorization verification is successful, to obtain the obfuscated core algorithm code, and to load the obfuscated core algorithm code into the runtime memory RAM for execution.

[0014] The third aspect of this application provides a two-wheeled vehicle, including a security protection method for the two-wheeled vehicle embedded toolkit SDK as described in the first aspect.

[0015] Compared with the prior art, this application has the following beneficial effects: This application's technical solution is applied to an embedded SDK in the electronic control unit (ECU) of a two-wheeled vehicle. Specifically, during the compilation phase of the embedded SDK, interface abstraction is performed to obtain a target SDK interface provided to external applications. This target SDK interface hides the internal data structures and implementation logic of the embedded SDK. Thus, through interface abstraction, this application only provides the target SDK interface to external applications, hiding the SDK's internal data structures and implementation logic, reducing the SDK's information exposure surface, and improving the SDK's black-box nature.

[0016] During the compilation phase of the embedded SDK, the core algorithm functions in multiple functions of the embedded SDK are obfuscated to obtain obfuscated core algorithm code. These core algorithm functions include at least those related to the two-wheeled vehicle motor control and battery state estimation. Thus, by obfuscating only the core algorithm functions, this application can effectively protect critical algorithms such as two-wheeled vehicle motor control and battery state estimation, while reducing the code bloat and performance loss caused by full obfuscation. During the compilation phase of the embedded SDK, the obfuscated core algorithm code is encrypted to obtain encrypted core algorithm code. This reduces the risk of static reverse engineering after the firmware is read.

[0017] During the runtime phase of the embedded SDK, in response to calls to the target SDK interface from external applications, the unique identifier of the microcontroller (MCU) in the ECU is verified based on a preset authorization list to obtain the MCU's authorization verification result. Finally, if the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain obfuscated core algorithm code, which is then loaded into the runtime memory (RAM) for execution. Thus, this application only decrypts the core algorithm code and loads it into RAM for execution after successful authorization verification, preventing the SDK from being copied to an unauthorized MCU and running completely. Therefore, this application avoids the problems encountered in related technical solutions and effectively provides security protection for the two-wheeled vehicle embedded toolkit SDK. Attached Figure Description

[0018] 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this application embodiment; Figure 2 A flowchart illustrating the watermark embedding process in a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this application embodiment; Figure 3 A flowchart illustrating the watermark extraction process in a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this application embodiment; Figure 4 A flowchart illustrating the SDK runtime phase of a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this application embodiment; Figure 5 This application provides an implementation architecture diagram of a security protection method for a two-wheeled vehicle embedded toolkit SDK, as illustrated in this embodiment. Figure 6 This is a schematic diagram of the structure of a safety protection device for a two-wheeled vehicle embedded toolkit SDK provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0021] It should be noted that the "first" and "second" in the names such as "first" and "second" (if they exist) mentioned in the embodiments of this application are only used as name identifiers and do not represent the first and second in order.

[0022] First, we will explain several terms that may be involved in the embodiments of this application below.

[0023] As described earlier, with the development of intelligent two-wheeled vehicles, OEMs typically provide embedded toolkits (SDKs) to suppliers of motors, batteries, and instruments to achieve functional integration. However, current SDKs face serious security challenges during supply chain distribution and integration. For example, suppliers or third parties may extract SDK binary code by reading ECU Flash (electronic control unit non-volatile memory); they may also use disassemblers to reverse engineer the SDK, obtaining its internal data structures, control flow, and core algorithm logic.

[0024] Therefore, how to better protect the security of the embedded toolkit SDK for two-wheeled vehicles is a key issue of concern for those skilled in the art.

[0025] In view of this, this application provides a method, apparatus, and two-wheeled vehicle for the security protection of an embedded toolkit SDK for two-wheeled vehicles, aiming to better protect the embedded toolkit SDK. The technical solution of this application is applied to the embedded SDK in the electronic control unit (ECU) of a two-wheeled vehicle. Specifically, firstly, during the compilation stage of the embedded SDK, interface abstraction processing is performed on the embedded SDK to obtain a target SDK interface provided to external applications. This target SDK interface hides the internal data structure and implementation logic of the embedded SDK. Thus, this application, through interface abstraction processing, only provides the target SDK interface to external applications, hiding the internal data structure and implementation logic of the SDK, reducing the SDK information exposure surface, and improving the SDK's black-box nature.

[0026] During the compilation phase of the embedded SDK, the core algorithm functions in multiple functions of the embedded SDK are obfuscated to obtain obfuscated core algorithm code. These core algorithm functions include at least those related to the two-wheeled vehicle motor control and battery state estimation. Thus, by obfuscating only the core algorithm functions, this application can effectively protect critical algorithms such as two-wheeled vehicle motor control and battery state estimation, while reducing the code bloat and performance loss caused by full obfuscation. During the compilation phase of the embedded SDK, the obfuscated core algorithm code is encrypted to obtain encrypted core algorithm code. This reduces the risk of static reverse engineering after the firmware is read.

[0027] During the runtime phase of the embedded SDK, in response to calls to the target SDK interface from external applications, the unique identifier of the microcontroller (MCU) in the ECU is verified based on a preset authorization list to obtain the MCU's authorization verification result. Finally, if the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain obfuscated core algorithm code, which is then loaded into the runtime memory (RAM) for execution. Thus, this application only decrypts the core algorithm code and loads it into RAM for execution after successful authorization verification, preventing the SDK from being copied to an unauthorized MCU and running completely. Therefore, this application avoids the problems encountered in related technical solutions and effectively provides security protection for the two-wheeled vehicle embedded toolkit SDK.

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0029] First, it should be noted that the security protection method for the two-wheeled vehicle embedded toolkit SDK provided in this application embodiment is applied to the embedded SDK in the electronic control unit (ECU) of a two-wheeled vehicle. The two-wheeled vehicle can be an electric bicycle, electric motorcycle, electric scooter, or other two-wheeled vehicle with an electric drive system. The ECU can be a motor controller, battery management controller, vehicle controller, or instrument controller, etc. The MCU can be an STM32 microcontroller, GD32 microcontroller, or other microcontrollers with unique identifiers. Furthermore, this embedded SDK can be distributed by the OEM or solution provider to the supplier to implement functions such as motor control, battery status estimation, vehicle status diagnosis, and communication interaction. The external application can be an application layer program in the supplier's firmware, which calls SDK functions through the target SDK interface.

[0030] The technical solution of this application can be divided into two parts: a compilation stage and a runtime stage. The compilation stage mainly completes interface abstraction, core algorithm function obfuscation, core algorithm code encryption, and digital watermark embedding; the runtime stage mainly completes MCU authorization verification, core algorithm code decryption and loading, restricted operation mode control, digital watermark log writing, and runtime detection.

[0031] Figure 1 A flowchart illustrating a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this application embodiment. Figure 1 The diagram illustrates that during the compilation phase, the SDK undergoes interface abstraction, core algorithm function obfuscation, and core algorithm code encryption. During runtime, when an external application calls the target SDK interface, the MCU's unique identifier is authenticated. Only after successful authentication is the core algorithm code decrypted and loaded into RAM for execution. Combined with... Figure 1 As shown, the security protection method may include: S101: During the compilation phase of the embedded SDK, the embedded SDK is subjected to interface abstraction processing to obtain the target SDK interface provided to external applications.

[0032] In this step, the target SDK interface can be one or more standardized, minimalist API interfaces (such as SDK_Init()). The target SDK interface hides the internal data structures and implementation logic of the embedded SDK. It is understood that through the target SDK interface in this application, external applications can only call the functions exposed by the SDK, and cannot directly access the SDK's internal data structures, core algorithm functions, parameter lists, function call chains, and intermediate variables. This hides the internal implementation and prevents information leakage.

[0033] The following is a specific example of the target SDK interface: int MotorCtrl_Init(void); int MotorCtrl_SetSpeed(uint16_t speed); void MotorCtrl_GetStatus(MotorStatus status); or, int SDK_Init(void); int SDK_SetTargetSpeed(uint16_t targetSpeed); int SDK_GetBatterySOC(uint8_t soc); It should be noted that the interface abstraction processing in this application may include, but is not limited to: setting SDK internal functions as static functions or hiding symbols; exporting only the symbols corresponding to the target SDK interface; deleting debug symbols, comment information and internal function names to reduce information exposure; hiding structure definitions and exposing only opaque handles or abstract data types to the outside; and providing only the necessary function declarations and parameter types through header files.

[0034] S102: During the compilation phase of the embedded SDK, the core algorithm functions among the multiple functions of the embedded SDK are obfuscated to obtain the obfuscated core algorithm code.

[0035] In this step, the core algorithm functions must include at least those related to the motor control and battery state estimation of the two-wheeled vehicle. In other words, the core algorithm functions can be understood as the core control algorithm functions that directly affect vehicle performance and safety. Specifically, the core algorithm functions may include: FOC motor control functions, such as FOC_Run(); Clarke coordinate transformation functions, such as Clarke_Transform(); Park coordinate transformation functions, such as Park_Transform(); and PI control functions, such as PI_Controller(). It is understandable that FOC is the core of the two-wheeled electric vehicle's motor drive, directly affecting the vehicle's acceleration response, energy efficiency, and riding stability. If reverse engineered, attackers can tamper with the control logic, causing the motor to malfunction or replicating a high-performance drive system.

[0036] The core algorithm functions may also include: battery state of charge (SOC) estimation functions, such as `SOC_Calculate()`; coulomb integration functions, such as `Coulomb_Counting()`; and open-circuit voltage (SOC) lookup table functions, such as `OCV_SOC_Lookup()`. Understandably, the SOC algorithm determines the accuracy of the battery level display and the battery protection strategy. Leakage could lead to false battery level displays, overcharge / over-discharge risks, or be used to counterfeit battery management systems. The core algorithm functions may also include: regenerative braking energy recovery functions and ramp detection and compensation functions.

[0037] It should be noted that before performing code obfuscation on the core algorithm functions among multiple functions of the embedded SDK to obtain the obfuscated core algorithm code, this application can further identify the core algorithm functions and non-core functions related to the two-wheeled vehicle operation control from among the multiple functions of the embedded SDK. The non-core functions include at least communication protocol functions (such as the Controller Area Network (CAN) / Universal Asynchronous Receiver / Transmitter (UART) communication protocol stack) and general-purpose input / output (GPIO) port configuration functions. These non-core functions are in an unobfuscated state, thus maintaining their original state and avoiding unnecessary code bloat and decreased execution efficiency.

[0038] Thus, by obfuscating only the core algorithm functions and keeping the non-core functions unobfuscated, this application can effectively protect key algorithms such as two-wheeled vehicle motor control and battery state estimation, while reducing the code bloat and performance loss caused by full obfuscation.

[0039] The code obfuscation process in this application includes at least one of structure transformation processing, jump insertion processing, and instruction substitution processing. The specific process of "obfuscating the core algorithm functions among multiple functions of the embedded SDK to obtain the obfuscated core algorithm code" in this application is as follows: First, it should be noted that different ECUs use MCUs with different performance levels. To balance security and resource consumption, MCUs can be categorized into three levels based on their performance information: Level 1, Level 2, and Level 3. MCU performance information can include: clock speed; non-volatile flash memory capacity; runtime RAM capacity; whether it supports a memory protection unit (MPU); whether it has high computing power; and whether it has sufficient code space. Furthermore, this application can provide a compile-time configuration interface (such as macro definitions or JavaScript object markup language JSON configuration files) to support dynamic adjustment of the obfuscation level based on the target MCU's performance information.

[0040] If the microcontroller (MCU) in the ECU is a first-level MCU, then the core algorithm functions in multiple functions of the embedded SDK are subjected to jump insertion processing to obtain obfuscated core algorithm code. The first-level MCU can be a low-end MCU with limited Flash and RAM resources, such as a small-capacity MCU. For the first-level MCU, jump insertion processing is only performed on the core algorithm functions to reduce resource overhead.

[0041] If the microcontroller (MCU) in the ECU is a second-level MCU, then the core algorithm functions in multiple functions of the embedded SDK undergo structural transformation and jump insertion processing to obtain obfuscated core algorithm code. The performance information corresponding to the first-level MCU is lower than that of the second-level MCU. The second-level MCU can be a mid-range MCU, such as the STM32F0 series. For second-level MCUs, structural transformation and jump insertion processing of the core algorithm functions achieve a balance between security and resource consumption, and can keep code bloat below 30%.

[0042] If the microcontroller (MCU) in the ECU is a Level 3 MCU, then the core algorithm functions in multiple functions of the embedded SDK undergo structural transformation, jump insertion, and instruction substitution processing to obtain obfuscated core algorithm code. The performance information corresponding to Level 2 MCUs is lower than that of Level 3 MCUs. Level 3 MCUs can be high-performance MCUs. For Level 3 MCUs, structural transformation, jump insertion, and instruction substitution processing are performed on the core algorithm functions to increase the difficulty of reverse engineering. It should be noted that for higher-level MCUs (such as STM32G4), encryption and virtualization obfuscation methods can also be used, and no obfuscation methods are used in the initial debug mode. Encryption methods can be used for MCUs of any level.

[0043] In this way, the application can dynamically adjust the obfuscation intensity according to different hardware resources, achieving a dynamic balance between security, performance and cost, and avoiding the introduction of excessive code bloat or real-time performance loss on low-cost MCUs.

[0044] It should also be noted that the obfuscation strategies used in this application are all of medium strength. Medium strength can be understood as not using high-strength virtualization (such as x86 instruction emulation) to avoid causing serious performance degradation or memory overflow on Cortex-M series MCUs. This balances security and resource overhead, and is particularly suitable for low-cost MCU platforms without hardware security modules, reducing decompilation readability and controlling code bloat.

[0045] Specifically, this application can employ obfuscation techniques based on the LLVM compiler intermediate representation (IR), combined with the open-source framework OLLVM (Obfuscator-LLVM) or other obfuscation tools (such as the Themida SDK software encryption and obfuscation development kit, or the Code Virtualizer tool), to implement the following medium-strength obfuscation operations, thereby converting native instructions into custom bytecode, further increasing the difficulty of reverse engineering, and is suitable for high-end vehicles with higher security requirements.

[0046] The "performing jump insertion processing on the core algorithm functions of multiple functions in the embedded SDK to obtain obfuscated core algorithm code" in this application specifically involves: inserting invalid jump instructions or redundant judgment conditions into the execution path of the core algorithm functions to obtain obfuscated core algorithm code. The "performing structure conversion processing and jump insertion processing on the core algorithm functions of multiple functions in the embedded SDK to obtain obfuscated core algorithm code" in this application specifically involves: converting the conditional branch structure and / or loop structure in the core algorithm function into a state machine scheduling structure, and inserting invalid jump instructions or redundant judgment conditions into the execution path of the core algorithm function to obtain obfuscated core algorithm code. The "performing structure conversion processing, jump insertion processing, and instruction replacement processing on the core algorithm functions of multiple functions in the embedded SDK to obtain obfuscated core algorithm code" in this application specifically involves: converting the conditional branch structure and / or loop structure in the core algorithm function into a state machine scheduling structure, inserting invalid jump instructions or redundant judgment conditions into the execution path of the core algorithm function, and replacing the target instruction in the core algorithm function with an equivalent instruction sequence that has the same execution result as the target instruction to obtain obfuscated core algorithm code.

[0047] Among these, structure transformation processing can be understood as control flow flattening. It is implemented by converting the control structures within functions (conditional branch structures like if / else and loop structures like loop) into a state machine + scheduler model, hiding the original execution path. This increases the difficulty of static analysis, prevents logic reconstruction, and increases code size by 15%~25%. Jump insertion processing can be understood as spurious jump insertion. It is implemented by inserting never-executed jump instructions or redundant conditional judgments into critical paths, thus interfering with the decompiler's control flow graph reconstruction, increasing code size by 10%. Instruction substitution processing can be understood as replacing simple operations (such as x+1→x-(-1)) with equivalent but more complex instruction sequences, thus increasing the readability of disassembly, but having only a slight impact on code size.

[0048] Thus, by selecting a combination of jump insertion processing, structure conversion processing, and instruction replacement processing based on the MCU performance level, this application can achieve a dynamic balance between safety, code size, and operating performance, adapting to the resource constraints of low-cost two-wheeled vehicle ECUs.

[0049] S103: During the compilation phase of the embedded SDK, the obfuscated core algorithm code is encrypted to obtain the encrypted core algorithm code.

[0050] Specifically, first, obtain the base key and the unique identifier of the microcontroller (MCU) in the ECU. The base key can be read from the microcontroller's built-in electronic fuse (eFUSE). The MCU can be the MCU to which the embedded SDK will be deployed. The MCU's unique identifier is a built-in 96-bit or 128-bit identifier stored at a specific register address. The MCU's unique identifier can be obtained through the following example: uint32_t uid[3]; uid[0] = (uint32_t 0x1FFF7A10; / / Read the lower 32 bits of the UID uid[1] = (uint32_t 0x1FFF7A14; / / Middle 32 bits uid[2] = (uint32_t 0x1FFF7A18; / / High 32 bits Next, a device binding key corresponding to the MCU can be generated based on the base key and the MCU's unique identifier using a hash algorithm or key derivation algorithm. For example, the device binding key is derived_key=SHA256(eFUSE_key||MCU_UID), where derived_key represents the device binding key, eFUSE_key| represents the base key, and MCU_UID represents the MCU's unique identifier.

[0051] Finally, based on the device binding key, the obfuscated core algorithm code is symmetrically encrypted to obtain the encrypted core algorithm code, which is stored in the ECU's non-volatile flash memory. Thus, this application, by encrypting the obfuscated core algorithm code, ensures that the core algorithm code is stored in ciphertext form in the ECU's non-volatile memory, reducing the risk of static reverse engineering after the firmware is read.

[0052] S104: During the operation phase of the embedded SDK, in response to the external application's call to the target SDK interface, based on a preset authorization list, the unique identifier of the microcontroller MCU in the ECU is authorized and verified to obtain the authorization verification result of the MCU.

[0053] In this step, during the SDK runtime phase, when an external application calls the target SDK interface, the SDK responds by reading the unique identifier of the MCU in the ECU and performing authorization verification based on a preset authorization list. This prevents the SDK from being illegally ported to unauthorized devices. The preset authorization list can be stored in an encrypted configuration area. This list can store the unique identifiers of one or more authorized MCUs, or it can store the hash values ​​of the unique identifiers of the authorized MCUs. Authorization verification can be performed using byte-by-byte comparison or hash comparison. In this way, this application can bind the SDK to an authorized MCU, preventing the same SDK firmware from being copied and run completely in an unauthorized ECU.

[0054] If the MCU does not have a unique identifier, the 128-bit key burned in eFUSE can be used as the binding basis; or it can be combined with external storage characteristics (such as the serial number of the SPI Flash serial peripheral interface flash chip) for composite verification to improve flexibility.

[0055] It should be noted that after performing authorization verification processing on the unique identifier of the microcontroller MCU in the ECU based on the preset authorization list and obtaining the authorization verification result of the MCU, this application can also perform the following process: if the authorization verification result indicates that the MCU authorization verification failed, then a restricted operation mode is started, wherein the restricted operation mode includes at least limiting the maximum output speed of the motor and the communication frequency of the two-wheeled vehicle.

[0056] Understandably, if the authorization verification result indicates that the MCU has failed verification, it means that the current SDK may have been copied to an unauthorized ECU, or the current device is not within the authorized scope. In this case, the SDK initiates a restricted operating mode. The restricted operating mode includes at least limiting the maximum output speed of the two-wheeled vehicle's motor and the communication frequency. For example, the maximum output speed of the motor can be limited to a certain percentage of the rated speed, such as 50%; the communication message sending frequency can be reduced, some function interface calls can be restricted, or abnormal states can be logged. Furthermore, the restricted operating mode can also include prohibiting calls to the target core algorithm function; limiting the motor output torque; restricting the regenerative braking function; logging authorization failures; and entering a locked state after multiple verification failures (first time: warning; second time: speed limit; third time: lockout).

[0057] Therefore, compared to directly shutting down the system, the restricted operation mode is more suitable for vehicle control scenarios. This is because if the motor output of a two-wheeled vehicle suddenly stops during operation, it may affect riding safety. This degradation method can reduce the profits from illegal use while minimizing the impact on vehicle safety.

[0058] S105: If the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain the obfuscated core algorithm code, and the obfuscated core algorithm code is loaded into the runtime memory RAM for execution.

[0059] In this step, the core function is stored encrypted and decrypted in RAM during runtime to prevent static analysis. The encrypted core algorithm code can be decrypted using the device's binding key to obtain the obfuscated core algorithm code. The decryption process is illustrated in the code below: aes_context ctx; aes_setkey_dec(&ctx, secret_key, 128); aes_crypt_ecb(&ctx, AES_DECRYPT, encrypted_foc_bin, decrypted_buf); memcpy(RAM_EXEC_ADDR, decrypted_buf, FOC_SIZE); This application can work with the MCU's memory protection unit (MPU) to set the area in RAM used for executing core algorithm code as an execution-only area or a protected area, thereby reducing the risk of runtime memory being read or tampered with. After execution, the temporary decryption buffer in RAM can also be cleared to reduce plaintext code residue. In this way, the SDK's core algorithm code is stored in encrypted form in non-volatile memory and is only decrypted and loaded for execution when running on an authorized MCU, thus forming a protection mechanism of "store encryption, runtime decryption, and hardware binding".

[0060] In one feasible implementation, during the runtime phase of the embedded SDK, in response to an external application's call to the target SDK interface, the unique identifier of the microcontroller (MCU) in the ECU is verified based on a preset authorization list. Before obtaining the MCU's authorization verification result, the following process may also be performed: During the compilation phase of the embedded SDK, a unique digital watermark is generated based on supplier information, project identification information, and compilation time information. Supplier information can be a supplier number or supplier name (e.g., OEM-A001, ODM-B002), project identification information can be a vehicle project, model project, or SDK project identifier (e.g., E26-Scooter-Pro), and compilation time information can be the build date or a build timestamp accurate to the second. This application can use lightweight hashing to generate a 64-bit watermark fingerprint and supports optional encryption to prevent plaintext exposure. The generated unique digital watermark can be represented as: OEM:E-BIKE-SDK-V2.1-SUPP_MOTOR_A-20260515 (Product-Version-Supplier-Date).

[0061] The unique digital watermark can then be linked to the firmware image of the ECU corresponding to the embedded SDK. This unique digital watermark identifies the vendor and project origin of the embedded SDK. Specifically, the digital watermark string can be dynamically generated using a compilation script, for example, the CMake script example: `add_definitions(-DBUILD_FINGERPRINT="OEM:E-BIKE-V2.1-SUPP_A-20260516")`.

[0062] Then, the watermark string is placed into the .rodata read-only data segment of the firmware using __attribute__((section(".rodata"))), making it part of the firmware image. In other words, it is packaged into the .rodata segment, and the final generated .bin or .hex file contains this string (i.e., the firmware image contains this unique digital watermark). For example, an example of defining a read-only variable in C code: const char__build_fingerprint__[] __attribute__((section(".rodata"))) =BUILD_FINGERPRINT; It should be noted that to prevent compiler optimizations, the following methods can be used to ensure that the string is not deleted: disable -fmerge-constants or -ffunction-sections; or preserve the symbol through the linker script: KEEP( (.rodata.__fingerprint)).

[0063] like Figure 2 As shown, Figure 2This document presents a flowchart illustrating the watermark embedding process in a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this embodiment. Figure 2 First, the source code file corresponding to the SDK is obtained. Then, a unique digital watermark is generated through a compilation script. Next, the unique digital watermark is defined as a global read-only constant using `__attribute__((section(".rodata")))` and stored in the `.rodata` read-only data segment of the firmware. Finally, the final firmware image is packaged, thus linking the unique digital watermark to the firmware image of the ECU corresponding to the embedded SDK.

[0064] Thus, by generating and embedding a unique digital watermark containing supplier information, project identification information, and compilation time information, this application enables the identification of the supplier, project, and compilation time corresponding to the firmware image after subsequent SDK leakage or infringing use, thereby tracing the source of the leakage.

[0065] It should be noted that, in addition to directly placing the digital watermark in the read-only data segment, the digital watermark can also be embedded in the following ways: constant replacement: replacing constants that have no functional impact (such as debug strings, unused arrays) with watermark data; function prologue insertion: inserting a sequence of no-operation instructions (NOP) that does not affect the logic at the beginning of the function, and encoding the watermark bits according to the pattern; jump offset encoding: using the offset relative to the jump instruction to steganographically write the watermark information.

[0066] Furthermore, in supply chain scenarios, different suppliers, projects, and build batches can correspond to different watermarks. Vehicle manufacturers can assign different watermarks and keys to different roles. For example, OEMs can hold a master key and project sub-keys, meaning they receive the complete watermark SDK and can view all project watermarks; ODMs can generate only watermarks for specific projects, holding project-level keys and binding them to the corresponding project identifier; contract manufacturers can only compile firmware with injected watermarks, meaning they have no keys and only perform compilation; third-party suppliers can use temporary or de-identified watermark versions, i.e., temporary keys, valid for a limited time. This application employs Hierarchical Key Derivation (HKDF), deriving keys for each role from the root key to prevent lateral privilege escalation. Thus, through a unique digital watermark, the corresponding supplier and project source can be identified when the SDK is leaked.

[0067] Thus, this application, through a differentiated digital watermarking mechanism for multi-role supply chains, deeply integrates supply chain role management with digital watermarking technology, achieving a precise traceability mechanism of "whoever compiles it is responsible for it," and significantly improving SDK copyright protection capabilities. It breaks through the limitations of traditional watermarks' "one code for all," enabling precise distribution based on supplier roles, key isolation, and leakage tracing, forming a complete closed-loop watermark lifecycle management system.

[0068] Furthermore, this application can extract the target digital watermark from the firmware image to be tested and perform comparison and tracing when the embedded SDK is suspected of being leaked or infringed. Specifically, firstly, the firmware image to be tested is obtained, which is a firmware image read from the ECU to be tested. It can be read from the ECU to be tested through the on-board fault diagnosis OBD interface, JTAG joint test working group debugging interface, SPI Flash serial peripheral interface flash memory chip, etc. The firmware image to be tested is a binary file such as .bin.

[0069] Next, the target digital watermark can be extracted from the firmware image to be tested. This can be done by loading the firmware image using a disassembler. The loading process involves setting the correct architecture (e.g., ARM Cortex-M) and firmware load address (usually 0x08000000) to correctly identify the firmware's memory segments and locate the read-only segment where the watermark is stored. The target digital watermark is then extracted from this read-only data segment. This can be done through the tool's built-in string window or by using commands to search for the target digital watermark, for example: `strings firmware.bin|grep "OEM:E-BIKE-SDK"`. Alternatively, the target digital watermark can be graphically retrieved using the open-source reverse engineering tool Ghidra, for example: `Search>ForStrings...→enter "OEM:E-BIKE-SDK"`, to locate the target digital watermark in the `.rodata` segment.

[0070] Next, the target digital watermark is compared with the digital watermarks in the preset watermark database to obtain the watermark comparison result. The preset watermark database can record the following information: digital watermark information; supplier information; project identification information; compilation time information; SDK version; build batch; distribution target; distribution time; and authorization scope.

[0071] Finally, based on the watermark comparison results, the supplier information, project identification information, and compilation time information corresponding to the firmware image to be tested are determined. Understandably, when the target digital watermark successfully matches a digital watermark in the preset watermark database, the target digital watermark can be parsed (fields parsed by delimiters), at least the supplier information, project identification information, and compilation time information corresponding to the firmware image to be tested can be obtained, and this information can be used as a traceability report.

[0072] like Figure 3 As shown, Figure 3 This document presents a flowchart illustrating the watermark extraction process in a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this embodiment of the application. Figure 3First, the firmware image to be tested is obtained. Then, the target digital watermark is extracted from the firmware image. When the target digital watermark matches the digital watermark in the preset watermark database, the target digital watermark can be parsed to obtain a traceability report based on the supplier information, project identification information and compilation time information corresponding to the firmware image to be tested.

[0073] Thus, by generating and embedding a unique digital watermark containing supplier information, project identification information, and compilation time information, and combining the watermark extraction and database comparison process, this application can determine the supplier, project, and compilation time corresponding to the firmware image after the SDK is leaked or used infringingly, thereby achieving traceability of the source of the leak.

[0074] Furthermore, after performing the following steps in this application: if the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain the obfuscated core algorithm code, and the obfuscated core algorithm code is loaded into the runtime memory RAM for execution: First, a unique digital watermark corresponding to the embedded SDK is written to the log. This log can be stored in the ECU's Flash log area, and the watermark content can be encrypted using a simple XOR algorithm to prevent direct searching. After writing to the log, write protection can be enabled for the log area, or a checksum can be stored to detect tampering. The integrity of the watermark log can be verified during startup. The log can also be embedded in communication protocol response frames using encryption. For example, when the CAN diagnostic service on the Controller Area Network (CAN) bus reads a specific data identifier (DID) in 0x22, the returned data stream contains encoded watermark information, which requires specialized tools to decode and extract, enhancing concealment.

[0075] At the same time, a runtime detection task is started. Understandably, during the operation of the embedded SDK, a background task is started to continuously monitor the status of the joint test group's JTAG / serial line SWD debugging interface. If an anomaly occurs, the event is recorded or the performance is gradually degraded. This can detect debugging behavior and prevent dynamic analysis.

[0076] Specifically, runtime detection tasks are used to check the connection status of the ECU's debug interface and / or the integrity of the operating environment to obtain runtime detection results. This can be understood as reading the MCU debug registers to check the connection status of hardware debug interfaces such as JTAG and SWD, while simultaneously verifying the integrity of the overall operating environment to generate runtime detection results. Taking the STM32 platform as an example, the DBGMCU register can be read to determine whether a debugger is connected and whether debug mode is enabled. The operating environment integrity detection includes: verifying whether the interrupt vector table has been tampered with, verifying the hash of critical code segments, detecting stack boundary violations, verifying read / write operations of the decryption algorithm area in RAM, and detecting critical function entry jump patches. Verification is achieved by calculating the hash of critical areas in real time and comparing it with a preset benchmark value. The detection cycle can be configured to once per second.

[0077] If the runtime detection results indicate that the ECU has an abnormal debug interface connection and / or an abnormal operating environment integrity, the abnormal event is recorded. The recorded content includes: abnormal type, event occurrence time, MCU unique identifier, SDK digital watermark, number of debug tests, environment integrity verification results, and real-time vehicle operating status. In addition to recording abnormal events, this application can also trigger degraded operation, limit motor output, close some SDK interfaces, or enter a locked state. Furthermore, in high-risk scenarios, a circuit breaker mechanism can be triggered to permanently lock the SDK function, requiring the OEM to send an unlock command through a secure channel to restore it. This is suitable for scenarios that strictly prevent counterfeiting.

[0078] Thus, by writing digital watermark logs during the runtime phase and starting runtime detection tasks, this application can detect abnormalities in the connection status of the debugging interface and / or the integrity of the runtime environment, and record abnormal events, thereby enhancing the SDK's ability to detect dynamic debugging and runtime tampering.

[0079] like Figure 4 As shown, Figure 4 This is a flowchart illustrating the SDK runtime phase of a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this application embodiment. Figure 4First, in response to external applications calling the target SDK interface, the unique identifier of the microcontroller (MCU) in the ECU is verified based on a pre-defined authorization list to obtain the MCU's authorization verification result. Then, if the authorization verification result indicates that the MCU authorization verification failed, a restricted operating mode is initiated; otherwise, if the authorization verification result indicates that the MCU authorization verification passed, the encrypted core algorithm code is decrypted to obtain obfuscated core algorithm code, which is then loaded into runtime memory (RAM) for execution. Additionally, the unique digital watermark corresponding to the embedded SDK is written to the log, and a runtime detection task is initiated. If the runtime detection result indicates that the ECU does not have debug interface connection abnormalities and / or runtime environment integrity abnormalities, it means the SDK is operating normally. In other words, when hardware binding verification is successful, dynamic decryption is successfully executed, watermark writing is successful, and runtime detection is successful, the SDK enters a normal service state.

[0080] like Figure 5 As shown, Figure 5 This diagram illustrates the implementation architecture of a security protection method for a two-wheeled vehicle embedded toolkit SDK provided in this application. The overall architecture includes an application layer, a security protection layer, and a target hardware layer. In response to calls to the target SDK interface from an external application, the lower-level security protection layer performs a verification process. The security protection layer integrates three core security capabilities: selective code obfuscation and hardening during the compilation phase, runtime authorization and dynamic decryption based on MCU hardware binding, and compiler-injected digital watermarking for traceability. The underlying target hardware layer provides a unique MCU identifier and an independent watermark log storage partition, providing hardware support for all upper-level security logic.

[0081] In summary, the embodiments of this application are applied to the embedded SDK protection scenario of electric two-wheeled vehicle motor controllers. This SDK is provided by the vehicle manufacturer to the motor supplier to achieve standardized integration of motor control algorithms, preventing the SDK from being decompiled, illegally copied, or used in unauthorized projects without increasing hardware costs. It should be noted that the SDK is not integrated into the supplier's firmware but runs independently in the OEM's own security coprocessor. The main control MCU only calls services through encrypted instructions, achieving physical-level isolation, suitable for high-value vehicle models.

[0082] Specifically, during the SDK compilation and build phase, a system integration code obfuscation toolchain is built based on CMake, and the security mechanism is enabled in a controlled manner through compilation macros. This application adopts a differentiated and precise obfuscation strategy, performing code obfuscation only on core algorithm functions such as motor control and battery state estimation, while retaining the original code structure for non-core functions, thus avoiding excessive expansion of the overall code size. Actual testing shows that the overall code expansion rate of this solution can be controlled within 12% to 15%, making it compatible with low-cost MCUs with flash memory capacities less than 128KB, especially 64KB flash memory, without interfering with existing business functions and the real-time performance of the electronic control system. The main control cycle fluctuation is less than 5%, demonstrating extremely strong engineering adaptability and stability.

[0083] Simultaneously, a watermark string is dynamically injected into the compilation script, in the format: "OEM:E-BIKE-SDK-V2.1.0-SUPP_MOTOR_X-YYYYMMDD", where SUPP_MOTOR_X is a unique supplier code. This string is stored in a read-only data segment and written to a dedicated log sector (write-protected) of Flash memory via the log_fingerprint() function during SDK initialization for subsequent traceability.

[0084] During the SDK runtime phase, when an external application calls the target SDK interface SDK_Init(), the following steps are executed in sequence: read the MCU's built-in unique ID and compare it with the preset authorization list; decrypt the encrypted core code segment and execute it in RAM; start a runtime detection task to debug the interface (such as SWD) status; if any verification fails, the SDK enters a restricted mode: the maximum speed of the motor is limited to 50% of the rated value, and abnormal events are continuously recorded.

[0085] As can be seen, this application does not require high-end security devices such as hardware security chips. Relying on a lightweight, purely software-based protection architecture, it is suitable for cost-sensitive application scenarios in two-wheeled vehicles. Simultaneously, it forms a multi-layered collaborative security system consisting of static hardening during the compilation phase, dynamic protection during the runtime phase, and leakage tracing and accountability. On the one hand, through interface abstraction, differentiated code obfuscation, and device binding encryption, it effectively prevents the SDK code from being decompiled, reverse-analyzed, and illegally copied and stolen. On the other hand, through a unique digital watermark retention and tracing comparison mechanism, in the event of SDK leakage or firmware infringement, by reading the ECU firmware image under test and extracting and comparing the watermark information, it can accurately locate the supplier, project, and compilation time corresponding to the leakage, achieving a deep integration of technical protection and legal accountability. While ensuring the real-time operation and device compatibility of the two-wheeled vehicle electronic control system, it significantly improves the overall security protection level of the embedded SDK.

[0086] Based on the security protection method for the two-wheeled vehicle embedded toolkit SDK provided in the above embodiments, this application embodiment can also provide a security protection device for the two-wheeled vehicle embedded toolkit SDK. The security protection device for the two-wheeled vehicle embedded toolkit SDK will be described below with reference to the embodiments and accompanying drawings.

[0087] Figure 6 This is a structural schematic diagram of a safety protection device for a two-wheeled vehicle embedded toolkit SDK provided in an embodiment of this application. (Combined with...) Figure 6 As shown in the embodiment of this application, the security protection device for the two-wheeled vehicle embedded toolkit SDK is applied to the embedded SDK in the two-wheeled vehicle electronic control unit (ECU). The security protection device for the two-wheeled vehicle embedded toolkit SDK includes: The interface abstraction processing unit 601 is used to perform interface abstraction processing on the embedded SDK during the compilation stage of the embedded SDK to obtain the target SDK interface provided to external applications, wherein the target SDK interface has hidden the internal data structure and implementation logic of the embedded SDK; The code obfuscation processing unit 602 is used to perform code obfuscation processing on the core algorithm functions among multiple functions of the embedded SDK during the compilation stage of the embedded SDK to obtain obfuscated core algorithm code, wherein the core algorithm functions include at least the algorithm functions related to two-wheeled vehicle motor control and battery state estimation. The core code encryption unit 603 is used to encrypt the obfuscated core algorithm code during the compilation stage of the embedded SDK to obtain the encrypted core algorithm code. The authorization verification processing unit 604 is used to, during the running phase of the embedded SDK, respond to the call of the target SDK interface by the external application, perform authorization verification processing on the unique identifier of the microcontroller MCU in the ECU based on a preset authorization list, and obtain the authorization verification result of the MCU; The core code decryption unit 605 is used to decrypt the encrypted core algorithm code if the authorization verification result indicates that the MCU authorization verification is successful, to obtain the obfuscated core algorithm code, and to load the obfuscated core algorithm code into the runtime memory RAM for execution.

[0088] In one feasible implementation, the apparatus further includes an algorithm function determination unit: The algorithm function determination unit is used to determine the core algorithm functions and non-core functions related to the operation control of the two-wheeled vehicle from multiple functions of the embedded SDK, wherein the non-core functions include at least communication protocol functions and the non-core functions are in a non-obfuscated state; The code obfuscation process includes at least one of structure conversion processing, jump insertion processing, and instruction substitution processing; the code obfuscation processing unit 602 is specifically used for: If the microcontroller (MCU) in the ECU is a first-level MCU, then the core algorithm function in the multiple functions of the embedded SDK is subjected to jump insertion processing to obtain the obfuscated core algorithm code; If the microcontroller (MCU) in the ECU is a second-level MCU, then the core algorithm functions in the multiple functions of the embedded SDK are subjected to structural transformation and jump insertion processing to obtain obfuscated core algorithm code, wherein the performance information corresponding to the first-level MCU is lower than the performance information corresponding to the second-level MCU; If the microcontroller (MCU) in the ECU is a third-level MCU, then the core algorithm functions in the multiple functions of the embedded SDK are subjected to structural conversion processing, jump insertion processing, and instruction replacement processing to obtain obfuscated core algorithm code, wherein the performance information corresponding to the second-level MCU is lower than the performance information corresponding to the third-level MCU.

[0089] In one feasible implementation, the code obfuscation processing unit 602 is specifically used for: Invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function to obtain obfuscated core algorithm code; The process of performing structural transformation and jump insertion processing on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: The conditional branch structure and / or loop structure in the core algorithm function are converted into a state machine scheduling structure, and invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function to obtain the obfuscated core algorithm code. The process of performing structural transformation, jump insertion, and instruction substitution on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: The conditional branch structure and / or loop structure in the core algorithm function are converted into a state machine scheduling structure, and invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function. The target instruction in the core algorithm function is replaced with an equivalent instruction sequence that has the same execution result as the target instruction, thus obtaining the obfuscated core algorithm code.

[0090] In one feasible implementation, the core code encryption unit 603 is specifically used for: Obtain the base key and the unique identifier of the microcontroller (MCU) in the ECU; Based on the base key and the unique identifier of the MCU, a device binding key corresponding to the MCU is generated; Based on the device binding key, the obfuscated core algorithm code is symmetrically encrypted to obtain the encrypted core algorithm code, wherein the encrypted core algorithm code is stored in the non-volatile memory of the ECU.

[0091] In one feasible implementation, the device further includes an operation mode activation unit: The operation mode activation unit is specifically used to activate a restricted operation mode if the authorization verification result indicates that the MCU authorization verification has failed. The restricted operation mode includes at least limiting the maximum output speed of the motor and the communication frequency of the two-wheeled vehicle.

[0092] In one feasible implementation, the apparatus further includes a digital watermark generation unit, which is specifically used for: During the compilation phase of the embedded SDK, a unique digital watermark is generated based on supplier information, project identification information, and compilation time information. The unique digital watermark is linked to the firmware image of the ECU corresponding to the embedded SDK, wherein the unique digital watermark is used to identify the supplier and project source of the embedded SDK.

[0093] In one feasible implementation, the device further includes a digital watermark extraction unit, which is specifically used for: Obtain the firmware image to be tested, wherein the firmware image to be tested is the firmware image read from the ECU to be tested; Extract the target digital watermark from the firmware image to be detected; The target digital watermark is compared with the digital watermarks in the preset watermark database to obtain the watermark comparison result. Based on the watermark comparison results, the supplier information, project identification information, and compilation time information corresponding to the firmware image to be detected are determined.

[0094] In one possible implementation, the apparatus further includes a detection task initiation unit, which is specifically used for: Write the unique digital watermark corresponding to the embedded SDK into the log and start the runtime detection task; The runtime detection task detects the debug interface connection status and / or the integrity of the operating environment of the ECU, and obtains the runtime detection results. If the runtime detection results indicate that the ECU has a debug interface connection abnormality and / or an operating environment integrity abnormality, then the abnormal event is recorded.

[0095] The security protection device for the two-wheeled vehicle embedded toolkit SDK provided in this application embodiment has the same beneficial effects as the security protection method for the two-wheeled vehicle embedded toolkit SDK provided in the above embodiment, and will not be described again here.

[0096] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0097] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A security protection method for a two-wheeled vehicle embedded toolkit SDK, characterized in that, An embedded SDK applied to the electronic control unit (ECU) of a two-wheeled vehicle, the method comprising: During the compilation phase of the embedded SDK, the embedded SDK undergoes interface abstraction to obtain a target SDK interface provided to external applications, wherein the target SDK interface has hidden the internal data structure and implementation logic of the embedded SDK; During the compilation phase of the embedded SDK, the core algorithm functions in multiple functions of the embedded SDK are obfuscated to obtain obfuscated core algorithm code. The core algorithm functions include at least the algorithm functions related to the two-wheeled vehicle motor control and battery state estimation. During the compilation phase of the embedded SDK, the obfuscated core algorithm code is encrypted to obtain the encrypted core algorithm code. During the runtime phase of the embedded SDK, in response to the external application's call to the target SDK interface, the unique identifier of the microcontroller (MCU) in the ECU is verified based on a preset authorization list to obtain the authorization verification result of the MCU. If the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain the obfuscated core algorithm code, and the obfuscated core algorithm code is loaded into the runtime memory RAM for execution.

2. The method according to claim 1, characterized in that, Before obfuscating the core algorithm functions among the multiple functions of the embedded SDK to obtain the obfuscated core algorithm code, the method further includes: From the multiple functions of the embedded SDK, core algorithm functions and non-core functions related to the operation control of the two-wheeled vehicle are determined, wherein the non-core functions include at least communication protocol functions, and the non-core functions are in a non-obfuscated state; The code obfuscation process includes at least one of structure transformation processing, jump insertion processing, and instruction substitution processing; the code obfuscation process performed on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: If the microcontroller (MCU) in the ECU is a first-level MCU, then the core algorithm function in the multiple functions of the embedded SDK is subjected to jump insertion processing to obtain the obfuscated core algorithm code; If the microcontroller (MCU) in the ECU is a second-level MCU, then the core algorithm functions in the multiple functions of the embedded SDK are subjected to structural transformation and jump insertion processing to obtain obfuscated core algorithm code, wherein the performance information corresponding to the first-level MCU is lower than the performance information corresponding to the second-level MCU; If the microcontroller (MCU) in the ECU is a third-level MCU, then the core algorithm functions in the multiple functions of the embedded SDK are subjected to structural conversion processing, jump insertion processing, and instruction replacement processing to obtain obfuscated core algorithm code, wherein the performance information corresponding to the second-level MCU is lower than the performance information corresponding to the third-level MCU.

3. The method according to claim 2, characterized in that, The step of performing jump insertion processing on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: Invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function to obtain obfuscated core algorithm code; The process of performing structural transformation and jump insertion processing on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: The conditional branch structure and / or loop structure in the core algorithm function are converted into a state machine scheduling structure, and invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function to obtain the obfuscated core algorithm code. The process of performing structural transformation, jump insertion, and instruction substitution on the core algorithm functions among multiple functions of the embedded SDK to obtain obfuscated core algorithm code includes: The conditional branch structure and / or loop structure in the core algorithm function are converted into a state machine scheduling structure, and invalid jump instructions or redundant judgment conditions are inserted into the execution path of the core algorithm function. The target instruction in the core algorithm function is replaced with an equivalent instruction sequence that has the same execution result as the target instruction, thus obtaining the obfuscated core algorithm code.

4. The method according to claim 1, characterized in that, The step of encrypting the obfuscated core algorithm code to obtain the encrypted core algorithm code includes: Obtain the base key and the unique identifier of the microcontroller (MCU) in the ECU; Based on the base key and the unique identifier of the MCU, a device binding key corresponding to the MCU is generated; Based on the device binding key, the obfuscated core algorithm code is symmetrically encrypted to obtain the encrypted core algorithm code, wherein the encrypted core algorithm code is stored in the non-volatile memory of the ECU.

5. The method according to claim 1, characterized in that, After performing authorization verification processing on the unique identifier of the microcontroller (MCU) in the ECU based on the preset authorization list, and obtaining the authorization verification result of the MCU, the method further includes: If the authorization verification result indicates that the MCU authorization verification has failed, a restricted operation mode is initiated, wherein the restricted operation mode includes at least limiting the maximum output speed of the motor and the communication frequency of the two-wheeled vehicle.

6. The method according to claim 1, characterized in that, During the runtime phase of the embedded SDK, in response to the external application's call to the target SDK interface, based on a preset authorization list, the method further includes performing authorization verification processing on the unique identifier of the microcontroller (MCU) in the ECU, and before obtaining the authorization verification result of the MCU, the method further includes: During the compilation phase of the embedded SDK, a unique digital watermark is generated based on supplier information, project identification information, and compilation time information. The unique digital watermark is linked to the firmware image of the ECU corresponding to the embedded SDK, wherein the unique digital watermark is used to identify the supplier and project source of the embedded SDK.

7. The method according to claim 6, characterized in that, The method further includes: Obtain the firmware image to be tested, wherein the firmware image to be tested is the firmware image read from the ECU to be tested; Extract the target digital watermark from the firmware image to be detected; The target digital watermark is compared with the digital watermarks in the preset watermark database to obtain the watermark comparison result. Based on the watermark comparison results, the supplier information, project identification information, and compilation time information corresponding to the firmware image to be detected are determined.

8. The method according to claim 6, characterized in that, After the authorization verification result indicates that the MCU authorization verification is successful, the encrypted core algorithm code is decrypted to obtain the obfuscated core algorithm code, and the obfuscated core algorithm code is loaded into the runtime memory RAM for execution, the method further includes: Write the unique digital watermark corresponding to the embedded SDK into the log and start the runtime detection task; The runtime detection task detects the debug interface connection status and / or the integrity of the operating environment of the ECU, and obtains the runtime detection results. If the runtime detection results indicate that the ECU has a debug interface connection abnormality and / or an operating environment integrity abnormality, then the abnormal event is recorded.

9. A safety protection device for a two-wheeled vehicle embedded toolkit SDK, characterized in that, An embedded SDK for use in the electronic control unit (ECU) of a two-wheeled vehicle, the device comprising: An interface abstraction processing unit is used to perform interface abstraction processing on the embedded SDK during the compilation phase of the embedded SDK to obtain a target SDK interface provided to external applications, wherein the target SDK interface has hidden the internal data structure and implementation logic of the embedded SDK; The code obfuscation processing unit is used to perform code obfuscation processing on the core algorithm functions among multiple functions of the embedded SDK during the compilation stage of the embedded SDK to obtain obfuscated core algorithm code, wherein the core algorithm functions include at least the algorithm functions related to two-wheeled vehicle motor control and battery state estimation. The core code encryption unit is used to encrypt the obfuscated core algorithm code during the compilation phase of the embedded SDK to obtain the encrypted core algorithm code. The authorization verification processing unit is used to, during the runtime phase of the embedded SDK, respond to the call of the target SDK interface by the external application, perform authorization verification processing on the unique identifier of the microcontroller MCU in the ECU based on a preset authorization list, and obtain the authorization verification result of the MCU; The core code decryption unit is used to decrypt the encrypted core algorithm code if the authorization verification result indicates that the MCU authorization verification is successful, to obtain the obfuscated core algorithm code, and to load the obfuscated core algorithm code into the runtime memory RAM for execution.

10. A two-wheeled vehicle, characterized in that, Including the security protection method for the two-wheeled vehicle embedded toolkit SDK as described in any one of claims 1-8.

Images