Code debugging method and device, equipment, storage medium and product

Abstract

Embodiments of the present application provide a code debugging method, device, equipment, storage medium and product. The method comprises: constructing a code stub according to environment configuration information of a running environment in which an original code is located, inserting the code stub into the original code to obtain a measured code; collecting current consumption characteristics of the measured code in a running process; and locating an anomaly according to the current consumption characteristics and an identification current consumption characteristic corresponding to the code stub. By inserting the code stub capable of generating the identification current consumption characteristic into the measured code, the code execution position is directly associated with the current change, without relying on the limited IO interface of the smart card, thereby realizing non-intrusive debugging. Meanwhile, the debugging is directly performed in the product packaging form of the smart card chip, thereby ensuring the authenticity of the fault reproduction environment. Based on the identification current characteristic, the code execution position can be accurately anchored, thereby reducing the tracking difficulty under a large amount of code, and finally realizing efficient and accurate positioning of the smart card code anomaly.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a code debugging method, apparatus, device, storage medium and product. Background Technology

[0002] Traditional methods have significant limitations in debugging smart card chip products: Firstly, the code volume in smart card form factor is enormous and the IO (Input / Output) communication capability is limited, making it difficult to efficiently trace the code execution flow when directly debugging based on this form factor, leading to complex problem localization. Secondly, if other packaged chips are used for debugging, the packaging differences will change the chip's electrical characteristics and operating environment, making it impossible to reproduce the problems unique to smart cards. In addition, debugging methods that print out status words through the smart card's IO interface may damage the card's original operating state or even cause physical damage, further hindering the reproduction and analysis of specific problems. Summary of the Invention

[0003] This invention provides a code debugging method, apparatus, device, storage medium, and product that can solve the technical problem of how to perform code tracing, debugging, and analysis on smart cards and achieve accurate problem localization.

[0004] In a first aspect, embodiments of the present invention provide a code debugging method, the method comprising:

[0005] At least one code stub is constructed based on the environment configuration information of the runtime environment of the original code, and the code stub is inserted into the original code to obtain the code under test;

[0006] The current consumption characteristics of the code under test during operation are collected;

[0007] The abnormal location in the original code is located based on the current consumption characteristics of the code under test and the current consumption characteristics of the identifier corresponding to the code stub.

[0008] In one feasible implementation, the step of locating the abnormal location in the original code based on the current consumption characteristics of the code under test and the identifier current characteristics corresponding to the code stub includes:

[0009] Based on the current consumption characteristics of the code under test and the current consumption characteristics of the identifier corresponding to the code stub, the code under test is separated into code segments to obtain at least one code block corresponding to the code under test and the current consumption characteristics of the code block.

[0010] The current consumption characteristics of the code block are compared with the consumption characteristic template of the code block to identify the abnormal code block;

[0011] The abnormal code block is debugged and analyzed to determine the location of the abnormality in the original code.

[0012] In one feasible implementation, the current consumption characteristics of the code block include the actual power consumption curve of the code block; the consumption characteristic template of the code block includes the standard power consumption curve of the code block.

[0013] The step of comparing the current consumption characteristics of the code block with the consumption characteristic template of the code block to determine the abnormal code block includes:

[0014] The standard power consumption curve and the actual power consumption curve are compared in the time domain to obtain the first comparison result;

[0015] The frequency domain features of the spectrum diagram corresponding to the standard power consumption curve and the spectrum diagram corresponding to the actual power consumption curve are compared to obtain the second comparison result.

[0016] If there is a discrepancy between the first comparison result and the second comparison result, the code block is determined to be an abnormal code block.

[0017] In one feasible implementation, the step of debugging and analyzing the abnormal code block to determine the location of the exception in the original code includes:

[0018] Insert a code stub in the middle of the code segment to be analyzed corresponding to the abnormal code block to obtain the code segment to be analyzed;

[0019] The current consumption characteristics of the code segment to be analyzed during its execution are collected;

[0020] The occurrence status of the identifier feature of the code stub is determined based on the current consumption characteristics of the code segment to be analyzed;

[0021] Based on the occurrence status of the identification features, determine the new segment to be analyzed corresponding to the abnormal code block;

[0022] The process involves inserting a code stub at the middle of the code segment corresponding to the abnormal code block to obtain the code segment to be analyzed, until the length of the new segment to be analyzed is less than or equal to a length threshold. The abnormal location in the original code is then determined based on the new segment to be analyzed.

[0023] In one feasible implementation, the environment configuration information of the runtime environment in which the source code is located includes the reference clock frequency of the runtime environment in which the source code is located.

[0024] The step of constructing at least one code stub based on the environment configuration information of the runtime environment of the original code includes:

[0025] The execution duration of the assembly-level no-instruction in the runtime environment of the original code is determined based on the reference clock frequency of the runtime environment in which the original code is running and the instruction cycle of the assembly-level no-instruction.

[0026] The number of assembly-level empty instructions is determined based on the interactive execution cycle of the runtime environment in which the original code is located and the execution duration of the assembly-level empty instructions.

[0027] The assembly-level empty instructions are continuously hard-coded according to the number of instructions in the assembly-level empty instructions to obtain code stubs.

[0028] In one feasible implementation, the environment configuration information of the runtime environment in which the source code is located includes the reference clock frequency of the runtime environment in which the source code is located.

[0029] The step of constructing at least one code stub based on the environment configuration information of the runtime environment of the original code includes:

[0030] The target clock frequency is determined based on the base clock frequency of the original code's operating environment and the preset downclocking ratio;

[0031] Configure the frequency configuration parameters of the clock controller in the runtime environment of the original code according to the target clock frequency;

[0032] Based on the frequency configuration parameters, code stubs are generated to perform write operations on the configuration register of the clock controller.

[0033] In one feasible implementation, the environment configuration information of the runtime environment in which the original code is located includes the hardware characteristics information of the public key algorithm coprocessor in the runtime environment in which the original code is located.

[0034] The step of constructing at least one code stub based on the environment configuration information of the runtime environment of the original code includes:

[0035] Based on the hardware characteristics of the public key algorithm coprocessor in the runtime environment of the original code, determine the algorithm operation type and the number of operand bits;

[0036] The configuration parameters of the public key algorithm coprocessor are determined based on the algorithm operation type and the number of operand bits.

[0037] Code stubs are generated according to the configuration parameters to control the registers of the public key algorithm coprocessor.

