Microandroid system debugging method and device and electronic equipment

Abstract

The invention discloses a MicroAndroid system debugging method and device and electronic equipment, and the method comprises the steps: receiving a starting mode switching instruction request, carrying out the signature verification of the instruction request through a preset instruction signature verification certificate, and storing a starting mode identifier in a safe storage area after the signature verification succeeds; if the starting mode identification stored in the safe storage area is a debugging mode, preset equipment information is inquired, a debugging authorization code of a user is obtained, the debugging authorization code is verified through the equipment information, and whether the user is allowed to debug the equipment or not is verified; if the user is allowed to debug the equipment, starting the MicroAndroid system according to the debugging mode; if the starting mode identification stored in the secure storage area is a normal mode, starting the MicroAndroid system according to the normal mode; and if the startup mode identifier does not exist in the secure storage area, starting the MicroAndroid system according to the startup mode in the static configuration mirror image file. According to the method and the device, the starting mode of the MicroAndroid system can be flexibly switched.

Description

Technical Field

[0001] This invention relates to the field of Microdroid system debugging, and more particularly to a Microdroid system debugging method, apparatus, and electronic device. Background Technology

[0002] In existing technologies, there are two methods for debugging the Microdroid system. One is to manually set the debugging mode in the Microdroid system's configuration image file. After the configuration file content changes, the configuration image needs to be recompiled and updated on the device to start the Microdroid system. This static setting method is inflexible and does not meet the application scenarios that require flexible switching of debugging modes. The other method is to use command-line tools to set the Microdroid system to debug mode. This method can temporarily start the Microdroid system in debug mode, but it only takes effect for the current startup and will be lost when the Microdroid system is restarted again. Furthermore, this method only requires the user to click the pop-up authorization on the host machine during the first debugging, meaning that anyone can switch to debug mode. This is not secure enough for scenarios such as financial payment terminals that require strong control over device debugging capabilities. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a Microdroid system debugging method, device and electronic device, which realizes the debugging mode of Microdroid system that can be flexibly set and securely controlled.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A Microdroid system debugging method, applied to electronic devices, the method comprising: Receive a startup mode switching instruction request, verify the instruction request using a preset instruction verification certificate, and store the startup mode identifier in a secure storage area after successful verification. If the startup mode identifier stored in the secure storage area is debug mode, query the preset device information and obtain the user's debug authorization code. Use the device information to verify the debug authorization code to verify whether the user is allowed to debug the device. If the user is allowed to debug the device, the Microdroid system is launched according to the debugging mode; If the startup mode identifier stored in the secure storage area is normal mode, then the Microdroid system is started according to the normal mode; If the boot mode identifier is not present in the secure storage area, the Microdroid system is launched according to the boot mode in the static configuration image file.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An apparatus comprising: The startup mode switching trigger module receives a startup mode switching instruction request, verifies the instruction request using a preset instruction verification certificate, and stores the startup mode identifier in a secure storage area after successful verification. The debugging authorization request module, if the startup mode identifier stored in the secure storage area is debug mode, queries the preset device information and obtains the user's debugging authorization code, and uses the device information to verify the debugging authorization code to verify whether the user is allowed to debug the device; If the startup management module allows users to debug the device, it starts the Microdroid system according to the debugging mode; if the startup mode identifier stored in the secure storage area is normal mode, it starts the Microdroid system according to the normal mode; if the startup mode identifier does not exist in the secure storage area, it starts the Microdroid system according to the startup mode in the static configuration image file.

[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the Microdroid system debugging method described above.

[0007] The beneficial effects of this invention are as follows: By receiving a startup mode switching command request, the system verifies the command request using a preset command verification certificate. Upon successful verification, the startup mode is stored in a secure storage area. This ensures that the source of the startup mode switching command is legitimate and authorized, and that it has not been tampered with during transmission. This prevents attackers from forging startup commands and guarantees the secure writing and storage of the startup mode identifier. If the startup mode identifier stored in the secure storage area is in debug mode, the system queries preset device information and obtains the user's debug authorization code. The debug authorization code is then verified using the device information to determine if the user is allowed to debug the device. If the user is allowed to debug the device, the Microdroid system is launched according to the debug mode. The debug authorization code controls the user's permission to debug the device, increasing the control over permissions to switch the device to debug mode. This solves the problem that anyone can set the device's startup mode to debug mode, meeting the needs of scenarios such as financial payment terminals that require strong control over device debugging capabilities. If the boot mode identifier stored in the secure storage area is normal mode, the Microdroid system will be launched according to normal mode. If the secure storage area does not have a boot mode identifier, the Microdroid system will be launched according to the boot mode in the static configuration image file. By dynamically writing the boot mode identifier in SE or TEE, the default boot mode of the Microdroid system controlled by the static configuration image file is extended to support dynamic management of the default boot mode, which can meet the actual application scenarios that require flexible switching of debug mode. Attached Figure Description

[0008] Figure 1 A flowchart illustrating the steps of a Microdroid system debugging method provided in this embodiment of the invention; Figure 2 A system architecture diagram of a Microdroid system debugging method provided in an embodiment of the present invention; Figure 3 A structural diagram of a Microdroid system debugging device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0009] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0013] The abbreviations and their definitions used in this application are as follows: Microdroid, a lightweight Android system within the Android virtualization framework, is a minimalist version of the Android operating system designed to run in a protected virtual machine.

