Detecting Functional Bugs in Smart Contract through LLM-powered and Bug-Oriented Compose Analysis
Binbin Zhao, Xingshuang Lin, Yuan Tian, Saman Zonouz, Na Ruan, Jiliang Li, Raheem Beyah, Shouling Ji
2025

Разбор статьи ч.2

Дальше происходит смешение ответов аудитора и атакующего

Для более точной оценки классификации багов по определенным правилам смешиваются ответы агентов. Грубо определенные атакующим первичные категории складываются с подкатегориями от аудитора по следующему алгоритму (рис. 1):
1) Если 𝑡 является подкатегорией 𝑇, подтверждается 𝑡 как тип-кандидат (строка 10-11).
2) В дополнение к подтверждению 𝑡, если 𝑡 принадлежит 𝑇, также включаются все другие подкатегории 𝑇 в качестве типов-кандидатов, чтобы устранить потенциальные дублирования или неоднозначности (строка 10-14).
3) Если 𝑡 не соответствует ни одной подкатегории 𝑇, или если 𝑇 не была идентифицирована, то 𝑡 исключается из числа типов-кандидатов. (строка 17)
4) Если 𝑡 не определен, но определен 𝑇, откладываем классификацию этого сегмента до получения дополнительной информации или проведения дополнительного анализа (строка 3).

Эти потенциальные уязвимости тем не менее нельзя считать точными, поскольку ответы нейросетей в определенной мере случайные.

Генерация чекера инваривантов

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

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

На втором этапе подход заключается в генерации чекеров на основе заранее подготовленных шаблонов. Авторы подготовили 6 шаблонов чекеров инвариантов, которые позволяют интегрировать критичные переменные и логику, извлеченные на первой стадии.


[Подробнее про извлечение переменных и логики]

Во-первых, производится анализ "в глубину" для каждой категории багов, чтобы пометить критичные переменные и действия (операторы, методы, места их первого появления и тд), без которых невозможно собрать бизнес логику. Для примера, если рассматривать манипуляцию ценой оракула, то критичной переменной будет та, которая содержит посчитанную цену LP токена. Характеристики и действия (в оригинале statement), представлены на рис.2

Во-вторых, для выявленных элементов формулируются специальные промпты, которые отправляются в GPT. На изображении 3 показан шаблон для извлечения критических переменных и statement из части кода, потенциально подверженной манипуляции ценой оракула.


[Подробнее про генерацию чекера с использованием шаблона]

Для каждого типа багов были спроектированы соответствующие шаблоны чекеров, которые ориентированы на уязвимые особенности каждого типа багов (рис. 2). Всего было спроектировано 6 видов шаблонов:
- PriceChange_Checker
- ExchangeRate_Checker
- TokenChange_Checker
- StatementOrder_Checker
- ShareSafety_Checker
- StateChange_Cheker

В каждом шаблоне определены условия, которые отслеживают изменения в состоянии контракта. Например в PriceChange_Checker, который создан для определения манипуляции ценой оракула АММ, отслеживается состояние переменной, которая хранит в себе цену LP токена. Если она становится меньше на 90% или больше на 110% старой цены, то это явно говорит о уязвимости.


Далее авторы говорят о том, что получившиеся баг чекеры надо имплементировать. Их предшественники верифицировали найденные баги использованием статических анализаторов кода, которые в часто выдают ложно-позитивные срабатывания (учитывая, что статический анализ - это верхушка айсберга аудита, то надежным я бы это не называл - прим. админа), так что этот метод они применять не захотели.

Предложение их следующее: чекеры инвариантов надо встроить прямо в код, до и после опасных мест. Затем получившийся код предлагается прогнать через stateful fuzzing (авторы говорят, что их метод основан на ItyFuzz, гибридном фаззере, по которому есть отдельная статья в списке литературы, возможно что он отличается от традиционного стейтфул фаззинга)