[0038] Secondly, embodiments of the present invention provide a code debugging apparatus, the apparatus comprising:

[0039] A building module is used to build at least one code stub based on the environment configuration information of the runtime environment of the original code, and insert the code stub into the original code to obtain the code under test.

[0040] The acquisition module is used to acquire the current consumption characteristics of the code under test during its operation.

[0041] The positioning module is used to locate the abnormal position in the original code based on the current consumption characteristics of the code under test and the identifier current consumption characteristics corresponding to the code stub.

[0042] Thirdly, embodiments of the present invention provide a code debugging device, the device comprising: a processor, and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the code debugging method as described in the first aspect.

[0043] Fourthly, embodiments of the present invention provide a computer storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the code debugging method of the first aspect is implemented.

[0044] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to execute the code debugging method as described in the first aspect.

[0045] The code debugging method, apparatus, device, storage medium, and product of this invention, by inserting code stubs that can generate identifiers of current consumption characteristics into the code under test, directly correlate the code execution location with current changes. This eliminates the need to rely on the limited I / O interfaces of the smart card, avoiding the risk of chip damage due to communication bandwidth occupation or improper operation, and achieving truly non-intrusive debugging. At the same time, debugging is performed directly in the product packaging of the smart card chip, ensuring the authenticity of the fault reproduction environment. Furthermore, the code execution location can be accurately anchored based on the identifier current characteristics, reducing the difficulty of tracing large amounts of code, and ultimately achieving efficient and accurate localization of smart card code anomalies. Attached Figure Description

[0046] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a schematic flowchart of an embodiment of a code debugging method provided by the present invention;

[0048] Figure 2This is a schematic flowchart of a second embodiment of a code debugging method provided by the present invention;

[0049] Figure 3 This is a flowchart illustrating Embodiment 3 of a code debugging method provided by the present invention;

[0050] Figure 4 This is a schematic diagram of the structure of a code debugging device provided in an embodiment of the present invention;

[0051] Figure 5 This is a schematic diagram of the structure of a code debugging device provided in an embodiment of the present invention. Detailed Implementation

[0052] The features and exemplary embodiments of various aspects of the present invention will now be described in detail. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present invention and not to limit the present invention. For those skilled in the art, the present invention can be practiced without some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present invention by illustrating examples of the invention.

[0053] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0054] Smart cards, an indispensable element of modern life, are widely used in daily life, such as ID cards, bank cards, mobile phone SIM (Subscriber Identity Module) cards, and access control cards. Smart cards generally support fewer interfaces. Taking a contact SIM card as an example, it only requires VCC (Voltage Collector), GND (Ground), Clock, I / O, and Reset signals to complete basic communication functions, such as base station authentication of the SIM card and simple file reading from the SIM card.

[0055] When chips are packaged into smart card form factors, the limited number of communication interfaces and low I / O communication speeds can lead to numerous problems when debugging the code. Therefore, in general, smart card chips are packaged in other ways, such as QFN (Quad Flat No-leads) packages, to support debugging interfaces like JTAG (Joint Test Action Group). JTAG interfaces typically come in 10-pin, 14-pin, and 20-pin configurations; although the number and arrangement of pins differ, they all support chip code simulation debugging and program downloading.

[0056] The following issues exist in smart card chip products: When a smart card chip powers on, it should sequentially execute a series of codes, perform chip configurations and security checks, and return an ATR (Answer To Reset) after all programs have finished executing, indicating that the smart card startup code process has been completed normally. However, during this program execution, the chip may become unresponsive due to program execution errors, and no ATR will be returned. Designers cannot identify the location of the problem in the chip code execution at this moment, making it impossible to effectively solve the problem. Before the smart card ATR returns, the I / O can only return the ATR status word, not the status of the internal program block, making it impossible to debug and trace that part of the code. If debugging is done directly using smart card form factor code, the code volume is very large, and the I / O communication capability is limited, making code debugging and localization extremely complex. If other packaged chip forms are used for code debugging, the problem cannot be reproduced due to differences in chip package forms, making the problem unsolvable. Furthermore, if the status word is printed out via the smart card I / O, the card may be damaged, making it impossible to reproduce the specific problem.

[0057] To address the problems of the prior art, embodiments of this application provide a code debugging method, apparatus, device, storage medium, and product. The code debugging method provided in this application embodiment will be described first below.

[0058] Figure 1 A flowchart illustrating a code debugging method provided in one embodiment of this application is shown. Figure 1 As shown, the method may include steps 210-230:

[0059] Step 210: Construct at least one code stub based on the environment configuration information of the original code's runtime environment, and insert the code stub into the original code to obtain the code under test.

[0060] The execution entity in this embodiment can be a code debugging device, which is a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone. The code debugging device can insert code stubs that generate significant current consumption characteristics into the code that needs debugging; and based on the current consumption characteristics collected during code execution and the significant current consumption characteristics corresponding to the code stubs, it can locate anomalies in the code that needs debugging.

[0061] The original code refers to the original program code that needs to be debugged; the environment configuration information of the runtime environment of the original code refers to the hardware and software environment information in which the original code runs. The hardware environment information includes, but is not limited to, power supply current, package type, clock frequency, etc.; the software environment information includes, but is not limited to, the underlying drivers and security protocols that the code depends on. In this embodiment, the example of the original code running on an embedded device such as a smart card chip is used for illustration. The original code can also run in the environment of other hardware devices; this embodiment does not limit the runtime environment of the original code.

[0062] A code stub is a piece of auxiliary code or chip configuration built based on environmental configuration information to detect the execution status of the original code. Code stubs are highly feasible; without altering the core logic of the original code, executing a code stub generates identifiable current consumption characteristics, serving as a special marker for the corresponding location in the original code, and thus as key information about the code execution location. The current consumption characteristics generated by the code stub can be any of the following: extremely low current plateau, extremely high current plateau, periodic fluctuations of a specific frequency, or other characteristics. This embodiment does not limit the specific form of the current consumption characteristics generated by the code stub.

[0063] Code stubs are constructed based on the environment configuration information of the original code's runtime environment. These stubs then generate identifiable current consumption characteristics within that environment. The constructed code stubs are then inserted into the original code; the original code with the inserted stubs constitutes the code under test.

[0064] Code stub construction schemes include, but are not limited to, the following: making the CPU (Central Processing Unit) execute the nop (No Operation) instruction; reducing the CPU operating frequency of the chip; calling the original code's runtime environment to calculate complex algorithms; and controlling peripheral state switching.

