Method and apparatus for verifying an application program of a microcontroller

Abstract

The embodiment of the present application provides a kind of microcontroller's application program's verification method and device, wherein the method comprises: obtaining the control state of the bootstrap program in microcontroller, wherein the control state is used to indicate whether the first application program compiled by non-CI system is allowed to be written;In the case where the control state is the forbidden state for indicating that the first application program is forbidden to be written, the application category of the to-be-written application is verified according to the identity of the to-be-written application, wherein the identity is used to identify whether the application program is compiled by CI system;In the case where it is determined that the application category is the first application program, the writing operation on the to-be-written application is prohibited to be executed.

Description

Technical Field

[0001] This application relates to the field of embedded systems, and more specifically, to a method and apparatus for verifying applications of a microcontroller. Background Technology

[0002] In the embedded systems field, programs / software often consist of a bootloader and an application (App). The bootloader is burned into the chip at the PCB (Printed Circuit Board) during manufacturing and generally cannot be changed during development and debugging. The App is updated and rewritten through the bootloader. Apps are frequently upgraded and modified during development and operation. For Apps with special requirements, such as those for the 61508, the development process must conform to specifications, and the modification process must have a fixed configuration. The common practice is for integration engineers or CI (Continuous Integration) systems to compile the code. The problem is that neither testing, after-sales, nor customers have a very intuitive way to distinguish whether the program is strictly configured according to the compilation process, which may lead to potential product risks. To address this, a one-size-fits-all approach could be adopted: all external software would be released through the CI system (because once the CI system is set up, only the administrator can modify it). However, this would also cause inconvenience, because embedded software development differs from conventional software development; it requires hardware testing, and releasing via CI for every modification and debugging would be inefficient.

[0003] In traditional embedded development, Boot struggles to distinguish between CI compilation and local compilation. Forcing a full CI release reduces efficiency, while complete openness poses compliance risks. Currently, no effective solution has been proposed. Summary of the Invention

[0004] This application provides a method and apparatus for verifying microcontroller applications, which at least solves the problem in traditional embedded development where Boot cannot distinguish between CI compilation and local compilation, and where mandatory full CI release reduces efficiency while complete openness poses compliance risks.

[0005] According to one embodiment of this application, a method for verifying an application of a microcontroller is provided, comprising: obtaining the control state of a bootloader in the microcontroller, wherein the control state is used to indicate whether flashing a first application compiled by a non-CI system is allowed; when the control state is a prohibited state indicating that flashing the first application is prohibited, verifying the application category of the application to be flashed according to the identity identifier of the application to be flashed, wherein the identity identifier is used to identify whether the application is compiled by a CI system; and when the application category is determined to be the first application, prohibiting the flashing operation of the application to be flashed.

[0006] According to another embodiment of this application, a microcontroller application verification device is provided, comprising: an acquisition module, configured to acquire the control state of a bootloader in the microcontroller, wherein the control state is used to indicate whether flashing a first application compiled by a non-CI system is permitted; a verification module, configured to verify the application category of the application to be flashed based on the identity identifier of the application to be flashed when the control state is a prohibition state indicating that flashing the first application is prohibited, wherein the identity identifier is used to identify whether the application is compiled by a CI system; and a prohibition module, configured to prohibit the flashing operation of the application to be flashed when the application category is determined to be the first application.

[0007] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0008] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0009] This application first obtains the control state of the bootloader in the microcontroller to determine whether the current microcontroller allows flashing a first application compiled by a non-CI system (i.e., an App compiled by a non-CI system). If the control state is determined to be a prohibited state indicating that flashing the first application is prohibited, the application category is determined according to the identity identifier of the application to be flashed to the microcontroller. The identity identifier is used to indicate whether the application was compiled by the CI system. If the application category is determined to be the first application, flashing the application to be flashed is prohibited. By adopting the above scheme, this application, by embedding a controlled switch in the bootloader, controls whether flashing Apps compiled by a non-CI system is allowed by controlling the state of the switch. While ensuring that all externally released software originates from the CI system to comply with specifications, it allows flexible flashing of non-CI compiled software during the development and debugging phase, achieving a balance between quality control and development efficiency. This solves the problem in related technologies where, in traditional embedded development, it is difficult for the bootloader to distinguish between CI compilation and local compilation. Forcing full CI release reduces efficiency, while complete openness poses compliance risks. Attached Figure Description

