Обратный инжиниринг контракта

Введение

В блокчейне нет секретов, все, что происходит, последовательно, поддается проверке и общедоступно. В идеале исходный код контрактов должен быть опубликован и верифицирован на 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 для контракта, нажав на вкладку Контракт и затем на Переключиться на вид опкодов. Вы получите представление, в котором на каждой строке находится один опкод.

Однако, чтобы понять переходы, вам нужно знать, где в коде расположен каждый опкод. Один из способов это сделать — открыть Google Таблицу и вставить опкоды в столбец C. Вы можете пропустить следующие шаги, создав копию этой уже подготовленной таблицы (opens in a new tab).

Следующий шаг — получить правильные местоположения в коде, чтобы мы могли понимать переходы. Мы поместим размер опкода в столбец B, а местоположение (в шестнадцатеричном формате) в столбец A. Введите эту функцию в ячейку B1, а затем скопируйте и вставьте ее в остальные ячейки столбца B до конца кода. После этого вы можете скрыть столбец B.

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

Сначала эта функция добавляет один байт для самого опкода, а затем ищет PUSH. Опкоды Push особенные, потому что им требуются дополнительные байты для значения, которое помещается в стек. Если опкод является PUSH, мы извлекаем количество байт и добавляем его.

В A1 укажите первое смещение, ноль. Затем в A2 введите эту функцию и снова скопируйте и вставьте ее в остальные ячейки столбца A:

1=dec2hex(hex2dec(A1)+B1)

Нам нужна эта функция для получения шестнадцатеричного значения, потому что значения, помещаемые в стек перед переходами (JUMP и JUMPI), даны нам в шестнадцатеричном формате.

Точка входа (0x00)

Исполнение контрактов всегда начинается с первого байта. Это начальная часть кода:

Этот код делает две вещи:

1. Записывает 0x80 как 32-байтное значение в ячейки памяти 0x40–0x5F (0x80 сохраняется в 0x5F, а 0x40–0x5E — все нули).
2. Считывает размер данных вызова (calldata). Обычно данные вызова для контракта Ethereum соответствуют ABI (двоичному интерфейсу приложения) (opens in a new tab), для которого требуется как минимум четыре байта для селектора функции. Если размер данных вызова меньше четырех, происходит переход к 0x5E.

Обработчик в 0x5E (для данных вызова не по ABI)

Этот фрагмент начинается с JUMPDEST. Программы EVM (виртуальной машины Ethereum) вызывают исключение, если вы переходите к опкоду, который не является JUMPDEST. Затем он смотрит на CALLDATASIZE, и если он «истинный» (то есть не нулевой), переходит к 0x7C. Мы вернемся к этому ниже.

Итак, когда нет данных вызова, мы считываем значение из Storage[6]. Мы еще не знаем, что это за значение, но мы можем поискать транзакции, которые контракт получил без данных вызова. Транзакции, которые просто переводят ETH без каких-либо данных вызова (и, следовательно, без метода), в Etherscan имеют метод Transfer. На самом деле, самая первая транзакция, которую получил контракт (opens in a new tab), — это перевод.