[0065] In some embodiments, after the original code is compiled, the execution time is estimated based on its assembly code size and processing flow to obtain the predicted execution time of the original code. The original code is divided into blocks according to a preset partitioning time (e.g., 1 millisecond), resulting in multiple code blocks. Each code block must contain a complete processing flow during partitioning. Code stubs are inserted at the start and end points of each code block to form the code under test. Code stubs can also be inserted in other ways, such as random insertion or insertion in the middle of the original code; this embodiment does not limit this.

[0066] Optionally, when inserting multiple code stubs in the original code, the same code stub can be used to insert into different positions, or different code stubs can be used to insert into different positions. This embodiment does not limit the specific method of insertion.

[0067] Step 220: Collect the current consumption characteristics of the code under test during operation.

[0068] Current consumption characteristics refer to the dynamic physical characteristics generated by the code under test during its execution. These characteristics include, but are not limited to, any one or more of the following: the dynamic characteristic curve of the current at the chip's power supply terminal changing over time, and the dynamic characteristic curve of the electromagnetic signal radiated by the chip during operation changing over time. Current consumption characteristics are strongly correlated with the logical steps executed by the code under test. The execution of different code segments will cause regular changes in current consumption or electromagnetic radiation; for example, the current increases during complex operations and decreases during idle periods.

[0069] When the code under test is running in the same environment as the original code, a high-precision current probe is connected to a current acquisition device (such as an oscilloscope or current analyzer). The sampling rate must be sufficient to capture the short-term current changes generated by the code studs, thereby capturing the dynamic characteristic curve of the current changing with time during the operation of the code under test. A near-field electromagnetic probe is connected to an electromagnetic acquisition device (such as a high-frequency oscilloscope or spectrum analyzer) to capture the dynamic characteristic curve of the electromagnetic signal changing with time during the operation of the code under test.

[0070] Step 230: Locate the abnormal location in the original code based on the current consumption characteristics of the code under test and the identifier current consumption characteristics corresponding to the code stub.

[0071] The current consumption characteristic corresponding to the code stub refers to the current consumption characteristic generated when the code stub is running; the current consumption characteristic corresponding to the code stub is obtained by means of, but not limited to, the following: the code stub is collected when it runs alone under the preset normal operating environment; or it is obtained through theoretical calculation.

[0072] Optionally, since the current consumption characteristics (such as extremely low / extremely high current plateaus, periodic fluctuations at a specific frequency, etc.) generated during code stub execution differ significantly from the current consumption characteristics generated by the original code in terms of amplitude, duration, or waveform, the current consumption characteristics corresponding to the code stub can be quickly segmented from the current consumption characteristics of the code under test based on this difference. Specifically, the segmentation process can be carried out in one or more of the following ways: Threshold detection method: Based on the known characteristics of the current consumption characteristics generated by the code stub (such as extremely low current values, extremely high current peaks, or specific current change rates), set corresponding amplitude thresholds or derivative thresholds; traverse the current consumption characteristics of the code under test, and when the data in the current consumption characteristics exceeds or falls below a preset threshold and the duration is greater than or equal to the preset execution duration of the code stub, the characteristic segment in the current consumption characteristics is determined to be the current consumption characteristic corresponding to the code stub. Template matching method: Pre-extract or calculate the standard waveform template corresponding to the current consumption feature of each code stub. Using methods such as sliding window, calculate the similarity between the curve corresponding to the current consumption feature of the code under test and the standard waveform template. Similarity algorithms such as correlation coefficient method can be used. When the similarity exceeds the preset matching threshold, it is considered that the current consumption feature of the code stub has been successfully matched and segmented at the window position.

[0073] Based on the current consumption characteristics of each segmented code stub, the actual execution flow of the tested code can be reconstructed by sorting it by time series. This actual execution flow is then matched with a preset code stub sequence (i.e., the expected insertion order of code stubs in the original code). If a sequence anomaly exists, an execution deviation is determined, and the starting point of the execution deviation in the original code is located based on the position of the first anomaly in the preset sequence and the actual execution flow.

[0074] Simultaneously, the segmented current consumption feature is compared with the set of current consumption features of all code stubs inserted in the original code: if a current consumption feature is missing, execution is determined to be interrupted, and the code interval in the original code where execution is interrupted is located based on the insertion position of the code stub corresponding to the missing feature; if a current consumption feature exists but the difference between the actual collected parameters and the preset current consumption feature exceeds a threshold, the code execution at the location of the code stub is determined to be abnormal, and the abnormal interval is located based on the insertion position of the code stub.

[0075] This embodiment inserts code stubs that generate current consumption characteristics into the code under test, directly linking the code execution location to current changes. This eliminates the need to rely on the limited I / O interfaces of the smart card, avoiding the risk of chip damage due to communication bandwidth consumption or improper operation, and achieving truly non-intrusive debugging. At the same time, debugging is performed directly within the product packaging of the smart card chip, ensuring the authenticity of the fault reproduction environment. Furthermore, the code execution location can be accurately anchored based on the identified current characteristics, reducing the difficulty of tracing large amounts of code, and ultimately achieving efficient and accurate localization of smart card code anomalies.

[0076] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step 230 in the code debugging method may include steps 310-330:

[0077] Step 310: Based on the current consumption characteristics of the code under test and the current consumption characteristics of the identifier corresponding to the code stub, the code under test is separated into code segments to obtain at least one code block corresponding to the code under test and the current consumption characteristics of the code block.

[0078] In the current consumption characteristics of the collected code under test, the current consumption characteristics corresponding to the code stubs are accurately located and positioned. The current consumption characteristics corresponding to all code stubs are the boundary markers of the code blocks. There is a code stub at the beginning of each code block and a code stub at the end of each code block.

[0079] Based on the time series of the current consumption characteristics corresponding to all extracted code stubs, the execution time range of each code block is defined. The start and end times of a code block are defined by its adjacent code stubs: the start time of code block n is the end time of the characteristics of code stub n, and the end time of code block n is the start time of the characteristics of code stub n+1. Through this time range segmentation, the current consumption characteristics of the tested code are divided into two parts: one is multiple independent intervals, each interval corresponding to the complete execution process of a code block in the original code; the other is the current consumption characteristics of each of the multiple code stubs, corresponding to the execution process of the code stub.

