Debugging methods and systems for applications, electronic devices

Abstract

This application relates to the field of security chip technology and discloses a method for debugging applications, comprising: obtaining standard debug request information based on a standard debug protocol sent by an integrated development platform; converting the standard debug request information into proprietary debug request information based on a proprietary debug protocol; sending the proprietary debug request information to a secure element to obtain debug response information of the application running the proprietary debug request information in the secure element; and sending debug response information to the integrated development platform so that the integrated development platform can analyze the debug response information and determine the fault information of the application in the secure element. Through a debug manager, remote debugging of applications in the secure element can be achieved without direct contact with the secure element. The debug manager can handle the conversion between different protocols, enabling the integrated development platform to communicate flexibly with the secure element. This application also discloses a debugging system and electronic device for applications.

Description

Technical Field

[0001] This application relates to the field of security chip technology, such as a debugging method and system for applications and electronic devices. Background Technology

[0002] In the field of security chips, with the continuous advancement of smart card and secure element technologies, the popularity and complexity of JavaCard applet applications are rapidly increasing. These applications not only play a crucial role in multiple fields such as financial services, mobile payments, transportation, and identity authentication, but their functional and performance requirements are also constantly rising, thus placing higher demands on application performance and space consumption. However, with the increasing complexity of applications, problem identification and resolution during development and maintenance become more difficult and time-consuming.

[0003] In related technologies, developers first need to analyze and modify the code suspected of having problems based on problem reports or test results. The modified applet needs to be reloaded into the security chip. After loading the new applet version, developers need to execute test cases or observe application behavior to verify whether the problem has been resolved.

[0004] In the process of implementing the embodiments of this disclosure, it was found that at least the following problems exist in the related technology: the existing application debugging methods mainly support local debugging and do not support remote debugging.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0007] This disclosure provides a method, system, and electronic device for debugging applications, enabling remote debugging of applications and improving the flexibility and accessibility of debugging.

[0008] In some embodiments, the debugging method for an application is applied to a debug manager, which is connected to a secure element and an integrated development platform (IDE). The debugging method includes: obtaining standard debug request information based on a standard debug protocol sent by the IDE; converting the standard debug request information into proprietary debug request information based on a proprietary debug protocol; sending the proprietary debug request information to the secure element to obtain debug response information of the application running the proprietary debug request information in the secure element; and sending debug response information to the IDE so that the IDE can analyze the debug response information and determine fault information of the application in the secure element.

[0009] In some embodiments, the debugging method for an application is applied to an integrated development platform (IDE), which is connected to a debug manager. The debugging method includes: generating standard debug request information based on a standard debug protocol; sending the standard debug request information to the debug manager so that the debug manager converts the standard debug request information into proprietary debug request information based on a proprietary debug protocol, and sending proprietary debug request information to a secure element to obtain debug response information of the application running proprietary debug request information in the secure element; obtaining and analyzing the debug response information sent by the debug manager to determine fault information of the application in the secure element.

[0010] In some embodiments, the debugging method for an application is applied to a secure element connected to a debug manager. The debugging method includes: obtaining proprietary debug request information sent by the debug manager; wherein the proprietary debug request information is converted from standard debug request information by the debug manager based on a proprietary debug protocol; the application in the secure element runs the proprietary debug request information and obtains debug response information; and sending debug response information to the debug manager, so that the debug manager sends debug response information to an integrated development platform, so that the integrated development platform analyzes the debug response information and determines fault information of the application in the secure element.

[0011] In some embodiments, a debugging system for an application includes: an integrated development platform (IDE) configured to generate standard debug request information based on a standard debug protocol, analyze debug response information of proprietary debug request information executed by the application in a secure element, and determine fault information of the application in the secure element; a secure element, on which the application is installed, configured to allow the application to execute proprietary debug request information and obtain debug response information; and a debug manager, including an uplink connection manager and a downlink connection manager, connected to the IDE via the uplink connection manager and connected to the secure element via the downlink connection manager, configured to: obtain standard debug request information sent by the IDE; convert the standard debug request information into proprietary debug request information based on a proprietary debug protocol; send proprietary debug request information to the secure element; and send debug response information to the IDE.

[0012] In some embodiments, the electronic device includes a processor and a memory storing program instructions, the processor being configured to execute the aforementioned debugging method for an application when the program instructions are executed.

[0013] The debugging method, system, and electronic device for applications provided in this disclosure can achieve the following technical effects:

[0014] In this disclosed technical solution, the debug manager is connected to both the secure element and the integrated development platform (IDE). After receiving standard debug request information based on a standard debug protocol from the IDE, the debug manager converts this information into proprietary debug request information based on a proprietary debug protocol. It then sends this proprietary debug request information to the secure element to obtain debug response information from the application running in the secure element. Finally, the debug manager sends debug response information to the IDE, enabling the IDE to analyze the debug response information and determine the fault information of the application in the secure element. In other words, communication between the IDE and the secure element is achieved through the debug manager. The debug manager acts as a bridge, receiving standard debug request information (based on a standard debug protocol) from the IDE, converting it into proprietary debug request information (based on a proprietary debug protocol), and sending it to the secure element. The secure element processes these proprietary debug requests and returns debug response information. The debug manager then sends the debug response information back to the IDE for analysis and determination of the application's fault information. In this way, the debug manager enables remote debugging of applications in the secure element without direct contact with the secure element. The debug manager can handle the conversion between different protocols, enabling the integrated development platform to communicate flexibly with the secure element and improving debugging accessibility. This allows developers to more easily access and debug applications embedded in the secure element.

[0015] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0016] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein:

[0017] Figure 1 This is a schematic diagram of the structure of a debugging system for an application provided in an embodiment of this disclosure;

[0018] Figure 2 This is a schematic diagram of another debugging system for applications provided in this disclosure embodiment;

[0019] Figure 3 This is a flowchart illustrating a debugging method for an application provided in an embodiment of this disclosure;

[0020] Figure 4 This is a flowchart illustrating another debugging method for an application provided in this disclosure embodiment;

[0021] Figure 5 This is a flowchart illustrating another debugging method for an application provided in this disclosure embodiment;

[0022] Figure 6 This is a flowchart illustrating another debugging method for an application provided in this disclosure embodiment;

[0023] Figure 7-1 This is a schematic diagram illustrating that the data type of proprietary debugging information in a proprietary debugging protocol provided in this embodiment of the disclosure is a request;

[0024] Figure 7-2 This is a schematic diagram illustrating that the data type of proprietary debugging information in another proprietary debugging protocol provided in this disclosure is a response;

[0025] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0026] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0027] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0028] Unless otherwise stated, the term "multiple" means two or more. In embodiments of this disclosure, the character " / " indicates that the preceding and following objects are in an "OR" relationship. For example, A / B means: A or B. The term "and / or" describes an association relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B. The term "correspondence" can refer to an association or binding relationship; A corresponding to B means that there is an association or binding relationship between A and B.

[0029] The following provides further explanation of some of the technical terms used in this application:

[0030] An Integrated Development Environment (IDE) is a software application development platform provided for software developers. It integrates functions such as a code editor, compiler, debugger, and project management tools, aiming to provide an integrated platform for writing, testing, and debugging code. IDEs include Eclipse, an open-source, Java-based, extensible development platform that provides developers with a unified and scalable framework for building and deploying various types of applications.

[0031] A Secure Element (SE) is a microcomputer that uses a security chip and a Chip Operating System (COS) to perform functions such as secure data storage and encryption / decryption. SEs can be packaged in various forms, such as smart cards and embedded security modules (eSEs). The COS is an operating system specifically designed for security chips, providing chip-level security functions and management.

[0032] Figure 1 This is a schematic diagram of the structure of an application debugging system provided in an embodiment of this disclosure. Figure 1 As shown, the application debugging system includes an integrated development platform (IDE), a secure element, and a debug manager. The debug manager includes an uplink connection manager and a downlink connection manager. The debug manager connects to the IDE via the uplink connection manager and to the secure element via the downlink connection manager. Wherein:

[0033] The integrated development platform (IDE) is configured to generate standard debug request information based on a standard debug protocol, analyze debug response information of proprietary debug request information executed by applications in the secure element, and determine fault information of the applications in the secure element. The secure element, with applications installed, is configured to execute proprietary debug request information and obtain debug response information. The debug manager is configured to: receive standard debug request information sent by the IDE; convert the standard debug request information into proprietary debug request information based on a proprietary debug protocol; send proprietary debug request information to the secure element; and send debug response information to the IDE.

[0034] Combination Figure 2 As shown, the secure element includes a debug agent terminal and a secure element SE body. The debug agent terminal is connected to both the debug manager and the secure element SE body. Specifically: the debug agent terminal receives proprietary debug request information sent by the debug manager and sends this proprietary debug request information to the secure element body; the application in the secure element body runs the proprietary debug request information and receives debug response information, then sends the debug response information to the debug agent terminal; the debug agent terminal sends the debug response information to the debug manager.