Если мы посмотрим на эту транзакцию и нажмем Щелкните, чтобы увидеть больше, мы увидим, что данные вызова, называемые входными данными, действительно пусты (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 бит, длины адреса Ethereum.

Этот переход является излишним, так как мы переходим к следующему опкоду. Этот код далеко не так эффективен с точки зрения расхода газа, как мог бы быть.

В самом начале кода мы установили Mem[0x40] в 0x80. Если мы посмотрим на 0x40 позже, то увидим, что мы его не меняем, поэтому можно предположить, что это 0x80.

Скопируйте все данные вызова в память, начиная с 0x80.

Теперь все стало намного яснее. Этот контракт может действовать как прокси (opens in a new tab), вызывая адрес в Storage[3] для выполнения реальной работы. DELEGATE_CALL вызывает отдельный контракт, но остается в том же хранилище. Это означает, что делегированный контракт, для которого мы являемся прокси, получает доступ к тому же пространству хранилища. Параметры вызова:

• Газ: весь оставшийся газ
• Вызываемый адрес: Storage[3]-as-address
• Данные вызова: байты CALLDATASIZE, начинающиеся с 0x80, куда мы поместили исходные данные вызова
• Возвращаемые данные: нет (0x00 - 0x00) Мы получим возвращаемые данные другими способами (см. ниже)

Здесь мы копируем все возвращаемые данные в буфер памяти, начиная с 0x80.

Таким образом, после вызова мы копируем возвращаемые данные в буфер 0x80 - 0x80+RETURNDATASIZE, и если вызов успешен, мы затем выполняем RETURN с этим же буфером.

Ошибка DELEGATECALL

Если мы попадаем сюда, в 0xC0, это означает, что вызванный нами контракт был отменен. Поскольку мы являемся лишь прокси для этого контракта, мы хотим вернуть те же данные и также выполнить откат.

Итак, мы выполняем REVERT с тем же буфером, который использовали для RETURN ранее: 0x80 - 0x80+RETURNDATASIZE

Вызовы ABI

Если размер данных вызова составляет четыре байта или более, это может быть действительный вызов ABI.

Etherscan сообщает нам, что 1C — это неизвестный опкод, потому что он был добавлен после того, как Etherscan написал эту функцию (opens in a new tab), и они ее еще не обновили. Актуальная таблица опкодов (opens in a new tab) показывает нам, что это сдвиг вправо.

Разделение тестов на соответствие сигнатуры метода на две части таким образом экономит в среднем половину тестов. Код, который следует сразу за этим, и код в 0x43 следуют одному и тому же шаблону: DUP1 первые 32 бита данных вызова, PUSH4 (((сигнатура метода))), запуск 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) и заставляет контракт выполнить RETURN с буфером, равным 0x80 - X.

В случае splitter() это возвращает адрес, для которого мы являемся прокси. RETURN возвращает буфер в 0x80-0x9F, куда мы и записали эти данные (смещение 0x130 выше).

currentWindow()

Код в смещениях 0x158-0x163 идентичен тому, что мы видели в 0x103-0x10E в splitter() (за исключением адреса назначения JUMPI), поэтому мы знаем, что currentWindow() также не является payable.

Код DA

Этот код также используется совместно с другими методами. Поэтому мы назовем значение в стеке Y и просто запомним, что в currentWindow() значение Y равно Storage[1].

Запишите Y в 0x80-0x9F.

А остальное уже объяснено выше. Таким образом, переходы к 0xDA записывают верхний элемент стека (Y) в 0x80-0x9F и возвращают это значение. В случае currentWindow() возвращается Storage[1].

merkleRoot()

Код в смещениях 0xED-0xF8 идентичен тому, что мы видели в 0x103-0x10E в splitter() (за исключением адреса назначения JUMPI), поэтому мы знаем, что merkleRoot() также не является payable.

Что происходит после прыжка, мы уже выяснили. Таким образом, merkleRoot() возвращает Storage[0].

0x81e580d3

Код в смещениях 0x138-0x143 идентичен тому, что мы видели в 0x103-0x10E в splitter() (за исключением адреса назначения JUMPI), поэтому мы знаем, что эта функция также не является payable.

Похоже, эта функция принимает по меньшей мере 32 байта (одно слово) данных вызова.

Если она не получает данные вызова, транзакция отменяется без каких-либо возвращаемых данных.

Давайте посмотрим, что произойдет, если функция получит необходимые ей данные вызова.

calldataload(4) — это первое слово данных вызова после сигнатуры метода

Если первое слово не меньше, чем Storage[4], функция завершается с ошибкой. Она отменяется без какого-либо возвращаемого значения:

Если calldataload(4) меньше, чем Storage[4], мы получаем этот код:

И ячейки памяти 0x00-0x1F теперь содержат данные 0x04 (0x00-0x1E — все нули, 0x1F — четыре)

Таким образом, в хранилище есть таблица поиска, которая начинается с SHA3 от 0x000...0004 и имеет запись для каждого легитимного значения данных вызова (значение ниже Storage[4]).

Мы уже знаем, что делает код по смещению 0xDA, он возвращает значение из вершины стека вызывающему. Таким образом, эта функция возвращает значение из таблицы поиска вызывающему.

0x1f135823

Код в смещениях 0xC4-0xCF идентичен тому, что мы видели в 0x103-0x10E в splitter() (за исключением адреса назначения JUMPI), поэтому мы знаем, что эта функция также не является payable.

Мы уже знаем, что делает код по смещению 0xDA, он возвращает значение из вершины стека вызывающему. Таким образом, эта функция возвращает Value*.

Сводка методов

Чувствуете ли вы, что понимаете контракт на этом этапе? Я — нет. Пока что у нас есть следующие методы:

Но мы знаем, что любая другая функциональность предоставляется контрактом в Storage[3]. Возможно, если бы мы знали, что это за контракт, это дало бы нам подсказку. К счастью, это блокчейн, и здесь все известно, по крайней мере, в теории. Мы не видели методов, которые устанавливают Storage[3], поэтому он, должно быть, был установлен конструктором.

Конструктор

Когда мы смотрим на контракт (opens in a new tab), мы также можем видеть транзакцию, которая его создала.

Если мы щелкнем по этой транзакции, а затем по вкладке State, мы сможем увидеть начальные значения параметров. В частности, мы видим, что Storage[3] содержит 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab). Этот контракт должен содержать недостающую функциональность. Мы можем понять его, используя те же инструменты, что и для исследуемого контракта.

Прокси-контракт

Используя те же методы, что и для исходного контракта выше, мы можем видеть, что контракт отменяется, если:

• К вызову прикреплен какой-либо ETH (0x05-0x0F)
• Размер данных вызова меньше четырех (0x10-0x19 и 0xBE-0xC2)

И что поддерживаемые им методы:

Мы можем игнорировать четыре нижних метода, потому что мы никогда до них не дойдем. Их сигнатуры таковы, что наш исходный контракт обрабатывает их самостоятельно (вы можете щелкнуть по сигнатурам, чтобы увидеть детали выше), поэтому они должны быть переопределенными методами (opens in a new tab).

Один из оставшихся методов — claim(<params>), а другой — isClaimed(<params>), так что это похоже на контракт для аирдропа. Вместо того чтобы проходить через остальные опкоды по одному, мы можем попробовать декомпилятор (opens in a new tab), который дает пригодные для использования результаты для трех функций из этого контракта. Обратный инжиниринг остальных оставляется в качестве упражнения для читателя.

scaleAmountByPercentage

Вот что декомпилятор выдает для этой функции:

1def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
2  require calldata.size - 4 >=′ 64
3  if _param1 and _param2 > -1 / _param1:
4      revert with 0, 17
5  return (_param1 * _param2 / 100 * 10^6)
Копировать

Первое требование require проверяет, что данные вызова, помимо четырех байтов сигнатуры функции, содержат не менее 64 байтов, что достаточно для двух параметров. Если нет, то очевидно, что что-то не так.

Оператор if, по-видимому, проверяет, что _param1 не равен нулю, и что _param1 * _param2 не является отрицательным. Вероятно, это сделано для предотвращения случаев переполнения.

Наконец, функция возвращает масштабированное значение.

claim

Код, создаваемый декомпилятором, сложен, и не весь он имеет для нас значение. Я пропущу некоторые его части, чтобы сосредоточиться на строках, которые, по моему мнению, содержат полезную информацию.

1def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
2  ...
3  require _param2 == addr(_param2)
4  ...
5  if currentWindow <= _param1:
6      revert with 0, 'cannot claim for a future window'
Копировать