[0014] Microdroid OS, a small Android operating system or micro-operating system, usually refers to a lightweight, dedicated operating system.

[0015] Android OS, the Android operating system.

[0016] Adb, Android Debug Bridge, is a command-line debugging tool in the Android operating system.

[0017] Adbd, Android Debug Bridge Daemon.

[0018] REE stands for Rich Execution Environment, which is an untrusted execution environment.

[0019] AVF, Android Virtualization Framework, provides a secure virtualization environment for Android devices.

[0020] VirtualizationService is used for debugging the Microdroid system.

[0021] android.permission.VIRTUAL_MACHINE_LOG is used to control access permissions to the virtualization environment.

[0022] TEE, or Trusted Execution Environment, is a secure area built on a computing platform using software and hardware methods to ensure the confidentiality and integrity of code and data.

[0023] SE, or Secure Element, is a dedicated hardware component that exists in the form of a chip. It protects sensitive data from unauthorized access through physical isolation and tamper-proof design, and has built-in encryption / decryption logic circuitry that operates in isolation from the main processor.

[0024] pVM, Protected VM, provides enhanced security and isolation at both the hardware and software levels.

[0025] PC Tool is a collection of PC utilities primarily serving the needs of file management and disk maintenance under the DOS operating system.

[0026] IPC, Inter-Process Communication, refers to the technology of exchanging data or signals between different processes through interfaces provided by the operating system.

[0027] UI stands for User Interface.

[0028] Binder, the inter-process communication mechanism in Android, is a core component of the Android operating system that allows different processes to communicate through a secure channel.

[0029] Vsock, or Virtual Socket, is a communication mechanism in the Linux kernel used in virtualization environments. It supports direct communication between virtual machines (Guest) and the host machine (Host) or across virtual machines, without the need for a traditional network protocol stack.

[0030] Non-Secure World is an insecure environment used to run ordinary applications and operating systems.

[0031] Secure World-Protected VM is a virtualization architecture that provides deep protection for the virtual machine's operating environment, ensuring that its critical data and operations are not subject to malicious attacks.

[0032] In related technologies, the debugging mechanism of the Android operating system mainly relies on the Android Debug Bridge (ADB). However, the Android Debug Bridge directly operates on the REE-side operating system, which cannot meet the strong security isolation required by the virtual machine instance between itself and the host operating system. In contrast, the debugging mechanism of the Android Virtualization Framework (AVF) provides a more secure debugging capability than the REE-side operating system through layered control and security isolation design.

[0033] The debugging mechanism of the Android Virtualization Framework (AVF) is implemented through the following layers: First, when the Microdroid operating system starts, its mode must be explicitly set to debug mode via startup parameters to enable full debugging support for the Microdroid system. Second, it implements permission management and security isolation. The host machine (i.e., the operating system on the Android REE side) no longer has direct access to the virtualization environment. All debugging requests must be reviewed and routed through a trusted security proxy (such as VirtualizationService). This proxy strictly verifies the identity and permissions of the requester, typically only allowing applications with platform signatures (such as critical system services) or high-level permissions such as android.permission.VIRTUAL_MACHINE_LOG to initiate debugging requests, thus ensuring the credibility of the initiator. Finally, users need to grant authorization via a pop-up window on the host machine when performing debugging for the first time.

[0034] However, the debugging mechanism of the Android Virtualization Framework (AVF) has the following drawbacks: First, whether debug mode is enabled or disabled is determined during the configuration phase of the virtual machine instance by statically modifying attributes in its configuration image file (e.g., protected_vm_config.img) (e.g., setting android:debuggable="true"). When VirtualizationService loads this configuration image and starts the Microdroid system, it reads this attribute and determines whether to set it to debug mode. While this method of statically binding debugging capabilities to the image file ensures determinism in configuration from the source, thus providing high static security, it severely lacks flexibility. Any change to debug mode requires recompiling the configuration image file, redistributing it, and updating it to the target device. This cannot meet the needs of real-world application scenarios requiring flexible switching of debug modes. Second, when using the ADB command-line tool, by entering the command "adb shell vm start" to set the Microdroid system startup mode to debug mode... This mode allows for temporary activation of debug mode. While this method does not require recompilation, it only applies to the currently running instance and becomes invalid after the MicroDroid system restarts. Furthermore, this method only requires the user to click the pop-up authorization on the host machine during the first debugging session to switch the MicroDroid system's startup mode to debug mode. This means that anyone can switch to debug mode, which is insufficient for scenarios such as financial payment terminals that require strong control over device debugging capabilities.

