Computer-implemented method for obtaining an access notification as part of a taint analysis when testing a software program, system, computer program and computer-readable data carrier
The method facilitates taint analysis on embedded systems by using a debugger to monitor memory access and generate notifications, addressing the challenge of tracking data flow and detecting security risks in embedded systems.
Patent Information
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-09-30
- Publication Date
- 2026-04-02
AI Technical Summary
Taint analysis is difficult to implement in embedded systems due to limited program memory and low-throughput data connections, especially for microcontrollers, which lack built-in mechanisms to track information flow and detect security risks like SQL injection.
A computer-implemented method for obtaining access notifications during taint analysis on hardware targets, using a debugger to monitor memory addresses, set data breakpoints, and transmit access notifications to a test module, allowing for real-time data flow tracking and security risk detection.
Enables effective taint analysis on embedded systems by monitoring memory access and generating access notifications, thereby identifying potential security risks and ensuring secure data handling.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
State of the art
[0001] Taint analysis is a technique used in information security to identify the flow of user input through a system and understand its security implications for system design. This analysis aims to mitigate risks, such as SQL injection, which generally arise when other parts of the program use user input without proper sanitization. Many programming languages, such as Ruby, have built-in taint analysis mechanisms. These mechanisms mark variables that have received user input as "tainted," and any variables derived from them are also marked as "tainted." Using this trail, the analysis tool can generate a list of infected variables. If a critical operation, such as a database call or an operating system-level call, uses suspicious variables, the testing tool can alert the developer to a potential security risk.
[0002] Taint analysis is used to track the flow of information in software programs and can be combined with fuzzing to detect potential information leaks. For runtime environments or languages that do not support taint analysis, there is generally no easy solution, especially for embedded devices.
[0003] Taint analysis can uncover the leakage of private data and the unintentional processing of untrusted data. However, the necessary tracking of information flow can require sophisticated code instrumentation or dynamic analysis. Both are typically difficult to implement in embedded systems program code. Microcontrollers, the key components of embedded systems, often lack sufficient program memory, have low-throughput data connections, and differ in many other ways.
[0004] DE 10 2021 212 596 A1 discloses a computer-implemented method for obtaining software coverage feedback during fuzzing of software on a hardware target, wherein the hardware target has at least one breakpoint register and is designed to halt execution of the software before execution of an instruction of the software when the instruction is reached during execution of the software and a memory address of the instruction is set in the at least one breakpoint register, comprising: setting a first breakpoint before a first instruction of the software; executing or continuing a fuzzing iteration of the software; first checking whether the first breakpoint is reached during execution or continuation of the fuzzing iteration; storing first log information comprising that the first instruction in the fuzzing iteration has been reached, and, optionally, clearing the first breakpoint if the first check is successful.The software coverage feedback during software fuzzing includes the initial protocol information. Disclosure of the invention
[0005] In a first aspect of the invention, a computer-implemented method for obtaining an access notification within the framework of a taint analysis during the testing of a software program running on a hardware target is proposed. The hardware target has a memory, wherein, during the execution of the software program, the software program stores data in at least a portion of the memory.
[0006] The method comprises the steps described below. The described steps can be performed in the specified order. However, a different order is also possible. Furthermore, it is possible for two or more of the method steps to be performed overlapping or simultaneously. It is also possible for one or more of the method steps to be repeated once or multiple times. The method may include further method steps that are not shown. For the disclosure regarding this aspect, reference may be made to any further aspect, embodiment, and / or definition.
[0007] The term "testing," as used here, is a broad term to which its usual and common meaning, as understood by those skilled in the art, should be attributed. The term is not limited to any specific or adapted meaning. Without restriction, the term can refer in particular to an automated process for testing the software program, i.e., software. Testing can comprise multiple test iterations. During a test iteration, input data for the software program under test, i.e., the software target, is generated. The software program is then executed using this input data. During a test iteration, the software program is monitored. This monitoring can generate software coverage feedback, which is then passed to the fixed module. In a subsequent test iteration, further input data can be generated based on this software coverage feedback.The test module can be a fuzzer, with the fuzzer generating the input data.
[0008] The term "hardware target," as used here, is a broad term and should be understood in its usual and common sense, as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without limitation, the term can refer in particular to hardware that functions as an embedded system and on which the software program is executed. The hardware target can, in particular, be a microcontroller.
[0009] The term "taint analysis," as used here, is a broad term and should be understood in its usual and common sense, as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without limitation, the term can refer in particular to a technique of security analysis and program verification used to identify vulnerabilities and potential security risks in the software program. In taint analysis, unsafe data (tainted data) is provided to the software program as input data, and the software program tracks the data flow of the input data and the data affected by it, which may then be identified. As already explained, the input data can be generated using the test module.Within the framework of dynamic taint analysis, the data flow of the software program can be monitored in real time during its execution.
[0010] The procedure comprises the following steps, which can represent a first test iteration: - Generating input data for the software program using a test module; - Transmitting the generated input data to the software program using the test module; - Monitoring at least one memory address using a debugger while the software program processes at least part of the transmitted input data; - Sending an access notification to the test module when at least one access is detected at at least one address of the monitored memory.
[0011] The exclusive use of generic debug functions makes it possible to use the method according to the invention on a variety of hardware targets and regardless of the programming languages and instruction sets used.
[0012] The term "generating input data," as used here, is a broad term to which its ordinary and common meaning, as understood by those skilled in the art, should be attributed. The term is not limited to any specific or adapted meaning. Without restriction, the term can refer to the process of generating input data. The input data can be generated using the test module. When generating the input data, the test module can access a known input corpus containing known input data, generating new input data from this known corpus. When generating input data, especially further input data, the test module can take change notifications into account, so that the generated input data is dependent on these change notifications.New input data can be generated for each test module iteration, each taking into account at least the most recently transmitted change notification.
[0013] The term "transmitting the generated input data," or code coverage as used here, is a broad term to which its usual and common meaning, as understood by those skilled in the art, should be attributed. The term is not limited to any specific or adapted meaning. Without restriction, the term can refer to the process of transferring the generated input data from the test module to the software program. The transmitted input data can be processed by the software program. Typically, a host computer is provided on which the test module is executed. The host computer may have an interface, in particular a physical interface. Furthermore, the hardware target may have an interface, in particular a physical interface. The transmission of the input data can take place via these interfaces.
[0014] The term "monitoring at least one memory address," as used here, is a broad term and should be interpreted according to its usual and common meaning as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without limitation, it can refer to the process of continuously observing and monitoring at least one memory address. This monitoring can be carried out, in particular, in such a way as to detect any access to the memory address.
[0015] At least one address of the storage can correspond to a storage address where sensitive data is stored. The sensitive data can include at least one of the following: - at least a secret key; - personal data, - intellectual property, - at least one sensitive model, - at least one sensitive configuration, - at least a certificate, - at least one access token, - at least a log, - at least one password, preferably a hashed password. For example, sensitive data in binary form, such as secret keys, can be found by searching for memory addresses with high entropy.
[0016] The term “sensitive data,” as used here, is a broad term and should be interpreted according to its usual and common meaning as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without limitation, it can refer to information whose disclosure could potentially be harmful to a person, organization, and / or system.
[0017] To monitor at least one memory address, one or more data breakpoints of the debugger can be set at that memory address. A data breakpoint is a function of the debugger that monitors access to at least part of the specified memory address. Typically, a data breakpoint can monitor a memory size of at least one byte. To monitor a data breakpoint using the debugger, the debugger can have an interface, particularly a physical interface, that connects to the memory of the hardware target. Through this interface, the debugger can read at least part of the specified memory address.
[0018] The term "debugger," as used here, is a broad term and should be understood in its usual and common sense, as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without limitation, the term can refer to any device or software capable of controlling the software program running on the hardware target.
[0019] The debugger can provide one or more functions to control the software program. These functions can include reading at least one register and / or memory value from the hardware target's memory, pausing, stopping, and / or starting the execution of the software program, particularly in such a way that the software program can be executed step by step.
[0020] The term "transmitting an access notification to the test module," as used here, is a broad term to which its ordinary and common meaning, as understood by those skilled in the art, should be attributed. The term is not limited to any special or adapted meaning. Without limitation, the term can refer to the process of transferring data to the test module, the access notification indicating to the test module that access to at least one memory address has been detected. The access notification can only be transmitted to the test module if access to at least one memory address has actually been detected. The access notification can be transmitted from the debugger to the test module. As already stated, the host computer may have an interface, in particular a physical interface.Furthermore, the debugger may have an interface, in particular a physical interface. Access notifications can be transmitted via this interface.
[0021] To transmit the access notification to the test module, the procedure may further include the following step: - Determining the state information of the hardware target using the debugger at the time when access to at least one address of the monitored memory is detected; wherein the access notification is or includes the state information read by the debugger.
[0022] The term "state information," as used here, is a broad term and should be interpreted according to its usual and common meaning as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without restriction, it can refer to data and / or at least one parameter that at least partially describes the current state or situation of the software program. The evaluation of state information obtained in a single test iteration can provide information about the data flow within the software program. Furthermore, the evaluation of state information obtained across multiple test iterations can provide information about the data flow within the software program.
[0023] To read the hardware target's state information using the debugger, the debugger can be instructed to transmit the memory contents and / or register contents to the host computer. For this to happen, at least one breakpoint and / or data watchpoint of the debugger must have been triggered beforehand.
[0024] To determine the state information of the hardware target, an access function that accesses at least one address of the monitored memory can be read using the debugger, where the state information is the access function or includes it.
[0025] The term "access function," as used here, is a broad term and should be understood in its usual and common sense, as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without limitation, the term can refer to any method by which the values at a given address of the monitored memory are accessed. The access function can describe the type of access to the values at a given address of the monitored memory. The access function can be a read access and / or a write access.
[0026] To determine the state information of the hardware target, the stack contents of the hardware target can be at least partially read using the debugger, where the state information is or includes the partially read stack contents.
[0027] The term "stack," as used here, is a broad term to which its usual and common meaning, as understood by those skilled in the art, should be attributed. The term is not limited to any specific or adapted meaning. Without restriction, the term can refer to a stack of storage. A stack can comprise a dynamic data structure. The "stack contents" can refer to the data stored in the stack.
[0028] To read the stack contents of the hardware target using the debugger, the debugger can be instructed to transmit the memory contents and / or register contents to the host computer. For this to happen, at least one breakpoint and / or data watchpoint of the debugger must have been triggered beforehand.
[0029] The partially read stack contents can be or include the active stack frame. The term "stack frame," as used here, is a broad term to which its ordinary and common meaning, as understood by those skilled in the art, should be attributed. The term is not limited to any special or adapted meaning. Without limitation, the term can refer to the area within a stack occupied by a specific program segment. The term "active stack frame," as used here, is a broad term to which its ordinary and common meaning, as understood by those skilled in the art, should be attributed. The term is not limited to any special or adapted meaning. Without limitation, the term can refer to the stack frame being processed at the time when access to at least one address of the monitored memory is detected.
[0030] To determine the state information of the hardware target, the execution of the software program is stopped using the debugger. After the state information of the hardware target has been read, the execution of the software program can be resumed using the debugger.
[0031] The procedure may also include: - Generating further input data for the software program using the test module, taking into account the access notification transmitted to the test module; - Transmitting the generated additional input data to the software program using the test module; - further monitoring of at least one memory address using the debugger while the software program processes at least part of the transmitted input data; - Sending another access notification to the test module if at least one further access is detected at at least one address of the monitored memory.
[0032] These steps can represent another test iteration. These steps can be repeated within one or more test iterations. These steps can be repeated until testing is aborted.
[0033] The test strategy of the test module can be chosen such that the test module generates the input data in such a way as to maximize the data flow of sensitive data.
[0034] The procedure may also include: - Determine whether a data security rule of the software program is being violated by evaluating the access notification and / or further access notifications.
[0035] The result of this assessment can be output during the procedure or after the taint analysis.
[0036] The term "data security rule," as used here, is a broad term and should be understood in its usual and common sense, as understood by those skilled in the art. The term is not limited to any specific or adapted meaning. Without limitation, the term can refer to at least one rule specifying which accesses to particular data and / or data flows are permitted. The data security rule can be, or include, at least one defined access pattern that must be fulfilled or must not occur during execution. For example, a data security rule can ensure that untrusted input data fed in via an interface is first processed by a cleansing function before being forwarded to, for instance, a database engine.Alternatively or additionally, a data security rule can stipulate that access to sensitive data may only be granted by at least one specific function. This can encompass all functions in the call stack. In this way, it can be determined whether sensitive data is leaking during runtime.
[0037] The procedure may also include: - Aborting the procedure for obtaining an access notification as part of a taint analysis when testing a software program if at least one of the following conditions is met: ◯ A violation of a data security rule of the software program was detected; ◯ A software coverage of the software program has reached or exceeded a lower threshold; ◯ A predetermined number of input data points were processed; ◯ a predetermined testing period has expired; ◯ The procedure was manually aborted.
[0038] In another aspect, a system is revealed, the system comprising: - a host computer on which the test module is run; - a hardware debugger on which the debugger is run; - a hardware target, wherein the hardware target preferably comprises or is a microcomputer, the system being configured to execute the computer-implemented method for obtaining an access notification as part of a taint analysis during the testing of a software program. For the disclosure relating to this aspect, reference may be made to any further aspect, embodiment, and / or definition.
[0039] In a further aspect, a computer program is disclosed which, when executed on the system according to the preceding claim directed to a system, performs the method for obtaining an access notification within the framework of a taint analysis when testing a software program according to one of the preceding claims directed to a method. For the disclosure relating to this aspect, reference may be made and / or made to any further aspect, embodiment, and / or definition.
[0040] In another aspect, a computer-readable data carrier is disclosed on which a data structure is stored that, after being loaded into the working and / or main memory of the system, executes the method for obtaining an access notification as part of a taint analysis during the testing of a software program. For the disclosure relating to this aspect, reference may be made and / or referenced to any further aspect, embodiment, and / or definition.
[0041] The terms "computer-readable data carrier" and "computer-readable storage medium," as used here, can refer in particular to non-transitory data storage devices, such as a hardware data storage medium on which computer-executable instructions are stored. The computer-readable data carrier or computer-readable storage medium can, in particular, be or comprise a storage medium such as random-access memory (RAM) and / or read-only memory (ROM). Brief description of the drawings
[0042] Further optional details and features of the invention will become apparent from the following description of preferred embodiments, which are shown schematically in the figures.
[0043] They show: Fig.1. A schematic representation of a computer-implemented procedure for obtaining an access notification during a taint analysis when testing a software program, and Fig. 2 in a schematic view an illustration of a system according to an embodiment of the invention. Embodiments of the invention
[0044] In Fig. Figure 1 is a computer-implemented method for obtaining an access notification as part of a taint analysis during the testing of a software program 110, wherein the software program is executed on a hardware target 140, the hardware target 140 having a memory, wherein, during the execution of the software program, the software program stores data in at least a part of the memory, the method comprising: - Generating input data 112 for the software program using a test module; - Transmitting the generated input data 114 to the software program using the test module; - Monitoring at least one address of memory 116 using a debugger 138 while the software program processes at least part of the transmitted input data; - Sending an access notification 118 to the test module when at least one access is detected at at least one address of the monitored memory.
[0045] The test module can include a fuzzer, where the fuzzer generates the input data.
[0046] To transmit the access notification to the test module, the procedure may further include: - Determining the state information of the hardware target 140 using the debugger 138 at the time when access to at least one address of the monitored memory is detected; wherein the access notification is or includes the state information read by the debugger 138.
[0047] To determine the state information of the hardware target 140, an access function that accesses at least one address of the monitored memory can be read using the debugger 138, where the state information is the access function or includes it.
[0048] To determine the state information of hardware target 140, the stack contents of hardware target 140 can be at least partially read using debugger 138, where the state information is or includes the partially read stack contents. The partially read stack contents can be or include the active stack frame.
[0049] To determine the status information about the hardware target 140, the execution of the software program can be stopped using the debugger 138.
[0050] At least one address of the storage can correspond to an address of the storage where sensitive data is stored, in particular where the sensitive data includes at least one of the following: - at least a secret key; - personal data, - intellectual property, - at least one sensitive model, - at least one sensitive configuration, - at least a certificate, - at least one access token, - at least a log, - at least one password, preferably a hashed password.
[0051] To monitor at least one memory address, one or more data breakpoints of debugger 138 can be set at that at least one memory address.
[0052] Procedure 110 may also include: - Generating further input data 122 for the software program using the test module, taking into account the access notification transmitted to the test module; - Transmitting the generated additional input data 124 to the software program using the test module; - further monitoring of at least one address of memory 126 using the debugger 138, while the software program processes at least part of the transmitted input data; - Sending another access notification 128 to the test module if at least one further access is detected at at least one address of the monitored memory.
[0053] The test strategy of the test module should be chosen in such a way that the test module generates the input data in such a way that the data flow of sensitive data is maximized.
[0054] Procedure 110 may also include: - Determine whether a violation of data security rule 142 (see below) has occurred. Fig. 2) of the software program is violated by evaluation of the access notification and / or the further access notification, in particular by means of the test module.
[0055] Procedure 110 may also include: - Aborting procedure 132 for obtaining an access notification as part of a taint analysis when testing a software program, in particular using the test module, if at least one of the following conditions is met: ◯ A violation of a data security rule of the software program was detected; ◯ A software coverage of the software program has reached or exceeded a lower threshold; ◯ A predetermined number of input data points were processed; ◯ a predetermined testing period has expired; The procedure was manually aborted.
[0056] In Fig. Figure 2 shows an exemplary system 134; the system comprises: - a host computer 136 on which the test module is run; - a hardware debugger 138 on which the debugger is run; - a hardware target 140, wherein the hardware target preferably comprises or is a microcomputer, the system being configured to execute the computer-implemented method for obtaining an access notification as part of a taint analysis during testing of a software program. The system may be a hardware-in-the-loop (HiL) system.
[0057] The data flow between the individual hardware components 136, 138, 140 can occur as shown by the arrows. The data flow can take place via appropriately configured physical interfaces. Fig. 2 further illustrate exemplary data security rules 142.
[0058] The data security rules of ISO 142 can, for example, be presented in the form of a table. Such a table might look like this: Memory address / symbol Rule 0x8FFFF1234 mask0xFFFFFF00 Access only through the function “safe_data_lookup” priv_key_RSA Access only through the hardware security module http_request_buffer Access via “sanitize_http_request” before access via “eval_sql_request” ... ...
[0059] The arrow pointing from host computer 136 to hardware target 140 can describe a communication interface, specifically a standard communication interface. The arrow pointing from host computer 136 via hardware debugger 138 to hardware target 140 can describe communication via the debugger. This can also apply in the opposite direction. The actual data flow, which will be examined using taint analysis, can take place on hardware target 140. QUOTES INCLUDED IN THE DESCRIPTION
[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature
[0000] DE 10 2021 212 596 A1
[0004]
Claims
[1] Computer-implemented method for obtaining an access notification as part of a taint analysis when testing a software program, wherein the software program is executed on a hardware target (140), the hardware target (140) having a memory, wherein, during the execution of the software program, the software program stores data in at least part of the memory, the method comprising: - Generating input data for the software program using a test module; - Transmitting the generated input data to the software program using the test module; - Monitoring at least one memory address using a debugger (138) while the software program processes at least part of the transmitted input data; - Sending an access notification to the test module when at least one access is detected at at least one address of the monitored memory. [2] Method according to the preceding claim, wherein, for transmitting the access notification to the test module, the method further comprises: - Determining the state information of the hardware target (140) using the debugger (138) at the time when access to at least one address of the monitored memory is detected; wherein the access notification is or includes the state information read by the debugger (138). [3] Method according to the preceding claim, wherein, in order to determine the state information of the hardware target (140), an access function which accesses the at least one address of the monitored memory is read out by means of the debugger (138), wherein the state information is the access function or comprises it. [4] Method according to one of the two preceding claims, wherein, in order to determine the state information of the hardware target (140), a stack content of the hardware target (140) is at least partially read out by means of the debugger (138), wherein the state information is the partially read stack content or comprises it. [5] Method according to the preceding claim, wherein the partially read stack content is or comprises the active stack frame. [6] Method according to one of the four preceding claims, wherein, in order to determine the state information about the hardware target (140), the execution of the software program is stopped using the debugger (138). [7] Method according to any of the preceding claims, wherein the at least one address of the memory corresponds to an address of the memory where sensitive data is stored. [8] Method according to any of the preceding claims, wherein, for monitoring the at least one address of the memory, one or more data breakpoints of the debugger (138) are set at the at least one address of the memory. [9] Method according to any of the preceding claims, the method continuing to encompass: - Generating further input data for the software program using the test module, taking into account the access notification transmitted to the test module; - Transmitting the generated additional input data to the software program using the test module; - further monitoring of at least one memory address using the debugger (138) while the software program processes at least part of the transmitted input data; - Sending another access notification to the test module if at least one further access is detected at at least one address of the monitored memory. [10] Method according to any of the preceding claims, wherein the test strategy of the test module is chosen such that the test module generates the input data in such a way as to maximize the data flow of the sensitive data. [11] Method according to any of the preceding claims, the method continuing to encompass: - Determine whether a data security rule of the software program is being violated by evaluating the access notification and / or further access notifications. [12] Method according to any of the preceding claims, the method continuing to encompass: - Aborting the procedure for obtaining an access notification as part of a taint analysis when testing a software program if at least one of the following conditions is met: ◯ A violation of a data security rule of the software program was detected; ◯ A software coverage of the software program has reached or exceeded a lower threshold; ◯ A predetermined number of input data points were processed; ◯ a predetermined testing period has expired; ◯ The procedure was manually aborted. [13] Method according to any of the preceding claims, wherein the test module comprises a fuzzer, wherein the fuzzer generates the input data. [14] System (134), wherein the system (134) comprises: - a host computer (136) on which the test module is run; - a hardware debugger (138) on which the debugger (138) is run; - a hardware target (140), wherein the hardware target (140) preferably comprises or is a microcomputer, wherein the system (134) is configured to execute the computer-implemented method for obtaining an access notification as part of a taint analysis when testing a software program according to one of the preceding claims. [15] Computer program which, when executed on the system (134) according to the preceding claim directed to a system (134), performs the method for obtaining an access notification in the context of a taint analysis when testing a software program according to one of the preceding claims directed to a method. [16] Computer-readable data carrier on which a data structure is stored which, after being loaded into a working and / or main memory of the system (134) according to the preceding claim directed to a system (134), executes the method for obtaining an access notification in the context of a taint analysis when testing a software program according to one of the preceding claims directed to a method.
Citation Information
Patent Citations
FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION
DE102021212596A1