コントラクトのリバースエンジニアリング

はじめに

ブロックチェーン上に秘密はありません。ブロックチェーン上で起こる全てのことは、一貫性があり、検証可能で、公開されています。 理想的には、コントラクトのソースコードはEtherscanで公開・検証されるべきですopens in a new tab。 しかし、必ずしもそうとは限りませんopens in a new tab。 この記事では、ソースコードがないコントラクト0x2510c039cc3b061d79e564b38836da87e31b342fopens in a new tabを調べることで、コントラクトをリバースエンジニアリングする方法を学びます。

逆コンパイラは存在しますが、必ずしも利用可能な結果opens in a new tabが得られるとは限りません。 この記事では、手動でリバースエンジニアリングを行い、オペコードopens in a new tabからコントラクトを理解する方法と、デコンパイラの結果を解釈する方法を学びます。

この記事を理解するには、イーサリアム仮想マシン(EVM)の基礎を理解しており、EVMアセンブラにある程度精通している必要があります。 これらのトピックについてはこちらをお読みくださいopens in a new tab。

実行可能コードの準備

コントラクトのEtherscanページにアクセスし、ContractタブをクリックしてからSwitch to Opcodes Viewをクリックすると、オペコードを取得できます。 1行に1つのオペコードが表示されるビューになります。

ただし、ジャンプを理解するには、コード内の各オペコードの場所を知る必要があります。 そのためには、Googleスプレッドシートを開き、オペコードをC列に貼り付けるという方法があります。こちらの準備済みのスプレッドシートのコピーを作成すれば、次の手順をスキップできますopens in a new tab。

次のステップでは、ジャンプを理解できるように、正しいコードのロケーションを取得します。 B列にオペコードサイズを、A列に(16進数の)ロケーションを入れます。セルB1にこの関数を入力し、コードの最後までB列の残りのセルにコピー＆ペーストします。 これを行った後、B列を非表示にできます。

1=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)

まず、この関数はオペコード自体のために1バイトを追加し、次にPUSHを探します。 プッシュオペコードは特殊で、プッシュされる値用に追加のバイトを保持する必要があります。 オペコードがPUSHの場合、バイト数を抽出して加算します。

A1に最初のオフセットであるゼロを配置します。 次に、A2にこの関数を配置し、A列の残りの部分にコピーアンドペーストします。

1=dec2hex(hex2dec(A1)+B1)

ジャンプ(JUMPとJUMPI)の前にプッシュされる値は16進数で渡されるため、この関数で16進数の値を得る必要があります。

エントリーポイント (0x00)

コントラクトは、必ず最初のバイトから実行されます。 以下は、コードの冒頭部分です。

このコードは、次の2つのことをしています。

1. メモリロケーションの0x40～0x5Fへ、32バイト値として0x80を書き込みます(0x5Fに0x80が格納され、0x40～0x5Eはすべてゼロになります)。
2. コールデータサイズを読み取ります。 通常、イーサリアムコントラクトのコールデータはABI (アプリケーションバイナリインターフェース)opens in a new tabに従います。これには、関数セレクタ用に最低4バイトが必要です。 コールデータのサイズが4未満の場合、0x5Eへジャンプします。

0x5Eのハンドラ (非ABIコールデータ用)

このスニペットは、JUMPDESTで始まります。 イーサリアム仮想マシン(EVM)プログラムは、JUMPDESTではないオペコードにジャンプした場合に例外を投げます。 次に、CALLDATASIZEを確認し、それが「true」の場合(ゼロではない場合)、0x7Cにジャンプします。 これについては後述します。

コールデータがない場合、Storage[6]の値を読み取ります。 このStorage[6]の値はまだわかりませんが、コールデータなしで受信したコントラクトのトランザクションを探すことはできます。 コールデータなしで(つまりメソッドなしで)ETHを送金するだけのトランザクションの場合、EtherscanにTransferメソッドがあります。 実際、コントラクトが受け取った最初のトランザクションopens in a new tabは送金です。

このトランザクションを調べ、「Click to see More」をクリックすると、コールデータ(インプットデータ)が実際に空(0x)であることが分かります。 また、値が1.559ETHであることに留意してください。これに関しては、後述します。

次に、Stateタブをクリックし、リバースエンジニアリングしているコントラクト(0x2510...)を展開します。 トランザクション中にStorage[6]が変更されたことが分かります。「Hex」からNumberに変更すると、次のコントラクトの値に応じてweiに変換された値、1,559,000,000,000,000,000になります(分かりやすくするためにコンマを追加しています)。