[0080] Step 320: Compare the current consumption characteristics of the code block with the consumption characteristic template of the code block to identify the abnormal code block.

[0081] The current consumption characteristic template library is created by pre-executing each code block individually or the original code without any exceptions under normal operating conditions, and collecting the current consumption characteristics of each code block during normal execution. The normal operating environment is consistent with the operating environment of the original code.

[0082] Optionally, before debugging the code, when constructing the consumption feature template of the code block, it is necessary to ensure that the execution time of the code block is in the millisecond range, collect the current consumption features of the entire code block and record them completely, so as to avoid a lot of collection and storage work for a large number of code blocks with short execution times.

[0083] In some embodiments, for each code block: the actual collected current consumption characteristics and the consumption characteristic template are compared. When the difference between the current consumption characteristics and the consumption characteristic template exceeds a set difference threshold, the code block is determined to be an abnormal code block. The feature comparison method includes, but is not limited to, correlation coefficient calculation, dynamic time warping, etc., and this embodiment does not limit it.

[0084] Step 330: Debug and analyze the abnormal code block to determine the location of the abnormality in the original code.

[0085] Debugging and analyzing abnormal code blocks includes, but is not limited to, stepping through the code snippets of the abnormal code block and replacing suspicious instructions for testing, in order to locate the code position in the abnormal code block where the exception occurs and use it as the location of the exception in the original code.

[0086] In one feasible implementation, the current consumption characteristics of the code block include the actual power consumption curve of the code block; the consumption characteristic template of the code block includes the standard power consumption curve of the code block; step 320 may include steps A11-A13:

[0087] Step A11: Compare the standard power consumption curve and the actual power consumption curve in the time domain to obtain the first comparison result.

[0088] The actual power consumption curve of a code block refers to the physical power consumption characteristic curve of the code block changing over time during actual operation; the standard curve of a code block refers to the physical power consumption characteristic curve of the code block changing over time when it is executed normally under normal operating conditions. In this embodiment, the physical power consumption characteristic curve is the dynamic characteristic curve of current changing over time, which is used as an example for explanation.

[0089] Optionally, for each code block: Alignment and normalization are performed on the actual power consumption curve and the standard power consumption curve. Key time-domain feature parameters are extracted from the two preprocessed curves, including but not limited to: peak current, valley current, total duration of the curve, and average current of the curve. For the feature parameters, the relative deviation between the actual value and the standard value is calculated; for the overall waveform, the time axes of the two curves are aligned, and a time-domain comparison algorithm is used to calculate the similarity between the two curves.

[0090] By combining the similarity of the two curves and the relative deviation between the feature parameters, a weighted calculation method can be used to obtain the similarity score between the standard power consumption curve and the actual power consumption curve in the time domain dimension. The higher the score, the higher the similarity. The similarity score is compared with a threshold (e.g., 90 points). When the similarity score is greater than the threshold, the first comparison result is considered consistent; when the similarity score is less than or equal to the threshold, the first comparison result is considered inconsistent, indicating that the difference between the actual power consumption curve and the standard power consumption curve is too large.

[0091] Step A12: Compare the frequency domain features of the spectrum diagram corresponding to the standard power consumption curve and the spectrum diagram corresponding to the actual power consumption curve to obtain the second comparison result.

[0092] For each code block: The preprocessed standard power consumption curve and the actual power consumption curve are frequency domain transformed using Fast Fourier Transform (FFT) or Short-Time Fourier Transform (SFT) to convert the curves into corresponding spectrograms. During the transformation, the sampling frequency and transform window size must be consistent. Key frequency domain feature parameters are extracted from the two spectrograms, including but not limited to: characteristic frequency parameters, spectral distribution parameters, and frequency shape parameters. For each feature parameter, the relative deviation between the actual and standard values ​​is calculated. Considering the deviations of all parameters, a weighted calculation method can be used to obtain the similarity score between the standard and actual power consumption curves in the frequency domain dimension. The higher the score, the higher the similarity. The similarity score is compared to a threshold (e.g., 90 points). When the similarity score is greater than the threshold, the second comparison result is considered a match; when the similarity score is less than or equal to the threshold, the second comparison result is considered an inconsistency, indicating that the difference between the actual and standard power consumption curves is too large.

[0093] Step A13: If there is a discrepancy between the first comparison result and the second comparison result, the code block is determined to be an abnormal code block.

[0094] Optionally, for each code block: if the first comparison result and the second comparison result are both consistent, then the code block is determined to be without anomalies; if there are discrepancies between the first comparison result and the second comparison result, and if both are inconsistent, then the code block is an abnormal code block.

[0095] In this embodiment, by combining time-domain and frequency-domain analysis, abnormal code blocks in the original code can be accurately located, avoiding the limitations of single-dimensional comparison and significantly improving the accuracy of abnormal code block determination. This enables high-precision, non-intrusive location of defects in embedded software such as smart cards.

[0096] In one feasible implementation, step 330 may include steps B11-B15:

[0097] Step B11: Insert a code stub in the middle of the code segment to be analyzed corresponding to the abnormal code block to obtain the code segment to be analyzed.

[0098] Step B12: Collect the current consumption characteristics of the code segment to be analyzed during its operation.

[0099] Step B13: Determine the occurrence status of the identifier feature of the code stub based on the current consumption characteristics of the code segment to be analyzed.

[0100] Step B14: Determine the new segment to be analyzed corresponding to the abnormal code block based on the occurrence status of the identification features.

[0101] Step B15: Insert code stubs in the middle of the code segment corresponding to the abnormal code block to obtain the code segment to be analyzed, until the length of the new segment to be analyzed is less than or equal to the length threshold, and determine the abnormal position in the original code based on the new segment to be analyzed.

[0102] The code segment to be analyzed corresponding to the exception code block refers to the local code segment selected from the exception code block that needs to be further located to pinpoint the specific location of the exception. Initially, the code segment to be analyzed is the original code corresponding to the entire exception code block; as the localization process progresses, its scope will gradually narrow down.

[0103] The middle position in the code refers to the intermediate stage in the logical or physical structure of the code segment to be analyzed. It can be determined based on code length, functional division, or execution time, and is used to insert code stubs to separate the segment. In this embodiment, the middle position in the code is determined based on the code length of the code segment to be analyzed.

[0104] The status of the identifier feature of the code stub is used to characterize whether the corresponding identifier current consumption feature of the inserted code stub is collected when the code segment to be analyzed is running. The status of the identifier feature includes two states: present and absent.

