DE102022203357A1 - FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON DISTANCES OF INSTRUCTION BLOCKS IN CONTROL FLOW GRAPH - Google Patents

Abstract

A first aspect of the present disclosure relates to a computer-implemented method for obtaining software coverage feedback when fuzzing software on a hardware target, wherein the hardware target has at least one breakpoint register and is configured to require execution of the software before executing an instruction of the software stopping when the instruction is reached in execution of the software and a memory address of the instruction is set in the at least one breakpoint register, comprising selecting a first instruction block of the software; setting a first breakpoint before an instruction of the first instruction block in the at least one breakpoint register; first running or resuming a fuzzing iteration of the software; first checking whether the first breakpoint is reached the first time the fuzzing iteration is executed or resumed; storing first protocol information including that the first instruction block has been reached in the fuzzing iteration - and, optionally, deleting the first breakpoint - if the first check is positive. The software coverage feedback when fuzzing the software includes the first protocol information. Selecting the first instruction block of the software may be based on distances, optionally distance weights, from instruction blocks to at least one instruction block reached during fuzzing in a control flow graph of the software.

Description

State of the art

Fuzzing (English: fuzzing or fuzz testing) is an automated technique for testing software. This involves running the software with invalid, unexpected and/or random input data in a variety of fuzzing iterations and monitoring for exceptions such as crashes, failed built-in code assertions, potential memory leaks, etc . For software whose input data must be in a predetermined data structure, fuzzers that are designed for this predetermined data structure can be used. The predetermined data structure is specified, for example, in a file format and/or protocol. An (efficient) fuzzer is designed to generate invalid, unexpected and/or random input data in the predetermined data structure so that execution of a respective fuzzing iteration of the software can be started based on the input data without parse errors. Fuzzing can be used to identify unexpected behavior such as unexpected (program) paths and/or programming errors as well as edge cases, particularly in complex software (such as software for the control, regulation and/or monitoring of a technical system). By gaining a better understanding of software in this way, the software and in particular its security can be improved.

A fuzzing target can be software (e.g. a program) and/or a part of it (e.g. a function) that is to be tested by fuzzing. The fuzzing target may be such that it accepts potentially untrusted input data that may be generated when fuzzing by a fuzzer for a variety of fuzzing iterations. In this context, fuzzing can be seen as the automated process of sending arbitrary and especially invalid, unexpected and/or random input data to the fuzzing target and then observing its response during the execution of this fuzzing iteration. The fuzzer or fuzzing machine is a computer program designed to automatically generate input data for the fuzzing target per fuzzing iteration. The fuzzer is not part of the fuzzing target, but is independent of the fuzzing target. As a rule, fuzzers are not instrumented. A well-known fuzzer is, for example, afl or libfuzzer. The combination of a fuzzing target and an associated fuzzer can be referred to as a fuzzing test. The fuzzing test is executable. The fuzzer can generate different (fuzzing) input data for a large number of fuzzing iterations - e.g. hundreds or thousands of fuzzing iterations per second - and can start, observe and, if necessary, stop a fuzzing test with the associated input data. A fuzzing iteration includes an execution of the fuzzing target/software based on (fuzzing) input data generated for this fuzzing iteration. By saving the respective input data, the fuzzing iteration can be reproduced at a later point in time, in particular if unexpected behavior of the software was detected during the fuzzing iteration (e.g. not yet known paths and/or programming errors), in which case the fuzzing -Target can be executed without a fuzzer but on the stored (fuzzing) input data.

During the execution of a fuzzing test, information from the software target can be output. Such software coverage feedback (coverage-guided fuzzing) can advantageously be used during fuzzing to detect paths/blocks that are not yet known and/or to localize programming errors in the software. For example, as with afl, software coverage feedback in fuzzing can be realized by static instrumentation of the fuzzing target. With static instrumentation, the fuzzing target - i.e. the software - is changed (for example when compiling) so that information about, for example, last executed instructions in the software and / or (program) paths during the execution of the software and in particular during a Fuzzing iteration can be retrieved. Alternatively or additionally, software coverage feedback can be obtained from dynamic instrumentation. The execution of the software is controlled at runtime using system functionalities and/or emulators in order to obtain information about the processes in the software. Software coverage feedback through dynamic instrumentation is particularly advantageous when the software is in compiled form (closed source).

JinSeok Oh, Sungyu Kim, Eunji Jeong, and Soo-Mook Moon, “Os-less dynamic binary instrumentation for embedded firmware,” in 2015 IEEE Symposium in LowPower and High-Speed Chips (COOL CHIPS XVIII), pages 1-3. IEEE, 2015 disclose dynamic instrumentation via debuggers and breakpoints based on software interrupts. The binary code of the software is actively changed and an instruction is replaced by a software interrupt instruction.

Disclosure of the invention

A first general aspect of the present disclosure relates to a computer-implemented method for obtaining software coverage feedback when fuzzing software on a hardware target, the hardware target having at least one breakpoint register and being configured to require execution of the software before executing an instruction of the To stop 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. The method includes selecting a first instruction block of the software. The method further comprises setting a first breakpoint before an instruction of the first instruction block in the at least one breakpoint register. The method further includes first executing or first resuming a fuzzing iteration of the software. The method further includes first checking whether the first breakpoint is reached when the fuzzing iteration is first executed or continued. The method further comprises storing first protocol information including that the first instruction block has been reached in the fuzzing iteration if the first check is positive. The method may include deleting the first breakpoint if the first check is positive. The software coverage feedback when fuzzing the software may include the first protocol information. Selecting the first instruction block of the software may be based on distances of instruction blocks from at least one instruction block reached during fuzzing (e.g., in a previous fuzzing iteration or in the fuzzing iteration of the software) in a control flow graph of the software. Alternatively or additionally, selecting the first instruction block of the software may be based on distance weights of instruction blocks to at least one instruction block reached during fuzzing (e.g. in a previous fuzzing iteration or in the fuzzing iteration of the software) in a control flow graph of the software.

A second general aspect of the present disclosure relates to a computer system configured to execute the computer-implemented method for obtaining software coverage feedback when fuzzing the software on the hardware target according to the first general aspect (or an embodiment thereof).