同期間の他のTransferトランザクションopens in a new tabによるステートの変更を見ると、Storage[6]がしばらくの間コントラクトの値を追跡していたことがわかります。 これを今からValue*と呼びます。 アスタリスク(*)は、この変数がまだ何をするかわからないことを示しています。しかし、これは単にコントラクトの値を追跡するためだけのものではありません。なぜなら、ADDRESS BALANCEを使ってアカウントの残高を取得できるのに、非常に高価なストレージを使う必要はないからです。 最初のオペコードは、コントラクト自体のアドレスをプッシュします。 2番目のオペコードは、スタックの上部にあるアドレスを読み込み、そのアドレスの残高で置き換えます。

ジャンプ先でも、このコードのトレースを続けます。

NOTはビットごとの演算であるため、コール値内の全てのビット値を反転します。

Value*の値が、2^256-CALLVALUE-1以下の場合にジャンプします。 これは、オーバーフローを防ぐためのロジックに見えます。 実際に、オフセット0x01DEでいくつかの無意味な操作(例: 削除される寸前にメモリへの書き込み)をした後、オーバーフローが検出されると、標準の動作としてコントラクトが元に戻されます。

このようなオーバーフローが発生する可能性は、非常に低いことに留意してください。これは、コール値にValue*を加えたものが、2^256 wei(約10^59 ETH)と同等になる必要があるためです。 ETHの総供給量は、この記事の執筆時点で2億未満ですopens in a new tab。

ここに到達した場合、Value* + CALLVALUEを取得して、オフセット0x75へジャンプします。

ここに到達した場合(コールデータが空である必要があります)、Value*にコール値を加えます。 これは、Transferトランザクションが行うことと一致しています。

最後に、スタックをクリアし(任意)、トランザクションが正常に終了したことを通知します。

まとめると、最初のコードのフローチャートは次のようになります。

0x7Cのハンドラ

意図的にこのハンドラが何をするか見出しに入れませんでした。 特定のコントラクトの動作を教えるのではなく、どのようにコントラクトをリバースエンジニアリングするかを学ぶのがポイントだからです。 同じ方法で、コードを追って何をするか学ぶことができます。

ここへ到達するのは、次のような場合です。

• (オフセット0x63から)1バイト、2バイトまたは3バイトのコールデータがある場合
• (オフセット0x42と0x5Dから)メソッドのシグネチャが不明な場合

これは別のストレージセルです。このセルはどのトランザクションにも見つからなかったので、これが何を意味しているのか理解するのは困難です。 しかし、以下のコードがこれを明確にします。

これらのオペコードは、Storage[3]から読み取った値を160ビットに切り捨てています。これは、イーサリアムアドレスの長さです。

次のオペコードに進むため、このジャンプは不要です。 このコードは、ガス効率が良くありません。

コードの最初で、Mem[0x40]を0x80に設定しました。 その後の0x40を確かめると変更していないことが分かります。つまり、これは0x80であると推測できます。

0x80から始まるすべてのコールデータをメモリにコピーします。

これで、かなり明確になりました。 このコントラクトはプロキシopens in a new tabとして機能しており、Storage[3] 内のアドレスを呼び出して、実際の作業をしています。 DELEGATE_CALLは、別のコントラクトを呼び出しますが、同じストレージ内に留まります。 つまり、委任されたコントラクト(現在のコントラクトがこのコントラクトのプロキシとなります)が、同じストレージスペースにアクセスします。 コール(呼び出し)のパラメータは次の通りです。

• ガス: 残りの全ガス
• 呼び出し先アドレス: Storage[3]-as-address
• コールデータ: 元のコールデータを配置する、0x80から始まるCALLDATASIZEバイト
• リターンデータ: なし(0x00 - 0x00)。リターンデータは他の方法で取得(以下を参照)

ここでは、すべてのリターンデータを0x80から始まるメモリバッファにコピーします。

リターンデータをバッファ(0x80～0x80+RETURNDATASIZE)にコピーする呼び出しの後、その呼び出しが成功した場合は、そのバッファを正確に返します。

DELEGATECALL失敗