[0010] Figure 1 This is a hardware structure block diagram of a microcontroller for verifying an application program of a microcontroller, according to an embodiment of this application.

[0011] Figure 2 This is a flowchart of a verification method for a microcontroller application according to an embodiment of this application;

[0012] Figure 3 This is a structural block diagram of a microcontroller application verification device according to an embodiment of this application. Detailed Implementation

[0013] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0015] The methods and embodiments provided in this application can be executed in a microcontroller or similar computing device. Taking running on a microcontroller as an example, Figure 1 This is a hardware block diagram of a microcontroller, illustrating a method for verifying microcontroller applications according to an embodiment of this application. Figure 1 As shown, a microcontroller may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The microcontroller may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the microcontroller described above. For example, the microcontroller may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0016] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the verification method of the microcontroller's application in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the microcontroller via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0017] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the microcontroller's communication vendor. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0018] This embodiment provides a method for verifying applications of a microcontroller, applied to the aforementioned microcontroller. Figure 2 This is a flowchart of a verification method for a microcontroller application according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0019] Step S202: Obtain the control state of the bootloader in the microcontroller, wherein the control state is used to indicate whether it is allowed to flash the first application compiled by a non-CI system;

[0020] It should be noted that the bootloader is the first code executed after the microcontroller is powered on, in order to complete the hardware initialization and system environment preparation before the operating system or main application is loaded.

[0021] It should be noted that the App compiled by the CI system refers to the application firmware built, tested and generated through a continuous integration automated pipeline. In embedded software development, it is not only a compiled software, but also represents a standardized, traceable and highly reliable software generation method.

[0022] CI is a software development practice in which developers frequently merge code into a shared repository, and each merge triggers an automated build and testing process.

[0023] Step S204: When the control state is a prohibited state for indicating that the first application is prohibited from being flashed, verify the application category of the application to be flashed according to the identity identifier of the application to be flashed, wherein the identity identifier is used to identify whether the application was compiled by the CI system.

[0024] Step S206: If the application category is determined to be the first application, the flashing operation on the application to be flashed is prohibited.

[0025] Through the above steps, the control state of the bootloader in the microcontroller is first obtained to determine whether the current microcontroller allows flashing of the first application compiled by a non-CI system (i.e., an App compiled by a non-CI system). If the control state is determined to be a prohibited state indicating that flashing the first application is prohibited, the application category is determined according to the identity identifier of the application to be flashed to the microcontroller. The identity identifier is used to indicate whether the application was compiled by the CI system. If the application category is determined to be the first application, flashing the application to be flashed is prohibited. By adopting the above scheme, this application, by embedding a controlled switch in the bootloader, controls whether flashing Apps compiled by a non-CI system is allowed by controlling the state of the switch. While ensuring that all externally released software originates from the CI system to comply with specifications, it allows flexible flashing of non-CI compiled software during the development and debugging phase, achieving a balance between quality control and development efficiency. This solves the problem in related technologies where, in traditional embedded development, it is difficult for the bootloader to distinguish between CI compilation and local compilation. Forcing full CI release reduces efficiency, while complete openness poses compliance risks. Specifically, the controlled switch can be turned on or off via the host computer. It is on by default, and when it is on, it is not allowed to flash apps compiled from non-CI systems.

[0026] In an optional embodiment, the control state is defaulted to the prohibited state, and the method further includes: receiving a control instruction from a host computer, wherein the control instruction is used to switch the control state from the prohibited state to the permitted state, and the permitted state is used to indicate that the first application can be flashed; after switching the control state to the permitted state in response to the control instruction, recording the number of restarts of the microcontroller; and when the number of restarts reaches a preset threshold, automatically switching the control state from the permitted state to the prohibited state.

[0027] During initialization, the boot program (i.e., the aforementioned bootloader) sets the control state to disabled by default, allowing only applications compiled by the CI system and bearing a compliant identity to be flashed, thus ensuring software compliance during factory release and daily operation. During the development and debugging phase, an authorized host computer on the intranet can issue control commands to switch the control state to enabled. In this state, the bootloader allows flashing of non-CI compiled applications to improve debugging efficiency. To prevent security risks caused by prolonged open permissions and forgetting to close them, after switching to enabled state, the bootloader increments the microcontroller's restart (or power-on / off) count N in non-volatile memory (NVM). When the restart (or power-on / off) count reaches a preset threshold (e.g., N≥2 times), the bootloader automatically resets the control state to disabled, restoring the security baseline without manual intervention. This effectively avoids version chaos or compliance risks caused by developers forgetting to close permissions.