A third general aspect of the present disclosure relates to a computer program configured to execute the computer-implemented method for obtaining software coverage feedback when fuzzing the software on the hardware target according to the first general aspect (or an embodiment thereof).

A fourth general aspect of the present disclosure relates to a computer-readable medium or signal that stores and/or contains the computer program according to the third general aspect (or an embodiment thereof).

The method according to the first aspect (or an embodiment thereof) proposed in this disclosure is directed to obtaining software coverage feedback when fuzzing software on a hardware target, particularly when the software itself or on the hardware target cannot be statically instrumented .

For computer systems such as desktop systems (PC etc.) and especially for software that is in the form of programming code (e.g. open source), static instrumentation is a well-known method to provide software coverage feedback when executing the software and especially during a fuzzing iteration of the software gain.

However, static instrumentation for fuzzing can be difficult for software running on an embedded system embedded in an engineering context for the following reasons: The fuzzer required for fuzzing typically needs to be ( e.g. due to lack of computing and/or storage capacity in the embedded system) must be executed on another computer. This means that software coverage feedback from the embedded system must first be transferred to the fuzzer (or another computer). Furthermore, an entire system must typically be tested, which may well include a large number of components. The software for the overall system may include third-party libraries and software components from other suppliers and/or customers. Such software components are often delivered as binary files (ie in compiled form, also: binary code), which cannot be modified or can only be modified with great effort. Since such software components are no longer compiled, they can only be statically instrumented with great effort. On the other hand, software (or software components thereof) that exist as programming code is easy to statically instrument at compile time. However, the size of the software increases in any case due to static instrumentation, so that the statically instrumented software often no longer fits into the memory of the embedded system due to the typically limited resources. The same applies to other functionalities that can be added to the software for fuzzing.

In an alternative approach, the embedded system software can be run in an emulator such as QEMU. Here, the transparency and configurability of the emulator can be used to provide software coverage feedback during fuzzing. Unfortunately, setting up such an emulator for a specific hardware target involves an enormous amount of work, as typically the functionality of the embedded system's software is based on the availability of external hardware components such as sensors and/or actuators. However, if such hardware components are missing from the emulator, the software cannot be tested under the conditions for which it was actually designed. In fact, in this case the software will behave differently than in the context of the technical system designed for it. This can be expressed, for example, in the fact that the software will probably follow other paths that only have a limited connection with the actual purpose of the software. The use of an emulator for software coverage feedback during fuzzing is therefore less suitable.

When a debugger is connected to the embedded system, breakpoint instructions (via at least one hardware breakpoint register) can be used to stop the execution of software in the embedded system at a specific location in the code. However, it will not be possible to obtain almost complete software coverage feedback using arbitrary breakpoints, as the number of simultaneously active breakpoints is usually very limited. For example, an ARM Cortex-MO microcontroller is designed for a maximum of four simultaneously active hardware breakpoints.

The method according to the first aspect (or an embodiment thereof) proposed in this disclosure is particularly suitable for fuzzing on a hardware target/embedded system and in the (typical) case where the number of breakpoints is highly limited. As already explained, the software can be tested more realistically and therefore better thanks to fuzzing on the (real) hardware target - in contrast to the emulator. For the method, it is sufficient if the hardware target allows at least one breakpoint. Starting from, for example, a start instruction, which is mostly specified, thanks to the method proposed in this disclosure and in particular by systematically executing instructions by strategically setting at least one breakpoint, one of the control flow graphs of the software can be at least to the part of the software covered by the fuzzing iteration Software can be identified and/or tested. If unexpected behavior occurs during a fuzzing iteration, the software coverage feedback can be used to improve the software and especially its security through a software change. This can further improve the functionality and in particular the security of the embedded system controlled, regulated and/or monitored by the software.

A method known in the prior art (Oh et al., supra) for dynamic instrumentation via debuggers and breakpoints based on software interrupts could, in light of the present disclosure, also be used to obtain software coverage feedback when fuzzing the software on the hardware target be used. For example, the already described replacement of an instruction with a software interrupt instruction can be repeated several times, thereby setting different breakpoints. However, the memory has to be rewritten with each repetition. However, with the EEPROM/Flash memories used in microcontrollers, this leads to considerable overhead. Obtaining software coverage feedback when fuzzing the software on the hardware target via software interrupts becomes inefficient or even impractical.

Instead, in the method proposed in this disclosure, hardware breakpoints are set (via the at least one hardware breakpoint register). The advantage here is that hardware breakpoints can be set without much overhead. Thus, software coverage feedback can be obtained efficiently and therefore quickly when fuzzing the software on the hardware target.

The method proposed in this disclosure is also suitable in applications (e.g. for testing/testing existing products) in which the software is executed from a read-only memory (ROM) of the hardware target. In this case, replacing instructions in the software binary code with software interrupt instructions is only possible with considerable effort, if at all.

In the method proposed in this disclosure according to the first aspect (or an embodiment thereof), the strategic setting (or selection) of the at least one breakpoint or, for example, one breakpoint per existing hardware breakpoint register - it can be, for example, one, two, three, four or more than four, eight or more than eight hardware breakpoint registers are present on the hardware target - a setting based on distances, in particular distance weights, from instruction blocks to at least one instruction block reached during fuzzing in the control flow graph. In one embodiment of the method, the strategic setting of the at least one breakpoint can involve, for example, successive setting of breakpoints before instructions of instruction blocks that are connected to a high degree in the control flow graph with instruction blocks already reached during fuzzing and/or to each other and are close to one another, ie small distances , in particular high distance weights, to at least one instruction block reached during fuzzing. In contrast, for example, to the successive setting of breakpoints in front of neighboring statements in an abstract syntax tree of the software and/or even to arbitrary statements in the software and especially in the case of sufficiently complex software - a criterion that is almost always met in practice and/or very can be easily fulfilled - by strategically setting based on (small) distances, in particular (high) distance weights, from instruction blocks to the at least one instruction block in the control flow graph reached during fuzzing, the probability of execution blocks being interesting and/or relevant for a software developer/user of the software to be found significantly increased. This makes fuzzing significantly more efficient, better and/or faster. This allows the software and in particular the system controlled, regulated and/or monitored by the software to be improved.