[0035] Here, the debug agent terminal is located between the SE body and the debug manager, using UART / SPI to achieve data pass-through and ensure efficient transmission of debug information between the SE cos and the debug manager. The Secure Element (SE) body sets up a proprietary debug protocol stack, including JCVM, GP, Applet / SD, HW, Driver, and COS. UART (Universal Asynchronous Receiver / Transmitter) is a protocol and standard for asynchronous serial communication, used for data transmission between microcontrollers, computers, and other devices. SPI (Serial Peripheral Interface) is a synchronous serial communication protocol, commonly used for short-distance communication, especially between components within embedded systems. JCVM (Java Card Virtual Machine) is a Java Virtual Machine running on the Secure Element, used to execute Java card applications. GP (Global Platform) is an open standards organization dedicated to developing standards for the security management, application management, and remote management of Secure Elements (such as smart cards and SIM cards). Applets / SDs are small applications and / or security domains that run on Java cards or similar environments, performing specific security functions or business logic. Hardware (HW) refers to the physical components that make up a computer system and various electronic devices, such as circuit boards, processors, and memory. A driver is the software interface between computer hardware and the operating system, used to control the operation of hardware devices. The Card Operating System (COS) is the operating system that runs on the secure element, used to manage the resources, security functions, and applications on the card.

[0036] The debug manager includes breakpoint management, logging and output, call stack tracing, a standard debug protocol stack, a debug protocol converter, a proprietary debug protocol stack, an uplink connection manager, a session manager, and a downlink connection manager. Breakpoint management is responsible for setting, managing, and maintaining breakpoints, which are the points where program execution pauses during debugging. Logging and output records key information and output results during debugging. Call stack tracing displays the order and context of function calls during program execution. The standard debug protocol stack is a set of components conforming to standard debug protocols, used for data exchange and communication during debugging. The debug protocol converter converts data formats from one debug protocol to another. The proprietary debug protocol stack is a custom-designed stack for a specific application or system. The uplink connection manager manages connections to the integrated development platform connected to the debug manager. The session manager manages session information during debugging, including session creation, maintenance, and termination. The downlink connection manager manages connections to the security element connected to the debug manager.

[0037] The integrated development platform (IDE) sets up a JavaCard perspective, which includes a debug view, a standard debug protocol stack, a performance analysis view, a CAP file attribute view, a bytecode view, a non-standard API analysis view, a CAP decompilation view, a DTR / RTR storage usage analysis view, and an application dependency analysis view. Among these: the debug view is the core of the JavaCard perspective, allowing developers to monitor and debug JavaCard applications in real time, typically including breakpoint setting, variable monitoring, expression evaluation, and stack tracing. The standard debug protocol stack is the foundation supporting the debug view, defining the communication protocol between the debugger and the debugged. The performance analysis view provides in-depth analysis of the JavaCard application's performance, including monitoring CPU usage, memory consumption, and thread activity. The CAP file is the installation package of the JavaCard application; the CAP file attribute view allows developers to view detailed information about the CAP file, such as version number, package name, and component list. The bytecode view displays the bytecode instructions of the JavaCard application, which is the intermediate code executed by the Java Virtual Machine (JVM). The non-standard API analysis view is used to identify and analyze non-standard APIs used in the JavaCard application. The CAP decompilation view allows developers to decompile CAP files into readable source code or pseudocode. The DTR (Data Transfer Register) and RTR (Receive / Transmit Register) are registers in JavaCard used for communication with external devices; the DTR / RTR storage usage analysis view provides in-depth analysis of the usage of these registers. The application dependency analysis view displays the dependencies between JavaCard applications, including library dependencies, module dependencies, etc.

[0038] The debug manager communicates with the integrated development platform based on a standard debug protocol and is connected via an APDU (Application Protocol Data Unit) channel. The debug manager communicates with the secure element based on a proprietary debug protocol and is also connected via an APDU channel.

[0039] This disclosure provides a debugging method for an application, applied to a debug manager, in conjunction with... Figure 3 As shown, it includes the following steps:

[0040] S301: Receive standard debug request information based on the standard debug protocol sent by the integrated development platform.

[0041] The IDE sends a standard debug request message, such as "read data at memory address 0x1000", through a standard debug interface (such as a USB debug bridge).

[0042] S302 converts standard debug request information into proprietary debug request information based on a proprietary debug protocol.

[0043] Optionally, the standard debug request information is converted into proprietary debug request information based on a proprietary debug protocol, including: parsing and extracting debug operation information from the standard debug request information; mapping the debug operation information to the data structure of the proprietary debug protocol to obtain proprietary debug request information.

