逆向工程合约

简介

区块链上没有秘密，发生的一切都是一致的、可验证的且公开可用的。理想情况下，合约应该在 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 来获取操作码。你将看到每行一个操作码的视图。

然而，为了能够理解跳转（jump），你需要知道每个操作码在代码中的位置。为此，一种方法是打开一个 Google 电子表格，并将操作码粘贴到 C 列。你可以通过复制这份已经准备好的电子表格来跳过以下步骤 (opens in a new tab)。

下一步是获取正确的代码位置，以便我们能够理解跳转。我们将把操作码大小放在 B 列，将位置（十六进制）放在 A 列。在单元格 B1 中输入此函数，然后将其复制并粘贴到 B 列的其余部分，直到代码结束。完成此操作后，你可以隐藏 B 列。

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

首先，该函数为操作码本身添加一个字节，然后查找 PUSH。PUSH 操作码比较特殊，因为它们需要额外的字节来存储被压入的值。如果操作码是 PUSH，我们将提取字节数并将其相加。

在 A1 中输入第一个偏移量，即零。然后，在 A2 中输入此函数，并再次将其复制并粘贴到 A 列的其余部分：

=dec2hex(hex2dec(A1)+B1)

我们需要这个函数来提供十六进制值，因为在跳转（JUMP 和 JUMPI）之前压入的值是以十六进制形式给出的。

入口点 (0x00)

合约总是从第一个字节开始执行。这是代码的初始部分：

这段代码执行两项操作：

1. 将 0x80 作为一个 32 字节的值写入内存位置 0x40-0x5F（0x80 存储在 0x5F 中，而 0x40-0x5E 全为零）。
2. 读取调用数据大小。通常，以太坊合约的调用数据遵循应用程序二进制接口 (ABI) (opens in a new tab)，这至少需要四个字节作为函数选择器。如果调用数据大小小于四，则跳转到 0x5E。

0x5E 处的处理程序（用于非 ABI 调用数据）

此代码片段以 JUMPDEST 开始。如果你跳转到一个不是 JUMPDEST 的操作码，EVM（以太坊虚拟机）程序将抛出异常。然后它会检查 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 获取账户余额时，就没有必要使用非常昂贵的存储。第一个操作码将合约自身的地址推入栈中。第二个操作码读取栈顶的地址，并将其替换为该地址的余额。

我们将继续在跳转目标处追踪此代码。

NOT 是按位操作，因此它会反转调用值中每个位的值。

如果 Value* 小于或等于 2^256-CALLVALUE-1，我们就会跳转。这看起来像是防止溢出的逻辑。事实上，我们看到在执行了一些无意义的操作（例如，写入内存的操作即将被删除）之后，在偏移量 0x01DE 处，如果检测到溢出，合约就会回退，这是正常的行为。

请注意，这种溢出极不可能发生，因为这需要调用值加上 Value* 达到 2^256 wei 的量级，大约是 10^59 ETH。在撰写本文时，ETH 的总供应量不到两亿 (opens in a new tab)。

如果我们到达这里，获取 Value* + CALLVALUE 并跳转到偏移量 0x75。

如果我们到达这里（这需要调用数据为空），我们将调用值加到 Value* 中。这与我们所说的 Transfer 交易的作用是一致的。

最后，清空栈（这并非必要），并发出交易成功结束的信号。

总而言之，这是初始代码的流程图。

0x7C 处的处理程序

我故意没有在标题中说明这个处理程序的作用。重点不是教你这个特定的合约是如何工作的，而是教你如何逆向工程合约。你将通过跟随代码，以和我相同的方式了解它的作用。

我们从几个地方来到这里：

• 如果有 1、2 或 3 个字节的调用数据（来自偏移量 0x63）
• 如果方法签名未知（来自偏移量 0x42 和 0x5D）

这是另一个存储单元，我在任何交易中都找不到它，因此很难知道它的含义。下面的代码会使其更加清晰。

这些操作码将我们从 Storage[3] 读取的值截断为 160 位，即以太坊地址的长度。

这个跳转是多余的，因为我们要进入下一个操作码。这段代码的 gas 效率远未达到最佳状态。

在代码的最开始，我们将 Mem[0x40] 设置为 0x80。如果稍后查找 0x40，我们会发现没有更改它——因此我们可以假设它是 0x80。

将所有调用数据复制到内存中，从 0x80 开始。