In embodiments of the method proposed in this disclosure according to the first aspect (or an embodiment thereof), the strategic setting (or selection) of the at least one breakpoint or, for example, one breakpoint per existing hardware breakpoint register can be achieved on the one hand by (small) distances, in particular ( high) distance weights, at least tend to be guided by instruction blocks, and on the other hand are based on a probabilistic selection of instruction blocks. For this purpose, for example, a probability measure can be calculated that assigns (normalized) distance weights to instruction blocks in the control flow graph or to a part of it. Selecting instruction blocks before or within which at least one breakpoint should be set may then involve single or multiple dragging of instruction blocks according to the probability measure. In other words: The instruction blocks can be rolled according to the probability measure (e.g. a la Monte Carlo). One advantage is that although instruction blocks with small distances/high distance weights are preferred and at least pseudo-randomly selected, it is still possible and does happen from time to time for a more distant but still networked instruction block to be selected. In particular, the randomness can ensure that the control flow graph is covered sufficiently well during fuzzing, i.e. that the selection of instruction blocks is not limited to just a small part of the control flow graph. This also makes fuzzing significantly more efficient, better and/or faster. This allows the software and in particular the system controlled, regulated and/or monitored by the software to be improved.

Short description of the characters

• 1a schematically illustrates a computer-implemented method for obtaining software coverage feedback when fuzzing software on a hardware target.
• 1b schematically illustrates a continuation of the computer-implemented method for obtaining software coverage feedback when fuzzing software on a hardware target.
• 2 schematically illustrates an exemplary embodiment of the computer-implemented method for obtaining software coverage feedback when fuzzing software on a hardware target.
• 3 shows an exemplary and schematic control flow graph of a software with instruction blocks and directed edges.

Detailed description

The method 100 proposed in this disclosure enables obtaining software coverage feedback when fuzzing software on a hardware target. The hardware target can be, for example, an electronic control unit, wherein the software can be designed to control, regulate and/or monitor the electronic control unit.

The method 100 proposed in this disclosure may be particularly suitable for the case where the software is not statically instrumented for fuzzing. Furthermore, the software can be closed source (in whole or in part). Instead, software coverage feedback can be obtained when fuzzing the software via dynamic instrumentation.

• Zunächst kann z.B. vor dem Ausführen der Fuzzing-Iteration ein nullter Haltepunkt vor eine Startanweisung (englisch: function to instrument) gesetzt werden. Diese Startanweisung kann dadurch gekennzeichnet sein, dass sie beim Ausführen der Software unabhängig von den Eingangsdaten und somit bei einer jeden Fuzzing-Iteration ausgeführt wird. Die Startanweisung kann zum Beispiel aus einer Spezifikation der Software (z.B. symbol file) und/oder durch einen Testingenieur identifiziert werden. Alternativ oder zusätzlich kann vor dem Ausführen der Fuzzing-Iteration ein erster Haltepunkt in oder vor einem ersten Anweisungsblock gesetzt werden.

If there is a debugging connection to the hardware target, for example, as follows and as in 2 Illustrated as an example, software coverage feedback can be obtained during fuzzing and in particular during a fuzzing iteration:

• First, for example, a zero breakpoint can be placed in front of a start instruction (function to instrument) before executing the fuzzing iteration. This start instruction can be characterized in that it is executed when the software is executed independently of the input data and thus at every fuzzing iteration. The start instruction can be identified, for example, from a specification of the software (e.g. symbol file) and/or by a test engineer. Alternatively or additionally, a first breakpoint can be set in or before a first instruction block before executing the fuzzing iteration.

The fuzzing iteration of the software can then be executed based on the fuzzing input data for the fuzzing iteration. If the zeroth or first breakpoint is reached while running the fuzzing iteration, it can be marked as reached. Optionally and especially if the maximum number of (hardware) breakpoint registers is severely limited, the zeroth and/or first breakpoint can be deleted.

At least one second breakpoint can then be set in or before a second instruction block. If the second breakpoint is reached when executing the fuzzing iteration, it can be marked as reached. Optionally, and especially if the maximum number of breakpoint registers is severely limited, the second breakpoint can be deleted. The fuzzing input data that caused the second breakpoint to be reached may be stored and associated with the associated instruction block in the control flow graph 10 of the software.
By successively implementing (or deleting and resetting) at least one breakpoint, software coverage feedback can be obtained during the execution of the fuzzing iteration. The software coverage feedback may, for example, include a path in the control flow graph 10, where the path may include a sequence of instruction blocks of the control flow graph 10.

However, the control flow graph 10 of the (compiled, closed-source) software is often not known in advance. Nevertheless, it can be constructed with reasonable effort using the method 100 proposed in this disclosure during fuzzing, for example by successively logged set breakpoints.

It may well happen that a set breakpoint is not reached when executing the fuzzing iteration. It can even happen that a set breakpoint is not reached when executing a large number of fuzzing iterations. Based on a predetermined criterion (e.g. if the breakpoint is not reached after a predetermined number of fuzzing iterations and/or if a timeout occurs), the breakpoint can be marked as skipped. This or a new breakpoint can then be set, for example, in or before an instruction block that is adjacent to the instruction block in the control flow graph 10 that was not reached.

The selection of the instruction blocks or the breakpoints is based in the method 100 on distances, optionally distance weights, from instruction blocks in the control flow graph 10 to at least one instruction block that has already been reached during fuzzing. However, various other strategies for setting the breakpoints available on the hardware target can also be used in the method 100. Furthermore, different strategies can be combined and/or alternated in the method 100. Alternatively or additionally, the strategy may include a probabilistic search. Alternatively or additionally, the strategy may include an entropic search. Alternatively or additionally, the strategy may include guided search. Alternatively or additionally, the strategy can include further search strategies. In the entropic search, for example, an instruction block (and/or a directed edge) in the control flow graph 10 that is reached during fuzzing (or which is traversed during fuzzing) can be provided with a respective value for information gain (also: entropy). The strategy in entropic search may then involve generating through the fuzzer such fuzzing input data that maximizes overall information gain. Thus, instruction blocks (and/or directed edges) with high information gain may be preferred. This means that fewer instruction blocks that have already been reached (and/or directed edges that have already been traversed) are discovered. This means new ones can Statement blocks (and/or directed edges) can be discovered more efficiently. In the case of guided searches, the setting of at least one breakpoint can still be based on user input. For example, if a user, a programmer and/or an auditor of the software knows a critical point in the software or in the control flow graph 10 of the software, such knowledge can be used via a user interface to select the breakpoints and/or fuzzing input data that the critical point is reached in at least one fuzzing iteration and is therefore tested in detail.