[0044] The debug manager parses the received standard debug request information and extracts debug operation information, such as key information like operation type (read memory) and target address (0x1000). The debug manager maps this debug operation information to the data structures of the smart card's proprietary debug protocol. For example, the proprietary debug protocol requires the use of specific command codes (such as CMD_READ_MEMORY) and parameter formats (such as a specific arrangement of address and length fields).

[0045] Assume the proprietary debugging protocol uses the following format:

[0046] Command code: CMD_READ_MEMORY; Address: 0x1000 (in hexadecimal); Length: 4 bytes (assuming only 4 bytes of data are read).

[0047] The debug manager combines this information into a proprietary debug request message: "CMD_READ_MEMORY; 0x1000; 4 bytes".

[0048] The debug manager converts standard debug request information into proprietary debug request information, enabling the IDE to seamlessly communicate with various security elements using different proprietary debug protocols. Developers do not need to understand the details of each security element's proprietary debug protocol; they can debug using a familiar IDE and standard debug protocol. This reduces development complexity and improves development efficiency. Furthermore, the debug manager can be easily updated or extended to support new standard or proprietary debug protocols, adapting to the ever-changing security elements and technological environment.

[0049] S303, send proprietary debug request information to the secure element to obtain debug response information for the application running proprietary debug request information in the secure element.

[0050] The debug manager sends proprietary debug request information to the smart card through a secure channel (such as APDU commands or specific communication protocols). After processing the request, the smart card returns debug response information, such as "the data at memory address 0x1000 is 0xABCD1234".

[0051] S304, send debug response information to the integrated development platform so that the integrated development platform can analyze the debug response information and determine the fault information of the application in the security element.

[0052] The debug manager receives this response information, converts it back to the standard debug protocol format, and then sends it back to the IDE. Upon receiving the debug response information, the IDE analyzes it and displays it to the developer, helping them determine the application's status or fault information.

[0053] Optionally, the data type of proprietary debugging information in the proprietary debugging protocol is determined as follows: parsing and extracting the proprietary identifier from the proprietary debugging information; if the proprietary identifier is not equal to the first preset identifier and the sum of the proprietary identifier and the second preset identifier is not zero, the data type of the proprietary debugging information is determined to be a response; if the proprietary identifier is equal to the first preset identifier, or the sum of the proprietary identifier and the second preset identifier is zero, the data type of the proprietary debugging information is determined to be a request.

[0054] Here, proprietary debugging information includes proprietary debugging request information or proprietary debugging response information. A request refers to data sent by the debug manager to the secure element, containing the operation the debug manager wants the secure element to perform or the information it wants to obtain, such as proprietary debugging request information. A response refers to data returned by the secure element to the debug manager after receiving the request, containing the result of the secure element's processing of the request or the information requested by the debug manager, such as proprietary debugging response information.

[0055] The data structure for proprietary debugging information is shown in Figure 7 below, where: Figure 7-1 This is a diagram illustrating the data structure of the request for proprietary debugging information. Figure 7-2 This is a schematic diagram of the data structure that responds to proprietary debugging information data types. The data types of proprietary debugging information are distinguished by proprietary identifiers within the proprietary debugging information.

[0056] In some alternative implementations, the first default identifier can be 0xFFFF, and the second default identifier can be 0x7FFF. The second default identifier is a hexadecimal mask used for a bitwise AND operation with the message ID, checking the lower-order bits of the ID (in this case, the lowest 15 bits, since 0x7FFF has 15 consecutive 1s in its binary representation). If the result is not 0, this usually means the message is a response, as responses typically require a unique ID to match the request, and the lower-order bits of this ID are usually not 0 (unless specifically specified by the protocol). This ensures the protocol can distinguish between requests and responses, thus correctly processing the message flow.

[0057] In some embodiments, the debugging method for an application further includes: sending a debugging information deletion instruction to a secure element, so that the secure element deletes the relevant debugging information of the application according to the debugging information deletion instruction.

[0058] The data structure for a debug information deletion command includes a command header, a target application identifier, and a debug information type. The command header includes the command type, command version, and command length. The command type identifies that this is a command to delete debug information; the command version indicates the version of the debug information deletion command data structure; and the command length indicates the length of the entire debug information deletion command data structure, including the command header and subsequent data sections. The target application identifier includes the application ID and application name. The application ID is a unique identifier for the target application and may be numbers, letters, or a combination thereof. The application name is the name of the target application, used to further confirm the application for which debug information is to be deleted. The debug information type includes the information type and information range. The information type specifies the type of debug information to be deleted, such as logs, breakpoints, variable values, etc. The information range specifies the range of debug information to be deleted, such as information within a specific time period, information about a specific module or function, etc.

