DE102022201663A1

DE102022201663A1 - Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung

Info

Publication number: DE102022201663A1
Application number: DE102022201663.7A
Authority: DE
Inventors: Jonn McShane; Timothy Scott Arntson; Zachariah Pelletier
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-02-19
Filing date: 2022-02-17
Publication date: 2022-08-25
Also published as: US20220269591A1; US11762761B2; KR20220118937A

Abstract

System zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung. Ein Beispiel beinhaltet einen elektronischen Prozessor. Der elektronische Prozessor ist ausgelegt zum Vorverarbeiten von Trainingsdaten, Verwenden der Trainingsdaten zum dahingehenden Trainieren eines Diskriminator-DNN, einen Prüffall auszuwerten, um zu bestimmen, ob der Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, und Verwenden des Diskriminator-DNN zum dahingehenden Trainieren eines Generator-DNN, einen Prüffall zu erzeugen, der wahrscheinlich eine Softwareschwachstelle offenlegt. Der elektronische Prozessor verwendet das Diskriminator-DNN zum Trainieren des Generator-DNN durch Bestimmen, ob ein durch das Generator-DNN erzeugter Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, und Senden einer Bestimmung, ob der durch das Generator-DNN erzeugte Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, an das Generator-DNN. Der elektronische Prozessor ist ferner ausgelegt zum Erzeugen, wenn das Generator-DNN trainiert ist, eines oder mehrerer Prüffälle.

Description

Verwandte Anmeldungen
Die vorliegende Anmeldung beansprucht die Priorität der am 19. Februar 2021 eingereichten vorläufigen US-Patentanmeldung Nr. 63/151,384 , deren gesamter Inhalt hiermit durch Bezugnahme aufgenommen wird.
TECHNISCHES GEBIET
Ausführungsformen betreffen Systeme und Verfahren zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung, beispielsweise zur Controller-Area-Network(CAN)-Bus-Fuzz-Prüfung.
KURZDARSTELLUNG
Viele moderne Fahrzeuge sind mit komplexen Berechnungssystemen (beispielsweise elektronischen Steuereinheiten (ECUs)) zum Durchführen verschiedener Fahrzeugfunktionen ausgestattet. ECUs können über Nachrichten (beispielsweise eine Reihe von Bits), die über ein Kommunikationsnetzwerk (beispielsweise einen CAN-Bus) gesendet werden, miteinander kommunizieren. ECUs können gegenüber Problemen wie Programmabstürzen, Speicherkorruption und Problemen extremer Ressourcennutzung anfällig sein. Diese Probleme oder Softwareschwachstellen können auftreten, wenn eine ECU eine korrupte Nachricht empfängt. Eine korrupte Nachricht kann aufgrund eines Softwarefehlers, eines vorsätzlichen Angriffs durch einen Hacker oder dergleichen gesendet werden. Ausrüstungshersteller, Fahrzeugbesitzer, Wartungs- und Reparaturtechniker und andere verwenden daher Techniken wie Fuzzing, um mögliche Schwachstellen zu identifizieren, bevor sie ausgenutzt werden. Fuzzing gestattet eine Stärkung der auf ECUs ausgeführten Software, um mit verschiedenen Arten von Prüffällen (beispielsweise einer korrupten Nachricht) umzugehen. Beispielsweise kann ein Softwaretechniker bei Identifikation einer Schwachstelle den Softwarecode ändern, um die identifizierte Schwachstelle zu beheben.
Die hierin beschriebenen Systeme und Verfahren gestatten die Erzeugung synthetischer Prüffälle zur Fuzz-Prüfung. Zur Unterstützung von Fahrzeugherstellern und Technikern bei der Identifikation von ECU-Schwachstellen, ein System, das synthetische Prüffälle für Fuzzing erzeugt, die wahrscheinlich Schwachstellen identifizieren, jedoch einigermaßen zufällig sind. Synthetische Prüffälle sind solche, die durch ein Maschinenlernmodell anstatt einen Techniker erzeugt werden, wodurch der Zeitaufwand zum Fuzzing einer ECU verringert wird. Es ist wichtig, dass Prüffälle ein Zufälligkeitselement aufweisen, damit neue Arten von Prüffällen oder korrupten Nachrichten identifiziert werden können. Viele Maschinenlernmodelle werden nur darauf trainiert, neue Prüffälle basierend auf Prüffällen, von denen bereits bekannt ist, dass sie einen Fehler produzieren, zu erzeugen, und daher ist es unwahrscheinlich, dass diese Maschinenlernmodelle ohne ein Zufälligkeitselement neue Arten von Prüffällen erzeugen, um die unbekannten Schwachstellen aufzufinden, die Hacker in ECUs ausnutzen wollen (dieses Problem wird oftmals als Overfitting bezeichnet). Um synthetische Prüffälle für Fuzzing zu erzeugen, die wahrscheinlich Schwachstellen identifizieren, jedoch einigermaßen zufällig sind, nutzen hierin beschriebenen Systeme und Verfahren unter anderem ein General Adversarial Network (GAN).
Ein Beispiel stellt ein System zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung bereit. Das System beinhaltet einen elektronischen Prozessor. Der elektronische Prozessor ist ausgelegt zum Vorverarbeiten von Trainingsdaten und Verwenden der Trainingsdaten zum dahingehenden Trainieren eines Diskriminator-DNN, einen Prüffall auszuwerten, um zu bestimmen, ob der Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt. Der elektronische Prozessor ist auch ausgelegt zum Verwenden des Diskriminator-DNN zum dahingehenden Trainieren eines Generator-DNN, einen Prüffall zu erzeugen, der wahrscheinlich eine Softwareschwachstelle offenlegt. Der elektronische Prozessor verwendet das Diskriminator-DNN zum Trainieren des Generator-DNN durch Bestimmen, ob ein durch das Generator-DNN erzeugter Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, und Senden einer Bestimmung, ob der durch das Generator-DNN erzeugte Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, an das Generator-DNN. Der elektronische Prozessor ist ferner ausgelegt zum Erzeugen, wenn das Generator-DNN trainiert ist, eines oder mehrerer Prüffälle unter Verwendung des Generator-DNN.
Ein anderes Beispiel stellt ein Verfahren zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung bereit. Das Verfahren beinhaltet Vorverarbeiten von Trainingsdaten, Verwenden der Trainingsdaten zum dahingehenden Trainieren eines Diskriminator-DNN, einen Prüffall auszuwerten, um zu bestimmen, ob der Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, und Verwenden des Diskriminator-DNN zum dahingehenden Trainieren eines Generator-DNN, einen Prüffall zu erzeugen, der wahrscheinlich eine Softwareschwachstelle offenlegt. Das Diskriminator-DNN trainiert das Generator-DNN durch Bestimmen, ob ein durch das Generator-DNN erzeugter Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, und Senden einer Bestimmung, ob der durch das Generator-DNN erzeugte Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, an das Generator-DNN. Das Verfahren beinhaltet ferner Erzeugen, wenn das Generator-DNN trainiert ist, eines oder mehrerer Prüffälle unter Verwendung des Generator-DNN.
Andere Aspekte, Merkmale und Ausführungsformen werden unter Berücksichtigung der ausführlichen Beschreibung und der begleitenden Zeichnungen ersichtlich werden.
Figurenliste