Disclosed is a computer-implemented method 100 for obtaining software coverage feedback when fuzzing software on a hardware target, the hardware target having at least one breakpoint register and being configured to halt execution of the software before executing an instruction of the software if the Instruction is reached when executing the software and a memory address of the instruction is set in the at least one breakpoint register. The at least one breakpoint register may be a hardware breakpoint register. A hardware breakpoint is a breakpoint that is set via a hardware breakpoint register.

The method 100, shown schematically in 1a , includes selecting 119 a first instruction block of the software.

The method 100 includes setting 120 a first breakpoint before an instruction of the first instruction block in the at least one breakpoint register. Setting 120 the first breakpoint before the software instruction may include setting a memory address of the instruction into the at least one breakpoint register.

The method 100 may include first executing 130 a fuzzing iteration of the software. Alternatively, the method 100 may include first resuming 131 an (already partially executed but stopped) fuzzing iteration of the software.

The method 100 includes first checking 140 whether the first breakpoint is reached during the first execution 130 or first continuation 131 of the fuzzing iteration. The first breakpoint is reached when, without the first breakpoint, the first instruction would have been executed when the software was executed based on the fuzzing input data of the fuzzing iteration.

The method 100 includes storing 150 a first protocol information, wherein the first protocol information includes that the first instruction block (or a corresponding instruction before or in the first instruction block) has been reached in the fuzzing iteration if the first check 140 is positive.

The method 100 can, for example, as shown as an optional step in FIG. La, include deleting 151 of the first breakpoint if the first check 140 is positive.

The software coverage feedback when fuzzing the software includes the first protocol information. The first protocol information can, for example, further include the fuzzing input data of the fuzzing iteration. Storing fuzzing input data can be used to (successively) create a map from fuzzing achieved training blocks to fuzzing input data (or vice versa). Such a figure is shown schematically in 2 shown.

Selecting 119 the first instruction block of the software can be done at distances (e.g. d(b, b_i)) from instruction blocks 11 to at least one instruction block 13 (e.g. b_i in B_achieved) in a control flow graph 10 of the software. Here, for example, b is an instruction block from a set of the instruction blocks B of the control flow graph or a part thereof and, for example, b_i is an instruction block in the set B_achieved of the instruction blocks reached, where B_achieved can be a subset of the set B. In other words, the selection 119 of the first instruction block of the software can be based on distances from the at least one instruction block 13 reached during fuzzing to each of the instruction blocks.

Alternatively or additionally, selecting 119 the first instruction block of the software can be based on distance weights (e.g. (d(b, b_i))^(-1)) of instruction blocks 11 to at least one when fuzzing - ie, for example, at a previous fuzzing iteration or at fuzzing -Iteration of the software - achieved instruction block 13 is based in a control flow graph 10 of the software. In other words: the choosing 119 of the first instruction block of the software can be based on distance weights from the at least one instruction block 13 reached during fuzzing to each of the instruction blocks.

A control flow graph 10, shown as an example and schematically in 3 , can be a directed graph used to describe the control flow of the software (or part of it). The control flow graph may be a set of nodes 11 (e.g. b1, b2, b3, b4, b5, b6, b7) representing the instruction blocks of the described program, as well as a set of directed edges 12 comprising possible transitions between instruction blocks, ie program flows represent. For example, the instruction block b5 can be the at least one instruction block reached during fuzzing (from B_reached). Control flow graphs 10 of a sufficiently complex software can have >= 1e2, >= 1e3, >= 1e4, >= 1e5, >=1e6, >=1e7 instruction blocks and >= 1e2, >= 1e3, >= 1e4, >= 1e5, >= 1e6, >=1e7, >=1e8, >=1e9 include directed edges.

For example, instruction blocks with the smallest distances, optionally highest distance weights, can be drawn with or without replacement and thus selected 119.

