Warnung
Dieser Artikel ist keine Bewertung der Wirksamkeit von Autoanalysatoren. Ich wende sie auf meine eigenen Verträge an, synthetisiere absichtlich Fehler und untersuche die Reaktionen. Eine solche Studie kann nicht die Grundlage für die Bestimmung von „besser-schlechter“ sein. Daher ist es sinnvoll, eine Blindstudie an einer großen Stichprobe von Verträgen durchzuführen, was angesichts des launischen Charakters dieser Art von Software äußerst schwierig ist. Es ist durchaus möglich, dass ein kleiner Fehler im Vertrag einen großen Teil der Analysatorlogik deaktivieren kann und ein einfaches heuristisches Vorzeichen dem Analysator eine enorme Anzahl von Punkten hinzufügen kann, indem ein weit verbreiteter Fehler gefunden wird, den die Wettbewerber einfach nicht hinzugefügt haben. Auch Fehler bei der Vorbereitung und Erstellung von Verträgen können eine Rolle spielen. Die gesamte fragliche Software ist noch recht jung und wird ständig weiterentwickelt. Nehmen Sie kritische Kommentare daher nicht als irreparable Probleme.
Der Zweck des Artikels ist es, dem Leser ein Verständnis dafür zu vermitteln, wie die Methoden der Codeanalyse in verschiedenen Analysegeräten funktionieren und wie sie korrekt verwendet werden können, anstatt "eine Wahl zu treffen". Eine vernünftige Wahl besteht darin, mehrere Tools gleichzeitig zu verwenden und sich auf das für den analysierten Vertrag am besten geeignete zu konzentrieren.
Einrichtung und Vorbereitung für den Start
Mythril verwendet mehrere Arten von Analysen gleichzeitig. Hier sind einige gute Artikel darüber: die wichtigsten , dies oder das . Bevor Sie fortfahren, ist es sinnvoll, sie zu lesen.
Lassen Sie uns zunächst unser eigenes Docker-Image von Mythril erstellen (spielt es keine Rolle, was wir daran ändern möchten?):
git clone https://github.com/ConsenSys/mythril-classic.git cd mythril-classic docker build -t myth .
Versuchen Sie nun, es auf unseren contracts/flattened.sol Ownable (ich verwende denselben Vertrag, der in der Einleitung besprochen wurde), in dem es zwei Hauptverträge gibt, Ownable from Zeppelin und our Booking . Wir haben immer noch ein Problem mit der Compiler-Version. Ich habe es auf die gleiche Weise wie im vorherigen Artikel behoben und der Docker-Datei Zeilen hinzugefügt, die die Compiler-Version ersetzen:
COPY --from=ethereum/solc:0.4.20 /usr/bin/solc /usr/bin
Nach dem erneuten Erstellen des Images können Sie versuchen, eine Vertragsanalyse auszuführen. Verwenden -v4 --verbose-report Flags -v4 und --verbose-report , um alle Warnungen --verbose-report . Lass uns gehen:
docker run -v $(pwd):/tmp \ -w /tmp myth:latest \ -v4 \ --verbose-report \ -x contracts/flattened.sol
Hier arbeiten wir mit einem abgeflachten Vertrag ohne Abhängigkeiten. Um einen separaten Booking.sol Vertrag zu analysieren und Mythril dazu zu bringen, alle Abhängigkeiten zu erfassen, können Sie Folgendes verwenden:
docker run -v $(pwd):/tmp \ -w /tmp myth:latest \ --solc-args="--allow-paths /tmp/node_modules/zeppelin-solidity/ zeppelin-solidity=/tmp/node_modules/zeppelin-solidity" \ -v4 \ --verbose-report \ -x contracts/Booking.sol
Ich arbeite lieber mit der abgeflachten Option als Wir werden viel im Code ändern. Mythril hat aber auch einen äußerst praktischen Modus - --truffle , der einfach alles --truffle was truffle , und das gesamte Projekt auf Schwachstellen überprüft. Ein weiteres wichtiges Merkmal ist die Möglichkeit, den Namen des zu analysierenden Vertrags über einen Doppelpunkt anzugeben. Andernfalls analysiert Mythril alle Verträge, auf die es stößt. Wir glauben, dass Ownable Ownable ein sicherer Vertrag ist, und wir werden nur die Booking analysieren. Die letzte Zeile lautet also:
docker run -v $(pwd):/tmp -w /tmp myth:latest -x contracts/flattened.sol:Booking -v4 --verbose-report
Vertrag starten und bereitstellen
Wir starten den Analysator mit der obigen Zeile, sehen uns die Ausgabe an und erhalten unter anderem diese Zeile:
mythril.laser.ethereum.svm [WARNING]: No contract was created during the execution of contract creation Increase the resources for creation execution (--max-depth or --create-timeout) The analysis was completed successfully. No issues were detected.
Es stellt sich heraus, dass unser Vertrag im Emulator nicht erstellt und "repariert" wurde. Aus diesem Grund empfehle ich, das Flag -v4 für alle Arten von Analysen zu verwenden, um alle Nachrichten -v4 und keine einzige wichtige zu verpassen. Lassen Sie uns herausfinden, was los ist. Die Lösung dieses praktischen Problems ist sehr wichtig, um zu verstehen, wie Mythril richtig angewendet wird.
Wir lesen also über Mythril: It uses concolic analysis, taint analysis and control flow checking to detect a variety of security vulnerabilities . Wenn Sie mit diesen Begriffen nicht sehr vertraut sind, empfehle ich das Wiki über konkole Tests hier , aber hier ist eine gute Präsentation über die Prüfung von Verschmutzungen auf x86. Kurz gesagt: Mythril emuliert die Ausführung eines Vertrags, legt die Verzweigungen fest, entlang derer die Ausführung erfolgen kann, und versucht, einen „unterbrochenen“ Vertragszustand zu erreichen, indem verschiedene Parameterkombinationen sortiert werden und versucht wird, alle möglichen Pfade zu umgehen. Hier ist ein Beispiel für ein Aktionsdiagramm aus dem obigen Artikel:
1. . symbolic-, . 2. , , trace . , , . 3. . 4. trace-. 5. symbolic execution trace, symbolic , , , . 6. , . , . 7. : , , input-, , . input- , .6 . 8. .4
Wenn Sie es stark vereinfachen, kann Mythril, nachdem er auf einen Zweig im Code gestoßen ist, verstehen, unter welchen Variablensätzen es möglich ist, in den einen und den anderen Zweig zu gelangen. In jedem Zweig weiß Mythril, ob es zu selfdestruct transfer , selfdestruct und anderen sicherheitsrelevanten Opcodes führt. Daher analysiert Mythril, welche Parametersätze und Transaktionen zu einer Sicherheitsverletzung führen können. Und die Art und Weise, wie Mythril Zweige abschneidet, die niemals die Kontrolle erhalten, und den Kontrollfluss analysiert, ist sein Haupttrick. Weitere Details zu Mythrildärmen und Astwandern finden Sie hier .
Aufgrund des deterministischen Charakters der intelligenten Vertragsausführung führt dieselbe Befehlsfolge immer streng zu einer Reihe von Statusänderungen, unabhängig von Plattform, Architektur oder Umgebung. Außerdem sind die Funktionen in intelligenten Verträgen relativ kurz und die Ressourcen äußerst begrenzt. Daher können Analysatoren wie Mythril, die symbolische und native Ausführung kombinieren, äußerst intelligent für intelligente Verträge arbeiten.
Dabei verwendet Mythril das Konzept des "Status" - dies ist der Code des Vertrags, seine Umgebung, ein Zeiger auf den aktuellen Befehl, die Speicherung des Vertrags und der Status des Stapels. Hier ist die Dokumentation:
The machine state μ is defined as the tuple (g, pc, m, i, s) which are the gas available, the program counter pc ∈ P256, the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents μm are a series of zeroes of size 256.
Der Übergangsgraph zwischen Zuständen ist das Hauptobjekt der Untersuchung. Bei erfolgreichem Start der Analyse werden Informationen zu diesem Diagramm im Analyseprotokoll angezeigt. Außerdem kann Mythril dieses Diagramm mit der Option --graph in einer für Menschen lesbaren Form --graph .
Nachdem wir mehr oder weniger verstanden haben, was Mythril tun wird, werden wir weiterhin verstehen, warum der Vertrag nicht analysiert wird und woher er stammt. [WARNING]: No contract was created during the execution of contract creation . Zu Beginn habe ich die --create-timeout und --max-depth (wie empfohlen) verdreht und --max-depth ich das Ergebnis nicht erhalten habe, dachte ich, dass der Konstruktor schuld ist - etwas darin hat nicht funktioniert. Hier ist sein Code:
function Booking( string _description, string _fileUrl, bytes32 _fileHash, uint256 _price, uint256 _cancellationFee, uint256 _rentDateStart, uint256 _rentDateEnd, uint256 _noCancelPeriod, uint256 _acceptObjectPeriod ) public payable { require(_price > 0); require(_price > _cancellationFee); require(_rentDateStart > getCurrentTime()); require(_rentDateEnd > _rentDateStart); require(_rentDateStart+_acceptObjectPeriod < _rentDateEnd); require(_rentDateStart > _noCancelPeriod); m_description = _description; m_fileUrl = _fileUrl; m_fileHash = _fileHash; m_price = _price; m_cancellationFee = _cancellationFee; m_rentDateStart = _rentDateStart; m_rentDateEnd = _rentDateEnd; m_noCancelPeriod = _noCancelPeriod; m_acceptObjectPeriod = _acceptObjectPeriod; }
Erinnern Sie sich an den Aktionsalgorithmus von Mythril. Um die Ablaufverfolgung auszuführen, müssen Sie den Vertragskonstruktor aufrufen, da die gesamte nachfolgende Ausführung davon abhängt, mit welchen Parametern der Konstruktor aufgerufen wurde. Wenn Sie beispielsweise den Konstruktor mit _price == 0 aufrufen, _price == 0 der Konstruktor bei _price == 0 eine Ausnahme aus require(_price > 0) . Selbst wenn Mythril über die vielen _price Werte iteriert, wird der Konstruktor trotzdem _price , wenn beispielsweise _price <= _cancellationFee . In diesem Vertrag sind ein Dutzend Parameter mit strengen Einschränkungen verbunden, und Mythril kann die gültigen Parameterkombinationen natürlich nicht erraten. Er versucht, zum nächsten Ausführungszweig zu gelangen und die Parameter des Konstruktors zu sortieren, hat aber praktisch keine Chance zu erraten - es gibt zu viele Kombinationen von Parametern. Daher funktioniert die Berechnung des Vertrags nicht - alle Möglichkeiten beruhen auf einer Art require(...) , und wir erhalten das oben genannte Problem.
Jetzt haben wir zwei Möglichkeiten: Die erste besteht darin, alle require im Konstruktor zu deaktivieren, indem Sie sie auskommentieren. Dann kann Mythril den Konstruktor mit einem beliebigen Satz von Parametern aufrufen und alles wird funktionieren. Dies bedeutet jedoch, dass Mythril bei der Prüfung eines Vertrags mit solchen Parametern Fehler findet, die mit falschen Werten möglich sind, die an den Konstruktor übergeben werden. Einfach ausgedrückt, wenn Mythril einen Fehler findet, der auftritt, wenn der Vertragsersteller _cancellationFee ein Milliardenfach des Mietpreises von _mprice , dann ist ein solcher Fehler nicht sinnvoll - ein solcher Vertrag wird niemals blockiert und Ressourcen werden für das Auffinden von Fehlern aufgewendet. Wir gehen davon aus, dass der Vertrag immer noch mit mehr oder weniger konsistenten Parametern verbunden ist. Für die weitere Analyse ist es daher sinnvoll, realistischere Konstruktorparameter anzugeben, damit Mythril nicht nach Fehlern sucht, die bei ordnungsgemäßem Abschluss des Vertrags niemals auftreten.
Ich habe viele Stunden damit verbracht, genau zu verstehen, wo die Bereitstellung unterbrochen wird, einschließlich und Deaktivierung verschiedener Teile des Konstruktors. Zusätzlich zu meinen Problemen verwendet der Konstruktor getCurrentTime() , das die aktuelle Zeit zurückgibt, und es ist unklar, wie dieser Aufruf Mythril behandelt. Ich werde diese Abenteuer hier nicht beschreiben, weil Bei regelmäßiger Anwendung werden diese Feinheiten dem Prüfer höchstwahrscheinlich bekannt. Daher habe ich den zweiten Weg gewählt: Um die Eingabedaten zu begrenzen und einfach alle Parameter aus dem Konstruktor zu entfernen, selbst getCurrentTime() , habe ich die erforderlichen Parameter einfach direkt im Konstruktor fest getCurrentTime() (idealerweise sollten diese Parameter vom Kunden bezogen werden):
function Booking( ) public payable { m_description = "My very long booking text about hotel and beautiful sea view!"; m_fileUrl = "https://ether-airbnb.bam/some-url/"; m_fileHash = 0x1628f3170cc16d40aad2e8fa1ab084f542fcb12e75ce1add62891dd75ba1ffd7; m_price = 1000000000000000000; // 1 ETH m_cancellationFee = 100000000000000000; // 0.1 ETH m_rentDateStart = 1550664800 + 3600 * 24; // current time + 1 day m_rentDateEnd = 1550664800 + 3600 * 24 * 4; // current time + 4 days m_acceptObjectPeriod = 3600 * 8; // 8 hours m_noCancelPeriod = 3600 * 24; // 1 day require(m_price > 0); require(m_price > m_cancellationFee); require(m_rentDateStart > 1550664800); require(m_rentDateEnd > m_rentDateStart); require((m_rentDateStart + m_acceptObjectPeriod) < m_rentDateEnd); require(m_rentDateStart > m_noCancelPeriod); }
Damit alles beginnt, müssen Sie außerdem den Parameter für die max-depth festlegen. Bei diesem Konstruktor mit --max-depth=34 auf der AWS t2.medium-Instanz hat es bei mir funktioniert. Gleichzeitig beginnt auf meinem leistungsstärkeren Laptop alles ohne max-depth . Nach der Verwendung dieses Parameters zu urteilen, ist es notwendig, Zweige für die Analyse zu erstellen , und sein Standardwert ist unendlich ( Code ). Drehen Sie diesen Parameter daher durch Drehen, stellen Sie jedoch sicher, dass der gewünschte Vertrag analysiert wird. Sie können dies unter folgenden Nachrichten verstehen:
mythril.laser.ethereum.svm [INFO]: 248 nodes, 247 edges, 2510 total states mythril.laser.ethereum.svm [INFO]: Achieved 59.86% coverage for code: .............
Die erste Zeile beschreibt nur das Diagramm, das analysiert wird. Lesen Sie den Rest der Zeilen selbst. Für die Analyse der verschiedenen Zweige, die ausgeführt werden können, sind umfangreiche Rechenressourcen erforderlich. Wenn Sie also große Verträge analysieren, müssen Sie auch auf einem schnellen Computer warten.
Suche nach Fehlern
Jetzt werden wir nach Fehlern suchen und unsere eigenen hinzufügen. Mythril sucht nach Zweigen, in denen Rundfunk, Selbstzerstörung, Behauptung und andere aus Sicherheitsgründen wichtige Aktionen stattfinden. Wenn eine der oben genannten Anweisungen irgendwo im Vertragscode enthalten ist, untersucht Mythril, wie es möglich ist, zu dieser Niederlassung zu gelangen, und zeigt außerdem die Reihenfolge der Transaktionen an, die zu dieser Niederlassung führen!
Lassen Sie uns zunächst sehen, was Mythril für den langmütigen Booking ausgegeben hat. Erste Warnung:
==== Dependence on predictable environment variable ==== SWC ID: 116 Severity: Low Contract: Booking Function name: fallback PC address: 566 Estimated Gas Usage: 17908 - 61696 Sending of Ether depends on a predictable variable. The contract sends Ether depending on the values of the following variables: - block.timestamp Note that the values of variables like coinbase, gaslimit, block number and timestamp are predictable and/or can be manipulated by a malicious miner. Don't use them for random number generation or to make critical decisions. -------------------- In file: contracts/flattened.sol:142 msg.sender.transfer(msg.value-m_price)
und es entsteht weil
require(m_rentDateStart > getCurrentTime());
in der Fallback-Funktion.
Beachten Sie, dass Mythril erkannt hat, dass getCurrentTime() in getCurrentTime() versteckt getCurrentTime() . Trotz der Tatsache, dass die Bedeutung des Vertrags kein Fehler ist, ist die Tatsache, dass Mythril block.timestamp mit der Sendung block.timestamp ausgezeichnet! In diesem Fall muss der Programmierer verstehen, dass die Entscheidung auf der Grundlage des Werts getroffen wird, den der Bergmann steuern kann. Und wenn in Zukunft an dieser Stelle des Vertrages eine Auktion oder eine andere Auktion für eine Dienstleistung stattfindet, muss die Möglichkeit von Front-Running-Angriffen berücksichtigt werden.
Mal sehen, ob Mythril eine Abhängigkeit von block.timestamp sieht, wenn wir die Variable in einem verschachtelten Aufruf wie block.timestamp ausblenden:
function getCurrentTime() public view returns (uint256) { - return now; + return getCurrentTimeInner(); } + function getCurrentTimeInner() internal returns (uint256) { + return now; + }
Und ja! Mythril sieht weiterhin die Verbindung zwischen block.timestamp und der Übertragung von Broadcasts. Dies ist für den Auditor äußerst wichtig. Die Verbindung zwischen der vom Angreifer kontrollierten Variablen und der Entscheidung, die nach mehreren Änderungen des Vertragsstatus getroffen wurde, kann durch die Logik stark maskiert werden, und Mythril ermöglicht es Ihnen, sie zu verfolgen. Obwohl es sich nicht lohnt, sich darauf zu verlassen, dass alle möglichen Verbindungen zwischen allen möglichen Variablen für Sie verfolgt werden: Wenn Sie die Funktion getCurrentTime() weiterhin verspotten und eine dreifache Verschachtelungstiefe getCurrentTime() , verschwindet die Warnung. Jeder Funktionsaufruf für Mythril erfordert die Erstellung neuer Statuszweige. Daher erfordert die Analyse sehr tiefer Verschachtelungsebenen enorme Ressourcen.
Es besteht natürlich eine ziemlich ernsthafte Chance, dass ich die Analyseparameter einfach falsch verwende oder der Cutoff irgendwo in den Tiefen des Analysators auftritt. Wie gesagt, das Produkt befindet sich in der aktiven Entwicklung. Zum Zeitpunkt des Schreibens sehe ich Commits im Repository mit der Erwähnung der max-depth . Nehmen Sie aktuelle Probleme also nicht ernst. Wir haben bereits genügend Beweise dafür gefunden, dass Mythril sehr effektiv nach impliziten Verbindungen zwischen diesen suchen kann Variablen.
Fügen Sie dem Vertrag zunächst eine Funktion hinzu, die die Sendung an Dritte weitergibt, jedoch erst, nachdem der Client die Sendung an den Vertrag gesendet hat. Wir haben jedem erlaubt, 1/5 des Äthers abzuholen, aber nur, wenn sich der Vertrag im Zustand State.PAID (d. H. Erst nachdem der Kunde die gemietete Nummer mit dem Äther bezahlt hat). Hier ist die Funktion:
function collectTaxes() external onlyState(State.PAID) { msg.sender.transfer(address(this).balance / 5); }
Mithril hat das Problem gefunden:
==== Unprotected Ether Withdrawal ==== SWC ID: 105 Severity: High Contract: Booking Function name: collectTaxes() PC address: 2492 Estimated Gas Usage: 2135 - 2746 Anyone can withdraw ETH from the contract account. Arbitrary senders other than the contract creator can withdraw ETH from the contract account without previously having sent a equivalent amount of ETH to it. This is likely to be a vulnerability. -------------------- In file: contracts/flattened.sol:149 msg.sender.transfer(address(this).balance / 5) -------------------- -------------------- Transaction Sequence: { "2": { "calldata": "0x", "call_value": "0xde0b6b3a7640000", "caller": "0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef" }, "3": { "calldata": "0x01b613a5", "call_value": "0x0", "caller": "0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef" } }
Großartig, d.h. Mythril hat sogar zwei Transaktionen durchgeführt, die dazu geführt haben, dass Sie dem Vertrag Äther entnehmen können. Ändern Sie nun die State.PAID Anforderung wie State.RENT in State.RENT :
- function collectTaxes() external onlyState(State.PAID){ + function collectTaxes() external onlyState(State.RENT) {
Jetzt kann collectTaxes() nur aufgerufen werden, wenn sich der Vertrag im State.RENT , und in diesem Moment ist nichts auf dem Kontostand, weil Der Vertrag hat bereits die gesamte Sendung an den Eigentümer gesendet. Und das Wichtigste dabei ist, dass Mythril diesmal NICHT den Fehler ==== Unprotected Ether Withdrawal ==== ! Unter der Bedingung onlyState(State.RENT) gelangte der Analysator nicht zu dem Code-Zweig, der Ether aus dem Vertrag mit einem Saldo ungleich Null sendet. Mythril hat verschiedene Optionen für die Parameter durchlaufen, aber Sie können in State.RENT nur gelangen, indem Sie die gesamte Sendung an den Vermieter senden. Daher ist es unmöglich, mit einem Saldo ungleich Null zu diesem Zweig des Codes zu gelangen, und Mythril stört den Auditor absolut nicht!
Auf die gleiche Weise wird Mythril Selbstzerstörung finden und assert und dem Prüfer zeigen, welche Handlungen zur Zerstörung des Vertrags oder zum Zusammenbruch einer wichtigen Funktion führen können. Ich werde diese Beispiele nicht nennen, sondern nur versuchen, eine ähnliche Funktion wie oben zu selfdestruct , nur selfdestruct und ihre Logik zu verdrehen.
Vergessen Sie auch nicht, dass einer der Teile von Mythril die symbolische Ausführung ist und dieser Ansatz allein, ohne die Ausführung zu emulieren, viele Schwachstellen bestimmen kann. Beispielsweise kann jede Verwendung von "+", "-" und anderen arithmetischen Operatoren als Sicherheitslücke des "Integer-Überlaufs" angesehen werden, wenn einer der Operanden irgendwie vom Angreifer gesteuert wird. Aber ich wiederhole noch einmal, das mächtigste Merkmal von Mythril ist die Kombination aus symbolischer und nativer Ausführung und die Bestimmung von Parameterwerten, die zur logischen Verzweigung führen.
Fazit
Um die gesamte Bandbreite potenzieller Probleme aufzuzeigen, die Mythril erkennen kann, sind natürlich nicht nur ein, sondern mehrere Artikel erforderlich. Für alles andere weiß er, wie man alles in einer echten Blockchain macht, die notwendigen Verträge und Schwachstellen durch Signaturen findet, schöne Anrufdiagramme erstellt und Berichte formatiert. Mit Mythril können Sie auch Ihre eigenen Testskripte schreiben, eine Python-basierte Schnittstelle zum Vertrag bereitstellen und einzelne Funktionen testen, Parameterwerte festlegen oder sogar Ihre eigene Strategie für die Arbeit mit disassembliertem Code mit einem beliebigen Grad an Flexibilität implementieren.
Mythril ist noch eine relativ junge Software, dies ist nicht IDA Pro, und es gibt nur sehr wenige Dokumentationen außer einigen Artikeln. Der Wert vieler Parameter kann nur im Mythril-Code gelesen werden, beginnend mit cli.py. Ich hoffe, dass eine vollständige und ausführliche Beschreibung der Funktionsweise der einzelnen Parameter in der Dokumentation enthalten ist.
Wenn der Vertrag mehr oder weniger groß ist, nimmt die Ausgabe einer Reihe von Fehlern viel Platz ein, aber ich möchte komprimierte Informationen über den gefundenen Fehler erhalten können, weil Wenn Sie mit Mythril arbeiten, müssen Sie sich unbedingt den Analysepfad ansehen, herausfinden, welche Verträge nach besten Kräften getestet wurden, und in der Lage sein, bestimmte Fehler, die der Prüfer als falsch positiv erachtet, zwangsweise zu deaktivieren.
Im Allgemeinen ist Mythril jedoch ein hervorragendes und äußerst leistungsfähiges Instrument zur Analyse intelligenter Verträge und sollte derzeit im Arsenal eines jeden Wirtschaftsprüfers stehen. Sie können damit zumindest auf kritische Teile des Codes achten und versteckte Beziehungen zwischen Variablen erkennen.
Zusammenfassend sind Empfehlungen für die Verwendung von Mythril:
- Grenzen Sie die Startbedingungen des zu untersuchenden Vertrags so weit wie möglich ein. Wenn Mythril während der Analyse viele Ressourcen für Zweige ausgibt, die in der Praxis niemals implementiert werden, verliert es die Fähigkeit, wirklich wichtige Fehler zu finden. Daher sollten Sie immer versuchen, den Bereich potenzieller Zweige einzugrenzen.
mythril.laser.ethereum.svm [WARNING]: No contract was created during the execution of contract creation Increase the resources for creation execution (--max-depth or --create-timeout) Sie sicher, dass die Vertragsanalyse gestartet wurde. Verpassen Sie keine Nachrichten wie mythril.laser.ethereum.svm [WARNING]: No contract was created during the execution of contract creation Increase the resources for creation execution (--max-depth or --create-timeout) , andernfalls könnten Sie fälschlicherweise mythril.laser.ethereum.svm [WARNING]: No contract was created during the execution of contract creation Increase the resources for creation execution (--max-depth or --create-timeout) , dass es keine Fehler gibt.- Sie können Zweige im Vertragscode beliebig deaktivieren, wodurch Mythril weniger Variationen bei der Auswahl von Zweigen und beim Einsparen von Ressourcen erhält. Versuchen Sie, auf Einschränkungen der
max-depth , um die Analyse nicht "abzuschneiden", aber achten Sie darauf, den Fehler nicht zu maskieren. - Achten Sie auf jede Warnung, selbst leichte Kommentare sind es manchmal wert, zumindest einen Kommentar zum Vertragscode hinzuzufügen, was es anderen Entwicklern erleichtert.
Im nächsten Artikel werden wir uns mit dem Manticore-Analysator befassen. Hier ist jedoch das Inhaltsverzeichnis für Artikel, die zum Schreiben bereit oder geplant sind:
Teil 1. Einführung. Zusammenstellung, Abflachung, Versionen von Solidity
Teil 2. Slither
Teil 3. Mithril (dieser Artikel)
Teil 4. Mantikor (während des Schreibens)
Teil 5. Echidna (während des Schreibens)