[0059] After the integrated development platform identifies and debugs the application's fault information within the secure element, the debug manager sends a debug information deletion command to the secure element. This command includes key information such as the application identifier and debug information type to be deleted, ensuring the secure element can accurately identify and delete the relevant debug information. Upon receiving the deletion command, the secure element executes the corresponding deletion operation and returns a confirmation message to the debug manager. The debug manager, upon receiving the confirmation message, can confirm that the relevant debug information has been successfully deleted.

[0060] By employing encrypted communication protocols and secure channels, as well as adding steps to remove debug information, the security and privacy of applications can be effectively protected.

[0061] The application debugging method provided in this disclosure enables communication between an integrated development platform (IDE) and a secure element through a debug manager. The debug manager acts as a bridge, receiving standard debug request information (based on a standard debug protocol) from the IDE, converting it into proprietary debug request information (based on a proprietary debug protocol), and sending it to the secure element. The secure element processes these proprietary debug requests and returns debug response information. The debug manager then sends the debug response information back to the IDE for analysis and to determine application fault information. Through the debug manager, remote debugging of applications within the secure element can be achieved without direct contact with the secure element. The debug manager can handle the conversion between different protocols, enabling the IDE to communicate flexibly with the secure element and improving debugging accessibility. This allows developers to more easily access and debug applications embedded in the secure element.

[0062] This disclosure provides a debugging method for applications, applied to an integrated development platform, combined with... Figure 4 As shown, it includes the following steps:

[0063] S401 generates standard debug request information based on the standard debug protocol.

[0064] S402, send standard debug request information to the debug manager so that the debug manager can convert the standard debug request information into proprietary debug request information based on the proprietary debug protocol, and send proprietary debug request information to the secure element to obtain debug response information of the application running proprietary debug request information in the secure element.

[0065] S403 obtains and analyzes the debug response information sent by the debug manager to determine the fault information of the application in the secure element.

[0066] In some embodiments, the debugging method for the application further includes: obtaining the user's identity information and work requirements; and displaying a view based on the user's identity information and work requirements.

[0067] In specific application scenarios, when the user's identity is that of a developer and their job requirement is to debug a newly developed application, a debug view, a bytecode view, and a performance analysis view are displayed. This allows developers to view the program's runtime status, variable values, and performance data in real time, enabling them to quickly locate and resolve problems.

[0068] In specific application scenarios, where the user's identity is that of a security auditor and their job requirement is to assess the security of an application, a non-standard API analysis view and a cap decompilation view are displayed. This allows the security auditor to analyze the non-standard APIs and source code used in the application to accurately assess its potential security risks.

[0069] In specific application scenarios, where the user's identity is that of a project manager and their job requirement is to assess the overall progress and resource usage of the project, an application dependency analysis view and a DTR / RTR storage usage analysis view are displayed. This allows the project manager to easily understand the dependencies between applications and resource usage, enabling them to assess the overall project progress and potential resource bottlenecks.

[0070] The system can flexibly display the corresponding view based on the user's identity information and work requirements, thereby improving debugging efficiency and user experience.

[0071] In this embodiment of the disclosure, by generating standard debug request information based on a standard debug protocol and communicating with the debug manager, the debugging process can be simplified, reducing complexity and uncertainty during debugging. The debug manager can convert standard debug request information into proprietary debug request information, enabling the debugging process to seamlessly adapt to the proprietary debug protocol of the secure element, thereby improving the accuracy and efficiency of debugging. Simultaneously, using a proprietary debug protocol to communicate with the secure element ensures data security and privacy protection during the debugging process, preventing the leakage of sensitive information.

[0072] This disclosure provides a debugging method for applications, applied to secure elements, in conjunction with... Figure 5 As shown, it includes the following steps:

[0073] S501, obtain proprietary debug request information sent by the debug manager; wherein, the proprietary debug request information is converted by the debug manager from the standard debug request information based on the proprietary debug protocol.

[0074] S502, applications in the secure element run proprietary debug request information and obtain debug response information.

[0075] S503 sends debug response information to the debug manager, so that the debug manager sends debug response information to the integrated development platform, and the integrated development platform analyzes the debug response information and determines the fault information of the application in the security element.

[0076] Optionally, the secure element includes a debug agent terminal and a secure element body, wherein the debug agent terminal is connected to both the debug manager and the secure element body; wherein: the debug agent terminal obtains proprietary debug request information sent by the debug manager and sends proprietary debug request information to the secure element body; the application in the secure element body runs the proprietary debug request information and obtains debug response information, and sends debug response information to the debug agent terminal; the debug agent terminal sends debug response information to the debug manager.