[0105] After identifying the abnormal code block, a binary search method can be used to insert code stubs for debugging and analysis. The process can be as follows: insert a code stub in the middle of the code segment to be analyzed corresponding to the abnormal code block; the code segment to be analyzed with the inserted code stub is the code segment to be analyzed; collect the current consumption characteristics of the code segment to be analyzed during its execution; search for the current consumption characteristics of the code segment to be analyzed to see if there is an identifier current consumption characteristic corresponding to the inserted code stub. If it exists, the identifier current consumption characteristic of the code stub is determined to be present; if it does not exist, the identifier current consumption characteristic of the code stub is determined to be missing.

[0106] If the identifier of a code stub is in the "present" state, it means that the exception occurred in the code segment after the code stub insertion position. Therefore, the new code segment to be analyzed is the code segment from the end position of the code stub to the end position of the original code segment to be analyzed. If the identifier of a code stub is in the "missing" state, it means that the exception occurred in the code segment before the code stub insertion position. Therefore, the new code segment to be analyzed is the code segment from the beginning position of the original code segment to the beginning position of the code stub.

[0107] If the length of the new code segment to be analyzed is greater than the length threshold, then steps B11-B14 are repeated based on the new code segment to be analyzed. That is, a code stub is inserted again at the middle position in the new code segment with half the range, and analysis is performed. If the length of the new code segment to be analyzed is less than or equal to the length threshold, then the iteration is terminated. At this time, the new code segment to be analyzed is the smallest range where the abnormal position is located in the original code, and thus the position of the new code segment to be analyzed in the original code is taken as the abnormal position in the original code.

[0108] In this embodiment, a binary search method is used to refine the localization of abnormal code blocks, gradually narrowing down from the initial code block level to the smallest analyzable unit. This solves the problem that embedded devices such as smart card chips cannot be directly debugged due to interface limitations, and significantly improves the accuracy and efficiency of abnormal localization.

[0109] This embodiment separates the tested code into code segments based on the current consumption characteristics of the tested code and the current consumption characteristics of the identifier corresponding to the code stub, obtaining at least one code block corresponding to the tested code and the current consumption characteristics of the code block; the current consumption characteristics of the code block are compared with the consumption characteristic template of the code block to identify abnormal code blocks; the abnormal code blocks are debugged and analyzed to determine the abnormal location in the original code. According to this embodiment, the anomaly location of the original code is refined from the overall process to the code block level, and then to the specific instruction or logic, avoiding the inefficiency of checking line by line in lengthy code, enabling debugging to quickly focus on the core of the problem, solving the problem that embedded devices such as smart card chips cannot be directly debugged due to interface limitations, and improving the efficiency and accuracy of anomaly location.

[0110] Based on any one or more embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In the code debugging method, the environment configuration information of the runtime environment where the original code is located includes the reference clock frequency of the runtime environment where the original code is located; step 210 may include steps 410-430:

[0111] Step 410: Determine the execution duration of the assembly-level no-instruction in the runtime environment of the original code based on the reference clock frequency of the runtime environment where the original code is located and the instruction cycle of the assembly-level no-instruction.

[0112] Power consumption analysis involves collecting the current generated during chip operation, while the chip's operating voltage remains constant. The current is used to characterize the chip's instantaneous power consumption. Currently, power consumption analysis typically involves collecting power consumption information during the computation of cryptographic algorithms to analyze the keys used in those algorithms. Power consumption analysis techniques generally require the use of an oscilloscope and current probe in conjunction with a smart card chip reader. When selecting the parameters of the oscilloscope and current probe, it is necessary to consider the internal operating frequency of the smart card chip's CPU. For example, if the smart card chip's CPU supports a 120MHz clock, the analog bandwidth of the current probe should exceed 120MHz, the analog bandwidth of the oscilloscope should also exceed 120MHz, and the sampling rate of the digital oscilloscope should be more than twice the analog bandwidth to satisfy the Nyquist theorem, such as using a sampling rate of 1G Samples / s.

[0113] Taking the operating environment of the smart card chip as an example, when acquiring current data from the smart card chip, a current probe is connected in series to the VCC or GND pin of the smart card chip and connected to an oscilloscope channel. An I / O communication interface is used for triggering. The smart card chip receives data via I / O and performs logic processing. After acquiring the real-time current value of the smart card chip, a one-to-one correspondence is made between the real-time current curve and the specific CPU instructions executed by the smart card chip. The following challenges exist: smart card chips generally execute at a high clock rate, while the time interval between sending an APDU (Application Protocol Data Unit) instruction, program execution, and the return of the APDU instruction data is relatively long, making it difficult to correlate the power consumption curve with the program code one-to-one. The time from power-on to the return of the ATR (Automatic Transfer Transmission) for a smart card, such as a SIM card, can last from several to tens of milliseconds. Modern smart card manufacturing processes are typically at the 40nm level, with clock frequencies exceeding 100MHz. Therefore, the entire process involves tens of millions of clock cycles and millions of CPU instructions executed. It's impossible to directly correlate real-time current values ​​with specific CPU instructions, and thus, it's impossible to determine the specific location of the smart card's internal program at a given moment. Furthermore, the real-time current of a smart card chip fluctuates, but these fluctuations cannot be directly correlated with specific code. This is because smart card chips contain various physical modules such as SRAM, Flash, bus modules, and communication I / O. The execution of certain code requires specific modules to perform operations, and these modules all contribute to changes in the chip's total current consumption, leading to current fluctuations. Therefore, interference from the operating current of other modules also affects the determination of the timing of the CPU's program execution on the smart card chip.

[0114] Therefore, in this embodiment, code stubs that can generate identifiable current consumption characteristics are constructed for code anomaly localization.

[0115] The base clock frequency refers to the fundamental operating clock frequency of the CPU in the runtime environment of the original code, measured in Hz. The base clock frequency serves as the benchmark for the chip's instruction execution rhythm, determining the time scale of instruction execution. The assembly-level no-op instruction (nop instruction) refers to a no-operation instruction at the assembly language level. Its function is to occupy one instruction cycle without performing any effective computation. When the CPU continuously executes nop instructions, the entire CPU's digital circuit logic no longer flips, thus continuously entering a low-current mode. When monitored externally, a significant decrease in transient real-time current can be observed (e.g., from 10mA to 1mA).