• - einer minimalen Pfadlänge (z.B. min {PL(b, b_i I über alle Pfade von b nach b_i}) von dem Anweisungsblock 11 (z.B. Anweisungsblock b) zu dem mindestens einen beim Fuzzing erreichten Anweisungsblock (z.B. Anweisungsblock b_i); und/oder
• - einer minimalen Pfadlänge (z.B. min {PL(b_i, b I über alle Pfade von b_i nach b}) von dem mindestens einen beim Fuzzing erreichten Anweisungsblock (z.B. Anweisungsblock b_i) zu dem Anweisungsblock 11 (z.B. Anweisungsblock b);

sein.A distance (e.g. d(b, b_i)) of an (arbitrary) instruction block 11 (e.g. instruction block b) to the at least one instruction block reached during fuzzing (e.g. instruction block b_i) can, for example, be a minimum of:

• - a minimum path length (e.g. min {PL(b, b_i I over all paths from b to b_i}) from the instruction block 11 (e.g. instruction block b) to the at least one instruction block reached during fuzzing (e.g. instruction block b_i); and/or
• - a minimum path length (e.g. min {PL(b_i, b I over all paths from b_i to b}) from the at least one instruction block reached during fuzzing (e.g. instruction block b_i) to the instruction block 11 (e.g. instruction block b);

be.

For example, d(b, b_i) = min {PL(b, b_i I over all paths from b to b_i}. For example, d(b, b_i) = min {PL(b_i, b I over all paths from b_i to b}. For example, d(b, b_i) = min(min {PL(b, b_i I over all paths from b to b_i}, min {PL(b_i, b I over all paths from b_i to b }) apply.

A distance can be a number, for example, in the (real) interval [0, infinity] (end points included). A distance can be, for example, a natural number (with zero). In particular, a distance can be positive or zero. Alternatively, a distance can be infinite (large). Alternatively, a distance can be a real (or natural) number e.g. in the interval (0, infinity) (right end point included). Alternatively, a distance can be a real (or natural) number e.g. in the interval (0, infinity) (end point not The minimum of a and infinity (or vice versa) can be defined as a. Similarly, the minimum of infinity and infinity can be defined as infinity.

• - ob ein Pfad, in dem Kontrollflussgraphen 10 oder einem Teil davon, umfassend mindestens eine gerichtete Kante 12 ausgehend von dem einen (beliebigen) Anweisungsblock und in Flussrichtung zu dem anderen (beliebigen) Anweisungsblock existiert; und/oder;
• - wie lang ein solcher Pfad ist, so dieser existiert, insbesondere wie viele der mindestens einen gerichteten Kante 12 dieser Pfad umfasst.

A path length from one (arbitrary) instruction block to another (arbitrary) instruction block can be at least an approximate measure of

• - whether a path exists in the control flow graph 10 or a part thereof, comprising at least one directed edge 12 starting from the one (arbitrary) instruction block and in the flow direction to the other (arbitrary) instruction block; and or;
• - How long such a path is, if it exists, in particular how many of the at least one directed edge 12 this path includes.

The path length can be defined for each path (as long as at least one path exists). The path length can be infinite (large) if no path exists.

In 3 The following example minimum path lengths and distances result: Instruction block bx Minimum path length from b5 to instruction block kbx Minimum path length from instruction block k bx to b5 Distance d bx to b b1 Infinite (not present) 2 2 b2 1 1 1 b3 2 Infinite (not present) 2 b4 2 Infinite (not present) 2 b5 0 0 0 b6 3 Infinite (not present) 3 b7 1 Infinite (not present) 1

Paths from the at least one instruction block reached during fuzzing (e.g. instruction block b_i) to the at least one instruction block reached during fuzzing (e.g. instruction block b_i) can have a path length of 0 and can be ignored.

A distance weight (e.g. (d(b, b_i))^(-1)) of an (arbitrary) instruction block 11 (e.g. b) to the at least one instruction block 13 (e.g. b_i) reached during fuzzing can be based on the distance of the (arbitrary) instruction block 11 (e.g. b) to the at least one instruction block 13 (e.g. b_i) reached during fuzzing. For example, the distance weight may be large when the distance is small and the distance weight may be small when the distance is large. Any (continuous) connections are conceivable for this purpose. Furthermore, for example, the distance weight can be inversely proportional to the distance. Furthermore, for example, the distance weight can be a reciprocal of the distance, i.e. distance weight = (d(b, b_i))^(-1).

A distance weight can be a real number in the interval [0, infinity) (left endpoint included). A distance weight can be a natural number (including zero). A distance weight can be positive or zero. Furthermore, (Infinity)^(-1) can be defined as zero.

In 3 The following distance weights result, for example, as the reciprocal of the distances: Instruction block bx Distance bx to b Distance weight bx to b b1 2 0.5 b2 1 1.0 b3 2 0.5 b4 2 0.5 b5 0 Infinite (ignored) b6 3 0.333333333 b7 1 1.0

In this case, for example, instruction blocks b2 or b7 with high distance weights could be selected 119, 159.

1a, the method 100 can calculate 118a at least one distance from instruction blocks 11 to the at least one instruction block 13 reached during fuzzing (e.g. in an earlier fuzzing iteration or in the fuzzing iteration of the software). include. Alternatively or additionally, the method may include calculating 118a at least one distance weight of instruction blocks 11 to the at least one instruction block reached during fuzzing (e.g. in a previous fuzzing iteration or in the fuzzing iteration of the software).

The method 100 can, for example, as shown as an optional step in FIG. 1a, include calculating 118b a first probability measure for the at least one instruction block reached during fuzzing. The first probability measure can, for example, assign a standardized weight G to at least two instruction blocks of the control flow graph 10 or a part thereof, wherein the weights G can be standardized in such a way that the sum of all weights for the at least two instruction blocks can result in one.

Selecting 119 the first instruction block of the software - in particular, selecting 119 the first instruction block of the software based on distances, in particular distance weights, of the instruction blocks to the at least one instruction block in the control flow graph 10 reached during fuzzing - can be random or at least pseudo-random first pulling an instruction block as the first instruction block from the instruction blocks distributed according to the first probability measure.

Here or in general, such a drawing can also be referred to as rolling dice (a la Monte Carlo). The (first, later second) drawing may include, for example, drawing at least one number on a uniformly distributed (quasi-)real interval [0, 1] and evaluating an inverted distribution function for the (first, later second) probability measure on the at least one drawn number . Other implementations of dragging are known in the art.

von Abstandsgewichten des (beliebigen) Anweisungsblocks 11 zu je einem Anweisungsblock einer Vielzahl von beim Fuzzing erreichten Anweisungsblöcken oder eines Teils davon sein. Die Summe kann zum Beispiel in folgender Weise von den Abständen abhängen: $$\text{G}\sim \text{Sigma}\_\left\{\text{b\_i in B\_erreicht}\right\}(\text{d}\left(\text{b}\text{,b\_i}\right))\left(-1\right)$$

A weight G of an (arbitrary) instruction block 11 (e.g. b) can, for example, be a sum $$\text{G}\sim \text{Sigma}\_\left\{\text{b\_i in B\_achieved}\right\}\text{distance weight}\left(\text{b},\text{bi}\right)$$

of distance weights of the (arbitrary) instruction block 11 to one instruction block of a large number of instruction blocks reached during fuzzing or a part thereof. For example, the sum can depend on the distances in the following way: $$\text{G}\sim \text{Sigma}\_\left\{\text{b\_i in B\_achieved}\right\}(\text{d}\left(\text{b}\text{,bi}\right))\left(-1\right)$$

The sum of distance weights can be generalized to a (continuous) function, especially to functions whose image is non-negative (i.e. positive or zero).

Alternatively or additionally (the sum would then only have one summand for the at least one instruction block 13 (e.g. b_i) reached during fuzzing), a weight of an (arbitrary) instruction block 11 can be a distance weight of the (arbitrary) instruction block 11 to one instruction block of a large number of instruction blocks or part of them reached during fuzzing. In this case, for a weight G: $$\text{G}\sim \text{distance weight}\left(\text{b},\text{bi}\right)$$

Or e.g.: $$\text{G}\sim \left(\text{d}\left(\text{b}\text{,bi}\right)\right)\left(-1\right)$$

The first pull of the instruction block may be such that a first plurality of instruction blocks (i.e., a first plurality of instruction blocks predetermined at the time of the first pull) are not pulled. Alternatively or additionally, the first pulling of the instruction block can take place in such a way that the large number of instruction blocks 13 (previously) achieved during fuzzing or the part thereof are not pulled.

Excluding certain instruction blocks from being pulled can be achieved, for example, by dragging an instruction block until one that should not be excluded has been pulled. Alternatively, for example, the (first, later second) probability measure can be modified before drawing in such a way that only non-excluded instruction blocks can be drawn. One such possibility is, for example, to scale the (distance) weights of the excluded instruction blocks with zero and to renormalize the modified probability measure.

By excluding certain instruction blocks, the efficiency of fuzzing can be further increased.

The method 100 can, for example, be shown schematically as an optional step in 1b (continued to 1a) shown, selecting 159 a second instruction block of the software if the first check 140 is positive (eg at the latest before step 160, eg already in step 119). The method 100 can continue, as for example in 1b shown as an optional step, setting 160 a second breakpoint an instruction of the second instruction block of the software in the at least one breakpoint register or in a further breakpoint register if the first check 140 is positive (for example before step 170 at the latest, for example also in step 120). Setting 160 the second breakpoint before the instruction of the second instruction block of the software may include setting a memory address of the instruction of the second instruction block in the at least one breakpoint register or in another breakpoint register.

The method 100 can, for example, in 1b shown as an optional step, include second execution 170 of a fuzzing iteration of the software (based on fuzzing input data associated with the fuzzing iteration). Alternatively or additionally, the method 100, such as in 1b shown as an optional step, include second continuation 171 of the (already partially executed but stopped) fuzzing iteration of the software.

The method 100 can, for example, in 1b shown as an optional step, second checking 180 whether the second breakpoint is reached during the second execution 170 or second continuation 171 of the fuzzing iteration. The second breakpoint is reached when, without the second breakpoint, the instruction of the second execution block would have been executed when the software was executed based on the fuzzing input data of the fuzzing iteration.

The method 100 can, for example, in 1b shown as an optional step, storing 190 a second protocol information that the second instruction block has been reached in the fuzzing iteration if the second check 180 is positive.

The method 100 can, for example, in 1b shown as an optional step, deleting 191 the second breakpoint if the second check 180 is positive.

The software coverage feedback when fuzzing the software may include the second protocol information. The second protocol information can include, for example, the previous or further fuzzing input data of the fuzzing iteration.

Selecting 159 the second instruction block of the software can be at distances (e.g. d(b, b_i)] from instruction blocks 11 to at least one further instruction block reached during fuzzing (e.g. in a previous fuzzing iteration or in the fuzzing iteration of the software) in the control flow graphs 10 of the software. Alternatively or additionally, the selection 159 of the second instruction block of the software can be based on distance weights (e.g. (d(b, b_i))^-1) from instruction blocks 11 to at least one further one during fuzzing (e.g. at a previous fuzzing Iteration or when fuzzing the software) is based on the instruction block reached in the control flow graph 10 of the software.

The at least one further instruction block reached during fuzzing may, but does not have to, have been reached during the first execution 130 or first continuation 131 of the fuzzing iteration of the software.

The at least one further instruction block reached during fuzzing can be the at least one instruction block reached during fuzzing.

The method 100 can, for example, in 1b shown as an optional step, calculating 158a at least one distance from instruction blocks 11 to the at least one further instruction block reached during fuzzing (eg in an earlier fuzzing iteration or in the fuzzing iteration of the software). Alternatively or additionally, the method 100 may include calculating 158a at least one distance weight of instruction blocks 11 to the at least one further instruction block reached during fuzzing (eg in an earlier fuzzing iteration or in the fuzzing iteration of the software).

The distances can, but do not have to, be recalculated. Furthermore, the distance weights can, but do not have to, be recalculated. A recalculation can make sense, for example, if distances and/or distance weights are recalculated for another part of the control flow graph 10, i.e. if the part has changed in the meantime.

The procedure can, for example, in 1b shown as an optional step, calculating 158b a second probability measure for the at least one further instruction block reached during fuzzing, the second probability measure comprising at least two instruction blocks of the control flow Graphs 10 or a part thereof are each assigned a standardized weight, the weights being standardized in such a way that the sum of all weights for the at least two instruction blocks can result in one.

Selecting 159 the second instruction block of the software - in particular, selecting 159 the second instruction block of the software based on distances, in particular distance weights, of instruction blocks in the control flow graph 10 - may involve random or at least pseudo-random second pulling of an instruction block as a second instruction block from the following include instruction blocks distributed according to the second probability measure.

As in the case of the first probability measure, for example, a weight G of an (arbitrary) instruction block 11 can be a sum of distance weights of the (arbitrary) instruction block 11 to an instruction block of a further plurality of instruction blocks achieved during fuzzing or a part thereof. Alternatively or additionally, a weight G can be a distance weight of the (arbitrary) instruction block 11 to an instruction block of a further plurality of instruction blocks achieved during fuzzing or a part thereof.

The further multiplicity of instruction blocks achieved during fuzzing can, but does not have to be, the multiplicity of instruction blocks achieved during fuzzing. For example, the further plurality of instruction blocks achieved during fuzzing can differ from the plurality of instruction blocks achieved during fuzzing in that the further plurality of instruction blocks achieved during fuzzing now additionally includes the first instruction block, if it was reached in step 130, 131 .

In principle, the second probability measure can be the first probability measure. In this case, a recalculation may be unnecessary. However, (as a rule) the second probability measure may differ from the first probability measure, in particular in the event that the further plurality of instruction blocks achieved during fuzzing differs from the plurality of instruction blocks achieved during fuzzing. A recalculation of the probability measure can also make sense, for example, if the part of the control flow graph 10 has changed in the meantime.

The second pull of the instruction block may occur such that a second plurality of instruction blocks (i.e., a second plurality of instruction blocks predetermined at the time of the second pull) are not pulled. The second plurality of instruction blocks may, but does not have to be, the first plurality of instruction blocks. Alternatively or additionally, the second pulling of the instruction block can take place in such a way that the further plurality of instruction blocks reached during fuzzing or the part thereof is not pulled. Alternatively or additionally, the second pulling of the instruction block can take place in such a way that the first instruction block is not pulled.

As already explained, the efficiency of fuzzing can be further increased by excluding certain instruction blocks.

The method 100 can, for example, in 1b shown as an optional step, generating 169 further fuzzing input data for the fuzzing iteration, optionally based on the first protocol information. The second execution 170 of the fuzzing iteration may be based on the further fuzzing input data.

Setting 120, 160 breakpoints can be done via a debugging connection to the hardware target. Furthermore, the fuzzing iteration can be executed 130, 170 and/or continued 131, 171 via the debugging connection to the hardware target. The method 100 can, for example, as shown as an optional step in FIG. 1a, include initializing 110 the debugging connection to the hardware target.

The first instruction block of the software may include a predetermined start function (function to instrument) of the software. Such a choice may be suitable for starting fuzzing or at least a fuzzing iteration of fuzzing. Alternatively, the first instruction block may be any instruction block in the software (for example, repeat 199). Alternatively or additionally, the method 100 can be started by setting a (zeroth) breakpoint before any instruction of the software, in particular before an instruction of any (zeroth) instruction block in the control flow graph 10.

The method 100 can, for example, as shown as an optional step in FIG. 1a, comprise generating 105 the control flow graph 10 of the software based on the programming code of the software. Alternatively or additionally, the method 100 may include generating 105 the control flow graph 10 of the software via reverse engineering of the software. Alternatively or additionally, the method 100 may include generating 105 the control flow graph 10 of the software successively via obtaining software coverage feedback when fuzzing the software on the hardware target.

1a, the method 100 can include storing 152 a first protocol information, wherein the first protocol information includes that the first instruction block has not been reached in the fuzzing iteration if the first check 140 is negative . The method 100 may include deleting 151 the first breakpoint if the first check 140 is negative. The first test 140 can, for example, be negative if a predetermined criterion is met. The predetermined criterion can be met, for example, if the first breakpoint is not reached after a predetermined period of time or by the end of the fuzzing iteration.

The method 100 can, for example, in 1b shown as an optional step, storing 192 a second protocol information, wherein the second protocol information includes that the second instruction block has not been reached in the fuzzing iteration if the second check 180 is negative. The method 100 may include deleting 191 the second breakpoint if the second test 180 is negative. The second test 180 can, for example, be negative if a/the predetermined criterion is met. The predetermined criterion can be met, for example, if the second breakpoint is not reached after a predetermined period of time or until the end of the fuzzing iteration.

The software coverage feedback when fuzzing the software may include the first and/or second protocol information. The first and/or second protocol information can further include, for example, the (further) fuzzing input data.

The method 100 can, for example, in 1a or 1b each shown as an optional step, repeating 199 of method 100. For example, the method 100 may be repeated 199 until the execution of the fuzzing iteration and/or the fuzzing is completed. By repeating 199 breakpoints can be set successively and thus software coverage feedback can be obtained during fuzzing. The repeat 199 can, for example, begin with a new step 110, 118a, 118b, 119 or 120. Alternatively or additionally, repeating 199 can begin with a new step 158a, 158b, 159, 160, with each numbering of breakpoints, instruction blocks, etc. being incremented by one. For example, the new step 160 can thus read: setting a third breakpoint before an instruction of the third instruction block if the second check is positive, etc.

Also disclosed is a computer system designed to execute the computer-implemented method 100 for obtaining software coverage feedback when fuzzing the software on the hardware target. The computer system may include a processor and/or memory. The computer system may be designed to communicate with the hardware target via the debugging connection. The computer system may include the fuzzer, which is designed to generate and provide fuzzing input data for at least one fuzzing iteration of the software on the hardware target.

Also disclosed is a computer program designed to execute the computer-implemented method 100 for obtaining software coverage feedback when fuzzing the software on the hardware target. The computer program can, for example, be in interpretable or compiled form. It can be loaded (even in parts) into the RAM of a computer for execution, for example as a bit or byte sequence.

Also disclosed is a computer-readable medium or signal that stores and/or contains the computer program. The medium may include, for example, one of RAM, ROM, EPROM, HDD, SDD, ... on which the signal is stored.

Claims (20)

A computer-implemented method (100) for obtaining software coverage feedback when fuzzing software on a hardware target, the hardware target having at least one breakpoint register and being configured to require execution of the software before executing an instruction stopping 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: - selecting (119) a first instruction block of the software; - Setting (120) a first breakpoint before an instruction of the first instruction block in the at least one breakpoint register; - first executing (130) or first continuing (131) a fuzzing iteration of the software; - first checking (140) whether the first breakpoint is reached when the fuzzing iteration is first executed (130) or continued (131); - storing (150) first protocol information comprising that the first instruction block has been reached in the fuzzing iteration - and, optionally, deleting (151) the first breakpoint - if the first check (140) is positive; wherein the software coverage feedback includes the first protocol information when fuzzing the software; wherein the selection (119) of the first instruction block of the software is based on distances, optionally distance weights, from instruction blocks (11) to at least one instruction block (13) reached during fuzzing in a control flow graph (10) of the software. Procedure (100) according to Claim 1 , wherein a distance of an instruction block (11) to the at least one instruction block reached during fuzzing is a minimum of: - a minimum path length from the instruction block (11) to the at least one instruction block reached during fuzzing; and/or - a minimum path length from the at least one instruction block reached during fuzzing to the instruction block (11); is. Procedure (100) according to Claim 2 , wherein a path length from one instruction block to another instruction block is an at least approximate measure of - whether a path, in the control flow graph (10) or a part thereof, comprising at least one directed edge (12) starting from the one instruction block and in the flow direction to the other statement block exists; and/or - how long such a path is if it exists, in particular how many of the at least one directed edge (12) this path includes. Method (100) according to one of the preceding claims, wherein a distance weight of an instruction block (11) to the at least one instruction block reached during fuzzing is based on the distance of the instruction block (11) to the at least one instruction block reached during fuzzing; - optional, where the distance weight is large when the distance is small, and where the distance weight is small when the distance is large; - optional, where the distance weight is inversely proportional to the distance; - optional, where the distance weight is a reciprocal of the distance. Method (100) according to one of the preceding claims, comprising: - Calculating (118a) at least one distance, optionally at least one distance weight, from instruction blocks (11) to the at least one instruction block reached during fuzzing. Method (100) according to one of the preceding claims, comprising: - Calculating (118b) a first probability measure for the at least one instruction block reached during fuzzing, the first probability measure assigning a standardized weight to at least two instruction blocks of the control flow graph (10) or a part thereof, the weights being normalized in such a way that the sum of all Weights for at least two instruction blocks equal one; wherein selecting (119) the first instruction block of the software - in particular, selecting (119) the first instruction block of the software based on distances, in particular distance weights, of the instruction blocks to the at least one instruction block in the control flow graph (10) reached during fuzzing - random first drawing an instruction block as a first instruction block from the instruction blocks distributed according to the first probability measure; where a weight of an instruction block (11): - a sum of distance weights of the instruction block (11) to one instruction block of a plurality of instruction blocks reached during fuzzing or a part thereof; and or - a distance weight of the instruction block (11) to one instruction block of a plurality of instruction blocks reached during fuzzing or a part thereof; is. Procedure (100) according to Claim 6 , wherein the first pulling of the instruction block is such that: - a first plurality of instruction blocks; and/or - the plurality of instruction blocks or part thereof reached during fuzzing; not be pulled. Method (100) according to one of the preceding claims, comprising: - Selecting (159) a second instruction block of the software if the first test (140) is positive; - Setting (160) a second breakpoint before an instruction of the second instruction block of the software in the at least one breakpoint register or in a further breakpoint register if the first check (140) is positive; - secondly executing (170) a fuzzing iteration or secondly continuing (171) the fuzzing iteration of the software; - second checking (180) whether the second breakpoint is reached during the second execution (170) or second continuation (171) of the fuzzing iteration; - storing (190) second protocol information comprising that the second instruction block has been reached in the fuzzing iteration - and, optionally, deleting (191) the second breakpoint - if the second check (180) is positive; wherein the software coverage feedback includes the second protocol information when fuzzing the software, wherein selecting (159) the second instruction block of the software is based on distances, optionally distance weights, from instruction blocks (11) to at least one further instruction block reached during fuzzing in the control flow graph (10) of the software; optionally, whereby the at least one further instruction block reached during fuzzing has been reached the first time the fuzzing iteration of the software is executed (130) or continued (131). Procedure (100) according to Claim 8 , comprising: - Calculating (158a) at least one distance, optionally at least one distance weight, from instruction blocks (11) to the at least one further instruction block reached during fuzzing. Procedure (100) according to Claim 8 or 9 , comprising: - Calculating (158b) a second probability measure for the at least one further instruction block reached during fuzzing, the second probability measure assigning a standardized weight to at least two instruction blocks of the control flow graph (10) or a part thereof, the weights being standardized in this way, that the sum of all weights for the at least two instruction blocks equals one; wherein selecting (159) the second instruction block of the software - in particular, selecting (159) the second instruction block of the software based on distances, in particular distance weights, of instruction blocks in the control flow graph (10) - randomly second pulling an instruction block as a second instruction block from the instruction blocks distributed according to the second probability measure; wherein a weight of an instruction block (11): - a sum of distance weights of the instruction block (11) to each instruction block of a further plurality of instruction blocks reached during fuzzing or a part thereof; and/or - a distance weight of the instruction block (11) to an instruction block of a further plurality of instruction blocks reached during fuzzing or a part thereof; is. Procedure (100) according to Claim 10 , wherein the second pulling of the instruction block is such that: - a second plurality of instruction blocks; - the further multitude of instruction blocks or parts thereof achieved during fuzzing; and/or - the first instruction block; not be pulled. Method (100) according to one of Claims 8 until 11 , comprising: - Generating (169) further fuzzing input data for the fuzzing iteration, optionally based on the first protocol information. wherein the second execution (170) of the fuzzing iteration is based on the further fuzzing input data. Method (100) according to one of the preceding claims, wherein the software is not statically instrumented for fuzzing and/or is closed-source. Method (100) according to one of the preceding claims, comprising: - generating (105) the control flow graph (10) of the software based on the programming code of the software, via reverse engineering of the software and / or successively via obtaining software coverage feedback when fuzzing the software on the Hardware target. Method (100) according to one of the preceding claims, wherein the hardware target is an electronic control unit and the software is designed to control, regulate and / or monitor the electronic control unit. Method (100) according to one of the preceding claims, comprising: - storing (152) first protocol information comprising that the first instruction block has not been reached in the fuzzing iteration - and, optionally, deleting (151) the first breakpoint - if the first check (140) is negative, the first check (140) is negative if the first breakpoint is not reached after a predetermined period of time or until the end of the fuzzing iteration; and or - storing (192) second protocol information comprising that the second instruction block has not been reached in the fuzzing iteration - and, optionally, deleting (191) the second breakpoint - if the second check (180) is negative, the second check (180) is negative if the second breakpoint is not reached after a predetermined period of time or until the end of the fuzzing iteration; wherein the software coverage feedback includes the first and/or second protocol information when fuzzing the software. Method (100) according to one of the preceding claims, comprising: - Repeating (199) the method (100) according to one of the preceding claims. Computer system adapted to carry out the computer-implemented method (100) for obtaining software coverage feedback when fuzzing the software on the hardware target according to any one of the preceding claims. Computer program designed to implement the computer-implemented method (100) for obtaining software coverage feedback when fuzzing the software on the hardware target according to one of the Claims 1 until 17 to carry out. Computer-readable medium or signal that the computer program reads Claim 19 stores and/or contains.

Images