[0077] By decomposing the debugging process into three main parts—the debug manager, the debug proxy terminal, and the secure element body—greater flexibility and scalability are provided. The debug proxy terminal, acting as an intermediate layer, can easily adapt to different secure elements and debugging protocols, enabling the entire debugging system to handle various complex application scenarios. This design allows for updates to the debug proxy terminal only when a new secure element or debugging protocol needs to be introduced, without requiring large-scale modifications to the entire debugging system. The introduction of the debug proxy terminal also enhances the security and reliability of the debugging process. It acts as a security isolation layer, preventing sensitive information from being leaked to external attackers. Simultaneously, the debug proxy terminal can verify and filter debug requests and responses, ensuring that only legitimate debug information is transmitted to the secure element body. This design effectively protects sensitive data within the secure element and ensures the secure operation of applications.

[0078] Combination Figure 6 As shown in the embodiments of this disclosure, a debugging method for an application is provided, including the following steps:

[0079] S601, the integrated development platform generates standard debug request information based on the standard debug protocol.

[0080] Configure the relevant parameters for remote debugging in the IDE (such as Eclipse, IntelliJ IDEA, etc.), including the IP address and port number of the debug manager. The IDE establishes a TCP / IP connection with the debug manager through the upstream connection manager.

[0081] S602, the integrated development platform sends standard debug request information to the debug manager.

[0082] Once the connection is established, the IDE can send a Request Packet containing standard debug request information to the debug manager. Standard debug request information follows the jdwp (Java Debug Wire Protocol) standard debugging protocol and includes commands such as setting breakpoints, querying variable values, and executing steps.

[0083] In some specific implementations, a breakpoint is set on line 10 in the IDE, and remote debugging is initiated. The IDE sends a Request Packet containing "Set breakpoint on line 10" to the debug manager via the upstream connection manager.

[0084] S603, the debug manager obtains standard debug request information.

[0085] S604, the debug manager converts standard debug request information into proprietary debug request information based on a proprietary debug protocol.

[0086] After receiving the Request Packet sent by the IDE, the debug manager converts it into a proprietary debug protocol that can be recognized by SE cos (Security Element Card Operating System) through a debug protocol converter.

[0087] S605, the debug manager sends proprietary debug request information to the secure element.

[0088] After the conversion is complete, the debug manager sends the converted proprietary debug request information to the device debug agent terminal through the downlink connection manager.

[0089] In some specific implementations, after the debug manager receives the "Set breakpoint at line 10" request packet from the IDE, it converts it into a "Set breakpoint" command in the SE cos proprietary debugging protocol and sends it to the device debug agent terminal via the downlink connection manager. Upon receiving the command, the device debug agent terminal forwards it to SE cos.

[0090] S606, the secure element receives proprietary debug request information sent by the debug manager.

[0091] S607, applications in the secure element run proprietary debug request information and obtain debug response information.

[0092] After receiving a proprietary debugging request from the device debugging agent terminal, SE cos executes the corresponding debugging operation based on the proprietary debugging request. For example, if the debugging information is "set breakpoint", SE cos will set a breakpoint on the specified line of code.

[0093] S608, the safety element sends debug response information to the debug manager.

[0094] After completing the debugging operation, SE cos will return the debugging response information (such as whether the breakpoint was set successfully, variable values, etc.) to the debug manager through the device debugging agent terminal.

[0095] In some specific implementations, after receiving the command "Set breakpoint on line 10", SE cos successfully sets the breakpoint on line 10 and returns a debugging result containing the message "Breakpoint set successfully" to the debug manager through the device debug agent terminal.

[0096] S609, the debug manager sends debug response information to the integrated development platform.

[0097] After receiving the debug response information returned by SE cos, the debug manager returns it to the IDE through the upstream connection manager.

[0098] S610, the integrated development platform obtains and analyzes the debug response information sent by the debug manager to determine the fault information of the application in the secure element.

[0099] After receiving debugging information, the IDE updates the debug view or debug information panel based on this information. The IDE displays relevant debugging information based on the debugging response, such as whether breakpoints were set successfully, changes in variable values, stack information, etc.

[0100] In some specific implementations, after the debug manager receives the "breakpoint set successfully" debug response from SE cos, it returns it to the IDE via the upstream connection manager. Upon receiving this debug response, the IDE displays the message "breakpoint set on line 10" in the debug view or debug information panel.

[0101] The following is a specific application scenario to further illustrate the technical solution of the embodiments of this disclosure.

[0102] Scenario Description: Customer C requires a smart card application that supports a specific function (Applet 1). Developer A is responsible for developing this application using an IDE (such as Eclipse) and completing initial local testing. After passing the tests, Developer A converts the application into a format suitable for smart card operation (such as a CAP file) and hands it over to front-end technical support B. During on-site integration testing at the customer's location, B discovers a bug that can only be reproduced in the customer's on-site environment.