1 veranschaulicht ein beispielhaftes System zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung gemäß einigen Ausführungsformen.
2 ist ein Blockdiagramm eines beispielhaftes Systems zur Fuzz-Prüfung gemäß einigen Ausführungsformen.
3 ist ein veranschaulichendes Beispiel eines Prüfwerkzeugs, das in dem System von 1 enthalten ist, gemäß einigen Ausführungsformen.
4 ist ein veranschaulichendes Beispiel eines Pseudocodes zum Trainieren, Kompilieren und Anpassen eines Diskriminator-DNN, das in dem System von 1 enthalten ist, gemäß einigen Ausführungsformen.
5 ist ein Flussdiagramm, das ein Verfahren zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung gemäß einigen Ausführungsformen veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
Vor einer detaillierten Erläuterung jeglicher Ausführungsformen versteht es sich, dass die Offenbarung in ihrer Anwendung nicht auf die Einzelheiten der Konstruktion und Anordnung von Komponenten beschränkt sein soll, die in der folgenden Beschreibung dargelegt oder in den folgenden Zeichnungen veranschaulicht sind. Ausführungsformen sind zu anderen Ausgestaltungen in der Lage und können auf verschiedene Weisen ausgeübt oder ausgeführt werden.
Eine Mehrzahl von hardware- und softwarebasierten Vorrichtungen sowie eine Mehrzahl unterschiedlicher struktureller Komponenten können zum Implementieren verschiedener Ausführungsformen verwendet werden. Zusätzlich dazu können Ausführungsformen Hardware, Software und elektronische Komponenten oder Module beinhalten, die zum Zweck der Erörterung so veranschaulicht und beschrieben sein können, als ob der Großteil der Komponenten einzig in Hardware implementiert wäre. Allerdings werden Durchschnittsfachleute auf der Grundlage der Lektüre dieser ausführlichen Beschreibung erkennen, dass die elektronikbasierten Aspekte der Erfindung in mindestens einer Ausführungsform in Software, die durch einen oder mehrere elektronische Prozessoren ausführbar ist, implementiert (zum Beispiel auf einem nichtflüchtigen computerlesbaren Medium gespeichert) werden können. Beispielsweise können „Steuereinheiten“ und „Steuerungen“, die in der Spezifikation beschrieben sind, einen oder mehrere elektronische Prozessoren, ein oder mehrere Speichermodule einschließlich eines nichtflüchtigen computerlesbaren Mediums, eine oder mehrere Eingabe/Ausgabe-Schnittstellen, eine oder mehrere anwendungsspezifische integrierte Schaltungen (ASICs) und verschiedene Verbindungen (zum Beispiel einen Systembus), die die verschiedenen Komponenten verbinden, beinhalten.
1 veranschaulicht ein beispielhaftes System 100 zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung. Das System 100 beinhaltet verschiedene Hardware- und Softwarekomponenten, ausgelegt zum Erhalten und Bereitstellen von Informationen, und verarbeitet die Informationen beispielsweise durch eine oder mehrere Softwareanweisungen oder ein oder mehrere Programme. In dem veranschaulichten Beispiel beinhaltet das System 100 ein Prüfwerkzeug 110. In einigen Ausführungsformen ist das Prüfwerkzeug 110 elektrisch mit einem Netzwerk (zum Beispiel einem Controller-Area-Network(CAN)-Bus) gekoppelt und zum Erhalten und Bereitstellen von Informationen an das und von dem Netzwerk ausgelegt.
In einigen Ausführungsformen beinhaltet das Prüfwerkzeug Fuzzer-Software 120, die in Software implementiert sein kann, die in einem mit dem Prüfwerkzeug 110 assoziierten Speicher gespeichert und durch einen mit dem Prüfwerkzeug 110 assoziierten elektronischen Prozessor ausführbar ist. In einigen Ausführungsformen ist die Fuzzer-Software 120 zum Senden von Prüffällen über ein Kommunikationsnetzwerk an eine oder mehrere ECUs (zum Beispiel die Zielvorrichtung 140) ausgelegt, um Schwachstellen in mit den ECUs assoziierter Software zu identifizieren.
In einigen Ausführungsformen beinhaltet die Zielvorrichtung 140 einen elektronischen Prozessor (zum Beispiel einen elektronischen Mikroprozessor, Mikrocontroller oder eine andere geeignete programmierbare Vorrichtung), einen Speicher und eine Eingabe/Ausgabe-Schnittstelle. In einigen Ausführungsformen erzeugt ein mit der Zielvorrichtung 140 assoziierter elektronischer Prozessor Daten als Reaktion auf ein Empfangen eines Prüffalls 130. In einigen Ausführungsformen beinhalten die durch die Zielvorrichtung 140 als Reaktion auf das Empfangen des Prüffalls 130 erzeugten Daten Informationen, die einen Fehler in der Zielvorrichtung 140 angegeben. Beispielsweise kann der durch die Zielvorrichtung 140 ausgeführte Softwarecode als Reaktion auf einen Prüffall eine Ausnahme auslösen, und die Zielvorrichtung 140 kann ein Ausgabeprotokoll erzeugen, das eine Angabe der ausgelösten Ausnahme und des Prüffalls, der das Auslösen der Ausnahme verursacht hat, beinhaltet. In einigen Ausführungsformen werden die durch die Zielvorrichtung 140 erzeugten Daten verschlüsselt und in einem/einer Structured-Query-Language(SQL)-Server oder -Datenbank, wie etwa der Verlaufsdaten-Datenbank 165, gespeichert. In einigen Ausführungsformen werden durch die Zielvorrichtung 140 erzeugte Daten an die Fuzzer-Software 120 gesendet, und die Fuzzer-Software 120 sendet die durch die Zielvorrichtung 140 erzeugten Daten an die Verlaufsdaten-Datenbank 165. In einigen Ausführungsformen werden durch die Zielvorrichtung 140 erzeugte Daten an das unten beschriebene Diskriminator-Dense-Neural-Network (DNN: Dichtes Neuronales Netz) gesendet.
Das System 100 beinhaltet auch ein GAN 145, das in durch einen elektronischen Prozessor ausführbarer Software implementiert sein kann. In einigen Ausführungsformen ist das GAN 145 in dem Prüfwerkzeug 110 implementiert, wie in 1 und 3 veranschaulicht und im Zusammenhang damit beschrieben. In anderen Ausführungsformen ist das GAN 145 in einer elektronischen Steuerung implementiert, die entfernt von dem Prüfwerkzeug 110 angeordnet ist aber mit diesem in Kommunikation steht (beispielsweise über ein drahtgebundenes oder drahtloses Kommunikationsnetzwerk). In einigen Ausführungsformen beinhaltet das GAN 145 ein Diskriminator-Dense-Neural-Network (DNN) 150 und ein Generator-Dense-Neural-Network (DNN) 160. Ein Dense Neural Network (DNN) wird in der Technik auch als Recurrent Neural Network (RNN: Rekurrentes Neuronales Netz) bezeichnet.
In einigen Ausführungsformen empfängt das Diskriminator-DNN 150 Trainingsdaten 170 aus der Verlaufsdaten-Datenbank 165, der Zielvorrichtung 140 oder beiden. In einigen Ausführungsformen wird das Diskriminator-DNN 150 unter Verwendung der Trainingsdaten 170 darauf trainiert, zu bestimmen, ob ein Prüffall eine Schwachstelle einer ECU prüfen wird. Beispielsweise kann das Diskriminator-DNN 150 einen Prüffall als „Pass-Fall“ („bestanden“) kennzeichnen, wenn es bestimmt, dass der Prüffall eine Schwachstelle einer ECU nicht prüfen wird, und als „Fail-Fall“ („nicht bestanden“) kennzeichnen, wenn es bestimmt, dass der Prüffall eine Schwachstelle einer ECU prüft. In einigen Ausführungsformen wird eine Bewertung, bei der es sich um einen Wert zwischen 0 und 1 handelt, durch das Diskriminator-DNN 150 erzeugt und zum Klassifizieren eines Prüffalls als „Pass-Fall“ oder als „Fail-Fall“ verwendet. Beispielsweise kann die Schwelle zum Kennzeichnen eines Prüffalls als ein „Fail-Fall“ 0,7 betragen, und das Diskriminator-DNN 150 kann einen numerischen Wert (oder eine Bewertung) von 0,986 für einen Prüffall erzeugen. Da der Wert 0,986 größer als 0,7 ist, kann das Diskriminator-DNN 150 den Prüffall als „Fail-Fall“ kennzeichnen.
In einigen Ausführungsformen wird das Diskriminator-DNN 150 unter Verwendung einer Bibliothek für Algorithmen künstlicher Intelligenz, wie etwa TensorFlow ®, implementiert. In einigen Ausführungsformen ist das Diskriminator-DNN 150 ein sequenzielles Modell zum Vornehmen von Vorhersagen, wobei jede Schicht des Diskriminator-DNN 150 einen Eingangstensor und einen Ausgangstensor aufweist. In einigen Ausführungsformen wird ein separates Korrelationsmodell für jedes Merkmal eines Prüffalls erstellt und vier separate dichte Schichten zu jedem Korrelationsmodell hinzugefügt. In einigen Ausführungsformen wird das Diskriminator-DNN 150 unter Verwendung eines stochastischen Gradientenabstiegsverfahrens (zum Beispiel des Adam-Optimierers aus der TensorFlow®-Bibliothek) mit einer Lernrate von 0,001 kompiliert. In einigen Ausführungsformen wird eine Verlustfunktion verwendet, um zu bestimmen, wie gut das Diskriminator-DNN 150 beim Modellieren der Trainingsdaten voranschreitet. In einigen Ausführungsformen wird das Diskriminator-DNN 150 unter Verwendung des mittleren absoluten Fehlers der Nutzdaten kompiliert, gemäß dem eine Bewertung durch das Diskriminator-DNN 150 erzeugt wird. In einigen Ausführungsformen wird das Diskriminator-DNN 150 unter Verwendung der TensorFlow®-Anpassungsfunktion durch Speisen des Diskriminator-DNN 150 mit einer Anzahl von Lerninteraktionen (Trainingsepochen), gekennzeichneten Trainingsdaten und einer Validationsteilung von 0,2 (20% der Trainingsdaten 170 werden zum Validieren des Diskriminator-DNN 150 verwendet) trainiert.
In einigen Ausführungsformen wird, nachdem das Diskriminator-DNN 150 kompiliert und an die Daten angepasst wurde, das Diskriminator-DNN 150 dazu verwendet, vorherzusagen, ob ein Prüffall in der Zielvorrichtung 140 wahrscheinlich einen Fehler verursachen oder eine Schwachstelle prüfen würde oder nicht, wie oben beschrieben. In einigen Ausführungsform wird die Vorhersage unter Verwendung der TensorFlow ®-„Predict“-Funktion durchgeführt, indem ein Beispielvektor genommen wird, der mit der Form der Eingangstrainingsdaten übereinstimmt und eine Gleitkomma-Ganzzahl ausgibt, die die Wahrscheinlichkeit (oder prozentuelle Wahrscheinlichkeit) repräsentiert, dass der Eingangswert mit der gegebenen Kennzeichnung übereinstimmt.
In einigen Ausführungsformen wird das Generator-DNN 160 durch das Diskriminator-DNN 150 darauf trainiert, Prüffälle zu erzeugen, die wahrscheinlich eine Softwareschwachstelle offenlegen. Sobald das Generator-DNN trainiert ist, erzeugt es einen oder mehrere Prüffälle und sendet den einen oder die mehreren Prüffälle an die Fuzzer-Software 120. In einigen Ausführungsformen stellt die Fuzzer-Software 120 der Zielvorrichtung 140 im Gegenzug einen von dem Generator-DNN 160 empfangenen Prüffall (zum Beispiel den Prüffall 130) bereit.
2 veranschaulicht ein beispielhaftes System 200 zur Netzwerkprüfung. In dem veranschaulichten Beispiel beinhaltet das System 200 eine elektronische Steuerung 210, die Zielvorrichtung 140, eine zweite ECU 220 und das Prüfwerkzeug 110, verbunden mit einem Kommunikationsnetzwerk 230. In dem veranschaulichten Beispiel ist das Kommunikationsnetzwerk 230 ein Controller Area Network (CAN) und es wird ein CAN-Protokoll genutzt. Hierin beschriebene Techniken können beispielsweise auf der Transportschicht eines anderen Netzwerks als ein CAN angewendet werden. Das Kommunikationsnetzwerk 230 kann beispielsweise unter Verwendung anderer Netzwerkmodalitäten implementiert werden, darunter zum Beispiel ein Weitbereichsnetzwerk, wie etwa das Internet, ein lokales Netzwerk, wie etwa ein WiFi-Netzwerk, Kurzreichweiten-Drahtlosnetzwerke, wie etwa ein Bluetooth™-Netzwerk, Nahfeldkommunikationsverbindungen und Kombinationen oder Ableitungen davon. Anstatt der Verwendung eines CAN-Protokolls können andere Netzwerkprotokolle, wie etwa ein Transmission Control Protocol (TCP), Ethernet, Internet Protocol Version 4 (IPv4) und dergleichen verwendet werden. Die in 2 veranschaulichte Ausführungsform stellt nur ein Beispiel für die Komponenten und Verbindungen des Systems 200 bereit. In anderen Ausführungsformen können diese Komponenten und Verbindungen auf andere Weisen als jene, die hierin veranschaulicht und beschrieben sind, erstellt werden. Beispielsweise kann das System 200 eine andere Anzahl an Vorrichtungen als die in 2 veranschaulichte Anzahl an Vorrichtungen beinhalten.
In einigen Ausführungsformen kann das System 200, anstatt Vorrichtungen zu beinhalten, Softwaremodule (zum Beispiel Softwareverfahren, Softwareklassen oder dergleichen) beinhalten, die durch die Fuzzer-Software 120 geprüft werden können. Zum Beispiel kann die Fuzzer-Software 120 unter Verwendung eines Software-in-the-Loop (SIL)-Protokolls (anstatt des in 2 veranschaulichten CAN-Protokolls) kommunizieren und mit kompilierten Softwaremodulen anstatt mit Vorrichtungen kommunizieren. In diesem Beispiel wäre die Zielvorrichtung 140 ein Softwareverfahren oder eine Softwareklasse, ausgelegt zum Empfangen von Daten oder Nachrichten von einer anderen Klasse, von einem anderen Verfahren, über ein Kommunikationsnetzwerk oder dergleichen. In einigen Ausführungsformen kann die Fuzzer-Software 120 mit nicht-kompiliertem Quellcode (zum Beispiel C-Code, Python-Code oder dergleichen) in Kommunikation stehen, um zu bestimmen, ob unbearbeitete Ausnahmen in dem Quellcode vorliegen. In diesem Beispiel würde kein Netzwerkprotokoll verwendet werden.
Das Prüfwerkzeug 110 ist unter anderem zum Erzeugen synthetischer Testfälle für das Kommunikationsnetzwerk 230 ausgelegt. Das Prüfwerkzeug 110 ist zum Empfangen eines Signals von dem Kommunikationsnetzwerk 230 ausgelegt, das ein oder mehrere durch die elektronische Steuerung 210, die Zielvorrichtung 140 und die zweite ECU 220 erzeugte Signale repräsentiert. Das Prüfwerkzeug 110 kann beispielsweise ein Desktop-Computer, ein Server, ein Laptop, ein Diagnosewerkzeug oder dergleichen sein. Das Prüfwerkzeug 110 führt unter anderem Anweisungen im Zusammenhang mit den hierin beschriebenen Prozessen und Verfahren aus. Während das Prüfwerkzeug 110 gemäß Beschreibung hierin ein GAN zum Erzeugen synthetischer Prüffälle für das Kommunikationsnetzwerk 230 implementiert, versteht es sich, dass das Prüfwerkzeug 110 unter Verwendung anderer Maschinenlernverfahren implementiert sein kann.
Wie in 3 gezeigt beinhaltet das Prüfwerkzeug 110 unter anderem einen elektronischen Prozessor 300 (beispielsweise einen elektronischen Mikroprozessor, einen Mikrocontroller oder eine andere geeignete programmierbare Vorrichtung), einen Speicher 310 und eine Eingabe/Ausgabe-Schnittstelle 320. Der elektronische Prozessor 300, der Speicher 310 und die Eingabe/Ausgabe-Schnittstelle 320 sind kommunikativ verbunden. In einigen Ausführungsformen beinhaltet der elektronische Prozessor 300 Hardware (zum Beispiel unter Verwendung eines programmierbaren Mikroprozessors, eines feldprogrammierbaren Gate-Arrays („FPGA“), einer anwendungsspezifischen integrierten Schaltung („ASIC“) oder anderer Vorrichtungen) oder ist unter Verwendung dieser implementiert.
Der elektronische Prozessor 300 erhält und liefert Informationen (zum Beispiel von dem Speicher 310 und/oder der Eingabe/Ausgabe-Schnittstelle 320) und verarbeitet die Informationen durch das Ausführen einer/eines oder mehrerer Softwareanweisungen oder -module, die in der Lage sind, beispielsweise in einem Direktzugriffsspeicher(„RAM“)-Bereich des Speichers 310 oder einem Nurlesespeicher („ROM“) des Speichers 310 oder einem anderen nichtflüchtigen computerlesbaren Medium (nicht gezeigt) gespeichert zu werden. Die Software kann Firmware, eine oder mehrere Anwendungen, Programmdaten, Filter, Regeln, ein oder mehrere Programmmodule und andere ausführbare Anweisungen beinhalten.
Der Speicher 310 kann ein oder mehrere nichtflüchtige computerlesbare Medien beinhalten und beinhaltet einen Programmspeicherungsbereich und einen Datenspeicherungsbereich. Gemäß der Verwendung in der vorliegenden Anmeldung umfasst „nichtflüchtige computerlesbare Medien“ alle computerlesbaren Medien, besteht jedoch nicht aus einem kurzzeitigen, sich ausbreitenden Signal. Der Programmspeicherungsbereich und der Datenspeicherungsbereich können Kombinationen unterschiedlicher Speicherarten beinhalten, beispielsweise Nurlesespeicher („ROM“), Direktzugriffsspeicher („RAM“), elektrisch löschbaren programmierbaren Nurlesespeicher („EEPROM“), Flash-Speicher oder sonstige geeignete digitale Speichervorrichtungen. Der elektronische Prozessor 300 ist mit dem Speicher 310 verbunden und führt Software, darunter Firmware, eine oder mehrere Anwendungen, Programmdaten, Filter, Regeln, ein oder mehrere Programmmodule und andere ausführbare Anweisungen aus. Der elektronische Prozessor 300 ruft unter anderem Anweisungen bezüglich der hierin beschriebenen Steuerprozesse und Verfahren aus dem Speicher 310 ab und führt diese aus. In einigen Ausführungsformen speichert oder enthält der Speicher 310 das GAN 145 und die Fuzzer-Software 120.
Die Eingabe/Ausgabe-Schnittstelle 320 ist zum Empfangen von Eingaben und Bereitstellen einer Systemausgabe ausgelegt. Die Eingabe/Ausgabe-Schnittstelle 320 erhält Informationen und Signale (zum Beispiel über eine oder mehrere drahtgebundene und/oder drahtlose Verbindungen) von sowohl internen als auch externen Vorrichtungen und/oder Komponenten des Systems 200 und liefert Informationen und Signale an diese.
In einigen Ausführungsformen kann das Prüfwerkzeug 110 zusätzliche, weniger oder andere Komponenten beinhalten. So kann das Prüfwerkzeug 110 beispielsweise in einigen Ausführungsformen einen Sendeempfänger oder separate Sende- und Empfangskomponenten, beispielsweise einen Sender und einen Empfänger, beinhalten. Einige oder alle der Komponenten des Prüfwerkzeugs 110 können in anderen Vorrichtungen/Komponenten des Systems 200 verteilt und/oder integriert sein.
Unter erneuter Bezugnahme auf 2 beinhaltet die elektronische Steuerung 210 in einigen Ausführungsformen ähnliche Komponenten wie das Prüfwerkzeug 110, und dementsprechend gilt die Beschreibung der Komponenten des Prüfwerkzeugs 110 gleichermaßen für die elektronische Steuerung 210. In einigen Ausführungsformen wird das Prüfwerkzeug 110 nur zum Erzeugen synthetischer Prüffälle und Senden der Prüffälle an Vorrichtungen, die einer Fuzz-Prüfung unterzogen werden, verwendet. Somit kann in diesen Ausführungsformen eine sekundäre Verarbeitungsvorrichtung, wie etwa die elektronische Steuerung 210, in dem System 200 implementiert sein, um durch die Zielvorrichtung 140 und die zweite ECU 220 erzeugte Daten zu verarbeiten. Beispielsweise handelt es sich in einer Ausführungsform bei der elektronischen Steuerung 210 um eine Bordrechenvorrichtung eines Fahrzeugs. Es sei angemerkt, dass, obgleich die Funktionen des Prüfwerkzeugs 110 gemäß Beschreibung hierin vollständig durch das Prüfwerkzeug 110 durchgeführt werden, es möglich ist, dass die eine oder die mehreren Funktionen des Prüfwerkzeugs 110 vollständig durch die elektronische Steuerung 210 durchgeführt werden.
4 ist ein veranschaulichendes Beispiel eines Pseudocodes 500 zum Trainieren, Kompilieren, Anpassen und Prüfen eines Maschinenlernmodells (wie etwa des Diskriminator-DNN 150). Der Pseudocode 500 präsentiert sowohl Teile von Entwicklungsbestreben oder -prozessen als auch tatsächliche Operationen, die in hierin beschriebenen Komponenten durchgeführt werden. Daher werden in einigen Ausführungsformen einige der logischen Schritte des Pseudocodes 500 in Software (zum Beispiel in dem Speicher 310 gespeichert) implementiert, die durch den elektronischen Prozessor 300 des Prüfwerkzeugs 110 ausgeführt wird.
In einigen Ausführungsformen beginnt der Pseudocode 500 in Zeile 1, in der eine Funktion, BuildModel(testData,epochs), aufgerufen wird, um das Trainieren, Kompilieren, Anpassen und Prüfen des Diskriminator-DNN 150 zu initialisieren. In Zeilen 2-3 empfängt der Pseudocode 500 Daten (zum Beispiel Trainingsdaten 170 von der Verlaufsdaten-Datenbank 165) und führt eine Vorverarbeitung der Daten durch. Ein Ausführungsbeispiel einer Datenvorverarbeitung wird unten unter Bezugnahme auf 5 erörtert. In Zeile 4 teilt der Pseudocode 500 die vorverarbeiteten Trainingsdaten (in 4 als processedData gezeigt) gleichmäßig in zwei Datengruppen, trainingData und testingData, auf. In Zeilen 5-6 erstellt der Pseudocode 500 einen Normalisierer und normalisiert die trainingData und die testingData. Ein Ausführungsbeispiel einer Datennormalisierung wird unten unter Bezugnahme auf 5 erörtert. In Zeile 7 wird das Diskriminator-DNN 150 kompiliert.
In Zeilen 8-11 führt der Pseudocode 500 eine For-Schleife durch, um das Diskriminator-DNN 150 unter Verwendung von trainingData anzupassen oder zu trainieren, wobei der Pseudocode 500 das Diskriminator-DNN 150 für eine vorbestimmte Anzahl von Epochen (i) trainiert und eine Verlustfunktion minimiert. Die Verlustfunktion kann eine Veränderung der Fähigkeit des Diskriminator-DNN 150 auswerten, um einen Fortschritt zu bestimmen. Wie in Zeile 11 gezeigt, kann ein Validationssatz von 20 Prozent der testingData durch die Verlustfunktion verwendet werden, um die Anpassung des Diskriminator-DNN 150 auszuwerten und das Diskriminator-DNN 150 während des Trainierens abzustimmen.
In Zeilen 12-15 initiiert der Pseudocode 500 eine While-Schleife, um die Leistungsfähigkeit des Diskriminator-DNN 150 zu prüfen, nachdem es in Zeilen 8-11 trainiert wurde, wobei während die Länge der testingData größer als null ist, das letzte Element oder der letzte Prüffall, das bzw. der in dem testingData-Array enthalten ist, der Variable „Prüffall“ zugewiesen wird, und die mit dem Prüffall assoziierte Kennzeichnung (zum Beispiel „Pass-Fall“ oder „Fail-Fall“) der Variable „Kennzeichnung“ zugewiesen wird. In Zeile 14 erzeugt das Diskriminator-DNN 150 eine Bewertung und eine Kennzeichnung für den der Variable „Prüffall“ zugewiesenen Prüffall. Die durch das Diskriminator-DNN 150 erzeugte Kennzeichnung wird der Variable „Ergebnis“ zugewiesen. In Zeile 15 bestimmt der Pseudocode 500, ob die der Variable „Ergebnis“ zugewiesene Kennzeichnung gleich der oder die gleiche wie die der Variable „Kennzeichnung“ zugewiesene Kennzeichnung ist. In einigen Ausführungsformen wird, wenn in Zeilen 12-15 bestimmt wird, dass das Diskriminator-DNN 150 eine unzureichende Leistung erbringt (das Diskriminator-DNN 150 zum Beispiel weniger als 80 Prozent der in den testingData enthaltenen Prüffälle korrekt klassifiziert hat), der in Zeilen 8-11 beschriebene Trainingsprozess wiederholt wird und, sobald der Trainingsprozess abgeschlossen ist, der in Zeilen 12-15 beschriebene Trainingsprozess wiederholt wird. In einigen Ausführungsformen kann das Diskriminator-DNN 150 unter Verwendung neuer oder aktualisierter Trainingsdaten periodisch neutrainiert werden.
6 ist ein Flussdiagramm, das ein beispielhaftes Verfahren 600 zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung veranschaulicht.
In einigen Ausdrucksformen beginnt das Verfahren 600, wenn das Prüfwerkzeug 110 Trainingsdaten, beispielsweise die Trainingsdaten 170, empfängt. In einigen Ausführungsformen beinhalten die Trainingsdaten 170 Ausgabeprotokolldateien, die beispielsweise ein Signal repräsentieren, das durch eine ECU als Reaktion auf ein Empfangen einer Nachricht über den CAN-Bus beispielsweise von dem Prüfwerkzeug 110 oder einer anderen ECU erzeugt wird. In einigen Ausführungsformen empfängt das Prüfwerkzeug 110 die Trainingsdaten 170 direkt von dem Kommunikationsnetzwerk 230. In anderen Ausführungsformen empfängt das Prüfwerkzeug 110 die Trainingsdaten 170 aus der Verlaufsdaten-Datenbank 165 oder einem mit der elektronischen Steuerung 210 assoziierten Speicher.
Bei Block 605 führt der elektronische Prozessor 300 eine Vorverarbeitung der Trainingsdaten 170 durch. Die Trainingsdaten 170 werden bei Block 605 vorverarbeitetet, um sicherzustellen, dass sie in einem Datenformat sind, das ein effizientes und effektives Trainieren des Diskriminator-DNN 150 gestattet. Durch Vorverarbeiten der Trainingsdaten 170 kann sichergestellt werden, dass die Trainingsdaten 170 viele, wenn nicht alle, in den Trainingsdaten 170 vorhandene Muster repräsentieren und keine Schiefe in Richtung von Inkonsistenzen in den Trainingsdaten 170 aufweisen.
In einigen Ausführungsformen können die Trainingsdaten 170 aufgefüllt werden, um einer zum Trainieren des Diskriminator-DNN 150 benötigten Standardform von Trainingsdaten zu entsprechen. Beispielsweise kann das Diskriminator-DNN 150 erfordern, dass Trainingsdaten eine Länge von 8 Byte aufweisen. In diesem Fall kann der elektronische Prozessor 300 jede Instanz oder jeden Prüffall in den Trainingsdaten 170, die bzw. der kürzer als 8 Byte ist, auffüllen. In einigen Ausführungsformen kann der elektronische Prozessor 300 einen Prüffall in den Trainingsdaten 170 auffüllen, indem leere Bytes in den Nutzdaten des Prüffalls mit einem Hexadezimalwert 0xCC aufgefüllt werden, sodass jeder Nutzdatenabschnitt in jedem in den Trainingsdaten 170 enthalten Prüffall die gleiche Länge aufweist.
In einigen Ausführungsformen normalisiert der elektronische Prozessor 300 die Trainingsdaten 170, bevor die Trainingsdaten 170 zum Trainieren des Diskriminator-DNN 150 verwendet werden. Beispielsweise können die Trainingsdaten 170 durch das Prüfwerkzeug 110 derartig manipuliert werden, dass sie auf einer Standardskala gemessen werden können, wobei der Durchschnittswert der Daten null beträgt. Bei einigen Ausführungsformen formatiert oder wandelt der elektronische Prozessor 300 die Struktur der Trainingsdaten 170 in eine andere Form um, bevor sie zum Trainieren des Diskriminator-DNN 150 verwendet werden. Beispielsweise wandelt der elektronische Prozessor 300 in einer Ausführungsform die Trainingsdaten 170 von Python-Listendaten in Tensor-Slices um.
In einigen Ausführungsformen wird die Reihenfolge der in den Trainingsdaten 170 enthaltenen Instanzen durch den elektronischen Prozessor 300 randomisiert, bevor die Trainingsdaten 170 zum Trainieren des Diskriminator-DNN 150 verwendet werden, um sicherzustellen, dass keine im Voraus bestehende Reihenfolge oder definierende Teilung der Trainingsdaten 170 vorliegt. Es versteht sich, dass obgleich der elektronische Prozessor 300 gemäß Beschreibung hierin einen spezifischen Satz von Vorverarbeitungsprozeduren durchführt, der elektronische Prozessor 300 andere oder zusätzliche Vorverarbeitungsprozeduren als die hierin beschriebenen durchführen kann.
Bei Block 610 verwendet der elektronische Prozessor 300 die Trainingsdaten 170 zum dahingehenden Trainieren eines Diskriminator-DNN (zum Beispiel des Diskriminator-DNN 150), einen Prüffall auszuwerten, um zu bestimmen, ob der Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt. In einigen Ausführungsformen kann das Diskriminator-DNN 150 darauf trainiert werden, zu bestimmen, ob der Prüffall wahrscheinlich eine Hardwareschwachstelle sowie oder anstatt einer Softwareschwachstelle offenlegt. Ein Beispiel des Trainierens des Diskriminator-DNN 150 wird oben unter Bezugnahme auf 4 beschrieben.
Bei Block 615 verwendet der elektronische Prozessor 300 das Diskriminator-DNN 150 zum dahingehenden Trainieren eines Generator-DNN (zum Beispiel des Generator-DNN 160), einen Prüffall zu erzeugen, der wahrscheinlich eine Softwareschwachstelle offenlegt, wobei der elektronische Prozessor 300 das Diskriminator-DNN 150 zum Trainieren des Generator-DNN 160 durch Bestimmen, ob ein durch das Generator-DNN 160 erzeugter Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, und Senden einer Bestimmung darüber, ob ein durch das Generator-DNN 160 erzeugter Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, an das Generator-DNN 160 verwendet.
Beispielsweise wird dem Generator-DNN 160 in einigen Ausführungsformen eine randomisierte Eingabe als Startwert bereitgestellt, die dem Format der Trainingsdaten 170 entspricht, und unter Verwendung des Diskriminator-DNN 150 trainiert. Während das Generator-DNN 160 durch das Diskriminator-DNN trainiert wird, erzeugt das Generator-DNN einen Prüffall und sendet den Prüffall, den es erzeugt hat, an das Diskriminator-DNN 150 zur Auswertung. Das Diskriminator-DNN 150 bewertet und kennzeichnet den durch das Generator-DNN 160 erzeugten Prüffall. Bei einigen Ausführungsformen kann, wenn das Diskriminator-DNN 150 den Prüffall als „Pass-Fall“ bestimmt, das Diskriminator-DNN 150 die Kennzeichnung „Pass-Fall“, die mit den Prüffall assoziierte Bewertung oder beides an das Generator-DNN 160 senden. Basierend auf der Bewertung kann das Generator-DNN 160 den Prüffall, den es ausgibt, anpassen und basierend auf seinen Anpassungen einen neuen Prüffall zur Auswertung an das Diskriminator-DNN 150 senden. Dieser Prozess der Anpassung durch das Generator-DNN 160 und Auswertung durch das Diskriminator-DNN 150 kann fortgeführt werden, bis das Diskriminator-DNN 150 bestimmt, dass das Generator-DNN 160 eine vorbestimmte Anzahl an Prüffällen, die durch das Diskriminator-DNN 150 als „Fail-Fälle“ gekennzeichnet wurden, produziert hat. Beispielsweise kann das Diskriminator-DNN 150 erfordern, dass das Generator-DNN 160 eine Rate von 80 Prozent „Fail-Fälle“ aus der Gesamtzahl erzeugter Prüffälle erzielt. In einigen Ausführungsformen kann das Diskriminator-DNN 150 eine vorbestimmte Anzahl an Trainingssitzungen oder -epochen mit dem Generator-DNN 160 durchführen. In jeder Trainingssitzung kann erfordert werden, dass das Generator-DNN 160 eine vorbestimmte Anzahl an Prüffällen, die durch das Diskriminator-DNN 150 als „Fail-Fälle“ gekennzeichnet wurden, erzeugt, bevor das Generator-DNN 160 eine aktuelle Trainingssitzung bestehen und zu einer nächsten Trainingssitzung übergehen kann. In einigen Ausführungsformen wird, wenn die vorbestimmte Anzahl an Trainingssitzungen abgeschlossen sind, das Generator-DNN 160 als trainiert und bereit zum Erzeugen von an die Fuzzer-Software 120 zu sendenden Prüffällen erachtet. In einigen Ausführungsformen kann das Generator-DNN 160 periodisch neutrainiert werden.
Bei Block 620 erzeugt, wenn das Generator-DNN 160 trainiert ist, der elektronische Prozessor 300 einen oder mehrere Prüffälle unter Verwendung des Generator-DNN 160.
Beispielsweise wird das Generator-DNN 160 in einer Ausführungsform, wenn das Generator-DNN 160 von dem Diskriminator-DNN 150 gelernt hat, dass Prüffälle mit Arbitrierungs-IDs im Bereich von 0x6XX mit größerer Wahrscheinlichkeit einen Fehler verursachen, synthetische Prüffälle mit Arbitrierungs-IDs im Bereich von 0x6XX erzeugen.
In einigen Ausführungsformen werden, wenn das Generator-DNN 160 in der Lage ist, synthetische Prüffälle genau zu erzeugen, der eine oder die mehreren durch das Generator-DNN 160 erzeugten synthetischen Prüffälle an die Fuzzer-Software 120 übertragen. Die Fuzzer-Software 120 verwendet die synthetischen Prüffälle zum Identifizieren einer oder mehrerer in der Zielvorrichtung 140 enthaltener Softwareschwachstellen. Beispielsweise kann die Fuzzer-Software 120 eine oder mehrere Nachrichten basierend auf dem einen oder den mehreren Prüffällen an die Zielvorrichtung 140 senden. Es versteht sich, dass obgleich das Verfahren 600 gemäß Erörterung hierin unter Verwendung eines General Adversarial Network wie des GAN 145 implementiert ist, das Verfahren 600 unter Verwendung anderer Maschinenlernverfahren implementiert werden kann.
In einigen Ausführungsformen sendet die Fuzzer-Software 120, wenn ein Prüffall besteht (die Fuzzer-Software 120 zum Beispiel keinen Fehler von der Zielvorrichtung 140 empfängt oder kein Auftreten eines Fehlers an dieser bestimmt) eine invertierte Version des Prüffalls, der bestanden hat, an die Zielvorrichtung 140. In einigen Ausführungsformen sendet die Fuzzer-Software 120, wenn ein Prüffall durchfällt (die Fuzzer-Software 120 zum Beispiel einen Fehler von der Zielvorrichtung 140 empfängt oder die Zielvorrichtung 140 nicht reagiert), ähnliche Prüffälle an die Zielvorrichtung 140, um den Fehler zu validieren. In einigen Ausführungsformen werden Daten, die die Fuzzer-Software 120 während einer Prüfung von der Zielvorrichtung 140 empfängt oder bezüglich dieser erzeugt, durch den elektronischen Prozessor 300 beispielsweise als eine Ausgabeprotokolldatei an die Verlaufsdaten-Datenbank 165 gesendet.
In einigen Ausführungsformen werden Daten, die die Fuzzer-Software 120 während einer Prüfung von der Zielvorrichtung 140 empfängt oder bezüglich dieser erzeugt, durch den elektronischen Prozessor 300 beispielsweise als eine Ausgabeprotokolldatei an eine Anzeigevorrichtung (zum Beispiel eine in dem Prüfwerkzeug 110 enthaltene Anzeigevorrichtung) gesendet oder ausgegeben. Ein Softwaretechniker kann das Ausgabeprotokoll über die Anzeigevorrichtung betrachten und unter Verwendung der in dem Ausgabeprotokoll enthaltenen Daten einen Software-Patch (computerausführbare oder -lesbare Anweisungen) zum Beheben einer in dem Ausgabeprotokoll enthaltenen Softwareschwachstelle erstellen. Beispielsweise empfängt der elektronische Prozessor 300 in einigen Ausführungsformen neue oder überarbeitete computerausführbare Anweisungen zum Beheben einer Softwareschwachstelle von einem Softwaretechniker und sendet die neuen oder überarbeiteten computerausführbaren Anweisungen an die Zielvorrichtung 140, die in dem Ausgabeprotokoll als mit der Softwareschwachstelle assoziiert aufgezeichnet ist. Die neuen oder überarbeiteten computerausführbaren Anweisungen ersetzen computerausführbare Anweisungen, die zuvor in dem Speicher der Zielvorrichtung 140 gespeichert waren. Die neuen oder überarbeiteten computerausführbaren Anweisungen sind dazu ausgestaltet, eine Fehlfunktion der Zielvorrichtung 140 zu verhindern, wenn die elektronische Vorrichtung in Zukunft Daten empfängt, die dem synthetischen Prüffall ähnlich sind, der dazu geführt hat, dass sie in dem Ausgabeprotokoll als mit einer Softwareschwachstelle assoziiert aufgezeichnet wurde.
Verschiedene Merkmale, Vorteile und Ausführungsformen werden in den folgenden Ansprüchen dargelegt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 63/151384 [0001]