[0035] To address the aforementioned problems, this application provides a Microdroid system debugging method, apparatus, and electronic device. The Microdroid system debugging method described in detail below is an example of this application.

[0036] The Microdroid system debugging method in this application can be used to securely set the Microdroid system's startup mode to debug mode, thereby enabling debugging of the Microdroid system. The electronic device in this application can be any electronic device that requires debugging of the Microdroid system, such as a mobile phone, tablet, or POS terminal.

[0037] The Microdroid system debugging method of this invention is described in detail below, with reference to the appendix. Figure 1 This includes steps 100-300.

[0038] Step 100: Receive a boot mode switching command request. Verify the command request using a preset command verification certificate. Upon successful verification, store the boot mode identifier in a secure storage area. Boot modes include normal mode and debug mode. The boot mode identifier identifies whether the boot mode is normal or debug. When the boot mode is normal, debugging and diagnostic functions for the MicroDroid system are restricted. When the boot mode is debug, debugging and diagnostic functions for the MicroDroid system are enabled. Boot mode switching commands include commands to switch from normal mode to debug mode, or vice versa.

[0039] Specifically, such as Figure 2 As shown, the boot mode switching command request is initiated by the PC tool or server backend to select whether to set the MicroDroid system's boot mode to debug mode or normal mode. For example, on the PC or other adbClient, the adb command `adb forward tcp:16666 localabstract:microdroid_adb` establishes a port forwarding rule. The command `adb connect localhost:16666` establishes a data transmission channel with the ADB proxy connection module pre-installed in the virtualization service via TCP port 16666. Users can initiate debug session requests by specifying the forwarding port (e.g., the user enters the debug command `adb -s localhost:16666 shell` on the PC). Command verification certificates are pre-installed in the Trusted Execution Environment (TEE) or Secure Element (SE) authentication module, including a boot mode switching command verification CA certificate and an application authentication CA certificate. The boot mode switching command verification CA certificate is used to authenticate the initiator of the command and verify the command signature. The application authentication CA certificate is used to sign the package name and application signature fingerprint information of the MicroDroid debug management application, which is used to perform MicroDroid system debugging and device management tasks. The application authentication CA certificate can be the same as the CA certificate used to verify the boot mode switching command. The secure storage area includes a Trusted Execution Environment (TEE) or a Secure Element (SE).

[0040] Step 200: If the boot mode identifier stored in the secure storage area is debug mode, query the preset device information and obtain the user's debug authorization code. Verify the debug authorization code using the device information to determine if the user is allowed to debug the device. The device information includes the device's unique identifier and the allowed debugging expiration time. The debug authorization code includes the device's unique identifier and the authorization time, used to verify whether the user has debugging permissions for the device. The device's unique identifier can be the device's serial number (SN). In practical applications, the valid time is the authorized validity period or a valid timestamp. For example, if the current time for starting Microdroid system debugging is 8:00 AM and the authorized time is 1 hour, then the allowed debugging expiration time is 9:00 AM, meaning the user is allowed to debug the device from 8:00 AM to 9:00 AM.

[0041] Step 300: If user is allowed to debug the device, the Microdroid system is started according to the debug mode. Specifically, a boot mode query module is set up in the TEE or SE for securely storing and querying boot mode configurations, and a boot management module is set up in the virtualization service to coordinate the virtual machine boot process. If the boot mode query module queries that the boot mode stored in the secure storage area is debug mode, the debug authorization verification module in Adbd is called to verify whether the terminal device has debug authorization. If the terminal device has debug authorization, the Microdroid system is started in debug mode through the boot management module. The debug authorization verification module in Adbd calls the debug authorization query module in the TEE or SE to collect the device SN identifier and authorization and compare them with the pre-stored device information. Based on the comparison result, the authorization verification result is returned to the virtualization service. The virtualization service decides whether to execute the debug command based on the authorization verification result.

[0042] Step 400: If the boot mode identifier stored in the secure storage area is normal mode, then the Microdroid system is started according to normal mode. Specifically, if the boot mode query module queries the boot mode stored in the secure storage area and finds it to be normal mode, then the boot management module calls the Virtualization Service to start the Microdroid system in non-debug mode. Step 500: If the secure storage area does not contain a boot mode identifier, the Microdroid system is started according to the boot mode in the static configuration image file. Specifically, if the boot mode query module is called to find that the secure storage area does not contain a boot mode identifier, the default boot configuration in the virtual machine configuration file (such as protected_vm_config.img) is automatically read by the virtualization service to determine the boot mode of the Microdroid system.