[0028] Based on the above steps, receiving control commands from the host computer includes: communicating with an authorization management system deployed on an internal network through the host computer to verify whether the host computer has the control authority to switch the control state; if it is determined that the host computer has the control authority, receiving an encrypted control command sent by the host computer, wherein the encrypted control command carries a timestamp; and decrypting the encrypted control command to obtain the control command.

[0029] Before initiating a state transition request, the host computer must establish a communication connection with the authorized management system deployed on the internal network (i.e., the intranet). This connection verifies the host computer's legitimate authority to operate the boot control state through authentication. This communication process is strictly confined to the intranet environment, physically blocking unauthorized external access. After successful authorization verification, the host computer issues encrypted control commands with timestamps. The boot terminal decrypts these commands using a preset key to obtain the specific content and control instructions. This ensures that only authorized personnel from a trusted intranet, possessing legitimate identities and whose data has not been tampered with can execute control state transitions, significantly enhancing the rigor and security of access control.

[0030] Based on the above steps, the encrypted control instruction is decrypted to obtain the control instruction, including: parsing the encrypted control instruction to obtain the timestamp and the encrypted content corresponding to the control instruction; performing anti-replay verification on the encrypted control instruction based on the timestamp; and, if it is determined that the encrypted control instruction passes the anti-replay verification, decrypting the encrypted content using a preset key to obtain the control instruction.

[0031] Boot first parses the received encrypted control command, separating the timestamp and the encrypted content. Then, it performs anti-replay verification by comparing the timestamp with the current system time to determine whether the command is within a preset valid time window, thereby intercepting expired or repeatedly intercepted attack commands. Only when the timestamp verification passes and is confirmed as a valid new command does Boot use a preset key to decrypt the encrypted content to restore the control command. This verification sequence effectively prevents attackers from bypassing access control by replaying old valid encrypted packets, ensuring the timeliness and authenticity of state switching commands.

[0032] Optionally, verifying the application category of the application to be flashed based on its identity identifier includes: receiving the application to be flashed; reading an encrypted identifier from the target location of the application to be flashed, wherein the encrypted identifier is generated by encrypting a first verification value of the application to be flashed and a first fingerprint information of the CI system; decrypting the encrypted identifier to obtain the first verification value and the first fingerprint information; recalculating a second verification value of the application to be flashed, verifying whether the first verification value and the second verification value are consistent, and verifying whether the first fingerprint information is consistent with preset second fingerprint information; and determining the application category as the first application if the encrypted identifier decryption fails, or the first verification value and the second verification value are inconsistent, or the first fingerprint information and the second fingerprint information are inconsistent.

[0033] Boot extracts an identity identifier encrypted and generated by the CI system from a pre-defined, secure location within the App. This identifier encapsulates the application hash value (i.e., the first verification value) and unique fingerprint information (i.e., the first fingerprint information) generated during CI compilation. After decryption using a matching key, Boot recalculates the current App's hash value (i.e., the second verification value) and compares it with the decrypted original hash value (i.e., the aforementioned first verification value) to verify whether the App content has been tampered with during transmission or storage. Simultaneously, Boot compares the decrypted CI fingerprint with the system's pre-defined standard fingerprint (i.e., the aforementioned second fingerprint information) to confirm that the App indeed originates from a trusted CI system. If any step (decryption failure, hash value mismatch, or fingerprint mismatch) fails, Boot determines that the application is a non-CI compiled debug version or an illegal program, and, based on the control status, refuses to flash the application, ensuring that only complete and compliant software can enter the system. The fingerprint information can be a string of agreed-upon characters or bytes; the encryption methods of the CI system and Boot can be symmetric or asymmetric encryption.

[0034] Optionally, the method further includes: activating a permanent lock switch during the off-line inspection process before the target product corresponding to the microcontroller leaves the factory; and when the permanent lock switch is in the activated state, forcibly locking the control state to the prohibited state and prohibiting the host computer from modifying the control state.

