DE102022203356A1 - FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON CONNECTIVITIES OF STATEMENT BLOCKS IN CONTROL FLOW GRAPH - Google Patents
FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON CONNECTIVITIES OF STATEMENT BLOCKS IN CONTROL FLOW GRAPH Download PDFInfo
- Publication number
- DE102022203356A1 DE102022203356A1 DE102022203356.6A DE102022203356A DE102022203356A1 DE 102022203356 A1 DE102022203356 A1 DE 102022203356A1 DE 102022203356 A DE102022203356 A DE 102022203356A DE 102022203356 A1 DE102022203356 A1 DE 102022203356A1
- Authority
- DE
- Germany
- Prior art keywords
- software
- fuzzing
- instruction
- connectivity
- breakpoint
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 89
- 230000015654 memory Effects 0.000 claims abstract description 12
- 238000012360 testing method Methods 0.000 claims description 14
- 238000004590 computer program Methods 0.000 claims description 8
- 230000006870 function Effects 0.000 claims description 6
- 230000003068 static effect Effects 0.000 description 5
- 230000006399 behavior Effects 0.000 description 3
- 230000001105 regulatory effect Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013016 damping Methods 0.000 description 1
- 238000005315 distribution function Methods 0.000 description 1
- 238000012067 mathematical method Methods 0.000 description 1
- JTJMJGYZQZDUJJ-UHFFFAOYSA-N phencyclidine Chemical compound C1CCCCN1C1(C=2C=CC=CC=2)CCCCC1 JTJMJGYZQZDUJJ-UHFFFAOYSA-N 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 210000002023 somite Anatomy 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- NWONKYPBYAMBJT-UHFFFAOYSA-L zinc sulfate Chemical compound [Zn+2].[O-]S([O-])(=O)=O NWONKYPBYAMBJT-UHFFFAOYSA-L 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3676—Test management for coverage analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
- G06F8/433—Dependency analysis; Data or control flow analysis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
Ein erster Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target, wobei das Hardware-Target mindestens ein Haltepunktregister aufweist und dafür ausgelegt ist, eine Ausführung der Software vor Ausführung einer Anweisung der Software anzuhalten, wenn die Anweisung bei der Ausführung der Software erreicht wird und eine Speicheradresse der Anweisung in dem mindestens einen Haltepunkteregister gesetzt ist, umfassend Auswählen eines ersten Anweisungsblocks der Software; Setzen eines ersten Haltepunkts vor einer Anweisung des ersten Anweisungsblocks in dem mindestens einen Haltepunktregister; erstes Ausführen oder erstes Fortsetzen einer Fuzzing-Iteration der Software; erstes Prüfen, ob der erste Haltepunkt beim ersten Ausführen oder ersten Fortsetzen der Fuzzing-Iteration erreicht wird; Speichern einer ersten Protokollinformation umfassend, dass der erste Anweisungsblock in der Fuzzing-Iteration erreicht worden ist - und, optional, Löschen des ersten Haltepunkts - wenn das erste Prüfen positiv ausfällt. Das Softwareabdeckungsfeedback beim Fuzzing der Software umfasst die erste Protokollinformation. Das Auswählen des ersten Anweisungsblocks der Software kann auf Konnektivitäten, optional Konnektivitätsgewichten, von Anweisungsblöcken in einem Kontrollflussgraphen der Software basieren.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 connectivities, optionally connectivity weights, of instruction blocks in a control flow graph of the software.
Description
Stand der TechnikState of the art
Fuzzing (englisch: fuzzing oder fuzz testing) ist eine automatisierte Technik zum Testen einer Software. Hierbei wird in einer Vielzahl von Fuzzing-Iterationen die Software mit ungültigen, unerwarteten und/oder zufälligen Eingangsdaten ausgeführt und dabei auf Ausnahmen (englisch: exceptions) wie Abstürze, fehlgeschlagene eingebaute Code-Zusicherungen (englisch: assertions), potenzielle Speicherlecks, etc. überwacht. Für Software, deren Eingangsdaten in einer vorbestimmten Datenstruktur vorliegen müssen, können Fuzzer (englisch: fuzzers), die für diese vorbestimmte Datenstruktur ausgelegt sind, zum Einsatz kommen. Die vorbestimmte Datenstruktur ist zum Beispiel in einem Dateiformat und/oder Protokoll spezifiziert. Ein (effizienter) Fuzzer ist dafür ausgelegt, ungültige, unerwartete und/oder zufällige Eingangsdaten in der vorbestimmten Datenstruktur zu generieren, so dass eine Ausführung einer jeweiligen Fuzzing-Iteration der Software ohne Parse-Fehler auf Basis der Eingangsdaten gestartet werden kann. Durch Fuzzing kann insbesondere in komplexer Software (wie z.B. Software für die Steuerung, Regelung und/oder Überwachung eines technischen Systems) unerwartetes Verhalten wie z.B. unerwartete (Progamm)pfade und/oder Programmierfehler sowie Randfälle ermittelt werden. Durch ein derart erlangtes besseres Softwareverständnis können die Software und insbesondere deren Sicherheit verbessert werden.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.
Ein Fuzzing-Target kann eine Software (z.B. ein Programm) und/oder ein Teil davon (z.B. eine Funktion) sein, die durch Fuzzing getestet werden soll. Das Fuzzing-Target kann dergestalt sein, dass es potenziell nicht vertrauenswürdige Eingangsdaten akzeptiert, die beim Fuzzing durch einen Fuzzer für eine Vielzahl von Fuzzing-Iterationen generiert werden können. In diesem Zusammenhang kann Fuzzing als der automatisierte Vorgang gesehen werden, beliebige und insbesondere ungültige, unerwartete und/oder zufällige Eingangsdaten an das Fuzzing-Target zu schicken und dessen Reaktion sodann während der Ausführung dieser Fuzzing-Iteration zu beobachten. Der Fuzzer oder die Fuzzing-Maschine ist ein Computer-Programm, das dafür ausgelegt ist, automatisiert Eingangsdaten je Fuzzing-Iteration für das Fuzzing-Target zu generieren. Der Fuzzer ist nicht Teil des Fuzzing-Targets, sondern unabhängig vom Fuzzing-Target. In der Regel sind Fuzzer nicht instrumentiert. Ein bekannter Fuzzer ist zum Beispiel afl oder libfuzzer. Die Kombination aus einem Fuzzing-Target und einem dazugehörigen Fuzzer kann als Fuzzing-Test bezeichnet werden. Der Fuzzing-Test ist ausführbar. Der Fuzzer kann jeweils unterschiedliche (Fuzzing-)Eingangsdaten für eine Vielzahl von Fuzzing-Iterationen - z.B. hunderte oder tausende Fuzzing-Iterationen pro Sekunde - generieren und jeweils einen Fuzzing-Test mit den dazugehörigen Eingangsdaten starten, beobachten, und gegebenenfalls auch anhalten. Eine Fuzzing-Iteration umfasst eine Ausführung des Fuzzing-Targets/der Software ausgehend von für diese Fuzzing-Iteration generierten (Fuzzing-) Eingangsdaten. Durch Speichern der jeweiligen Eingangsdaten, kann die Fuzzing-Iteration, insbesondere, wenn ein unerwartetes Verhalten der Software während der Fuzzing-Iteration (z.B. noch nicht bekannte Pfade und/oder Programmierfehler) erkannt wurde, zu einem späteren Zeitpunkt reproduziert werden, wobei dann das Fuzzing-Target ohne Fuzzer aber auf den gespeicherten (Fuzzing-) Eingangsdaten ausgeführt werden kann.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.
Während der Ausführung eines Fuzzing-Tests können Informationen aus dem Software-Target ausgegeben werden. Ein solches Softwareabdeckungsfeedback (englisch: coverage-guided fuzzing) kann vorteilhafterweise beim Fuzzing genutzt werden, um noch nicht bekannte Pfade/Blöcke zu erkennen und/oder Programmierfehler in der Software zu lokalisieren. Softwareabdeckungsfeedback beim Fuzzing kann zum Beispiel wie bei afl durch statische Instrumentierung des Fuzzing-Targets realisiert werden. Bei der statischen Instrumentierung wird das Fuzzing-Target - d.h. die Software - (zum Beispiel beim Kompilieren) dahingehend geändert, dass Informationen über zum Beispiel zuletzt ausgeführte Anweisungen in der Software und/oder (Programm)pfade bei der Ausführung der Software und insbesondere während einer Fuzzing-Iteration abgerufen werden können. Alternativ oder zusätzlich kann Softwareabdeckungsfeedback aus einer dynamischen Instrumentierung erlangt werden. Hierbei wird über Systemfunktionalitäten und/oder Emulatoren die Ausführung der Software zur Laufzeit gesteuert, um Informationen über die Abläufe in der Software zu erhalten. Softwareabdeckungsfeedback durch dynamische Instrumentierung ist insbesondere dann vorteilhaft, wenn die Software in kompilierter Form (englisch: closed-source) vorliegt.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 offenbaren eine dynamische Instrumentierung über Debugger und Haltepunkte, die auf Software-Interrupts basiert. Dabei wird aktiv der Binärcode (englisch: binary) der Software verändert und eine Instruktion durch eine Software-Interrupt-Instruktion ersetzt.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.
Lawrence Page, Sergey Brin, Rajeev Mofinrani, and Terry Winograd, „The pagerank citation ranking: Bringing order to the web“, technical report, Stanford InfoLab, 1999, offenbaren einen Algorithmus zu Berechnung eines PageRank (bzw. einer PageRank-Bewertung). Diese Offenbarung lehrt, dass die Bedeutung einer Webseite von Natur aus eine subjektive Angelegenheit sei, die von den Interessen, Kenntnissen und Einstellungen der Nutzer der Webseite abhängt. Dennoch lasse sich vieles objektiv über die relative Bedeutung von Webseiten sagen. PageRank ist ein mathematisches Verfahren zur objektiven und mechanischen Bewertung von Webseiten, mit dem das menschliche Interesse und die Aufmerksamkeit, die ihnen gewidmet wird, effektiv gemessen werden kann. PageRank könne mit einem idealisierten zufälligen Web-Surfer verglichen werden. Weiterhin kann PageRank für eine große Anzahl von Seiten effizient berechnen werden. Es werde gezeigt, wie man PageRank auf die Suche und auf die Benutzernavigation anwendet.Lawrence Page, Sergey Brin, Rajeev Mofinrani, and Terry Winograd, “The pagerank citation ranking: Bringing order to the web,” technical report, Stanford InfoLab, 1999, disclose an algorithm for calculating a PageRank (or a PageRank rating). This disclosure teaches that the meaning of a website is inherently a subjective matter that depends on the interests, knowledge and attitudes of the website's users. Nevertheless, a lot can be said objectively about the relative importance of websites. PageRank is a mathematical method for objectively and mechanically evaluating web pages, which can effectively measure human interest and the attention paid to them. PageRank can be compared to an idealized random web surfer. Furthermore, PageRank can be calculated efficiently for a large number of pages. Shown how to apply PageRank to search and user navigation.
Offenbarung der ErfindungDisclosure of the invention
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target, wobei das Hardware-Target mindestens ein Haltepunktregister aufweist und dafür ausgelegt ist, eine Ausführung der Software vor Ausführung einer Anweisung der Software anzuhalten, wenn die Anweisung bei der Ausführung der Software erreicht wird und eine Speicheradresse der Anweisung in dem mindestens einen Haltepunkteregister gesetzt ist. Das Verfahren umfasst Auswählen eines ersten Anweisungsblocks der Software. Das Verfahren umfasst weiterhin Setzen eines ersten Haltepunkts vor einer Anweisung des ersten Anweisungsblocks in dem mindestens einen Haltepunktregister. Das Verfahren umfasst weiterhin erstes Ausführen oder erstes Fortsetzen einer Fuzzing-Iteration der Software. Das Verfahren umfasst weiterhin erstes Prüfen, ob der erste Haltepunkt beim ersten Ausführen oder ersten Fortsetzen der Fuzzing-Iteration erreicht wird. Das Verfahren umfasst weiterhin Speichern einer ersten Protokollinformation umfassend, dass der erste Anweisungsblock in der Fuzzing-Iteration erreicht worden ist, wenn das erste Prüfen positiv ausfällt. Das Verfahren kann Löschen des ersten Haltepunkts, wenn das erste Prüfen positiv ausfällt, umfassen. Das Softwareabdeckungsfeedback beim Fuzzing der Software umfasst die erste Protokollinformation. Das Auswählen des ersten Anweisungsblocks der Software kann auf Konnektivitäten von Anweisungsblöcken in einem Kontrollflussgraphen der Software basieren. Alternativ oder zusätzlich kann das Auswählen des ersten Anweisungsblocks der Software auf Konnektivitätsgewichten von Anweisungsblöcken in einem Kontrollflussgraphen der Software basieren.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 includes the first protocol information. Selecting the first instruction block of the software may be based on connectivities of instruction blocks in a control flow graph of the software. Alternatively or additionally, selecting the first instruction block of the software may be based on connectivity weights of instruction blocks in a control flow graph of the software.
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-System, das dafür ausgelegt ist, das computer-implementierte Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.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).
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-Programm, das dafür ausgelegt ist, das computer-implementierte Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.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).
Ein vierter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-lesbares Medium oder Signal, das das Computer-Programm nach dem dritten allgemeinen Aspekt (oder einer Ausführungsform davon) speichert und/oder enthält.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).
Das in dieser Offenbarung vorgeschlagene Verfahren nach dem ersten Aspekt (oder einer Ausführungsform davon) ist auf die Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target gerichtet, insbesondere wenn die Software an sich oder auf dem Hardware-Target nicht statisch instrumentiert werden kann.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 .
Für Computersysteme wie Desktop-Systeme (PC etc.) und insbesondere für Software die in Form eines Programmiercodes vorliegt (z.B. open source) ist die statische Instrumentierung eine bekannte Methode, um Softwareabdeckungsfeedback beim Ausführen der Software und insbesondere während einer Fuzzing-Iteration der Software zu erlangen.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.
Die statische Instrumentierung für das Fuzzing kann jedoch bei Software, die auf einem eingebetteten System (englisch: embedded system), das in einem technischen Kontext eingebunden ist, ausgeführt wird, aus den folgenden Gründen schwierig sein: Der für das Fuzzing erforderliche Fuzzer muss typischerweise (z.B. aus Mangel an Rechen- und/oder Speicherkapazität im eingebetteten System) auf einem anderen Rechner ausgeführt werden. Daraus ergibt sich, dass Softwareabdeckungsfeedback aus dem eingebetteten System erst zu dem Fuzzer (oder einem anderen Rechner) transferiert werden muss. Weiterhin muss typischerweise ein Gesamtsystem getestet werden, dass durchaus eine Vielzahl von Komponenten umfassen kann. Die Software für das Gesamtsystem kann Drittparteibibliotheken und Softwarekomponenten anderer Zulieferer und/oder Kunden aufweisen. Häufig werden solche Softwarekomponenten als Binärdateien (d.h. in kompilierter Form, auch: Binärcode) geliefert, die nicht oder nur mit Aufwand modifiziert werden können. Da solche Softwarekomponenten nicht mehr kompiliert werden, können sie nur mit Aufwand statisch instrumentiert werden. Dagegen kann Software (oder Softwarekomponenten davon), die als Programmiercode vorliegt, leicht beim Kompilieren statisch instrumentiert werden. Allerdings nimmt die Größe der Software in jedem Fall durch die statische Instrumentierung zu, so dass häufig aufgrund der typischerweise beschränkten Ressourcen die statisch instrumentierte Software nicht mehr in den Speicher des eingebetteten Systems passt. Dasselbe gilt für weitere Funktionalitäten, um die die Software für das Fuzzing erweitert werden kann.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 do not contain or only contain On wall can be modified. Since such software components are no longer compiled, they can only be statically instrumented with great effort. In contrast, software (or software components thereof) that exists as programming code can easily be statically instrumented during compilation. 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 einer alternativen Herangehensweise kann die Software des eingebetteten Systems in einem Emulator wie z.B. QEMU ausgeführt werden. Hierbei kann die Transparenz und Konfigurierbarkeit des Emulators dazu genutzt werden, das Softwareabdeckungsfeedback während des Fuzzing bereitzustellen. Leider ist die Einrichtung eines solchen Emulators für ein spezifisches Hardware-Target mit einem enormen Arbeitsaufwand verbunden, da typischerweise die Funktionalität der Software des eingebetteten Systems auf der Verfügbarkeit externer Hardware-Komponenten wie Sensoren und/oder Aktuatoren basiert. Fehlen allerdings solche Hardware-Komponenten in dem Emulator, kann die Software nicht unter denen Bedingungen getestet werden, für die sie eigentlich konzipiert ist. In der Tat wird sich die Software in diesem Fall anders verhalten als im Kontext des für sie konzipierten technischen Systems. Das kann sich zum Beispiel darin äußern, dass die Software wahrscheinlich andere Pfade durchlaufen wird, die nur bedingt mit dem eigentlichen Einsatzzweck der Software zu tun haben. Der Einsatz eines Emulators zwecks Softwareabdeckungsfeedback beim Fuzzing ist somit weniger geeignet.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.
Wird ein Debugger mit dem eingebetteten System verbunden, können Haltepunkt-Anweisungen (über mindestens ein Hardware-Haltepunktregister) genutzt werden, um die Ausführung der Software im eingebetteten System an einer gezielten Position im Code anzuhalten. Allerdings wird man nicht durch beliebige Haltepunkte ein annährend komplettes Softwareabdeckungsfeedback erhalten können, da die Anzahl der gleichzeitig aktiven Haltepunkte normalerweise stark limitiert ist. Zum Beispiel ist ein ARM Cortex-MO Mikrokontroller für maximal vier gleichzeitig aktive Hardware-Haltepunkte ausgelegt.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.
Das in dieser Offenbarung vorgeschlagene Verfahren nach dem ersten Aspekt (oder einer Ausführungsform davon) eignet sich besonders für das Fuzzing auf einem Hardware-Target/eingebetteten System und im (typischen) Fall, dass die Anzahl der Haltepunkte stark limitiert ist. Wie bereits ausgeführt, kann die Software durch das Fuzzing auf dem (echten) Hardware-Target - im Gegensatz zum Emulator - realistischer und somit besser getestet werden. Für das Verfahren ist es ausreichend, wenn das Hardware-Target mindestens einen Haltepunkt zulässt. Ausgehend von z.B. einer Startanweisung, die zumeist spezifiziert ist, kann dank des in dieser Offenbarung vorgeschlagenen Verfahrens und insbesondere durch ein systematisches Abfahren von Anweisungen durch strategisches Setzen mindestens eines Haltepunkts ein/der Kontrollflussgraph der Software zumindest zu dem durch die Fuzzing-Iteration abgedeckten Teil der Software ermittelt und/oder erprobt werden. Tritt unerwartetes Verhalten während einer Fuzzing-Iteration auf, kann das Softwareabdeckungsfeedback dazu genutzt werden, die Software und insbesondere deren Sicherheit durch eine Software-Änderung zu verbessern. Dadurch kann weiterhin die Funktionalität und insbesondere die Sicherheit des durch die Software gesteuerten, geregelten und/oder überwachten eingebetteten Systems verbessert werden.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, a control flow graph 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.
Ein im Stand der Technik (Oh et al., siehe oben) bekanntes Verfahren für die dynamische Instrumentierung über Debugger und Haltepunkte auf Basis von Software-Interrupts könnte im Lichte der vorliegenden Offenbarung ebenfalls zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target eingesetzt werden. Zum Beispiel kann das bereits beschriebene Ersetzen einer Instruktion durch eine Software-Interrupt-Instruktion mehrfach wiederholt werden und dadurch verschiedene Haltepunkte gesetzt werden. Dabei muss allerdings der Speicher bei jeder Wiederholung neu geschrieben werden. Bei den genutzten EEPROM/Flash Speichern in Mikrocontrollern führt das jedoch zu einem erheblichen Overhead. Die Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target via Software-Interrupts wird dadurch ineffizient oder gar impraktikabel.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.
Stattdessen werden in dem in dieser Offenbarung vorgeschlagenen Verfahren Hardware-Haltepunkte (via das mindestens eine Hardware-Haltepunktregister) gesetzt. Vorteilhaft erweist sich dabei, dass Hardware-Haltepunkte ohne großen Overhead gesetzt werden können. Somit kann Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target effizient und somit schnell erlangt werden.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.
Das in dieser Offenbarung vorgeschlagene Verfahren ist weiterhin auch in Anwendungsfällen (z.B. zum Testen/Erproben existierender Produkte) geeignet, in denen die Software aus einem Nur-Lese-Speicher (englisch: ROM, read-only memory) des Hardware-Targets ausgeführt wird. In diesem Fall ist das Ersetzen von Anweisungen im Binärcode der Software durch Software-Interrupt-Instruktionen, wenn überhaupt, nur mit erheblichem Aufwand möglich.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 In this case, replacing instructions in the binary code of the software with software interrupt instructions is only possible with considerable effort, if at all.
In dem in dieser Offenbarung vorgeschlagenen Verfahren nach dem ersten Aspekt (oder einer Ausführungsform davon) umfasst das strategische Setzen (oder Auswählen) des mindestens einen Haltepunkts oder z.B. jeweils eines Haltepunkts je vorhandenem Hardware-Haltepunktregister - es können z.B. ein, zwei, drei, vier oder mehr als vier, acht oder mehr als acht Hardware-Haltepunktregister auf dem Hardware-Target vorhanden sein - ein Setzen basierend auf Konnektivitäten, insbesondere Konnektivitätsgewichten, von Anweisungsblöcken in dem Kontrollflussgraphen. In einer Ausführungsform des Verfahrens kann das strategische Setzen des mindestens einen Haltepunkts ein z.B. sukzessives Setzen von Haltepunkten vor Anweisungen von Anweisungsblöcken, die im Kontrollflussgraphen jeweils in einem hohen Maß mit anderen Anweisungsblöcken verbunden sind, d.h. hohe Konnektivitäten, insbesondere hohe Konnektivitätsgewichte, aufweisen, umfassen. Im Gegensatz z.B. zum sukzessiven Setzen von Haltepunkten vor benachbarten Anweisungen in einem abstrakten Syntaxbaum der Software und/oder gar zu beliebigen Anweisungen der Software und insbesondere im Fall von hinreichend komplexer Software - ein Kriterium, das in der Praxis fast immer erfüllt ist und/oder sehr leicht erfüllt werden kann - wird durch das strategische Setzen basierend auf (hohen) Konnektivitäten, insbesondere (hohen) Konnektivitätsgewichten, von Anweisungsblöcken im Kontrollflussgraphen die Wahrscheinlichkeit für einen Softwareentwickler/Nutzer der Software interessante und/oder relevante Ausführungsblöcke zu finden deutlich erhöht. Dadurch wird das Fuzzing erheblich effizienter, besser und/oder schneller. Dadurch kann die Software und insbesondere das von der Software gesteuerte, geregelte und/oder überwachte System verbessert werden.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 on the hardware target - setting based on connectivity, in particular connectivity weights, of instruction blocks in the control flow graph. In one embodiment of the method, the strategic setting of the at least one breakpoint can include, for example, successive setting of breakpoints before instructions of instruction blocks, which are each highly connected to other instruction blocks in the control flow graph, i.e. have high connectivity, in particular high connectivity weights. 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 - strategically setting based on (high) connectivity, in particular (high) connectivity weights, of instruction blocks in the control flow graph significantly increases the probability for a software developer/user of the software to find interesting and/or relevant execution blocks. 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 Ausführungsformen des in dieser Offenbarung vorgeschlagenen Verfahrens nach dem ersten Aspekt (oder einer Ausführungsform davon) kann das strategische Setzen (oder Auswählen) des mindestens einen Haltepunkts oder z.B. jeweils eines Haltepunkts je vorhandenem Hardware-Haltepunktregister zum einen durch (hohe) Konnektivitäten, insbesondere (hohe) Konnektivitätsgewichte, von Anweisungsblöcken zumindest tendenziell geleitet werden, und zum anderen auf einer probabilistischen Auswahl von Anweisungsblöcken basieren. Dazu kann zum Beispiel ein Wahrscheinlichkeitsmaß berechnet werden, das Anweisungsblöcken im Kontrollflussgraphen oder einem Teil davon (normierte) Konnektivitätsgewichte zuordnet. Das Auswählen von Anweisungsblöcken, vor oder in denen mindestens ein Haltepunkt gesetzt werden soll, kann dann einzelnes oder mehrfaches Ziehen von Anweisungsblöcken gemäß des Wahrscheinlichkeitsmaßes umfassen. In anderen Worten: Die Anweisungsblöcke können nach dem Wahrscheinlichkeitsmaß (z.B. ä la Monte Carlo) gewürfelt werden. Ein Vorteil besteht darin, dass zwar Anweisungsblöcke mit hohen Konnektivitäten/Konnektivitätsgewichten bevorzugt und zumindest pseudo-zufällig ausgewählt werden, es dennoch aber möglich ist und von Zeit zu Zeit auch geschieht, dass ein weniger vernetzter Anweisungsblock ausgewählt wird. Die Zufälligkeit kann insbesondere bewirken, dass der Kontrollflussgraph hinreichend gut beim Fuzzing abgedeckt wird, d.h. dass das Auswählen von Anweisungsblöcke nicht nur auf einem kleinen Teil des Kontrollflussgraphen beschränkt ist. Auch dadurch wird das Fuzzing erheblich effizienter, besser und/oder schneller. Dadurch kann die Software und insbesondere das von der Software gesteuerte, geregelte und/oder überwachte System verbessert werden.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 (high) connectivity, in particular ( high) connectivity 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) connectivity 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 high connectivity/connectivity weights are preferred and at least pseudo-randomly selected, it is still possible, and does happen from time to time, for a less connected 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.
Kurzbeschreibung der FigurenShort description of the characters
- Fig. la illustriert schematisch ein computer-implementiertes Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target.Fig. la schematically illustrates a computer-implemented method for obtaining software coverage feedback when fuzzing software on a hardware target.
-
1b illustriert schematisch eine Fortsetzung des computer-implementierten Verfahrens zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem 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 illustriert schematisch eine beispielhafte Ausführungsform des computer-implementierten Verfahrens zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem 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 zeigt einen beispielhaften und schematischen Kontrollflussgraphen einer Software mit Anweisungsblöcken und gerichteten Kanten.3 shows an exemplary and schematic control flow graph of a software with instruction blocks and directed edges.
Detaillierte BeschreibungDetailed description
Das in dieser Offenbarung vorgeschlagene Verfahren 100 ermöglicht die Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target. Das Hardware-Target kann zum Beispiel eine elektronische Steuereinheit sein, wobei die Software dafür ausgelegt sein kann, die elektronische Steuereinheit zu steuern, regeln und/oder zu überwachen.The
Das in dieser Offenbarung vorgeschlagene Verfahren 100 kann sich besonders für den Fall eignen, in dem die Software nicht statisch für Fuzzing instrumentiert ist. Weiterhin kann die Software (ganz oder teilweise) closed-source sein. Stattdessen kann Softwareabdeckungsfeedback beim Fuzzing der Software über dynamische Instrumentierung erlangt werden.The
Bei Bestehen einer Debugging-Verbindung zu dem Hardware-Target kann zum Beispiel wie folgt, und wie in
- Zunächst kann z.B. vordem 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.
- First, for example, a zero breakpoint can be set 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.
Sodann kann die Fuzzing-Iteration der Software auf Basis der Fuzzing-Eingangsdaten für die Fuzzing-Iteration ausgeführt werden. Wird der nullte oder erste Haltepunkt beim Ausführen der Fuzzing-Iteration erreicht, kann er als erreicht markiert werden. Optional und insbesondere, wenn die maximale Anzahl der (Hardware-)Haltepunktregister stark limitiert ist, kann der nullte und/oder erste Haltepunkt gelöscht werden.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.
Sodann kann mindestens ein zweiter Haltepunkt in oder vor einem zweiten Anweisungsblock gesetzt werden. Wird wiederum der zweite Haltepunkt beim Ausführen der Fuzzing-Iteration erreicht, kann er als erreicht markiert werden. Optional und insbesondere, wenn die maximale Anzahl der Haltepunktregister stark limitiert ist, kann der zweite Haltepunkt gelöscht werden. Die Fuzzing-Eingangsdaten, die dazu geführt haben, dass der zweite Haltepunkt erreicht wurde, können gespeichert und mit dem dazugehörigen Anweisungsblock in dem Kontrollflussgraphen 10 der Software verknüpft werden.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 linked to the associated instruction block in the
Durch sukzessives Umsetzen (oder Löschen und Neusetzen) mindestens eines Haltepunkts kann Softwareabdeckungsfeedback während der Ausführung der Fuzzing-Iteration erlangt werden. Das Softwareabdeckungsfeedback kann zum Beispiel einen Pfad in dem Kontrollflussgraphen 10 umfassen, wobei der Pfad eine Sequenz von Anweisungsblöcken des Kontrollflussgraphen 10 umfassen kann.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
Häufig ist der Kontrollflussgraph 10 der (kompilierten, closed-source) Software allerdings nicht im Vorfeld bekannt. Dennoch kann er mit dem in dieser Offenbarung vorgeschlagenen Verfahren 100 während des Fuzzing zum Beispiel durch sukzessiv protokollierte gesetzte Haltepunkte mit vertretbarem Aufwand konstruiert werden.However, the
Es kann durchaus vorkommen, dass ein gesetzter Haltepunkt beim Ausführen der Fuzzing-Iteration nicht erreicht wird. Es kann sogar vorkommen, dass ein gesetzter Haltepunkt beim Ausführen einer Vielzahl von Fuzzing-Iterationen nicht erreicht wird. Anhand eines vorbestimmten Kriteriums (z.B. wenn nach einer vorbestimmten Anzahl von Fuzzing-Iterationen der Haltepunkt nicht erreicht wird und/oder bei einer Zeitüberschreitung), kann der Haltepunkt als übersprungen markiert werden. Dieser oder ein neuer Haltepunkt kann dann z.B. in oder vor einem Anweisungsblock gesetzt werden, der zu dem nicht erreichten Anweisungsblock im Kontrollflussgraphen 10 benachbart ist.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
Die Auswahl der Anweisungsblöcke bzw. der Haltepunkte basiert im Verfahren 100 auf Konnektivitäten, optional Konnektivitätsgewichten von Anweisungsblöcken im Kontrollflussgraphen 10. Es können allerdings verschiedene weitere Strategien, die auf dem Hardware-Target verfügbaren Haltepunkte zu setzen, in dem Verfahren 100 zusätzlich zur Anwendung kommen. Weiterhin können verschiedene Strategien in dem Verfahren 100 kombiniert und/oder abgewechselt werden. Alternativ oder zusätzlich kann die Strategie eine probabilistische Suche umfassen. Alternativ oder zusätzlich kann die Strategie eine entropische Suche umfassen. Alternativ oder zusätzlich kann die Strategie eine angeleitete Suche umfassen. Alternativ oder zusätzlich kann die Strategie weitere Suchstrategien umfassen. Bei der entropischen Suche kann z.B. ein Anweisungsblock (und/oder eine gerichtete Kante) im Kontrollflussgraphen 10, der beim Fuzzing erreicht wird (bzw. die beim Fuzzing durchlaufen wird), mit einem jeweiligen Wert für Informationsgewinn (auch: Entropie) versehen werden. Die Strategie bei der entropischen Suche kann dann umfassen, durch den Fuzzer solche Fuzzing-Eingangsdaten zu generieren, die einen Gesamtinformationsgewinn maximieren. Somit können eher Anweisungsblöcke (und/oder gerichtete Kanten) mit hohem Informationsgewinn bevorzugt werden. Dadurch werden weniger bereits erreichte Anweisungsblöcke (und/oder bereits durchlaufene gerichtete Kanten) entdeckt. Somit können neue Anweisungsblöcke (und/oder gerichtete Kanten) effizienter entdeckt werden. Bei der angeleiteten Suche kann weiterhin das Setzen des jeweiligen mindestens einen Haltepunkts auf einer Benutzereingabe basieren. Wenn zum Beispiel ein Nutzer, ein Programmierer und/oder ein Auditor der Software eine kritische Stelle in der Software oder Kontrollflussgraphen 10 der Software kennen, kann ein solches Wissen über eine Benutzerschnittstelle genutzt werden, die Haltepunkte und/oder Fuzzing-Eingangsdaten derart zu wählen, dass die kritische Stelle bei mindestens einer Fuzzing-Iteration erreicht und somit eingehend getestet wird.The selection of the instruction blocks or the breakpoints is based in the
Offenbart wird ein computer-implementiertes Verfahren 100 zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target, wobei das Hardware-Target mindestens ein Haltepunktregister aufweist und dafür ausgelegt ist, eine Ausführung der Software vor Ausführung einer Anweisung der Software anzuhalten, wenn die Anweisung bei der Ausführung der Software erreicht wird und eine Speicheradresse der Anweisung in dem mindestens einen Haltepunkteregister gesetzt ist. Das mindestens eine Haltepunktregister kann ein Hardware-Haltepunktregister sein. Ein Hardware-Haltepunkt ist ein Haltepunkt, der via ein Hardware-Haltepunktregister gesetzt wird.Disclosed is a computer-implemented
Das Verfahren 100, schematisch dargestellt in Fig. la, umfasst Auswählen 119 eines ersten Anweisungsblocks der Software.The
Das Verfahren 100 umfasst Setzen 120 eines ersten Haltepunkts vor einer Anweisung des ersten Anweisungsblocks in dem mindestens einen Haltepunktregister. Setzen 120 des ersten Haltepunkts vor der Anweisung der Software kann Setzen einer Speicheradresse der Anweisung in das mindestens eine Haltepunktregister umfassen.The
Das Verfahren 100 kann erstes Ausführen 130 einer Fuzzing-Iteration der Software umfassen. Alternativ kann das Verfahren 100 erstes Fortsetzen 131 einer (bereits teilweise ausgeführten, aber angehaltenen) Fuzzing-Iteration der Software umfassen.The
Das Verfahren 100 umfasst erstes Prüfen 140, ob der erste Haltepunkt beim ersten Ausführen 130 oder ersten Fortsetzen 131 der Fuzzing-Iteration erreicht wird. Der erste Haltepunkt wird dann erreicht, wenn ohne den ersten Haltepunkt die erste Anweisung bei Ausführung der Software auf Basis der Fuzzing-Eingangsdaten der Fuzzing-Iteration ausgeführt worden wäre.The
Das Verfahren 100 umfasst Speichern 150 einer ersten Protokollinformation, wobei die erste Protokollinformation umfasst, dass der erste Anweisungsblock (oder eine korrespondierende Anweisung vor oder in dem ersten Anweisungsblock) in der Fuzzing-Iteration erreicht worden ist, wenn das erste Prüfen 140 positiv ausfällt.The
Das Verfahren 100 kann, wie z.B. in Fig. la als optionaler Schritt dargestellt, Löschen 151 des ersten Haltepunkts, wenn das erste Prüfen 140 positiv ausfällt, umfassen.The
Das Softwareabdeckungsfeedback beim Fuzzing der Software umfasst die erste Protokollinformation. Die erste Protokollinformation kann zum Beispiel weiterhin die Fuzzing-Eingangsdaten der Fuzzing-Iteration umfassen. Speichern der Fuzzing-Eingangsdaten kann zum (sukzessivem) Erstellen einer Abbildung von beim Fuzzing erreichten Ausbildungsblöcken zu Fuzzing-Eingangsdaten (oder umgekehrt) verwendet werden.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).
Das Auswählen 119 des ersten Anweisungsblocks der Software kann auf Konnektivitäten (z.B. PR(b)) von Anweisungsblöcken 11 in einem Kontrollflussgraphen 10 der Software basieren. Hier ist z.B. b ein Anweisungsblock aus einer Menge der Anweisungsblöcke B des Kontrollflussgraphen oder einem Teil davon.Selecting 119 the first instruction block of the software may be based on connectivity (e.g. PR(b)) of instruction blocks 11 in a
Alternativ oder zusätzlich kann das Auswählen 119 des ersten Anweisungsblocks der Software kann auf Konnektivitätsgewichten von Anweisungsblöcken 11 in einem Kontrollflussgraphen 10 der Software basieren.Alternatively or additionally, selecting 119 the first instruction block of the software may be based on connectivity weights of instruction blocks 11 in a
Ein Kontrollflussgraph 10, beispielhaft und schematisch dargestellt in
Zum Beispiel können Anweisungsblöcke mit den höchsten Konnektivitäten, optional höchsten Konnektivitätsgewichten mit oder ohne Zurücklegen gezogen und somit ausgewählt 119 werden.For example, instruction blocks with the highest connectivity, optionally highest connectivity weights, can be drawn with or without replacement and thus selected 119.
Eine Konnektivität (z.B. PR(b)) eines (beliebigen) Anweisungsblocks 11 (z.B. eines Anweisungsblock b aus einer Menge der Anweisungsblöcke B des Kontrollflussgraphen oder einem Teil davon) kann ein zumindest approximatives Maß dafür sein, wie viele und/oder wie wichtige weitere Anweisungsblöcke 11 des Kontrollflussgraphen 10 oder eines Teils davon über je eine gerichtete Kante 12 im Kontrollflussgraphen 10 auf den Anweisungsblock 11 zeigen.A connectivity (e.g. PR(b)) of an (arbitrary) instruction block 11 (e.g. an instruction block b from a set of instruction blocks B of the control flow graph or a part thereof) can be an at least approximate measure of how many and/or how important other instruction blocks are 11 of the
Eine Konnektivität kann eine reelle Zahl z.B. in dem Intervall [0, Unendlich) (linker Endpunkt inbegriffen) sein. Eine Konnektivität kann eine natürliche Zahl (mit Null) sein. Insbesondere kann eine Konnektivität positiv oder Null sein.A connectivity can be a real number, for example in the interval [0, infinity) (left end point incl grasped). A connectivity can be a natural number (with zero). In particular, connectivity can be positive or zero.
In
Ein Konnektivitätsgewicht eines (beliebigen) Anweisungsblocks 11 (z.B. Anweisungsblock b) kann auf der Konnektivität des (beliebigen) Anweisungsblocks 11 (z.B. Anweisungsblock b) basieren. Zum Beispiel kann das Konnektivitätsgewicht groß sein, wenn die Konnektivität groß ist, und das Konnektivitätsgewicht klein sein, wenn die Konnektivität klein ist. Hierzu sind beliebige (stetige) Zusammenhänge denkbar. Weiterhin kann zum Beispiel das Konnektivitätsgewicht proportional zur Konnektivität sein. Weiterhin kann zum Beispiel das Konnektivitätsgewicht (z.B. PR(b)) die Konnektivität (z.B. PR(b)) sein.A connectivity weight of an (arbitrary) instruction block 11 (e.g. instruction block b) can be based on the connectivity of the (arbitrary) instruction block 11 (e.g. instruction block b). For example, the connectivity weight can be large when connectivity is large and the connectivity weight can be small when connectivity is small. Any (continuous) connections are conceivable for this purpose. Furthermore, for example, the connectivity weight can be proportional to the connectivity. Furthermore, for example, the connectivity weight (e.g. PR(b)) can be the connectivity (e.g. PR(b)).
Ein Konnektivitätsgewicht kann eine reelle Zahl in dem Intervall [0, Unendlich) (linker Endpunkt inbegriffen) sein. Ein Konnektivitätsgewicht kann eine natürliche Zahl (mit Null) sein. Ein Konnektivitätsgewicht kann positiv oder Null sein.A connectivity weight can be a real number in the interval [0, infinity) (left endpoint included). A connectivity weight can be a natural number (including zero). A connectivity weight can be positive or zero.
Das Verfahren 100 kann, wie z.B. in Fig. la als optionaler Schritt dargestellt, Berechnen 118a mindestens einer Konnektivität von Anweisungsblöcken 11 umfassen. Alternativ oder zusätzlich kann das Verfahren 100 Berechnen 118a mindestens eines Konnektivitätsgewichts von Anweisungsblöcken 11 umfassen.The
Zum Beispiel kann die mindestens eine Konnektivität und/oder das mindestens eine Konnektivitätsgewicht via einem - im Stand der Technik bekannten - PageRank Algorithmus mit der Maßgabe, dass der Kontrollflussgraph 10 oder ein Teil davon an die Stelle des Internets, die Anweisungsblöcke an die Stelle der Webseiten des Internets, und die gerichteten Kanten 12 an die Stelle der Hyperlinks treten, berechnet 118a werden. Ein/der PageRank Algorithmus vergleicht nicht nur eingehende Links, sondern gewichtet diese auch nach der Bedeutung der Herkunft. Eine mögliche Implementierung des PageRank Algorithmus findet sich zum Beispiel in https://networkx.org/documentation/stable/_modules/networkx/algorithms/link_analysis/ pagerank_alg.html#pagerank. Ein/der PageRank Algorithmus kann weitere Eingangsparameter aufweisen (und durch solche spezifiziert werden). Zum Beispiel kann der PageRank Algorithmus auf networkX die voreingestellten (Default-)Eingangsparameter - z.B. einen Dämpfungsfaktor alpha = 0.85, eine maximale Anzahl von Iterationen = 100 und eine Toleranz = 1e-6 - aufweisen. Zum Beispiel kann der PageRank Algorithmus auf networkX mit den voreingestellten (Default-) Eingangsparametern für das Berechnen 118a verwendet werden.For example, the at least one connectivity and/or the at least one connectivity weight can be provided via a PageRank algorithm - known in the art - with the proviso that the
Das Verfahren 100 kann, wie z.B. in Fig. la als optionaler Schritt dargestellt, Berechnen 118b eines ersten Wahrscheinlichkeitsmaßes umfassen. Das erste Wahrscheinlichkeitsmaß kann zum Beispiel mindestens zwei Anweisungsblöcken des Kontrollflussgraphen 10 oder eines Teils davon jeweils ein normiertes Konnektivitätsgewicht zuordnen, wobei die Konnektivitätsgewichte derart normiert werden können, dass die Summe aller Konnektivitätsgewichte für die mindestens zwei Anweisungsblöcke eins ergeben kann.The
Das Auswählen 119 des ersten Anweisungsblocks der Software - insbesondere, das Auswählen 119 des ersten Anweisungsblocks der Software basierend auf Konnektivitäten, insbesondere Konnektivitätsgewichten, der Anweisungsblöcke in dem Kontrollflussgraphen 10 - kann zufälliges oder zumindest pseudo-zufälliges erstes Ziehen eines Anweisungsblocks als ersten Anweisungsblock aus den nach dem ersten Wahrscheinlichkeitsmaß verteilten Anweisungsblöcken umfassen.Selecting 119 the first instruction block of the software - in particular, selecting 119 the first instruction block of the software based on connectivity, in particular connectivity weights, of the instruction blocks in the control flow graph 10 - may involve random or at least pseudo-random first pulling of an instruction block as the first instruction block from the following instruction blocks distributed according to the first probability measure.
Hier oder im Allgemeinen kann ein solches Ziehen auch als Würfeln (ä la Monte Carlo) bezeichnet werden. Das (erste, später zweite) Ziehen kann zum Beispiel Ziehen von mindestens einer Zahl auf einem gleichverteilten (quasi-)reellen Intervall [0, 1] und Auswerten einer invertierten Verteilungsfunktion zum (ersten, später zweiten) Wahrscheinlichkeitsmaß an der mindestens einen gezogenen Zahl umfassen. Andere Implementierungen des Ziehens sind in Fachkreisen bekannt.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.
Das erste Ziehen des Anweisungsblocks kann derart erfolgen, dass eine erste Vielzahl von Anweisungsblöcken (d.h. eine zum Zeitpunkt des ersten Ziehens vorbestimmte erste Vielzahl von Anweisungsblöcken) nicht gezogen werden. Alternativ oder zusätzlich kann das erste Ziehen des Anweisungsblocks derart erfolgen, dass eine Vielzahl der (bisher) beim Fuzzing erreichten Anweisungsblöcke 13 oder des Teils davon nicht gezogen werden.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 a large number of the instruction blocks 13 (previously) achieved during fuzzing or parts thereof are not pulled.
Das Ausschließen, dass bestimmte Anweisungsblöcke gezogen werden können, kann zum Beispiel dadurch erreicht werden, dass so lange ein Anweisungsblock gezogen wird, bis einer gezogen worden ist, der nicht ausgeschlossen werden soll. Alternativ kann zum Beispiel das (erste, später zweite) Wahrscheinlichkeitsmaß vor dem Ziehen derart modifiziert werden, dass nur nicht ausgeschlossene Anweisungsblöcke gezogen werden können. Eine solche Möglichkeit besteht zum Beispiel darin, (Konnektivitäts-)Gewichte der ausgeschlossenen Anweisungsblöcke mit Null zu skalieren und das so modifizierte Wahrscheinlichkeitsmaß zu renormieren.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 (connectivity) weights of the excluded instruction blocks with zero and renormalize the modified probability measure.
Durch das Ausschließen von bestimmten Anweisungsblöcke kann die Effizienz des Fuzzings weiter erhöht werden.By excluding certain instruction blocks, the efficiency of fuzzing can be further increased.
Das Verfahren 100 kann, wie z.B. schematisch als optionaler Schritt in
Das Verfahren 100 kann, wie z.B. in
Das Verfahren 100 kann, wie z.B. in
Das Verfahren 100 kann, wie z.B. in
Das Verfahren 100 kann, wie z.B. in
Das Softwareabdeckungsfeedback beim Fuzzing der Software kann die zweite Protokollinformation umfassen. Die zweite Protokollinformation kann zum Beispiel die bisherigen oder weiteren Fuzzing-Eingangsdaten der Fuzzing-Iteration umfassen.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.
Das Auswählen 159 des zweiten Anweisungsblocks der Software kann auf Konnektivitäten von Anweisungsblöcken 11 in dem Kontrollflussgraphen 10 der Software basieren. Alternativ oder zusätzlich kann das Auswählen 159 des zweiten Anweisungsblocks der Software auf Konnektivitätsgewichten von Anweisungsblöcken 11 in dem Kontrollflussgraphen 10 der Software basieren.Selecting 159 the second instruction block of the software may be based on connectivity of instruction blocks 11 in the
Das Verfahren 100 kann, wie z.B. in
Die Konnektivitäten können, aber müssen nicht neu berechnet werden. Weiterhin können, aber müssen nicht die Konnektivitätsgewichte neu berechnet werden. Eine Neuberechnung kann zum Beispiel sinnvoll sein, wenn Konnektivitäten und/oder Konnektivitätsgewichte für einen anderen Teil des Kontrollflussgraphen 10 neu berechnet werden, d.h. wenn der Teil sich in der Zwischenzeit geändert hat. Alternativ oder zusätzlich kann eine Neuberechnung sinnvoll sein, wenn der Kontrollflussgraph 10 der Software zunächst unbekannt ist und via Erlangung von Softwareabdeckungsfeedback sukzessive ermittelt wird.The connectivity can, but does not have to, be recalculated. Furthermore, the connectivity weights can, but do not have to, be recalculated. A recalculation may be useful, for example, if connectivity and/or connectivity weights are recalculated for another part of the
Das Verfahren 100 kann, wie z.B. in
Das Auswählen 159 des zweiten Anweisungsblocks der Software - insbesondere, das Auswählen 159 des zweiten Anweisungsblocks der Software basierend auf Konnektivitäten, insbesondere Konnektivitätsgewichten, von Anweisungsblöcken in dem Kontrollflussgraphen 10 - kann zufälliges oder zumindest pseudo-zufälliges zweites Ziehen eines Anweisungsblocks als zweiten Anweisungsblock aus den nach dem zweiten Wahrscheinlichkeitsmaß verteilten Anweisungsblöcken umfassen.Selecting 159 the second instruction block of the software - in particular, selecting 159 the second instruction block of the software based on connectivity, in particular connectivity weights, of instruction blocks in the control flow graph 10 - may involve random or at least pseudo-random second drawing Instruction blocks as a second instruction block from the instruction blocks distributed according to the second probability measure.
Das zweite Wahrscheinlichkeitsmaß kann, muss aber nicht das erste Wahrscheinlichkeitsmaß sein. Bei Gleichheit des ersten und zweiten Wahrscheinlichkeitsmaßes kann eine Neuberechnung entbehrlich sein. Eine Neuberechnung kann zum Beispiel sinnvoll sein, wenn sich der Teil des Kontrollflussgraphen 10 in der Zwischenzeit geändert hat.The second probability measure can, but does not have to be, the first probability measure. If the first and second probability measures are equal, a recalculation may be unnecessary. A recalculation can make sense, for example, if the part of the
Das zweite Ziehen des Anweisungsblocks kann derart erfolgen, dass eine zweite Vielzahl von Anweisungsblöcken (d.h. eine zum Zeitpunkt des zweiten Ziehens vorbestimmte zweite Vielzahl von Anweisungsblöcken) nicht gezogen wird. Die zweite Vielzahl von Anweisungsblöcken kann, muss aber nicht die erste Vielzahl von Anweisungsblöcken sein. Alternativ oder zusätzlich kann das zweite Ziehen des Anweisungsblocks derart erfolgen, dass der erste Anweisungsblock nicht gezogen wird.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 first instruction block is not pulled.
Wie bereits dargelegt, kann durch das Ausschließen von bestimmten Anweisungsblöcke die Effizienz des Fuzzings weiter erhöht werden.As already explained, the efficiency of fuzzing can be further increased by excluding certain instruction blocks.
Das Verfahren 100 kann, wie z.B. in
Das Setzen 120, 160 von Haltepunkten kann via eine Debugging-Verbindung zum Hardware-Target erfolgen. Weiterhin kann das Ausführen 130, 170 und/oder Fortsetzen 131, 171 der Fuzzing-Iteration via die Debugging-Verbindung zum Hardware-Target erfolgen. Das Verfahren 100 kann, wie z.B. in Fig. la als optionaler Schritt dargestellt, Initialisieren 110 der Debugging-Verbindung zum Hardware-Target umfassen.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
Der erste Anweisungsblock der Software kann eine vorbestimmte Startfunktion (englisch: function to instrument) der Software umfassen. Eine solche Wahl kann dafür geeignet sein, das Fuzzing oder zumindest eine Fuzzing-Iteration des Fuzzing zu starten. Alternativ kann der erste Anweisungsblock ein beliebiger Anweisungsblock der Software (zum Beispiel bei Wiederholen 199) sein. Alternativ oder zusätzlich kann das Verfahren 100 mit dem Setzen eines (nullten) Haltepunkts vor einer beliebigen Anweisung der Software, insbesondere vor einer Anweisung eines beliebigen (nullten) Anweisungsblocks in dem Kontrollflussgraphen 10 gestartet werden.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
Das Verfahren 100 kann, wie z.B. in Fig. la als optionaler Schritt dargestellt, Erzeugen 105 des Kontrollflussgraphen 10 der Software basierend auf dem Programmiercode der Software umfassen. Alternativ oder zusätzlich kann das Verfahren 100 Erzeugen 105 des Kontrollflussgraphen 10 der Software via Reverse engineering der Software umfassen. Alternativ oder zusätzlich kann das Verfahren 100 Erzeugen 105 des Kontrollflussgraphen 10 der Software sukzessive via Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target umfassen.The
Das Verfahren 100 kann, wie z.B. in Fig. la als optionaler Schritt dargestellt, Speichern 152 einer ersten Protokollinformation umfassen, wobei die erste Protokollinformation umfasst, dass der erste Anweisungsblock in der Fuzzing-Iteration nicht erreicht worden ist, wenn das erste Prüfen 140 negativ verläuft. Das Verfahren 100 kann Löschen 151 des ersten Haltepunkts, wenn das erste Prüfen 140 negativ verläuft, umfassen. Das erste Prüfen 140 kann z.B. negativ verlaufen, wenn ein vorbestimmtes Kriterium erfüllt ist. Das vorbestimmte Kriterium kann zum Beispiel erfüllt sein, wenn der erste Haltepunkt nach einer vorbestimmten Zeitdauer oder bis zum Ende der Fuzzing-Iteration nicht erreicht wird.1a, the
Das Verfahren 100 kann, wie z.B. in
Das Softwareabdeckungsfeedback beim Fuzzing der Software kann die erste und/oder zweite Protokollinformation umfassen. Die erste und/oder zweite Protokollinformation kann weiterhin zum Beispiel die (weiteren) Fuzzing-Eingangsdaten umfassen.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.
Das Verfahren 100 kann, wie z.B. in
Offenbart wird weiterhin ein Computer-System, dafür ausgelegt ist, das computer-implementierte Verfahren 100 zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target auszuführen. Das Computer-System kann einen Prozessor und/oder einen Arbeitsspeicher umfassen. Das Computer-System kann dafür ausgelegt sein, über die Debugging-Verbindung mit dem Hardware-Target zu kommunizieren. Das Computer-System kann den Fuzzer umfassen, der dafür ausgelegt ist Fuzzing-Eingangsdaten für mindestens eine Fuzzing-Iteration der Software auf dem Hardware-Target zu generieren und bereitzustellen.Also disclosed is a computer system designed to execute the computer-implemented
Offenbart wird weiterhin ein Computer-Programm, das dafür ausgelegt ist, das computer-implementierte Verfahren 100 zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target auszuführen. Das Computer-Programm kann z.B. in interpretierbarer oder in kompilierter Form vorliegen. Es kann (auch in Teilen) zur Ausführung z.B. als Bit- oder Byte-Folge in den RAM eines Computers geladen werden.Also disclosed is a computer program designed to execute the computer-implemented
Offenbart wird weiterhin ein computer-lesbares Medium oder Signal, das das Computer-Programm speichert und/oder enthält. Das Medium kann z.B. eines von RAM, ROM, EPROM, HDD, SDD, ... umfassen, auf/in dem das Signal gespeichert wird.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)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102022203356.6A DE102022203356A1 (en) | 2022-04-05 | 2022-04-05 | FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON CONNECTIVITIES OF STATEMENT BLOCKS IN CONTROL FLOW GRAPH |
CN202310357493.3A CN116893957A (en) | 2022-04-05 | 2023-04-04 | Fuzzy test using software overlay feedback through dynamic detection of connectivity based on instruction blocks in a control flow graph |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102022203356.6A DE102022203356A1 (en) | 2022-04-05 | 2022-04-05 | FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON CONNECTIVITIES OF STATEMENT BLOCKS IN CONTROL FLOW GRAPH |
Publications (1)
Publication Number | Publication Date |
---|---|
DE102022203356A1 true DE102022203356A1 (en) | 2023-10-05 |
Family
ID=88018984
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE102022203356.6A Pending DE102022203356A1 (en) | 2022-04-05 | 2022-04-05 | FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON CONNECTIVITIES OF STATEMENT BLOCKS IN CONTROL FLOW GRAPH |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN116893957A (en) |
DE (1) | DE102022203356A1 (en) |
-
2022
- 2022-04-05 DE DE102022203356.6A patent/DE102022203356A1/en active Pending
-
2023
- 2023-04-04 CN CN202310357493.3A patent/CN116893957A/en active Pending
Also Published As
Publication number | Publication date |
---|---|
CN116893957A (en) | 2023-10-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69909945T2 (en) | Method and arrangement for correlating profile data dynamically generated by an optimized executable program with source code instructions | |
US7500149B2 (en) | Generating finite state machines for software systems with asynchronous callbacks | |
DE102006019292A1 (en) | Modeling programmable devices | |
DE102007029133A1 (en) | Method for computer-aided determination of the dependencies of a plurality of modules of a technical system, in particular of a software system | |
DE102014102551A1 (en) | Machine and method for evaluating failed software programs | |
DE202016008043U1 (en) | Apparatus for creating, collecting, storing and loading debug information for failed test scripts | |
Hamou-Lhadj et al. | Measuring various properties of execution traces to help build better trace analysis tools | |
EP0721620A1 (en) | Tracer system for analysing errors of running real time systems | |
DE102022203356A1 (en) | FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON CONNECTIVITIES OF STATEMENT BLOCKS IN CONTROL FLOW GRAPH | |
EP3770766A1 (en) | Method for testing a system | |
US10579761B1 (en) | Method and system for reconstructing a graph presentation of a previously executed verification test | |
DE102022203357A1 (en) | FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION BASED ON DISTANCES OF INSTRUCTION BLOCKS IN CONTROL FLOW GRAPH | |
Sousa et al. | Evaluating co-occurrence of GOF design patterns with god class and long method bad smells | |
DE102009009172B4 (en) | Mapping addresses of a program code and addresses of data in a memory | |
DE102021212596A1 (en) | FUZZING WITH SOFTWARE COVERAGE FEEDBACK THROUGH DYNAMIC INSTRUMENTATION | |
Van Bladel et al. | Test refactoring: a research agenda | |
DE102021212597A1 (en) | MEMORY USAGE-BASED FUZZING | |
DE10126018A1 (en) | Method for providing error information about inconsistencies in a system of differential equations | |
Lin | Regression testing in research and practice | |
Kamma et al. | High productivity programmers use effective task processes in unit-testing | |
DE10058371A1 (en) | Management of non-fixed register values during random program generation e.g. for design verification of CPUs, requires marking a value state as non-fixed when the content is unknown and when any desired content can be generated | |
AL-Zaghameem | An aspect oriented programming framework to support transparent runtime monitoring of applications | |
Sawadpong | Toward a defect prediction model of exception handling method call structures | |
CH713111A2 (en) | Static detection of concurrency errors in computer programs. | |
DE102004021975A1 (en) | Method for determining deadlocks in concurrent processes |