[0043] In this way, by receiving a startup mode switching command request, the system verifies the command request using a pre-set command verification certificate. Upon successful verification, the startup mode is stored in a secure storage area. This ensures that the source of the startup mode switching command is legitimate and authorized, and that it has not been tampered with during transmission. This prevents attackers from forging startup commands and guarantees the secure writing and storage of the startup mode identifier. If the startup mode identifier stored in the secure storage area is in debug mode, the system queries the preset device information and obtains the user's debug authorization code. The debug authorization code is then verified using the device information to determine if user debugging is allowed. If user debugging is allowed, the Microdroid system is launched according to the debug mode. The debug authorization code controls the user's device debugging permissions, adding permission control for switching the device to debug mode. This solves the problem that anyone can set the device's startup mode to debug mode, meeting the needs of scenarios such as financial payment terminals that require strong control over device debugging capabilities. If the boot mode identifier stored in the secure storage area is normal mode, the Microdroid system will be launched according to normal mode. If the secure storage area does not have a boot mode identifier, the Microdroid system will be launched according to the boot mode in the static configuration image file. By dynamically writing the boot mode identifier in SE or TEE, the default boot mode of the Microdroid system controlled by the static configuration image file is extended to support dynamic management of the default boot mode, which can meet the actual application scenarios that require flexible switching of debug mode.

[0044] In one embodiment of this application, step 100 includes steps 110 to 120.

[0045] Step 110: Encrypt the boot mode switching command using the command verification certificate and send it to the secure virtual machine. Specifically, the PC tool or server backend uses a pre-installed command verification CA certificate and corresponding private key to digitally sign the boot mode switching command, and then transmits the signed boot mode switching command wirelessly (e.g., via USB) or over a network to the MicroDroid debug management application. The pVM management module pre-installed in the MicroDroid debug management application establishes a vSock connection with the secure virtual machine pVM side through the native AVF mechanism. The vSock connection uses encrypted communication to ensure the confidentiality and integrity of the command transmission process. Through the vSock connection, the pVM management module forwards the signed boot mode switching command to the boot mode switching trigger module on the secure virtual machine pVM side.

[0046] Step 120: The secure virtual machine decrypts and verifies the boot mode switching command. Upon successful verification, it stores the boot mode identifier in the secure storage area. Specifically, before the secure virtual machine decrypts the boot mode switching command, the boot mode switching triggering module on the pVM side does not immediately execute the command upon receiving it. Instead, it displays a confirmation dialog box showing the user the device's current boot mode and the target boot mode to which it intends to switch, waiting for the user to confirm or cancel the boot mode switching operation. This prevents the boot mode from being remotely and maliciously switched without the user's knowledge. If the user confirms the switch, the pVM-side boot mode switching triggering module submits the signed boot mode switching command to the pVM-side boot mode writing module. The boot mode writing module decrypts and verifies the signature of the boot mode switching command. Upon successful verification, it initiates a boot mode write request, requesting that the boot mode identifier be written to the secure storage area.

[0047] In this way, the boot mode switching command is encrypted using a command verification certificate and sent to the secure virtual machine. The secure virtual machine decrypts and verifies the boot mode switching command. If the verification is successful, the boot mode is stored in the secure storage area. In other words, before the application identity information and the switching command are sent, the pVM uses the public key or session key pre-set by the TEE / SE to encrypt and sign them. Even if the data packet passes through the REE layer, the REE layer cannot decrypt or tamper with its content because it lacks a private key, and tampering would cause the signature verification to fail. This ensures the confidentiality and integrity of the command transmitted from the insecure REE environment to the secure virtual machine pVM.

[0048] In one embodiment of this application, step 120 includes steps 121 to 123.

[0049] Step 121: Based on the startup mode switching instruction, obtain the caller's identity to check whether the caller is a secure virtual machine-side application. Specifically, the pVM-side startup mode writing module sets up caller identity checks on its externally exposed interface. When this module receives the startup mode switching instruction, it obtains the caller's unique identity through the system-level API provided by the AVF framework (e.g., the Binder.getCallingUid() method) or the dedicated interface of the trust domain communication daemon. The caller's unique identity is established during AVF framework initialization and is bound to the pVM instance. The system queries the caller's identity in a pre-defined trusted identity whitelist. If the query is successful, the verification passes. Specifically, the system maintains a predefined trusted identity whitelist, which only contains authorized pVM-side security component identifiers. When the caller's unique identity matches any pre-defined identity in the whitelist, the verification result is successful. If any mismatch occurs, the request processing is immediately terminated and a rejection response is returned.

[0050] Step 122: If the requesting caller is a secure virtual machine-side application, then application authentication and startup mode switching instruction verification are performed based on the startup mode switching instruction. Specifically, the pVM-side startup mode writing module obtains the startup mode switching instruction and sends an instruction request to be forwarded to the startup mode writing module in the Trusted Execution Environment (TEE) or Secure Element (SE).