[0116] The instruction cycle of a nop instruction refers to the number of base clock cycles required to execute one nop instruction. Based on the clock base frequency and instruction cycle, the execution time of a single nop instruction in the original code execution environment can be calculated as follows: Execution time = Instruction cycle / Base clock frequency.

[0117] Step 420: Determine the number of assembly-level empty instructions based on the interactive execution cycle of the runtime environment in which the original code is located and the execution duration of the assembly-level empty instructions.

[0118] The interactive execution cycle refers to the execution cycle of APDU instructions in the runtime environment of the original code. Since the execution time of a single nop instruction in the runtime environment of the original code is relatively short, if the interactive execution cycle of the runtime environment of the original code is relatively long, the current consumption characteristics of a single nop instruction will be masked.

[0119] To ensure that the CPU enters low-power mode for a sufficiently long time and finds the nop instruction in a large amount of code as quickly as possible, the number of nop instructions can be determined based on the interactive execution cycle and the execution time of a single nop instruction in the original code's runtime environment, thereby increasing the execution time of all nop instructions.

[0120] Optionally, the number of nop instructions can be determined based on the following formula: Number of instructions = Interactive execution cycle / Execution time of a single nop instruction, thus obtaining the number of nop instructions required to construct the code stub. Other methods can also be used to determine the number of instructions, and this embodiment does not limit this.

[0121] Step 430: Hard-encode the assembly-level empty instructions continuously according to the number of assembly-level empty instructions to obtain code stubs.

[0122] Instead of dynamically generating or calling `nop` instructions, they are written directly into the code in a continuous, fixed format. This ensures that the execution logic of the code stubs is immutable, preventing the presence of digital logic components running and thus avoiding the CPU constantly switching between low and high power consumption, which would ultimately lead to fluctuations in current characteristics. Furthermore, the code stubs are compatible with the original code's compilation and runtime environment, and the total number of `nop` instructions written matches the number of `nop` instructions, resulting in the constructed code stubs.

[0123] For example, if there are 10,000 instructions, 10,000 NOP instructions are constructed using continuous hard coding to obtain the completed code stubs. At this time, the execution time of the code stubs is 83 microseconds. It is easier to find the location of the code stubs with continuous low power consumption characteristics based on the current consumption characteristics of the original code.

[0124] In one feasible implementation, the environment configuration information of the runtime environment where the original code is located includes the reference clock frequency of the runtime environment where the original code is located; step 210 may further include steps C11-C13:

[0125] Step C11: Determine the target clock frequency based on the reference clock frequency of the original code's operating environment and the preset downclocking ratio.

[0126] Step C12: Configure the frequency configuration parameters of the clock controller in the runtime environment of the original code according to the target clock frequency.

[0127] Step C13: Generate code stubs for writing to the configuration register of the clock controller according to the frequency configuration parameters.

[0128] The preset downclocking ratio refers to a pre-defined percentage reduction in the reference clock frequency. Since the chip's power is proportional to the square of the clock frequency, reducing the chip's CPU operating frequency lowers the chip's operating current, which can be detected by an external current probe. Therefore, the preset downclocking ratio must be chosen to ensure a sufficiently large difference between the downclocked clock frequency and the original code execution frequency to create a identifiable characteristic. In this embodiment, the preset downclocking ratio is set to 0.25.

[0129] The target clock frequency is the temporary operating frequency that the chip needs to switch to when the code stub is triggered. In this embodiment, the target clock frequency = reference clock frequency × preset downclocking ratio. Frequency control parameters are specific parameters used to configure the clock controller to output the target clock frequency, including but not limited to the division factor and enable signal.

[0130] In addition to the code stub construction method proposed in steps 410-430, the code stub can also be constructed using steps C11-C13. The construction process can be as follows: determine the configuration of the clock controller in the runtime environment of the original code; based on the clock controller architecture, calculate the frequency configuration parameters required to achieve the target clock frequency. The configuration method includes, but is not limited to, calculation of the division factor, multiplication factor, and combination of division factors. After obtaining the frequency configuration parameters of the clock controller, generate an instruction sequence that writes the parameters to the configuration register. This instruction sequence is the code stub that can reduce the CPU operating frequency.

[0131] For example, when a smart card chip is operating normally at 120MHz, after executing the code stub that changes the CPU's operating frequency, the CPU runs at 30MHz. At this point, the chip's transient power consumption becomes 1 / 16 of its original value. Considering other factors such as background noise and leakage current, the chip's overall power consumption does not change drastically, but it still shows a significant decrease, and then continues to operate at a low power level. The point at which the power consumption curve shows a clear step change is the location of the code stub that changes the CPU's operating frequency.

[0132] In this embodiment, the significant current difference generated by the dynamic switching of clock frequency is used to generate corresponding code stubs, providing reliable physical markers for subsequent current consumption characteristic acquisition and anomaly localization.

[0133] In one feasible implementation, the environment configuration information of the runtime environment where the original code resides includes the hardware characteristics information of the public key algorithm coprocessor in the runtime environment where the original code resides; step 210 may further include steps D11-D13:

[0134] Step D11: Determine the algorithm operation type and operand bit length based on the hardware characteristics of the public key algorithm coprocessor in the runtime environment of the original code.

[0135] Step D12: Determine the configuration parameters of the public key algorithm coprocessor based on the algorithm operation type and the number of operands.

[0136] Step D13: Generate code stubs for controlling the registers of the public key algorithm coprocessor according to the configuration parameters.

[0137] Hardware characteristic information refers to the inherent hardware parameters and functional limitations of the public-key algorithm coprocessor, including but not limited to: supported public-key algorithm types (e.g., ECC, RSA), maximum number of operands, and executable operation subtypes. Algorithm operation type refers to the specific computational logic that the public-key algorithm coprocessor can execute. Operand bit length refers to the length of binary data processed by the public-key algorithm coprocessor during computation. Configuration parameters refer to the set of parameters used to control the public-key algorithm coprocessor to execute specific operations, including but not limited to: algorithm selection code, operation subtype code, and operand length code.

[0138] In addition to the code stub construction methods proposed in steps 410-430 and C11-C13, the code stub construction method in steps D11-D13 can also be used. The construction process can be as follows: From the hardware characteristic information of the public key algorithm coprocessor in the original code's running environment, filter out the algorithm operation type and operand bit length; query the hardware manual of the public key algorithm coprocessor to determine the key registers and bit definitions that control the operation; convert the algorithm operation type and operand bit length into the parameter values ​​corresponding to the registers according to the algorithm operation type and operand bit length; integrate the parameters of each register into configuration parameters in address order; generate an instruction sequence that writes the configuration parameters into the corresponding registers. This instruction sequence is the code stub that can run the public key cryptographic algorithm.