0xC0に到達した場合は、現在のコントラクトが呼び出したコントラクトが、元に戻された(REVERTされた)ことを意味します。 現在のコントラクトはこのコントラクトの単なるプロキシであるため、現在のコントラクトも同じデータを返して、元に戻す(REVERTする)必要があります。

そのため、前にRETURNで使用した同じバッファ(0x80～0x80+RETURNDATASIZE)を元に戻します(REVERTします)。

ABIコール

コールデータのサイズが4バイト以上である場合、有効なABIコールである可能性があります。

Etherscanによると1Cは未知のオペコードですが、これはEtherscanがこの機能を実装した後に追加されたopens in a new tabもので、まだ更新されていないためです。 最新のオペコード表opens in a new tabを見ると、これが右シフトであることがわかります

このようにメソッドシグネチャのマッチングテストを2つに分割することで、平均的にテストの半分を節約できます。 その直後のコードと0x43のコードは、コールデータの最初の32ビットの複製(DUP1)、プッシュ(PUSH4 (((method signature))、EQを実行し等式を判定、メソッドシグネチャがマッチした場合はJUMPI、という同じパターンをたどります。 以下に、メソッドシグネチャ、そのアドレス、既知の場合は対応するメソッド定義opens in a new tabを示します。

一致するものが見つからない場合、そのコードは、現在のコントラクトがプロキシとなっているコントラクトに一致するものがあることを期待して、0x7Cのプロキシハンドラへジャンプします。

splitter()

この関数が最初に行うことは、呼び出しがETHを送金していないことを確認することです。 この関数はpayableopens in a new tabではありません。 誰かがETHを送金してきた場合は、何かの間違いです。ETHを戻せなくなる前にREVERTして回避する必要があります。

そして0x80にはプロキシアドレスが含まれるようになりました

E4コード

これらの行を見るのは初めてですが、他のメソッドと共有されています(以下を参照)。 スタックの値をXと呼びます。splitter()で、このXの値が0xA0であることを覚えておいてください。

したがって、このコードは、スタック(X)内のメモリのポインターを受け取ります。これにより、コントラクトが0x80～XまでのバッファをRETURNします。

splitter()の場合、これは現在のコントラクトがプロキシとなっているアドレスを返します。 RETURNは、0x80～0x9Fのバッファを返します。これは、このデータを書き込んだ場所です(上記のオフセット0x130)。

currentWindow()

オフセット0x158～0x163のコードは、splitter()の0x103～0x10Eで見たものと(JUMPIの宛先以外は)同一であるため、currentWindow()も同様にpayableではないことが分かります。

DAコード

このコードもまた他のメソッドと共有されます。 スタックの値をYと呼びます。currentWindow()で、このYの値がStorage[1]であることを覚えておいてください。

0x80～0x9FにYを書き込みます。

残りはすでに、上記で説明されています。 0xDAにジャンプして、スタックの先頭(Y)を0x80～0x9Fに書き込み、その値を返します。 currentWindow()の場合、Storage[1]を返します。

merkleRoot()

オフセット0xED～0xF8のコードは、splitter()の0x103～0x10Eで見たものと(JUMPIの宛先以外は)同一であるため、merkleRoot()も同様にpayableではないことが分かります。

ジャンプの後に何が起こるかは、すでに分かっています。 つまり、merkleRoot()は、Storage[0]を返します。

0x81e580d3

オフセット0x138～0x143のコードは、splitter()の0x103～0x10Eで見たものと(JUMPIの宛先以外は)同一であるため、この関数も同様にpayableではないことが分かります。

この関数は、コールデータに少なくとも32バイト(1ワード)を必要とするようです。

コールデータを取得しなかった場合、トランザクションはリターンデータなしで元に戻されます。

この関数が、必要なコールデータを取得した場合、何が起こるか見ていきましょう。

calldataload(4)は、メソッドシグネチャの_後_にあるコールデータの最初のワードです

最初のワードがStorage[4]以上の場合、この関数は失敗します。 次のように、戻り値なしで元に戻されます。

calldataload(4)がStorage[4]より小さい場合、次のコードになります。

メモリロケーション0x00～0x1Fに、データ0x04が含まれるようになりました(0x00～0x1Eはすべてゼロ、0x1Fは4)。

ストレージ内にルックアップテーブルがあり、0x000...0004のSHA3から始まります。さらに、すべて正当なコールデータ値(Storage[4]より小さい値)のエントリが含まれています。

オフセット0xDAのコードが何をしているかはすでに分かっています。これは、スタックの先頭の値を呼び出し元に返します。 そのため、この関数はルックアップテーブルにある値を呼び出し元に返します。

0x1f135823

オフセット0xC4～0xCFのコードは、splitter()の0x103～0x10Eで見たものと(JUMPIの宛先以外は)同一であるため、この関数も同様にpayableではないことが分かります。

オフセット0xDAのコードが何をしているかはすでに分かっています。これは、スタックの先頭の値を呼び出し元に返します。 そのため、この関数はValue*を返します。

メソッドの概要

この時点でコントラクトを理解したと思えますか? 私は思えません。 これまで、次のようなメソッドを見てきました。

しかし、他の機能がStorage[3]のコントラクトによって提供されていることが分かっています。 そのコントラクトについて何か分かれば、手掛かりになるかもしれません。 幸いにも、これはブロックチェーンであり、少なくとも理論的にはすべてが既知です。 Storage[3]を設定するメソッドは何も見られなかったため、コンストラクタによって設定されているはずです。

コンストラクタ

コントラクトを見るopens in a new tabと、それを生成したトランザクションも確認できます。

そのトランザクションをクリックしてStateタブをクリックすると、パラメータの初期値を確認できます。 具体的には、Storage[3]に0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761opens in a new tabが含まれていることがわかります。 このコントラクトに、不足している機能が含まれているはずです。 調査中のコントラクトに使用した同じツールを使うことで、それを理解できます。

プロキシコントラクト

上記のオリジナルのコントラクトで使用したのと同じ手法を使用すると、次の場合にコントラクトが元に戻されることが分かります。

• 呼び出しにETHが添付されている(0x05-0x0F)
• コールデータのサイズが4未満(0x10-0x19および0xBE-0xC2)

サポートされるメソッドは次のとおりです。

下の4つのメソッドに到達することはないので、無視しても問題ありません。 それらのシグネチャは、オリジナルのコントラクトが単独で処理します(シグネチャをクリックすると、上記の詳細が表示されます)。そのため、オーバーライドされたメソッドopens in a new tabである必要があります。

残りのメソッドの1つがclaim(<params>)、もう一つがisClaimed(<params>)であり、エアドロップコントラクトのように見えます。 ここからは、オペコードごとに調べる代わりに、デコンパイラopens in a new tabを使用します。デコンパイラは、このコントラクトの3つの関数について利用可能な結果を生成します。 他の関数のリバースエンジニアリングは、読者の演習として残しておきます。

scaleAmountByPercentage

この関数についてデコンパイラが提供した内容は、次のとおりです。

1def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:\n  require calldata.size - 4 >=′ 64\n  if _param1 and _param2 > -1 / _param1:\n      revert with 0, 17\n  return (_param1 * _param2 / 100 * 10^6)
コピー

最初のrequireでは、コールデータ内に2つのパラメータにとって十分なサイズ、つまり関数シグネチャの4バイトに加え少なくとも64バイトあるかどうかをテストしています。 そうでない場合、問題があるのは明らかです。

if文は、_param1がゼロでないこと、さらに_param1 * _param2が負でないことを確認していると思われます。 これは、ラップアラウンドを防ぐためでしょう。

最後に、この関数はスケーリング値を返します。

claim

デコンパイラが作成するコードは複雑であり、すべてが重要なわけではありません。 役立つ情報を提供していると思われる行に焦点を当てるので、一部をスキップします。

1def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:\n  ...\n  require _param2 == addr(_param2)\n  ...\n  if currentWindow <= _param1:\n      revert with 0, '将来のウィンドウに対して請求することはできません'
コピー

ここでは、重要事項が2つあります。

• _param2は、uint256として宣言されていますが、実際にはアドレスです
• _param1は、請求対象のウィンドウであり、currentWindowであるか、それ以前のウィンドウである必要があります。

1  ...\n  if stor5[_claimWindow][addr(_claimFor)]:\n      revert with 0, 'アカウントはすでに指定されたウィンドウで請求済みです'
コピー

そのため、Storage[5]はウィンドウとアドレスの配列であり、アドレスがウィンドウの報酬を請求したかどうかが分かります。

1  ...\n  idx = 0\n  s = 0\n  while idx < _param4.length:\n  ...\n      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:\n          mem[mem[64] + 32] = mem[(32 * idx) + 296]\n          ...\n          s = sha3(mem[_62 + 32 len mem[_62]])\n          continue\n      ...\n      s = sha3(mem[_66 + 32 len mem[_66]])\n      continue\n  if unknown2eb4a7ab != s:\n      revert with 0, '無効な証明です'
コピー

unknown2eb4a7abは実際にはmerkleRoot()関数であることがわかっているので、このコードはマークル証明opens in a new tabを検証しているようです。 これは、_param4がマークル証明であることを意味します。

1  call addr(_param2) with:\n     value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei\n       gas 30000 wei
コピー

これは、コントラクトが自身のETHを別のアドレス(コントラクトまたは外部所有)に送金する方法です。 送金する金額の値で呼び出します。 これはETHのエアドロップであると思われます。

1  if not return_data.size:\n      if not ext_call.success:\n          require ext_code.size(stor2)\n          call stor2.deposit() with:\n             value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
コピー

下の2行は、Storage[2]も呼び出すコントラクトであることを示しています。 コンストラクタのトランザクションopens in a new tabを見ると、このコントラクトが0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2opens in a new tab (Wrapped Etherコントラクトで、そのソースコードはEtherscanにアップロードされていますopens in a new tab) であることがわかります。

このコントラクトは、_param2にETHを送金しようとしていると思われます。 送金できれば問題ありません。 そうでなければ、WETHopens in a new tabを送ろうと試みます。 _param2が外部所有アカウント (EOA)である場合、必ずETHを受け取ることができますが、コントラクトはETHの受け取りを拒否することができます。 しかし、WETHはERC-20であるため、コントラクトは受け取りを拒否できません。

1  ...\n  log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)
コピー

関数の最後に、ログエントリが生成されていることがわかります。 生成されたログエントリopens in a new tabを確認し、0xdbd5...で始まるトピックでフィルタリングします。 そのようなエントリを生成したトランザクションの1つをクリックするとopens in a new tab、実際に請求のように見えることがわかります。アカウントは、リバースエンジニアリングしているコントラクトにメッセージを送信し、代わりにETHを取得しています。

1e7df9d3

この関数は、上記のclaimと非常に類似しています。 この関数はマークル証明も同様に確認し、ETHを最初に送金しようと試み、同じタイプのログエントリを生成します。

1def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:\n  ...\n  idx = 0\n  s = 0\n  while idx < _param3.length:\n      if idx >= mem[96]:\n          revert with 0, 50\n      _55 = mem[(32 * idx) + 128]\n      if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:\n          ...\n          s = sha3(mem[_58 + 32 len mem[_58]])\n          continue\n      mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])\n  ...\n  if unknown2eb4a7ab != s:\n      revert with 0, '無効な証明です'\n  ...\n  call addr(_param1) with:\n     value s wei\n       gas 30000 wei\n  if not return_data.size:\n      if not ext_call.success:\n          require ext_code.size(stor2)\n          call stor2.deposit() with:\n             value s wei\n               gas gas_remaining wei\n  ...\n  log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
コピー

