Как ethereum Opcodes обрабатывают память, вызовы и поток управления
15 июля 2025 г.Таблица ссылок
Аннотация и 1. Введение
Фон
2.1 Ethereum Primer
2.2 Проверка адреса белого списка
2.3 Анализ Taint по интеллектуальным контрактам и 2,4 модели угрозы
Мотивирующий пример и проблемы
3.1 Мотивирующий пример
3.2 Проблемы
3.3 Ограничения существующих инструментов
Дизайн Avverifier и 4.1 Обзор
4.2 обозначения
4.3 Компонент № 1: График кода
4.4 Компонент № 2: симулятор EVM
4.5 Компонент № 3: детектор уязвимости
Оценка
5.1 Экспериментальная настройка и исследовательские вопросы
5.2 RQ1: эффективность и эффективность
5.3 RQ2: характеристики уязвимых контрактов реального мира
5.4 RQ3: обнаружение в реальном времени
Дискуссия
6.1 Угрозы для достоверности и 6.2 ограничения
6.3 Этическое рассмотрение
Связанная работа
Заключение, доступность и ссылки
4.4 Компонент № 2: симулятор EVM
Основываясь на F, передаваемом графством, симулятор отвечает за: 1) поддержание структур данных, необходимых EVM, и 2) обновления информации с уловой. В частности, S состоит из всех контролируемых пользователей переменных, например, происхождения, Calldata и баланса. Для каждого OpCode симулятор определяет набор правил для обновления как структур данных, так и на статической информации. Без потери общности EVM Opcodes классифицируются на четыре категории:кучасвязанныйВнагрузкаИмагазинсвязанныйВвызовсвязанный, иСвязанный с потоком управления.
4.4.1 Связанные стеки ОПКОДЫ
4.4.2 Связанные с загрузкой и хранилищами Opcodes
Как мы упоминали в §2.1, память и хранилище поддерживаются EVM. Данные в них организованы по -разному. В частности, хранилище работает как словарь ключевой стоимости, то есть значения извлекаются с помощью заданного ключа [3]. Что касается памяти, его можно рассматривать как плоский и смежный массив байтов. Доступ к элементу в памяти достигается с помощью рассчитанного смещения. Однако в умных контрактах Ethereum память всегда редкая. Таким образом, мы мотивированы методом, поднятым HE et al. [41], т.е. абстрагирование области памяти в виде пары ключей, где ключ-смещение, а значение-соответствующие данные. С этой целью данные в памяти и смещении могут быть извлечены и индексировать равномерно, какСто[ключ] или мем [компенсировать]
Связанные с нагрузки ОПКОДЫ.Это включает в себя Mload и Sload, то есть нагрузку из памяти или хранилища, соответственно. Оба они берут один аргумент, смолу, то есть целевой адрес и возвращаются в RET, указывая на полученные данные. Правила заряда определяются как:
То есть, если какой -нибудь издольдоилидатиспорчен, окончательный сохраненныйдольдобудет испорчен. При поддержании отношения с порядок зависимости мы рассмотрим только еслидольдозависит отдатПолем Не существует преимущества отдольдокдольдоПолем
4.4.3 Связанные с вызовом ОПКОДЫ
4.4.4 ОПКОДЫ, СПАСИЖАЮЩИЕ ОПИСАНИЕ УПРАВЛЕНИЯ
Согласно спецификации, некоторые из них не принимают аргументы, такие как возврат, остановка, возвращение и недействительную. Следовательно, при моделировании этих инструкций не распространяется ни один из них. Симулятор выполняет только моделирование потока управления на них. Например, когда симулятор сталкивается с неверной инструкцией, она останавливает моделирование текущего пути и перемещается к следующему.
Опыты Jump и Jumpi имеют решающее значение для обработки размножения, поскольку они берут место для прыжка, чтобы явно изменить поток управления, где Jumpi принимает аргумент в качестве условия. Поскольку прыжок можно рассматривать как специальное издание Jumpi, мы демонстрируем обработку на Jumpi в следующем. В частности, Jumpi берет два аргумента, то есть,датикондиционер, ссылаясь на пункт назначения прыжков и условие прыжка, соответственно. Он не возвращает значения и непосредственно выполняет прыжок управления. Для каждого прыжков есть две следующие ветви,ОсеннийипрыжокПолем Первый соответствует последовательному оптовому коду, который выполняется после того, как условие не выполнено, в то время как последний выполняется, когда условие соответствует. Согласно спецификации [66], DEST не должен полагаться на какие -либо аргументы, то есть определяемые статически во время компиляции. Следовательно, в соответствии с тем, определяется ли Cond динамически, симулятор принимает следующие правила:
Есликондиционерэто конкретный номер, либоОсеннийилипрыжоквыбирается симулятором детерминированным.
В противном случае все возможны два пути.
(а) Если предком Cond является CallDataload, расставьте приоритетыпрыжокПуть, то есть,кондиционер= Правда, чтобы подражать злоумышленникам успешно обошли экзамен.
(б) В противном случае это требует двух путей.
Приоритет филиала на шаге 2 (а) является эвристическим. В частности, как только условие испорчено от источника, это означает, что оно полностьюуправляемыйДля злоумышленников, таких как L17 в списке 3, то есть злоумышленники всегда могут обойти утверждение, построив функцию владельца. На уровне Bytecode существует условный прыжок на L17, один из них - L18, связанный с условием MET, другой не отображается в листинге 3, что указывает на сбое требования при L17. Таким образом, эвристика на шаге 2 (а) приоритет филиалам L18, то есть злоумышленникам успешно обходит проверку. По сравнению с символическим исполнением, которое собирает условия пути вдоль симуляции и запрашивает контрольный решатель SMT, чтобы получить конкретный набор решений, преимущества этой эвристики имеют два раза. С одной стороны, сбор условий пути и просьба об решении времени- это время и ресурсы, что является наибольшим узким местом [26]. С другой стороны, символическое выполнение иногда даже не может обрабатывать сложную логику проверки адреса. Например, при обращении с L17 в листинге 3 символический исполнитель должен провести межконтракт-анализ в Ivisor, чтобы получить значение владельца (), которое не может быть завершено в течение приемлемого времени. Хотя шаг 2 (b) может ввести некоторые ложные позитивы, это компромисс между эффективностью и эффективностью. В §5.2 это доказывает свою эффективность и практичность.
Что касается правил размножения, мы должны отметить, что эти опкоды не возвращаются. Более того, они не имеют побочных эффектов как на память, так и на хранение. Таким образом, не размножаются ни один из них.
Авторы:
(1) Tianle Sun, Университет науки и техники Хуажонга;
(2) Ningyu HE, Peking University;
(3) Цзян Сяо, Университет науки и техники Хуажонга;
(4) Yinliang Yue, лаборатория Zhongguancun;
(5) Сяпу Луо, Гонконгский политехнический университет;
(6) Хаою Ван, Университет науки и техники Хуажонга.
Эта статья есть
Оригинал