[0051] Step 123: Once the application authentication and startup mode switching command verification are successful, a startup mode write request is responded to. Specifically, the startup mode write module in the Trusted Execution Environment (TEE) or Secure Element (SE) performs the application authentication and startup mode switching command verification.

[0052] In this way, firstly, based on the startup mode switching instruction, the identity of the requesting caller is obtained to check whether the caller is a secure virtual machine-side application. That is, it verifies whether the startup mode switching request originates from the protected application pVM side. This explicitly restricts the startup mode writing module to only accept secure requests from pVM-side applications and rejects direct requests from the REE side. Even if an attacker attempts to directly call the startup mode writing interface, it will be blocked because the identity cannot pass the whitelist verification. Through this verification mechanism, attacks and forged startup mode switching requests initiated on the REE side are effectively prevented. Secondly, if the requesting caller is a secure virtual machine-side application, application identity authentication and startup mode switching instruction signature verification are performed based on the startup mode switching instruction. When application identity authentication and startup mode switching instruction signature verification are successful, the startup mode writing request is responded to. That is, by performing double security verification—application identity authentication and startup mode switching instruction signature verification—it is ensured that the application issuing the request is legitimate and not malicious code disguised as a legitimate application. It is also ensured that the received "startup mode switching instruction" has not been tampered with during transmission and indeed comes from a trusted instruction source.

[0053] In one embodiment of this application, step 122 includes steps 1221 to 1222.

[0054] Step 1221: Parse the corresponding application identity information based on the process identifier requested by the instruction. The application identity information refers to the identity information of the MicroDroid debug management app, including the application package name and application signature fingerprint information. Since directly extracting application identity information from the launch mode switching instruction may result in forged application information, the application identity information is parsed by calling the process identifier requested by the instruction.

[0055] Specifically, when the boot mode writing module on the pVM side receives a request, it initiates a query to the system service (such as PackageManagerService) running on the REE side, which is responsible for managing application identities, through a secure IPC mechanism. During the query, the process identifier that called the request is passed in. The system service parses the corresponding application package name based on this process identifier and retrieves the application's signature certificate fingerprint from the secure storage area, which stores the signature fingerprint information of all installed applications. After obtaining the application identity information, the pVM-side boot mode encrypts the identity information and boot mode command using a pre-set key. Through the established pVM-REE-TEE / SE secure transmission channel, the encrypted application identity information and boot mode switching command are sent together to the secure boot mode writing module within the TEE or SE environment. The pVM-REE-TEE / SE secure transmission channel can use secure channels provided by the Android system (such as the Hidl or Aidl interfaces behind the Android Keystore system) to interact with the TEE or SE. These channels are hardened at the driver layer to minimize the risk of interception at the REE. In practical applications, if the device hardware supports a Secure Element (SE), the SE will be chosen to perform subsequent boot mode write operations to take advantage of its higher security level.

[0056] Step 1222: Using a pre-set instruction verification certificate, the application identity information is verified against the application information pre-stored in the secure storage area to confirm whether the instruction request originates from a legitimate application. Specifically, the boot mode writing module on the TEE or SE side obtains the encrypted application identity information, compares the application package name and application signature fingerprint information with the legitimate application information pre-stored in the identity authentication module on the TEE or SE side, and verifies the legitimacy of the application identity.

[0057] In this way, by parsing the application identity information based on the process identifier of the instruction request, the system avoids the possibility that the extracted application identity information might be forged, as this could occur if the application identity information is directly extracted from the startup mode switching instruction. This ensures that the application identity information is not forged. Furthermore, by using a pre-built instruction verification fingerprint, the application identity information is compared with the application information stored in a secure storage area to verify whether the instruction request originates from a legitimate application. Attackers cannot impersonate legitimate applications by decompiling or repackaging the application because the signature fingerprint cannot be forged. In this application's solution, the startup mode write module of the TEE or SE first performs decryption and verification. Only if the verification passes, proving that the data has not been tampered with during transmission and originates from a legitimate pVM, will processing continue. That is, if the verification is successful, the startup mode write request is responded to, ensuring the security of startup mode writes.

[0058] In one embodiment of this application, step 123 includes steps 1231 to 1233.

[0059] Step 1231: Decrypt the boot mode switching instruction using a preset decryption key to obtain the instruction signature data. Specifically, the boot mode writing module of the TEE or SE decrypts the boot mode switching instruction to extract the instruction signature data, which is used for instruction signature verification.

[0060] Step 1232: Parse the signing certificate from the instruction signature data, and verify the signing certificate against the pre-set instruction verification certificate chain. If the verification passes, the initiator of the instruction is authenticated and the instruction signature is verified in the signing certificate. Specifically, the boot mode writing module on the TEE or SE side parses the certificate for performing this signing operation from the instruction signature data, and verifies the certificate chain using the pre-set root CA certificate within the TEE / SE to ensure the legality and authenticity of the certificate itself. After the certificate chain verification passes, the signing certificate is used to verify the digital signature of the instruction to confirm the integrity and source credibility of the instruction.