Здесь мы видим две важные вещи:

• _param2, хотя он объявлен как uint256, на самом деле является адресом.
• _param1 — это окно, на которое подается заявка, и оно должно быть currentWindow или раньше.

1  ...
2  if stor5[_claimWindow][addr(_claimFor)]:
3      revert with 0, 'Account already claimed the given window'
Копировать

Итак, теперь мы знаем, что Storage[5] — это массив окон и адресов, и в нем хранится информация о том, получил ли адрес вознаграждение за это окно.

1  ...
2  idx = 0
3  s = 0
4  while idx < _param4.length:
5  ...
6      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
7          mem[mem[64] + 32] = mem[(32 * idx) + 296]
8          ...
9          s = sha3(mem[_62 + 32 len mem[_62]])
10          continue
11      ...
12      s = sha3(mem[_66 + 32 len mem[_66]])
13      continue
14  if unknown2eb4a7ab != s:
15      revert with 0, 'Invalid proof'
Показать все
Копировать

Мы знаем, что unknown2eb4a7ab на самом деле является функцией merkleRoot(), поэтому этот код, похоже, проверяет доказательство Меркла (opens in a new tab). Это означает, что _param4 является доказательством Меркла.

1  call addr(_param2) with:
2     value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
3       gas 30000 wei
Копировать

Именно так контракт переводит свои собственные ETH на другой адрес (контракт или внешний счет). Он вызывает его со значением, равным сумме для перевода. Так что похоже, это аирдроп ETH.

1  if not return_data.size:
2      if not ext_call.success:
3          require ext_code.size(stor2)
4          call stor2.deposit() with:
5             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, и контракты не могут отказаться от его приема.

1  ...
2  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 первому и создает тот же тип записи в журнале.

1def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
2  ...
3  idx = 0
4  s = 0
5  while idx < _param3.length:
6      if idx >= mem[96]:
7          revert with 0, 50
8      _55 = mem[(32 * idx) + 128]
9      if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
10          ...
11          s = sha3(mem[_58 + 32 len mem[_58]])
12          continue
13      mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
14  ...
15  if unknown2eb4a7ab != s:
16      revert with 0, 'Invalid proof'
17  ...
18  call addr(_param1) with:
19     value s wei
20       gas 30000 wei
21  if not return_data.size:
22      if not ext_call.success:
23          require ext_code.size(stor2)
24          call stor2.deposit() with:
25             value s wei
26               gas gas_remaining wei
27  ...
28  log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
Показать все
Копировать

Основное отличие в том, что первый параметр, окно для вывода средств, отсутствует. Вместо этого есть цикл по всем окнам, которые можно было бы затребовать.

1  idx = 0
2  s = 0
3  while idx < currentWindow:
4      ...
5      if stor5[mem[0]]:
6          if idx == -1:
7              revert with 0, 17
8          idx = idx + 1
9          s = s
10          continue
11      ...
12      stor5[idx][addr(_param1)] = 1
13      if idx >= unknown81e580d3.length:
14          revert with 0, 50
15      mem[0] = 4
16      if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
17          revert with 0, 17
18      if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
19          revert with 0, 17
20      if idx == -1:
21          revert with 0, 17
22      idx = idx + 1
23      s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
24      continue
Показать все
Копировать

Так что это похоже на вариант claim, который запрашивает все окна.

Заключение

К настоящему моменту вы должны знать, как понимать контракты, исходный код которых недоступен, используя либо опкоды, либо (когда это работает) декомпилятор. Как видно из длины этой статьи, обратный инжиниринг контракта — нетривиальная задача, но в системе, где безопасность имеет первостепенное значение, умение проверять, что контракты работают, как обещано, является важным навыком.

Больше моих работ смотрите здесь (opens in a new tab).

Последнее обновление страницы: 22 августа 2025 г.

q (opens in a new tab)

b (opens in a new tab)

p (opens in a new tab)

+7

Посмотреть участников