Post #17
163
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, гибридном фаззере, по которому есть отдельная статья в списке литературы, возможно что он отличается от традиционного стейтфул фаззинга)
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, гибридном фаззере, по которому есть отдельная статья в списке литературы, возможно что он отличается от традиционного стейтфул фаззинга)
- ❤ 1