[0061] Step 1233: If the signature verification passes, the boot mode identifier is stored in the secure storage area. Specifically, the boot mode writing module of TEE or SE stores the normal mode or debug mode in the secure storage area TEE or SE.

[0062] In this way, the boot mode switching command is decrypted using a pre-set decryption key to obtain the command signature data. By digitally signing the command, any minor modification to the command content (such as changing "normal mode" to "debug mode") will cause the final signature verification to fail. This ensures that the boot mode switching command transmitted to the TEE or SE is not maliciously tampered with during transit. The signing certificate is parsed from the command signature data and verified against a pre-set command verification certificate chain. If the verification passes, the initiator of the command is authenticated and the command signature is verified in the signing certificate. If the signature verification passes, the boot mode is stored in a secure storage area. By verifying the certificate chain of the signing certificate, the system ultimately traces back to the pre-set, trusted root certificate. This means that only authorized parties holding the corresponding private key can issue valid commands, preventing unauthorized operations.

[0063] In one embodiment of this application, step 200 includes steps 210 to 230.

[0064] Step 210: Extract the device's unique identifier and the allowed debugging deadline from the device information preset in the secure storage area. Specifically, a device information storage area is preset in the debugging authorization query module of the TEE or SE to store the device's unique identifier and the allowed debugging deadline. The debugging authorization query module is used to query the device's unique identifier and the allowed debugging deadline stored in the preset debugging authorization information storage area. For example, the device's unique identifier in the device information is device SN identifier 1234, and the allowed debugging deadline is 12:00.

[0065] Step 220: Determine if the allowed debugging deadline has expired based on the current time. If the deadline has expired, request the user's debugging authorization code and verify it using device information. The current time is obtained from the device's secure clock or a trusted time source synchronized with a time server. For example, if the allowed debugging deadline is 12:00, and the current time is 11:00, the user is allowed to debug the device; if the current time is 13:00, the user is requested to obtain the debugging authorization code. The debugging authorization code can be an authorization code entered by the user or an encrypted authorization code passed by the MicroDroid debugging management application. The debugging authorization code is generated in the background or on a PC tool. For example, the MicroDroid debugging authorization management module on the pVM side can pop up an authorization code input interface, supporting user input of authorization code information. Users can input the authorization code by scanning a code or manually entering it.

[0066] Specifically, on the pVM side, Adbd has a pre-configured debug license verification module used to respond to debug requests from boot mode switching commands. When Adbd receives a debug request, it requests the debug license query module of the TEE or SE to check the current debug license information, i.e., to query the device's unique identifier and the expiration time of the allowed debugging, which are pre-stored in the pre-configured device information storage area. The debug license query module returns the query results to Adbd, where the query results can be valid license, no license record, expired license, or device SN mismatch, and returns the corresponding fields. For example, the field AUTHORIZED indicates valid license, the field UNAUTHORIZED indicates no license record, the field EXPIRED indicates expired license, and the field DEVICE_MISMATCH indicates device SN mismatch. If no authorization record is found, the authorization has expired, or the device serial number does not match, Adbd's debug authorization verification module calls the MicroDroid debug authorization management module on the pVM side, which displays an authorization code input interface for the user to enter the debug authorization code. Here, the pVM debug authorization management module directly manages the authorization code input UI, making the input of debug authorization information more secure. When a valid authorization is found, the device is started in debug mode by calling the Virtualization Service.

[0067] Step 230: If the current time is within the allowed debugging deadline, the user is allowed to debug the device. For example, if a user starts the system in debug mode at 8:00, and the allowed debugging deadline stored in the device information is 9:00, meaning the allowed debugging period is 8:00-9:00, and the user starts the device in normal mode again at 8:20 or shuts it down for a period of time, and then wants to restart the device in debug mode at 8:30, then since it is still within the allowed debugging deadline, there is no need to obtain a new debugging authorization code, and the user can directly start the device in debug mode.

[0068] In this way, the device's unique identifier and the allowed debugging deadline are extracted from the device information preset in the secure storage area. The current time is used to determine whether the allowed debugging deadline has expired. If the allowed debugging deadline has expired, the user's debugging authorization code is requested and verified using the device information. If the current time is within the allowed debugging deadline, the user is allowed to debug the device, ensuring that debugging can only be performed within the specified time window.

[0069] In one embodiment of this application, step 220 includes steps 221 to 222.

[0070] Step 221: If the device unique identifier in the debugging authorization code matches the device unique identifier in the device information, the verification is successful. For example, if both the device SN identifier in the debugging authorization code and the device SN identifier in the device information are 1234, the comparison is successful. If the verification fails, the user is refused access to debug the device.