主な違いは、最初のパラメータである引き出しを行うためのウィンドウがないことです。 代わりに、請求対象となるすべてのウィンドウについてのループがあります。

1  idx = 0\n  s = 0\n  while idx < currentWindow:\n      ...\n      if stor5[mem[0]]:\n          if idx == -1:\n              revert with 0, 17\n          idx = idx + 1\n          s = s\n          continue\n      ...\n      stor5[idx][addr(_param1)] = 1\n      if idx >= unknown81e580d3.length:\n          revert with 0, 50\n      mem[0] = 4\n      if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:\n          revert with 0, 17\n      if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):\n          revert with 0, 17\n      if idx == -1:\n          revert with 0, 17\n      idx = idx + 1\n      s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)\n      continue
コピー

そのため、すべてのウィンドウについて請求するclaimの変種のようです。

結論

ここまでで、オペコードまたは(動作する場合は)デコンパイラを使用して、ソースコードが入手できないコントラクトを理解する方法を身に付けられたはずです。 この記事の長さが示しているように、コントラクトのリバースエンジニアリングは簡単ではありません。しかしながら、セキュリティが不可欠なシステムでは、コントラクトが想定した通りに動作しているかを検証できることは、非常に重要なスキルです。

私の他の作品はこちらでご覧いただけますopens in a new tab.

最終更新： 2025年8月22日

qopens in a new tab

bopens in a new tab

popens in a new tab

+7

貢献者を表示