Wie funktioniert der Honeypot-Vertrag PassHasBeenSet?

Ich habe versucht, diesen Honeypot-Vertrag auseinanderzunehmen, aber ich habe nicht genau herausgefunden, wie er funktioniert.

Überblick

Die Prämisse ist ziemlich einfach, der Vertrag sieht aus wie ein "Neujahrsgeschenk", bei dem die ETH abrufbar ist, wenn jemand (wahrscheinlich der Geschenkempfänger) das richtige Passwort eingibt.

Allerdings ist dem Vertragsautor ein fataler "Fehler" unterlaufen. Wenn ein bestimmtes benanntes Feld passHasBeenSetfalsch ist, kann jeder den Vertrag >1 ETH senden und der Eigentümer des Vertrags werden! Sobald Sie der Eigentümer sind, können Sie die Funktion aufrufen revoce, um alle Gelder aus dem Vertrag abzuheben.

Was ist das Problem? Ich fand diesen Vertrag verdächtig, weil er 1) vom Ersteller eines anderen Honeypot-Vertrags erstellt wurde, der auf reddit beschrieben wurde, und 2) im Allgemeinen seltsam – warum die Quelle bei Etherscan posten? Warum jemand anderem Eigentümer werden lassen, wenn er mehr in den Vertrag einzahlt? Der Vertrag ist mit if-Anweisungen entworfen/wirft keine Fehler und sieht aus, als wäre er von einem Anfänger geschrieben worden.

Allerdings konnte ich zunächst nichts an dem Vertrag erkennen. Außerdem schien es, als hätte es nur zwei Transaktionen, eine Vertragserstellung und einen Aufruf an setPass. Dies sollte set immer noch passHasBeenSetauf false belassen.

Pen-Tests

Ich dachte, ich könnte genauso gut nachsehen, ob der Vertrag ein Honeypot war oder nicht. Ich wusste, dass ich den „Angriffs“-Vertrag so gestalten konnte, dass ich nicht verlieren konnte, aber ich war trotzdem neugierig.

Ich habe einen Vertrag zusammengestellt, der anrufen würde setPassund dann revoce. Wenn der Saldo des Vertrags abnimmt, wird er zurückgesetzt. Diese Konstruktion bedeutete, dass ich kein Geld verlieren konnte.

Der Honeypot-Vertrag (& Angriffsvertrag) funktionierte bei Ropsten wie erwartet. Jegliches Guthaben im Vertrag wurde extrahiert und konnte dann aus dem angreifenden Vertrag zurückgezogen werden. Der Angriffsvertrag scheiterte jedoch im Mainnet. Der Saldo wurde erfolgreich an den Zielvertrag gesendet, aber das ist revocefehlgeschlagen, sodass die Rückfallsicherung des Vertrags ausgelöst wurde. Das Debuggen der Transaktion hat gezeigt, dass passHasBeenSetdas stimmt.

Also, wie konnte der "anfällige" Vertrag gesetzt werden passHasBeenSet? Ich muss etwas ziemlich Offensichtliches übersehen.

Tut mir leid, ich habe nicht genug Ruf, um einen Kommentar abzugeben. > Der Saldo wurde erfolgreich an den Zielvertrag gesendet. Wenn passHasBeenSetwahr, wie war der Aufruf Ihres Vertrags zu SetPass() überhaupt erfolgreich?

Antworten (1)

PassHasBeenSetwurde in dieser Transaktion aufgerufen:

https://etherscan.io/vmtrace?txhash=0x17c44511bcb28a34eac5653fc6cdd8367a978265e7528a0660f7e8aa9c8b55e7&type=parity

Suchen Sie 0x31fd725ain der Ablaufverfolgung. (Das ist der Funktionswähler für PassHasBeenSet(bytes32).)

Dieser Trick nutzt die Tatsache aus, dass Etherscan nicht alle Aufrufe eines Vertrags anzeigt. (Ich glaube, es überspringt Nachrichten von einem anderen Vertrag, wenn kein Ether angeschlossen ist.) Etherchain ist besser: https://www.etherchain.org/account/13c547Ff0888A0A876E6F1304eaeFE9E6E06FC4B#transactions .

Nun, das löst es. Das ist eine wirklich interessante Möglichkeit, speziell Etherscan zu nutzen.