[0139] Running public-key cryptographic algorithms involves numerous registers and caches process results, heavily utilizing SRAM (Static Random-Access Memory) for data caching. Furthermore, the algorithm typically involves reading data from lower addresses while simultaneously writing data to higher addresses. Therefore, to ensure correct execution, dual-port SRAM is used to meet the requirements of public-key cryptographic algorithms. When running the code stubs of a public-key cryptographic algorithm, the chip's power consumption increases momentarily, returning to normal after the computation is complete. Therefore, using the code stubs for running public-key cryptographic algorithms allows for clear location of the code position on the power consumption curve.

[0140] In this embodiment, the hardware characteristics of the public key algorithm coprocessor are used to construct corresponding code stubs, thereby generating highly identifiable current consumption characteristics. This not only does not interfere with the core logic of the original code, but also accurately marks the code execution nodes, providing stable physical markers for subsequent current characteristic analysis and anomaly localization.

[0141] This embodiment determines the execution duration of the assembly-level no-instruction in the runtime environment of the original code based on the reference clock frequency of the runtime environment and the instruction cycle of the assembly-level no-instruction; it determines the number of assembly-level no-instructions based on the interactive execution cycle of the runtime environment and the execution duration of the assembly-level no-instruction; and it continuously hard-codes the assembly-level no-instructions according to the number of assembly-level no-instructions to obtain code stubs. According to this embodiment, it is possible to generate code stubs with accurate timing and stable characteristics, providing reliable marking signals for subsequent current consumption characteristic acquisition and anomaly localization.

[0142] like Figure 4 As shown, this application embodiment provides a code debugging device 200, which may include a construction module 201, a collection module 202 and a positioning module 203;

[0143] The construction module 201 is used to construct at least one code stub based on the environment configuration information of the runtime environment of the original code, and insert the code stub into the original code to obtain the code under test.

[0144] The acquisition module 202 is used to acquire the current consumption characteristics of the code under test during its operation.

[0145] The positioning module 203 is used to locate the abnormal position in the original code based on the current consumption characteristics of the code under test and the identifier current consumption characteristics corresponding to the code stub.

[0146] Optionally, the positioning module 203 is further configured to:

[0147] Based on the current consumption characteristics of the code under test and the current consumption characteristics of the identifier corresponding to the code stub, the code under test is separated into code segments to obtain at least one code block corresponding to the code under test and the current consumption characteristics of the code block.

[0148] The current consumption characteristics of the code block are compared with the consumption characteristic template of the code block to identify the abnormal code block;

[0149] The abnormal code block is debugged and analyzed to determine the location of the abnormality in the original code.

[0150] Optionally, the positioning module 203 is further configured to:

[0151] The standard power consumption curve and the actual power consumption curve are compared in the time domain to obtain the first comparison result;

[0152] The frequency domain features of the spectrum diagram corresponding to the standard power consumption curve and the spectrum diagram corresponding to the actual power consumption curve are compared to obtain the second comparison result.

[0153] If there is a discrepancy between the first comparison result and the second comparison result, the code block is determined to be an abnormal code block.

[0154] Optionally, the positioning module 203 is further configured to:

[0155] Insert a code stub in the middle of the code segment to be analyzed corresponding to the abnormal code block to obtain the code segment to be analyzed;

[0156] The current consumption characteristics of the code segment to be analyzed during its execution are collected;

[0157] The occurrence status of the identifier feature of the code stub is determined based on the current consumption characteristics of the code segment to be analyzed;

[0158] Based on the occurrence status of the identification features, determine the new segment to be analyzed corresponding to the abnormal code block;

[0159] The process involves inserting a code stub at the middle of the code segment corresponding to the abnormal code block to obtain the code segment to be analyzed, until the length of the new segment to be analyzed is less than or equal to a length threshold. The abnormal location in the original code is then determined based on the new segment to be analyzed.

[0160] Optionally, the building module 201 is further configured to:

[0161] The execution duration of the assembly-level no-instruction in the runtime environment of the original code is determined based on the reference clock frequency of the runtime environment in which the original code is running and the instruction cycle of the assembly-level no-instruction.

[0162] The number of assembly-level empty instructions is determined based on the interactive execution cycle of the runtime environment in which the original code is located and the execution duration of the assembly-level empty instructions.

[0163] The assembly-level empty instructions are continuously hard-coded according to the number of instructions in the assembly-level empty instructions to obtain code stubs.

[0164] Optionally, the building module 201 is further configured to:

[0165] The target clock frequency is determined based on the base clock frequency of the original code's operating environment and the preset downclocking ratio;

[0166] Configure the frequency configuration parameters of the clock controller in the runtime environment of the original code according to the target clock frequency;

[0167] Based on the frequency configuration parameters, code stubs are generated to perform write operations on the configuration register of the clock controller.

[0168] Optionally, the building module 201 is further configured to:

[0169] Based on the hardware characteristics of the public key algorithm coprocessor in the runtime environment of the original code, determine the algorithm operation type and the number of operand bits;

[0170] The configuration parameters of the public key algorithm coprocessor are determined based on the algorithm operation type and the number of operand bits.

[0171] Code stubs are generated according to the configuration parameters to control the registers of the public key algorithm coprocessor.

[0172] Figure 5 A schematic diagram of the hardware structure of the code debugging device provided in an embodiment of the present invention is shown.

[0173] The code debugging device may include a processor 301 and a memory 302 storing computer program instructions.

[0174] Specifically, the processor 301 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0175] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 302 may include removable or non-removable (or fixed) media, or memory 302 may be non-volatile solid-state memory. Memory 302 may be internal or external to the integrated gateway disaster recovery device.

[0176] In one instance, memory 302 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0177] Memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0178] The processor 301 reads and executes computer program instructions stored in the memory 302 to achieve... Figure 1 The code debugging method in the illustrated embodiment.

[0179] In one example, the code debugging device may also include a communication interface 303 and a bus 304. Wherein, as Figure 5 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 304 and complete communication with each other.

[0180] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of the present invention.