[0035] During the MCU product off-line testing phase, a permanent lock switch is activated through a specific process. Once triggered, this switch irreversibly locks the boot control state to a mode that prohibits the flashing of non-CI programs, and cuts off the host computer's modification permissions for this state. This design completely eliminates the possibility of unauthorized flashing of debugging software in subsequent production, logistics, and sales stages from the physical manufacturing source, ensuring that every device ultimately delivered to the customer strictly runs a compliant version verified and released by the CI system, achieving closed-loop quality control throughout the entire lifecycle from development to delivery.

[0036] Optionally, the permanent lock switch is in the off state by default, and once the permanent lock switch is in the active state, it cannot be turned off.

[0037] This embodiment establishes a hardware-level security feature for the permanent lock switch: "single-trigger, irreversible." The switch is initially in the off state by default to maintain production flexibility. However, once activated during the off-line testing process, its state is permanently fixed by the hardware or underlying logic. The system level prohibits any software commands or external operations from attempting to restore it to the off state. This one-way locking mechanism eliminates the risk of lock failure due to inactivity or malicious tampering, ensuring that the bootloader's interception permissions for non-CI software after shipment have absolute persistence and immutability.

[0038] In an optional embodiment, CI and boot encryption and decryption can be performed using either symmetric or asymmetric encryption.

[0039] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0040] This embodiment also provides a microcontroller application verification device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementations, or a combination of software and hardware, are also possible and contemplated.

[0041] Figure 3 This is a structural block diagram of a microcontroller application verification device according to an embodiment of this application, such as... Figure 3 As shown, the device includes:

[0042] The acquisition module 32 is used to acquire the control status of the bootloader in the microcontroller, wherein the control status is used to indicate whether it is allowed to flash the first application compiled by a non-CI system;

[0043] Verification module 34 is used to verify the application category of the application to be flashed based on the identity identifier of the application to be flashed when the control state is a prohibited state that indicates that the first application is prohibited from being flashed, wherein the identity identifier is used to identify whether the application was compiled by the CI system.

[0044] The blocking module 36 is used to block the flashing operation of the application to be flashed when the application category is determined to be the first application.

[0045] The above-described device first obtains the control state of the bootloader in the microcontroller to determine whether the current microcontroller allows flashing a first application compiled by a non-CI system (i.e., an App compiled by a non-CI system). If the control state is determined to be a prohibited state indicating that flashing the first application is prohibited, the application category is determined according to the identity identifier of the application to be flashed to the microcontroller. The identity identifier is used to indicate whether the application was compiled by the CI system. If the application category is determined to be the first application, flashing the application to be flashed is prohibited. By adopting the above scheme, this application, by embedding a controlled switch in the bootloader, controls whether flashing Apps compiled by a non-CI system is allowed by controlling the state of the switch. While ensuring that all externally released software originates from the CI system to comply with specifications, it allows flexible flashing of non-CI compiled software during the development and debugging phase, achieving a balance between quality control and development efficiency. This solves the problem in related technologies where, in traditional embedded development, it is difficult for the bootloader to distinguish between CI compilation and local compilation. Forcing full CI release reduces efficiency, while complete openness poses compliance risks.

[0046] In an exemplary embodiment, the control state is defaulted to the prohibited state. The acquisition module 32 is further configured to receive a control instruction from the host computer, wherein the control instruction is configured to switch the control state from the prohibited state to the permitted state, and the permitted state is configured to indicate that the first application can be flashed; after switching the control state to the permitted state in response to the control instruction, the number of restarts of the microcontroller is recorded; when the number of restarts reaches a preset threshold, the control state is automatically switched from the permitted state to the prohibited state.

[0047] During initialization, the boot program (i.e., the aforementioned bootloader) sets the control state to disabled by default, allowing only applications compiled by the CI system and bearing a compliant identity to be flashed, thus ensuring software compliance during factory release and daily operation. During the development and debugging phase, an authorized host computer on the intranet can issue control commands to switch the control state to enabled. In this state, the bootloader allows flashing of non-CI compiled applications to improve debugging efficiency. To prevent security risks caused by prolonged open permissions and forgetting to close them, after switching to enabled state, the bootloader increments the microcontroller's restart (or power-on / off) count N in non-volatile memory. When the restart (or power-on / off) count reaches a preset threshold (e.g., N≥2 times), the bootloader automatically resets the control state to disabled, restoring the security baseline without manual intervention. This effectively avoids version chaos or compliance risks caused by developers forgetting to close permissions.