[0071] Step 222: After successful verification, store the debugging authorization code in the secure storage area.

[0072] In this way, if the device unique identifier in the debug authorization code matches the device unique identifier in the device information, the verification is successful, preventing the debug authorization code from being copied to other incompatible devices. After successful verification, the debug authorization code is stored in a secure storage area to ensure the security of the device information storage.

[0073] In one embodiment of this application, step 222 includes steps 2221 to 2222.

[0074] Step 2221: Encrypt the device unique identifier and authorization time in the debug authorization code using the encryption key pre-stored in the secure storage area. Specifically, a debug authorization writing module is pre-installed on the pVM side to write the debug authorization code to the secure storage area. The debug authorization writing module on the pVM side receives the debug authorization code input by the user, encrypts the device unique identifier and authorization time using the debug authorization code encryption key pre-stored in the TEE or SE, or receives the encrypted device unique identifier and authorization time from the MicroDroid debug management APP, and sends the encrypted debug authorization code write request to the TEE or SE.

[0075] Step 2222: Send the encrypted device unique identifier and authorized time to the secure storage area. Decrypt the device unique identifier and authorized time using the decryption key preset in the secure storage area. If decryption is successful, update the allowed debugging deadline in the device information according to the authorized time. Specifically, a debug authorization code writing module is preset in the TEE or SE to receive debug authorization code writing requests from the pVM side and write the authorization code into the TEE or SE for storage. The TEE or SE debug authorization code writing module receives the debug authorization code writing request, decrypts the debug authorization code using the debug authorization code decryption private key preset in the TEE or SE, parses out the plaintext device unique identifier and authorized time (e.g., 1 hour), and updates the allowed debugging deadline in the device information. For example, if the current time is 8:00, update the allowed debugging deadline to 9:00.

[0076] This method uses a pre-stored encryption key in a secure storage area to encrypt the device's unique identifier and authorization time in the debug authorization code. This prevents the device's unique identifier and authorization time from being stolen or eavesdropped on during transmission from the pVM to the TEE or SE. Even if the transmission channel is monitored, attackers will only obtain incomprehensible ciphertext. The encrypted device's unique identifier and authorization time are sent to the secure storage area, where they are decrypted using a pre-stored decryption key. If decryption is successful, the allowed debugging expiration time in the device information is updated according to the authorization time. This effectively prevents the debug authorization code from being tampered with during transmission, and ensures the security of device information storage.

[0077] Please refer to Figure 3 The present invention also provides a Microdroid micro-Android system debugging device, the device comprising: The startup mode switching trigger module 100 receives a startup mode switching instruction request, verifies the instruction request using a preset instruction verification certificate, and stores the startup mode identifier in a secure storage area after successful verification. The debug authorization request module 200, if the boot mode identifier stored in the secure storage area is debug mode, queries the preset device information and obtains the user's debug authorization code, and uses the device information to verify the debug authorization code to verify whether the user is allowed to debug the device; If the startup management module 300 allows users to debug the device, it starts the Microdroid system according to the debugging mode; if the startup mode identifier stored in the secure storage area is normal mode, it starts the Microdroid system according to normal mode; if the secure storage area does not have a startup mode identifier, it starts the Microdroid system according to the startup mode in the static configuration image file.

[0078] Please refer to Figure 4 The present invention also provides an electronic device 300, including a memory 301 and a processor 302, and a computer program stored on the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the various steps in the Microdroid system debugging method described above.

[0079] The beneficial effects of the apparatus and electronic equipment in this application are the same as those of the methods described above, and will not be repeated here.

[0080] In summary, by receiving a boot mode switching command request and verifying the request using a pre-set command verification certificate, the boot mode identifier is stored in a secure storage area upon successful verification. This ensures that the source of the boot mode switching command is legitimate and authorized, and that it has not been tampered with during transmission. This prevents attackers from forging boot commands and guarantees the secure writing and storage of the boot mode identifier. If the boot mode identifier stored in the secure storage area is in debug mode, the system queries the preset device information and obtains the user's debug authorization code. The debug authorization code is then verified using the device information to determine if the user is allowed to debug the device. If the user is allowed to debug the device, the Microdroid system is launched according to the debug mode. The debug authorization code is used to control the user's permissions to debug the device, adding permission control for switching the device to debug mode. This solves the problem that anyone can set the device's boot mode to debug mode, which can meet the needs of scenarios such as financial payment terminals that require strong control over device debugging capabilities. If the boot mode identifier stored in the secure storage area is normal mode, the Microdroid system will be launched according to normal mode. If the secure storage area does not have a boot mode identifier, the Microdroid system will be launched according to the boot mode in the static configuration image file. By dynamically writing the boot mode identifier in SE or TEE, the default boot mode of the Microdroid system controlled by the static configuration image file is extended to support dynamic management of the default boot mode, which can meet the actual application scenarios that require flexible switching of debug mode.