[0103] In this scenario, Developer A deploys a debug manager in the cloud, while Technical Support B, at the customer's site, connects to the cloud-based debug manager via a device with Applet1 installed. Developer A uses the debug manager's UI to send Applet1's debug information (such as breakpoints and variable information) to the SE (Secure Element) or the COS (Card Operating System) on the smart card. Developer A launches the IDE and connects to the cloud-based debug manager to receive and send debug information in real time. Developer A sets breakpoints in the IDE and sends commands to the SE or smart card via the APDU (Application Protocol Data Unit) channel. When the COS on the SE or smart card reaches the set breakpoint, a breakpoint event is triggered, notifying the IDE. Upon receiving the breakpoint event, the IDE stops the code at the breakpoint. Developer A uses the IDE's step-by-step debugging function to execute the code step by step to find the location of the exception. After locating and fixing the problem in the IDE, Developer A can continue debugging or testing until the problem is confirmed to be resolved. Developer A uses the debug manager's UI to send commands to remove Applet1's debug information from the SE or smart card's COS to ensure application security.

[0104] When the COS on the SE or smart card needs to be upgraded, R&D team A only needs to send the COS upgrade file to technical support team B. Since the debug manager is already deployed and configured, no further operations or porting work are required for remote debugging. Technical support team B can then use the upgrade file to upgrade the SE or smart card at the customer's site and ensure the upgraded system functions correctly.

[0105] In this application's technical solution, an indirect communication between the integrated development platform (IDE) and the secure element is achieved by introducing a debug manager as an intermediary. The debug manager receives standard debug requests from the IDE and converts them into proprietary debug requests that the secure element can understand. This design allows developers to debug the secure element without direct contact, significantly improving debugging flexibility. Furthermore, the proprietary debug protocol between the debug manager and the secure element ensures accurate transmission of debug information. The debug manager receives debug responses from the secure element and sends them back to the IDE, allowing developers to view and analyze debug information in real time on the IDE, enabling rapid location and resolution of application faults. This design not only improves debugging accessibility but also reduces debugging difficulty and cost. In addition, the debug manager, acting as an intermediary, can filter and optimize debug requests and responses to reduce unnecessary communication overhead and processing time. This design not only enhances debugging security but also optimizes the debugging process, making it more efficient and reliable.

[0106] Combination Figure 8As shown, this disclosure provides an electronic device (e.g., a debug manager, integrated development platform, secure element, computer, server, etc.) 800, including a processor 80 and a memory 81, and may also include a communication interface 82 and a bus 83. The processor 80, communication interface 82, and memory 81 can communicate with each other via the bus 83. The communication interface 82 can be used for information transmission. The processor 80 can call logical instructions in the memory 81 to execute the debugging method for application programs described in the above embodiments.

[0107] Furthermore, the logic instructions in the aforementioned memory 81 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0108] The memory 81, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 80 executes functional applications and data processing by running the program instructions / modules stored in the memory 81, that is, it implements the debugging method for the application program in the above method embodiments.

[0109] The memory 81 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 81 may include high-speed random access memory and may also include non-volatile memory.

[0110] The electronic device provided in this disclosure enables communication between an integrated development platform (IDE) and a secure element via a debug manager. The debug manager acts as a bridge, receiving standard debug request information (based on a standard debug protocol) from the IDE, converting it into proprietary debug request information (based on a proprietary debug protocol), and sending it to the secure element. The secure element processes these proprietary debug requests and returns debug response information. The debug manager then sends the debug response information back to the IDE for analysis and to determine application fault information. Through the debug manager, remote debugging of applications within the secure element can be achieved without direct contact with the secure element. The debug manager can handle conversions between different protocols, enabling the IDE to communicate flexibly with the secure element and improving debugging accessibility. This allows developers to more easily access and debug applications embedded in the secure element.

[0111] This disclosure provides a computer-readable storage medium storing computer-executable instructions configured to perform the above-described debugging method for an application.

[0112] This disclosure provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the above-described debugging method for an application.

[0113] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0114] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code; it can also be a transient storage medium.