现在事情清楚多了。这个合约可以作为一个代理 (opens in a new tab)，调用 Storage[3] 中的地址来完成实际工作。DELEGATE_CALL 调用一个独立的合约，但保留在相同的存储中。这意味着被委托的合约（即我们为其代理的合约）访问相同的存储空间。调用的参数是：

• Gas：所有剩余的 gas
• 被调用的地址：Storage[3]-as-address
• 调用数据：从 0x80 开始的 CALLDATASIZE 个字节，这是我们放置原始调用数据的地方
• 返回数据：无 (0x00 - 0x00) 我们将通过其他方式获取返回数据（见下文）

在这里，我们将所有返回数据复制到从 0x80 开始的内存缓冲区。

因此，在调用之后，我们将返回数据复制到缓冲区 0x80 - 0x80+RETURNDATASIZE，如果调用成功，我们随后使用完全相同的缓冲区执行 RETURN。

DELEGATECALL 失败

如果我们到达这里，即 0xC0，这意味着我们调用的合约已回退。由于我们只是该合约的代理，我们希望返回相同的数据并同样回退。

因此，我们使用之前用于 RETURN 的相同缓冲区执行 REVERT：0x80 - 0x80+RETURNDATASIZE

ABI 调用

如果调用数据的大小为 4 个字节或更多，这可能是一个有效的 ABI 调用。

Etherscan 告诉我们 1C 是一个未知的操作码，因为它是在 Etherscan 编写此功能之后添加的 (opens in a new tab)，并且他们还没有更新它。一张最新的操作码表 (opens in a new tab)向我们显示这是右移操作。

像这样将方法签名匹配测试一分为二，平均可以节省一半的测试。紧随其后的代码和 0x43 处的代码遵循相同的模式：DUP1 调用数据的前 32 位，PUSH4 (((method signature>，运行 EQ 检查是否相等，如果方法签名匹配，则 JUMPI。以下是方法签名、它们的地址，以及（如果已知的话）相应的方法定义 (opens in a new tab)：

如果未找到匹配项，代码将跳转到 0x7C 处的代理处理程序，希望我们所代理的合约中存在匹配项。

splitter()

此函数要做的第一件事是检查调用是否没有发送任何 ETH。此函数不是 payable (opens in a new tab)。如果有人向我们发送了 ETH，那一定是个错误，我们希望 REVERT 以避免这些 ETH 留在他们无法取回的地方。

现在 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]。

0x81e580d3

偏移量 0x138-0x143 处的代码与我们在 splitter() 中的 0x103-0x10E 处看到的完全相同（除了 JUMPI 目标不同），因此我们知道此函数也不是 payable。

看起来这个函数至少需要 32 字节（一个字）的调用数据。

如果它没有获取到调用数据，交易将被回退，且没有任何返回数据。

让我们看看如果函数_确实_获取了它需要的调用数据会发生什么。

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)

并且它支持的方法有：

我们可以忽略底部的四个方法，因为我们永远不会执行到它们。它们的签名表明我们的原始合约会自行处理它们（你可以点击签名查看上面的详细信息），因此它们必须是被重写的方法 (opens in a new tab)。

剩下的方法中有一个是 claim(<params>)，另一个是 isClaimed(<params>)，所以它看起来像是一个空投合约。与其逐个操作码地检查其余部分，我们可以尝试使用反编译器 (opens in a new tab)，它为该合约的三个函数生成了可用的结果。逆向工程其他函数就留给读者作为练习。

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 个字节的函数签名外，是否至少有 64 个字节，足以容纳两个参数。如果没有，那么显然有问题。

if 语句似乎在检查 _param1 不为零，并且 _param1 * _param2 不为负数。这可能是为了防止发生回绕（wrap around）的情况。

最后，该函数返回一个按比例缩放的值。

claim

反编译器生成的代码很复杂，并非所有代码都与我们相关。我将跳过其中一些，重点关注我认为提供有用信息的代码行

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'

我们在这里看到两件重要的事情：

• _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

底部的两行告诉我们 Storage[2] 也是我们调用的一个合约。如果我们查看构造函数交易 (opens in a new tab)，我们会看到这个合约是 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab)，一个封装以太币合约，其源代码已上传到 Etherscan (opens in a new tab)。

所以看起来合约试图将 ETH 发送到 _param2。如果能成功，那很好。如果不成功，它会尝试发送 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... 开头的主题。如果我们点击生成此类条目的其中一笔交易 (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)。