[0048] In an exemplary embodiment, the acquisition module 32 is further configured to communicate with an authorization management system deployed on an internal network via the host computer to verify whether the host computer has the control authority to switch the control state; if it is determined that the host computer has the control authority, receive an encrypted control instruction sent by the host computer, wherein the encrypted control instruction carries a timestamp; and decrypt the encrypted control instruction to obtain the control instruction.

[0049] Before initiating a state transition request, the host computer must establish a communication connection with the authorized management system deployed on the internal network (i.e., the intranet). This connection verifies the host computer's legitimate authority to operate the boot control state through authentication. This communication process is strictly confined to the intranet environment, physically blocking unauthorized external access. After successful authorization verification, the host computer issues encrypted control commands with timestamps. The boot terminal decrypts these commands using a preset key to obtain the specific content and control instructions. This ensures that only authorized personnel from a trusted intranet, possessing legitimate identities and whose data has not been tampered with can execute control state transitions, significantly enhancing the rigor and security of access control.

[0050] In an exemplary embodiment, the acquisition module 32 is further configured to parse the encrypted control instruction to obtain the timestamp and the encrypted content corresponding to the control instruction; perform anti-replay verification on the encrypted control instruction based on the timestamp; and, if it is determined that the encrypted control instruction passes the anti-replay verification, decrypt the encrypted content using a preset key to obtain the control instruction.

[0051] First, boot parses the received encrypted control command, separating the timestamp and the encrypted content. Then, it performs anti-replay verification by comparing the timestamp with the current system time to determine whether the command is within a preset valid time window, thereby intercepting expired or repeatedly intercepted attack commands. Only when the timestamp verification passes and is confirmed as a valid new command will boot1 use a preset key to decrypt the encrypted content to restore the control command. This verification sequence effectively prevents attackers from bypassing access control by replaying old valid encrypted packets, ensuring the timeliness and authenticity of state switching commands.

[0052] In an exemplary embodiment, the verification module 34 is further configured to receive the application to be flashed; read an encrypted identifier from the target location of the application to be flashed, wherein the encrypted identifier is generated by the CI system encrypting a first verification value of the application to be flashed and a first fingerprint information of the CI system; decrypt the encrypted identifier to obtain the first verification value and the first fingerprint information; recalculate the second verification value of the application to be flashed, verify whether the first verification value and the second verification value are consistent, and verify whether the first fingerprint information is consistent with the preset second fingerprint information; and determine the application category as the first application if the encrypted identifier fails to decrypt, or the first verification value and the second verification value are inconsistent, or the first fingerprint information and the second fingerprint information are inconsistent.

[0053] Boot extracts an identity identifier encrypted and generated by the CI system from a specific, secure location pre-defined by the App. This identifier encapsulates the application hash value (i.e., the first verification value) and unique fingerprint information (i.e., the first fingerprint information) generated during CI compilation. After decryption using a matching key, Boot recalculates the hash value of the current App (i.e., the second verification value) and compares it with the decrypted original hash value (i.e., the aforementioned first verification value) to verify whether the App content has been tampered with during transmission or storage. On the other hand, Boot compares the decrypted CI fingerprint with the system's pre-defined standard fingerprint (i.e., the aforementioned second fingerprint information) to confirm that the App indeed originates from a trusted CI system. If any step (decryption failure, hash value mismatch, or fingerprint mismatch) is abnormal, Boot determines that the application is a non-CI compiled debug version or an illegal program, and thus, based on the control status, decides to refuse to flash the application, ensuring that only complete and compliant software can enter the system.

[0054] In an exemplary embodiment, the aforementioned prohibition module 36 is further configured to activate a permanent lock switch during the off-line inspection process before the target product corresponding to the microcontroller leaves the factory; when the permanent lock switch is in the activated state, the control state is forcibly locked to the prohibited state, and the host computer is prohibited from modifying the control state.

[0055] During the MCU product off-line testing phase, a permanent lock switch is activated through a specific process. Once triggered, this switch irreversibly locks the boot control state to a mode that prohibits the flashing of non-CI programs, and cuts off the host computer's modification permissions for this state. This design completely eliminates the possibility of unauthorized flashing of debugging software in subsequent production, logistics, and sales stages from the physical manufacturing source, ensuring that every device ultimately delivered to the customer strictly runs a compliant version verified and released by the CI system, achieving closed-loop quality control throughout the entire lifecycle from development to delivery.