[0081] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for debugging a Microdroid system, characterized in that, The method includes: Receive a startup mode switching instruction request, verify the instruction request using a preset instruction verification certificate, and store the startup mode identifier in a secure storage area after successful verification. If the startup mode identifier stored in the secure storage area is debug mode, query the preset device information and obtain the user's debug authorization code. Use the device information to verify the debug authorization code to verify whether the user is allowed to debug the device. If the user is allowed to debug the device, the Microdroid system is launched according to the debugging mode; If the startup mode identifier stored in the secure storage area is normal mode, then the Microdroid system is started according to the normal mode; If the boot mode identifier is not present in the secure storage area, the Microdroid system is launched according to the boot mode in the static configuration image file.

2. The Microdroid system debugging method according to claim 1, characterized in that, The instruction request is verified using a pre-set instruction verification certificate. Upon successful verification, the startup mode identifier is stored in a secure storage area, including: The boot mode switching command is encrypted using the command verification certificate and sent to a secure virtual machine; The secure virtual machine decrypts and verifies the boot mode switching instruction. If the verification is successful, the boot mode identifier is stored in the secure storage area.

3. The Microdroid system debugging method according to claim 2, characterized in that, The secure virtual machine decrypts and verifies the boot mode switching instruction. Upon successful verification, it stores the boot mode identifier in the secure storage area, including: Based on the startup mode switching instruction, obtain the identity identifier of the requesting caller to check whether the requesting caller is a secure virtual machine-side application; If the requesting party is a secure virtual machine-side application, then application identity authentication and startup mode switching instruction signature verification are performed according to the startup mode switching instruction. When the application authentication and the launch mode switching instruction verification are successful, a launch mode write request is responded to.

4. The Microdroid system debugging method according to claim 3, characterized in that, According to the startup mode switching command, the application identity authentication and startup mode switching command signature verification include: Based on the process identifier of the startup mode switching instruction, parse the corresponding application identity information; Using the pre-set instruction verification signature, the application identity information is verified against the application information pre-stored in the secure storage area to verify whether the instruction request originates from a legitimate application.

5. The Microdroid system debugging method according to claim 3, characterized in that, When the application authentication and the launch mode switching command verification are successful, the launch mode write request response includes: The startup mode switching instruction is decrypted using a preset decryption key to obtain the instruction signature data; The signature certificate is parsed from the instruction signature data and verified against the preset instruction verification certificate chain. If the verification passes, the initiator of the instruction is authenticated and the instruction signature is verified in the signature certificate. If the signature verification is successful, the startup mode identifier will be stored in the secure storage area.

6. The Microdroid system debugging method according to claim 1, characterized in that, If the boot mode identifier stored in the secure storage area is debug mode, the preset device information is queried, and the user's debug authorization code is obtained. The debug authorization code is then verified using the device information. Verification of whether the user is allowed to debug the device includes: Extract the device's unique identifier and the deadline for allowed debugging from the device information preset in the secure storage area; Determine whether the deadline for allowing debugging has expired based on the current time. If the deadline for allowing debugging has expired, request the user's debugging authorization code and verify the debugging authorization code using the device information. If the current time is within the allowed debugging deadline, then the user is allowed to debug the device.

7. The Microdroid system debugging method according to claim 6, characterized in that, The request to obtain the user's debugging authorization code and to verify the debugging authorization code using the device information includes: If the device unique identifier in the debugging authorization code matches the device unique identifier in the device information, the verification is successful. After successful verification, the debugging authorization code is stored in the secure storage area.

8. The Microdroid system debugging method according to claim 7, characterized in that, After successful verification, storing the debugging authorization code in the secure storage area includes: The device unique identifier and authorization time in the debug authorization code are encrypted using an encryption key pre-stored in the secure storage area; The encrypted device unique identifier and the authorized time are sent to the secure storage area. The device unique identifier and the authorized time are decrypted according to the decryption key preset in the secure storage area. If the decryption is successful, the allowed debugging deadline in the device information is updated according to the authorized time.

9. A Microdroid system debugging device, characterized in that, The device includes: The startup mode switching trigger module receives a startup mode switching instruction request, verifies the instruction request using a preset instruction verification certificate, and stores the startup mode identifier in a secure storage area after successful verification. The debugging authorization request module, if the startup mode identifier stored in the secure storage area is debug mode, queries the preset device information and obtains the user's debugging authorization code, and uses the device information to verify the debugging authorization code to verify whether the user is allowed to debug the device; If the startup management module allows users to debug the device, it starts the Microdroid system according to the debugging mode; if the startup mode identifier stored in the secure storage area is normal mode, it starts the Microdroid system according to the normal mode; if the startup mode identifier does not exist in the secure storage area, it starts the Microdroid system according to the startup mode in the static configuration image file.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps in the Microdroid system debugging method according to any one of claims 1-8.

Images