[0181] Bus 304 includes hardware, software, or both, that couples components of a code debugging device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 304 may include one or more buses. While specific buses are described and illustrated in embodiments of the invention, the invention contemplates any suitable bus or interconnect.

[0182] This code debugging device can be based on code debugging methods to achieve integration. Figures 1-3 Describes the methods for debugging the code.

[0183] Furthermore, in conjunction with the code debugging methods described in the above embodiments, this invention can be implemented using a computer storage medium. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the code debugging methods described in the above embodiments.

[0184] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the code debugging methods described in the above embodiments.

[0185] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0186] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0187] It should also be noted that the exemplary embodiments mentioned in this invention describe methods or systems based on a series of steps or apparatus. However, this invention is not limited to the order of the steps described above; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0188] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0189] The above description is merely a specific embodiment of the present invention. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the protection scope of the present invention.

Claims

1. A code debugging method, characterized in that, The method includes: At least one code stub is constructed based on the environment configuration information of the runtime environment of the original code, and the code stub is inserted into the original code to obtain the code under test; The current consumption characteristics of the code under test during operation are collected; The abnormal location in the original code is located based on the current consumption characteristics of the code under test and the current consumption characteristics of the identifier corresponding to the code stub. The step of constructing at least one code stub based on the environment configuration information of the original code's runtime environment includes any of the following methods: The environment configuration information of the runtime environment where the original code is located includes the base clock frequency of the runtime environment where the original code is located; the execution duration of the assembly-level no-instruction in the runtime environment where the original code is located is determined based on the base clock frequency of the runtime environment where the original code is located and the instruction cycle of the assembly-level no-instruction; the number of assembly-level no-instructions is determined based on the interactive execution cycle of the runtime environment where the original code is located and the execution duration of the assembly-level no-instruction; the assembly-level no-instructions are continuously hard-coded according to the number of assembly-level no-instructions to obtain code stubs; or The environment configuration information of the runtime environment where the original code is running includes the base clock frequency of the runtime environment; a target clock frequency is determined based on the base clock frequency and a preset downclocking ratio; frequency configuration parameters of the clock controller in the runtime environment of the original code are configured according to the target clock frequency; and code stubs are generated to write to the configuration register of the clock controller according to the frequency configuration parameters; or The environment configuration information of the runtime environment where the original code is running includes the hardware characteristics information of the public key algorithm coprocessor in the runtime environment where the original code is running; based on the hardware characteristics information of the public key algorithm coprocessor in the runtime environment where the original code is running, the algorithm operation type and the number of operand bits are determined; based on the algorithm operation type and the number of operand bits, the configuration parameters of the public key algorithm coprocessor are determined; and code stubs for controlling the registers of the public key algorithm coprocessor are generated according to the configuration parameters.

2. The method according to claim 1, characterized in that, The step of locating the abnormal location in the original code based on the current consumption characteristics of the tested code and the identifier current characteristics corresponding to the code stub includes: Based on the current consumption characteristics of the code under test and the current consumption characteristics of the identifier corresponding to the code stub, the code under test is separated into code segments to obtain at least one code block corresponding to the code under test and the current consumption characteristics of the code block. The current consumption characteristics of the code block are compared with the consumption characteristic template of the code block to identify the abnormal code block; The abnormal code block is debugged and analyzed to determine the location of the abnormality in the original code.

3. The method according to claim 2, characterized in that, The current consumption characteristics of the code block include the actual power consumption curve of the code block; the consumption characteristic template of the code block includes the standard power consumption curve of the code block. The step of comparing the current consumption characteristics of the code block with the consumption characteristic template of the code block to determine the abnormal code block includes: The standard power consumption curve and the actual power consumption curve are compared in the time domain to obtain the first comparison result; The frequency domain features of the spectrum diagram corresponding to the standard power consumption curve and the spectrum diagram corresponding to the actual power consumption curve are compared to obtain the second comparison result. If there is a discrepancy between the first comparison result and the second comparison result, the code block is determined to be an abnormal code block.

4. The method according to claim 2, characterized in that, The step of debugging and analyzing the abnormal code block to determine the location of the exception in the original code includes: Insert a code stub in the middle of the code segment to be analyzed corresponding to the abnormal code block to obtain the code segment to be analyzed; The current consumption characteristics of the code segment to be analyzed during its execution are collected; The occurrence status of the identifier feature of the code stub is determined based on the current consumption characteristics of the code segment to be analyzed; Based on the occurrence status of the identification features, determine the new segment to be analyzed corresponding to the abnormal code block; The process involves inserting a code stub at the middle of the code segment corresponding to the abnormal code block to obtain the code segment to be analyzed, until the length of the new segment to be analyzed is less than or equal to a length threshold. The abnormal location in the original code is then determined based on the new segment to be analyzed.

5. A code debugging device, characterized in that, The device includes: A building module is used to build at least one code stub based on the environment configuration information of the runtime environment of the original code, and insert the code stub into the original code to obtain the code under test. The acquisition module is used to acquire the current consumption characteristics of the code under test during its operation. The positioning module is used to locate the abnormal position in the original code based on the current consumption characteristics of the code under test and the identifier current consumption characteristics corresponding to the code stub; The construction module is further configured to determine the execution duration of the assembly-level empty instruction in the runtime environment of the original code based on the base clock frequency of the runtime environment of the original code and the instruction cycle of the assembly-level empty instruction; determine the number of assembly-level empty instructions based on the interactive execution cycle of the runtime environment of the original code and the execution duration of the assembly-level empty instruction; and perform continuous hard encoding of the assembly-level empty instructions according to the number of assembly-level empty instructions to obtain code stubs; The construction module is further configured to determine the target clock frequency based on the reference clock frequency of the runtime environment where the original code is located and a preset downclocking ratio; configure the frequency configuration parameters of the clock controller in the runtime environment where the original code is located based on the target clock frequency; and generate code stubs for writing to the configuration register of the clock controller according to the frequency configuration parameters. The construction module is further configured to determine the algorithm operation type and operand bit length based on the hardware characteristics information of the public key algorithm coprocessor in the runtime environment of the original code; determine the configuration parameters of the public key algorithm coprocessor based on the algorithm operation type and the operand bit length; and generate code stubs for controlling the registers of the public key algorithm coprocessor according to the configuration parameters.

6. A code debugging device, characterized in that, The code debugging device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the code debugging method as described in any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the code debugging method as described in any one of claims 1-4.

8. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the code debugging method as described in any one of claims 1-4.

Images