[0056] In one exemplary embodiment, the permanent lock switch is in the off state by default, and once the permanent lock switch is in the active state, it is prohibited from being turned off.

[0057] This embodiment establishes a hardware-level security feature for the permanent lock switch: "single-trigger, irreversible." The switch is initially in the off state by default to maintain production flexibility. However, once activated during the off-line testing process, its state is permanently fixed by the hardware or underlying logic. The system level prohibits any software commands or external operations from attempting to restore it to the off state. This one-way locking mechanism eliminates the risk of lock failure due to inactivity or malicious tampering, ensuring that the bootloader's interception permissions for non-CI software after shipment have absolute persistence and immutability.

[0058] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0059] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0060] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0061] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0062] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0063] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0064] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0065] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for verifying a microcontroller's application program, characterized in that, include: Obtain the control state of the bootloader in the microcontroller, wherein the control state is used to indicate whether it is permissible to flash the first application compiled on a non-CI system; When the control state is a prohibited state that indicates that the first application is prohibited from being flashed, the application category of the application to be flashed is verified according to the identity identifier of the application to be flashed, wherein the identity identifier is used to identify whether the application was compiled by the CI system; If the application category is determined to be the first application, the flashing operation on the application to be flashed is prohibited.

2. The method according to claim 1, characterized in that, The control state is defaulted to the prohibited state, and the method further includes: Receive control instructions from the host computer, wherein the control instructions are used to switch the control state from the prohibited state to the allowed state, and the allowed state is used to indicate that the first application can be flashed; After switching the control state to the allowed state in response to the control command, the number of times the microcontroller is restarted is recorded; If the number of restarts reaches a preset threshold, the control state will be automatically switched from the allowed state to the prohibited state.

3. The method according to claim 2, characterized in that, Receive control commands from the host computer, including: The host computer communicates with the authorization management system deployed on the internal network to verify whether the host computer has the control authority to switch the control state. If it is determined that the host computer has the control authority, the encrypted control command sent by the host computer is received, wherein the encrypted control command carries a timestamp; The encrypted control command is decrypted to obtain the control command.

4. The method according to claim 3, characterized in that, Decrypting the encrypted control command yields the control command, which includes: The encryption control command is parsed to obtain the timestamp and the encrypted content corresponding to the control command; The encryption control command is verified against replay based on the timestamp. If the encrypted control command passes the anti-replay verification, the encrypted content is decrypted using a preset key to obtain the control command.

5. The method according to claim 1, characterized in that, Verify the application category of the application to be flashed based on its identity identifier, including: Receive the application to be flashed; Read the encrypted identifier from the target location of the application to be flashed, wherein the encrypted identifier is generated by encrypting the first verification value of the application to be flashed and the first fingerprint information of the CI system. Decrypt the encrypted identifier to obtain the first verification value and the first fingerprint information; Recalculate the second verification value of the application to be flashed, verify whether the first verification value and the second verification value are consistent, and verify whether the first fingerprint information is consistent with the preset second fingerprint information; If the encryption identifier fails to decrypt, or the first verification value is inconsistent with the second verification value, or the first fingerprint information is inconsistent with the second fingerprint information, the application category is determined to be the first application.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: During the pre-shipment inspection process of the target product corresponding to the microcontroller, the permanent lock switch is activated. When the permanent lock switch is active, the control state is forcibly locked to the prohibited state, and the host computer is prohibited from modifying the control state.

7. The method according to claim 6, characterized in that, The permanent lock switch is in the off state by default, and once the permanent lock switch is in the active state, it cannot be turned off.

8. A device for verifying microcontroller application programs, characterized in that, include: The acquisition module is used to acquire the control status of the bootloader in the microcontroller, wherein the control status is used to indicate whether it is allowed to flash the first application compiled by a non-CI system; The verification module is used to verify the application category of the application to be flashed based on the identity identifier of the application to be flashed when the control state is a prohibited state that indicates that the first application is prohibited from being flashed. The identity identifier is used to identify whether the application was compiled by the CI system. The blocking module is used to block the flashing operation of the application to be flashed when the application category is determined to be the first application.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to perform the method described in any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 7.

Images