[0115] The foregoing description and accompanying drawings fully illustrate embodiments of the present disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included or substituted for parts and features of other embodiments. The scope of the embodiments of this disclosure includes the entire scope of the claims and all available equivalents of the claims. While the terms “first,” “second,” etc., may be used in this application to describe elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be called a second element without changing the meaning of the description, and similarly, a second element may be called a first element, provided that all occurrences of “first element” are consistently renamed and all occurrences of “second element” are consistently renamed. First and second elements are both elements, but may not be the same element. Moreover, the terminology used in this application is only for describing embodiments and is not intended to limit the claims. As used in the description of the embodiments and claims, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to also include the plural forms. Similarly, the term “and / or” as used herein means including one or more of the associated listed elements and all possible combinations thereof. Additionally, when used herein, the terms “comprise” and its variations “comprises” and / or “comprising” refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase “comprising an…” does not exclude the presence of additional identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0116] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0117] The methods and products (including but not limited to devices and equipment) disclosed in the embodiments herein can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed units may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to implement this embodiment according to actual needs. Furthermore, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0118] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. A debugging method for an application, characterized in that, Applied to the debug manager, which connects to both the secure element and the integrated development platform, the debug methods include: Obtain standard debug request information based on the standard debug protocol sent by the integrated development platform; Transform standard debug request information into proprietary debug request information based on a proprietary debug protocol; Send a proprietary debug request message to the secure element to obtain debug response information for the application running the proprietary debug request message in the secure element; Send debug response information to the integrated development platform so that the integrated development platform can analyze the debug response information and determine the fault information of the application in the security element.

2. The debugging method according to claim 1, characterized in that, Converting standard debug request information into proprietary debug request information based on a proprietary debug protocol includes: Parse and extract debugging operation information from standard debug request information; The debugging operation information is mapped to the data structure of the proprietary debugging protocol to obtain proprietary debugging request information.

3. The debugging method according to claim 1, characterized in that, The data type of proprietary debugging information in the proprietary debugging protocol shall be determined as follows: Parse and extract proprietary identifiers from proprietary debugging information; If the proprietary identifier is not equal to the first preset identifier and the sum of the proprietary identifier and the second preset identifier is not zero, the data type of the proprietary debugging information is determined to be a response. If the proprietary identifier is equal to the first preset identifier, or if the sum of the proprietary identifier and the second preset identifier is zero, the data type of the proprietary debugging information is determined to be a request.

4. The debugging method according to claim 1, 2 or 3, characterized in that, Also includes: Send a debug information deletion command to the secure element so that the secure element deletes the relevant debug information of the application according to the debug information deletion command.

5. A debugging method for an application, characterized in that, It is used in an integrated development platform (IDE), which connects to a debug manager. Debugging methods include: Generate standard debug request information based on the standard debug protocol; Send standard debug request information to the debug manager so that the debug manager can convert the standard debug request information into proprietary debug request information based on the proprietary debug protocol, and send proprietary debug request information to the secure element to obtain debug response information of the application running proprietary debug request information in the secure element; Obtain and analyze the debug response information sent by the debug manager to determine the fault information of the application in the secure element.

6. The debugging method according to claim 5, characterized in that, Also includes: Obtain user identity information and work requirements; The view is displayed based on the user's identity information and work requirements.

7. A debugging method for an application, characterized in that, Applied to the safety element, the safety element connects to the debug manager, and the debugging methods include: Obtain proprietary debug request information sent by the debug manager; wherein, the proprietary debug request information is converted from standard debug request information by the debug manager based on proprietary debug protocol; Applications within the secure element execute proprietary debug request information and obtain debug response information; Send debug response information to the debug manager, so that the debug manager sends debug response information to the integrated development platform, which then analyzes the debug response information and determines the application's fault information in the secure element.

8. The debugging method according to claim 7, characterized in that, The secure element includes a debug agent terminal and a secure element body. The debug agent terminal is connected to both the debug manager and the secure element body. The debugging agent terminal obtains the proprietary debugging request information sent by the debugging manager and sends the proprietary debugging request information to the secure element body; The application in the secure element body runs proprietary debug request information and obtains debug response information, and sends debug response information to the debug agent terminal; The debugging agent terminal sends debugging response information to the debugging manager.

9. A debugging system for an application, characterized in that, include: The integrated development platform is configured to generate standard debug request information based on standard debug protocols, analyze debug response information of application-specific debug request information in the secure element, and determine fault information of the application in the secure element. The safety element, with an application installed, is configured to execute proprietary debug request information and obtain debug response information for the application. The debug manager, which includes an uplink connection manager and a downlink connection manager, connects to the integrated development platform via the uplink connection manager and to the secure element via the downlink connection manager. It is configured to receive standard debug request information sent by the integrated development platform. Convert standard debug request information into proprietary debug request information based on a proprietary debug protocol; send proprietary debug request information to the secure element; Send debug response information to the integrated development platform.

10. An electronic device comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to perform the debugging method for an application as described in any one of claims 1 to 8 when executing the program instructions.

Images