Claims

System zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung, wobei das System Folgendes umfasst: einen elektronischen Prozessor, der zu Folgendem ausgelegt ist: Vorverarbeiten von Trainingsdaten; Verwenden der Trainingsdaten zum dahingehenden Trainieren eines Diskriminator-DNN, einen Prüffall auszuwerten, um zu bestimmen, ob der Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt; Verwenden des Diskriminator-DNN zum dahingehenden Trainieren eines Generator-DNN, einen Prüffall zu erzeugen, der wahrscheinlich eine Softwareschwachstelle offen legt, wobei der elektronische Prozessor das Diskriminator-DNN zum Trainieren des Generator-DNN durch Bestimmen, ob ein durch das Generator-DNN erzeugter Prüffall wahrscheinlich eine Softwareschwachstelle offen legt, und Senden einer Bestimmung darüber, ob der durch das Generator-DNN erzeugte Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, an das Generator-DNN verwendet; und wenn das Generator-DNN trainiert ist, Erzeugen eines oder mehrerer Prüffälle unter Verwendung des Generator-DNN.
System nach Anspruch 1, wobei die Bestimmung eine Kennzeichnung und eine Bewertung beinhaltet.
System nach Anspruch 1, wobei der elektronische Prozessor ausgelegt ist zum Bestimmen, dass das Generator-DNN trainiert ist, wenn eine vorbestimmte Anzahl an Trainingssitzungen abgeschlossen sind.
System nach Anspruch 3, wobei der elektronische Prozessor ausgelegt ist zum Bestimmen, dass eine Trainingssitzung abgeschlossen ist, wenn das Generator-DNN eine vorbestimmte Anzahl an Prüffällen produziert, die eine Softwareschwachstelle wahrscheinlich offenlegen.
System nach Anspruch 1, wobei der elektronische Prozessor ausgelegt ist zum Vorverarbeiten der Trainingsdaten durch Durchführen mindestens eines ausgewählt aus der Gruppe bestehend aus Auffüllen der Trainingsdaten, Normalisieren der Trainingsdaten, Umformatieren der Trainingsdaten, Randomisieren der Reihenfolge der Trainingsdaten.
System nach Anspruch 1, wobei der elektronische Prozessor ferner ausgelegt ist zum Empfangen der Trainingsdaten aus einer Verlaufsdaten-Datenbank, einer Zielvorrichtung oder beiden.
System nach Anspruch 1, wobei der elektronische Prozessor zu Folgendem ausgelegt ist: Senden des einen oder der mehreren Prüffälle von dem Generator-DNN an einen Fuzzer; und Verwenden des Fuzzers zum Prüfen einer Zielvorrichtung oder eines Softwaremoduls durch Senden einer oder mehrerer Nachrichten basierend auf dem einen oder den mehreren Prüffällen an die Zielvorrichtung oder das Softwaremodul.
System nach Anspruch 7, wobei die Zielvorrichtung eine in einem Fahrzeug enthaltene ECU ist und zum Empfangen und Senden von Nachrichten über einen CAN-Bus ausgelegt ist.
System nach Anspruch 1, wobei der elektronische Prozessor zu Folgendem ausgelegt ist: Senden des einen oder der mehreren Prüffälle von dem Generator-DNN an einen Fuzzer; und Verwenden des Fuzzers zum Auswerten eines Quellcodes für unbearbeitete Ausnahmen.
Verfahren zum Erzeugen synthetischer Prüffälle zur Fuzz-Prüfung, wobei das Verfahren Folgendes umfasst: Vorverarbeiten von Trainingsdaten; Verwenden der Trainingsdaten zum dahingehenden Trainieren eines Diskriminator-DNN, einen Prüffall auszuwerten, um zu bestimmen, ob der Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt; Verwenden des Diskriminator-DNN zum dahingehenden Trainieren eines Generator-DNN, einen Prüffall zu erzeugen, der wahrscheinlich eine Softwareschwachstelle offenlegt, wobei das Diskriminator-DNN das Generator-DNN durch Bestimmen, ob ein durch das Generator-DNN erzeugter Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, und Senden einer Bestimmung darüber, ob der durch das Generator-DNN erzeugte Prüffall wahrscheinlich eine Softwareschwachstelle offenlegt, an das Generator-DNN trainiert; und wenn das Generator-DNN trainiert ist, Erzeugen eines oder mehrerer Prüffälle unter Verwendung des Generator-DNN.
Verfahren nach Anspruch 10, wobei die Bestimmung eine Kennzeichnung und eine Bewertung beinhaltet.
Verfahren nach Anspruch 10, wobei das Verfahren ferner Bestimmen, dass das Generator-DNN trainiert ist, wenn eine vorbestimmte Anzahl an Trainingssitzungen abgeschlossen sind, umfasst.
Verfahren nach Anspruch 12, wobei das Verfahren ferner Bestimmen, dass eine Trainingssitzung abgeschlossen ist, wenn das Generator-DNN eine vorbestimmte Anzahl an Prüffällen produziert, die eine Softwareschwachstelle wahrscheinlich offenlegen, umfasst.
Verfahren nach Anspruch 10, wobei das Vorverarbeiten der Trainingsdaten Durchführen mindestens eines ausgewählt aus der Gruppe bestehend aus Auffüllen der Trainingsdaten, Normalisieren der Trainingsdaten, Umformatieren der Trainingsdaten, Randomisieren der Reihenfolge der Trainingsdaten beinhaltet.
Verfahren nach Anspruch 10, wobei das Verfahren ferner Empfangen der Trainingsdaten aus einer Verlaufsdaten-Datenbank, einer Zielvorrichtung oder beiden umfasst.
Verfahren nach Anspruch 10, wobei das Verfahren ferner Folgendes umfasst: Senden des einen oder der mehreren Prüffälle von dem Generator-DNN an einen Fuzzer; und Verwenden des Fuzzers zum Prüfen einer Zielvorrichtung oder eines Softwaremoduls durch Senden einer oder mehrerer Nachrichten basierend auf dem einen oder den mehreren Prüffällen an die Zielvorrichtung oder das Softwaremodul.
Verfahren nach Anspruch 16, wobei die Zielvorrichtung eine in einem Fahrzeug enthaltene ECU ist und zum Empfangen und Senden von Nachrichten über einen CAN-Bus ausgelegt ist.
Verfahren nach Anspruch 10, wobei das Verfahren ferner Folgendes umfasst: Senden des einen oder der mehreren Prüffälle von dem Generator-DNN an einen Fuzzer; und Verwenden des Fuzzers zum Auswerten eines Quellcodes für unbearbeitete Ausnahmen.