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

はじめに

ブロックチェーン上に秘密はありません。発生するすべてのことは一貫性があり、検証可能で、公開されています。理想的には、コントラクトはソースコードが公開され、Etherscan上で検証されているべきです (opens in a new tab)。しかし、常にそうであるとは限りません (opens in a new tab)。この記事では、ソースコードのないコントラクトである0x2510c039cc3b061d79e564b38836da87e31b342f (opens 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つのオペコードが表示されるビューになります。

ただし、ジャンプを理解するためには、各オペコードがコード内のどこにあるかを知る必要があります。そのための1つの方法は、Googleスプレッドシートを開き、C列にオペコードを貼り付けることです。この準備済みのスプレッドシートのコピーを作成することで、以下の手順をスキップできます (opens in a new tab)。

次のステップは、ジャンプを理解できるように正しいコードの場所を取得することです。B列にオペコードのサイズを、A列に場所（16進数）を入力します。セルB1にこの関数を入力し、コードの最後までB列の残りの部分にコピーして貼り付けます。これを行った後、B列を非表示にすることができます。

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

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

A1に最初のオフセットであるゼロを入力します。次に、A2にこの関数を入力し、A列の残りの部分に再度コピーして貼り付けます。

=dec2hex(hex2dec(A1)+B1)

ジャンプ（JUMPおよびJUMPI）の前にプッシュされる値は16進数で与えられるため、16進数の値を取得するためにこの関数が必要です。

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

コントラクトは常に最初のバイトから実行されます。以下はコードの初期部分です。

このコードは2つのことを行います。

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

0x5Eのハンドラ（非ABIコールデータ用）

このスニペットはJUMPDESTから始まります。EVM（イーサリアム仮想マシン）プログラムは、JUMPDEST以外のオペコードにジャンプすると例外をスローします。次にCALLDATASIZEを確認し、それが「真」（つまりゼロではない）であれば0x7Cにジャンプします。これについては後述します。

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

そのトランザクションを見てClick to see Moreをクリックすると、入力データと呼ばれるコールデータが確かに空（0x）であることがわかります。また、値が1.559 ETHであることにも注目してください。これは後で関連してきます。

次に、Stateタブをクリックし、リバースエンジニアリングしているコントラクト（0x2510...）を展開します。トランザクション中にStorage[6]が変更されたことがわかります。HexをNumberに変更すると、1,559,000,000,000,000,000になっていることがわかります。これはwei単位で送金された値（わかりやすくするためにカンマを追加しました）であり、次のコントラクトの値に対応しています。

同時期の他の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のハンドラ

このハンドラが何をするのか、あえて見出しには書きませんでした。目的は、この特定のコントラクトがどのように機能するかを教えることではなく、コントラクトをリバースエンジニアリングする方法を教えることだからです。私がしたのと同じように、コードを追うことで、それが何をするのかを学ぶことができます。

ここにはいくつかの場所から到達します：

• 1、2、または3バイトのコールデータがある場合（オフセット0x63から）
• メソッドの署名が不明な場合（オフセット0x42および0x5Dから）

これは別のストレージセルですが、どのトランザクションでも見つけることができなかったため、その意味を知るのはより困難です。以下のコードを見れば、より明確になるでしょう。

これらのオペコードは、Storage[3]から読み取った値を、Ethereumのアドレスの長さである160ビットに切り詰めます。

次のオペコードに進むため、このジャンプは不要です。このコードは、可能な限りガス効率が良いとは言えません。

コードの最初で、Mem[0x40]を0x80に設定しました。後で0x40を探すと、変更されていないことがわかるため、0x80であると想定できます。

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

これで状況がずっと明確になりました。このコントラクトはプロキシ (opens in a new tab)として機能し、Storage[3]のアドレスを呼び出して実際の作業を行うことができます。DELEGATE_CALLは別のコントラクトを呼び出しますが、同じストレージに留まります。つまり、委譲されたコントラクト（私たちがプロキシとなっているコントラクト）は、同じストレージ空間にアクセスします。呼び出しのパラメータは以下の通りです：

• Gas: 残りのすべてのガス
• Called address: Storage[3]-as-address
• Call data: 0x80から始まるCALLDATASIZEバイト（ここに元のコールデータを配置しました）
• Return data: なし（0x00 - 0x00）戻り値のデータは別の方法で取得します（以下を参照）

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

したがって、呼び出しの後、戻り値のデータをバッファ0x80 - 0x80+RETURNDATASIZEにコピーし、呼び出しが成功した場合は、まさにそのバッファを使用してRETURNします。

DELEGATECALLの失敗

ここ（0xC0）に到達した場合、呼び出したコントラクトがリバートしたことを意味します。私たちはそのコントラクトのプロキシにすぎないため、同じデータを返してリバートさせたいと考えます。

したがって、先ほどRETURNに使用したのと同じバッファ（0x80 - 0x80+RETURNDATASIZE）を使用してREVERTします。

ABIコール

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

Etherscanは1Cを不明なオペコードとして表示します。なぜなら、Etherscanがこの機能を記述した後にそれが追加され (opens in a new tab)、まだ更新されていないからです。最新のオペコード表 (opens in a new tab)を見ると、これが右シフト（shift right）であることがわかります。

このようにメソッド署名の照合テストを2つに分割することで、平均してテストの半分を節約できます。この直後に続くコードと0x43のコードは同じパターンに従っています。コールデータの最初の32ビットをDUP1し、PUSH4 (((method signature>し、EQを実行して等しいかどうかを確認し、メソッド署名が一致する場合はJUMPIします。以下は、メソッド署名、そのアドレス、および判明している場合は対応するメソッド定義 (opens in a new tab)です。

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

splitter()

この関数が最初に行うのは、呼び出しでETHが送信されていないことを確認することです。この関数はpayable (opens 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]であることを覚えておきましょう。

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

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

merkleRoot()

オフセット0xED-0xF8のコードは、splitter()の0x103-0x10Eで見たものと（JUMPIの宛先を除いて）同一であるため、merkleRoot()もpayableではないことがわかります。

ジャンプ後に何が起こるかは、すでに解明しました。したがって、merkleRoot()はStorage[0]を返します。

オフセット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)と、それを作成したトランザクションも確認できます。

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

プロキシ・コントラクト

上記の元のコントラクトで使用したのと同じ手法を使用すると、次の場合にコントラクトがリバートすることがわかります。

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

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

下部の4つのメソッドは、到達することがないため無視できます。これらの署名は、元のコントラクトが単独で処理するようになっているため（署名をクリックすると上記の詳細を確認できます）、オーバーライドされたメソッド (opens in a new tab)であるはずです。

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

scaleAmountByPercentage

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

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

最初の require は、コールデータに、関数署名の4バイトに加えて、2つのパラメータに十分な少なくとも64バイトがあることをテストします。そうでない場合は、明らかに何かが間違っています。

if ステートメントは、_param1 がゼロではなく、_param1 * _param2 が負ではないことを確認しているようです。これはおそらく、ラップアラウンドのケースを防ぐためです。

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

請求

デコンパイラが作成するコードは複雑であり、そのすべてが私たちに関連しているわけではありません。有用な情報を提供していると思われる行に焦点を当てるため、一部を省略します。

def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
  ...
  require _param2 == addr(_param2)
  ...
  if currentWindow <= _param1:
      revert with 0, 'cannot claim for a future window'

ここで2つの重要なことがわかります。

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

  ...
  if stor5[_claimWindow][addr(_claimFor)]:
      revert with 0, 'Account already claimed the given window'

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

  ...
  idx = 0
  s = 0
  while idx < _param4.length:
  ...
      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
          mem[mem[64] + 32] = mem[(32 * idx) + 296]
          ...
          s = sha3(mem[_62 + 32 len mem[_62]])
          continue
      ...
      s = sha3(mem[_66 + 32 len mem[_66]])
      continue
  if unknown2eb4a7ab != s:
      revert with 0, 'Invalid proof'

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

  call addr(_param2) with:
     value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
       gas 30000 wei

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

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

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

したがって、コントラクトは _param2 にETHを送金しようとしているようです。それができれば素晴らしいです。できない場合は、WETH (opens in a new tab) を送金しようとします。_param2 が外部所有アカウント (EOA) の場合、常にETHを受け取ることができますが、コントラクトはETHの受け取りを拒否できます。ただし、WETHはERC-20であり、コントラクトはそれを受け入れることを拒否できません。

  ...
  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を送金しようとし、同じタイプのログエントリを生成します。

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

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

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

したがって、これはすべてのウィンドウを請求する claim のバリアントのようです。

まとめ

これで、オペコードや（機能する場合は）デコンパイラを使用して、ソースコードが公開されていないコントラクトを理解する方法がわかったはずです。この記事の長さからも明らかなように、コントラクトのリバースエンジニアリングは簡単なことではありませんが、セキュリティが不可欠なシステムにおいて、コントラクトが約束通りに機能することを検証できることは重要なスキルです。

私の他の記事についてはこちらをご覧ください (opens in a new tab)。

ページの最終更新: 2026年4月3日

q (opens in a new tab)

b (opens in a new tab)

n (opens in a new tab)

+7

コントリビューターを見る