ERC2612, ERC20Permit, аппрув без газа, EIP712

На канале у Ильи вышел новый интересный урок. Смотрим и учимся.

#erc2612 #permit #approve

ReentrancyGuard в прокси?

Необычный способ реализации ReentrancyGuard предложила одна из команд на мероприятии ETHDenver 2023 Hackathon.

Основной смысл заключается в том, чтобы вместо добавления модификатора ReentrancyGuard в каждую функцию в контракте Логики, создать защиту только в Прокси контракте.

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

Более подробно можно прочитать в этой статье.

Возможно, мы скоро увидим этот концепт в конкурсных аудитах.

#reentrancy #security #proxy

Обновления и патчи Openzeppelin

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

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

#openzeppelin

Больше о побитовых операциях

На днях в одном из конкурсных аудитов встретил следующий код:

function hasBeenDistributed(uint256 _index) public view returns (bool) {

    uint256 distributedWordIndex = _index / 256;
    uint256 distributedBitIndex = _index % 256;
    uint256 distributedWord = distributedBitMap[distributedWordIndex];
    uint256 mask = (1 << distributedBitIndex);

    return distributedWord & mask == mask;
}

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

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

Статьи на английском языке, но время на них стоит потратить, чтобы хорошо разобраться.

Во-первых, читаем эту статью на Медиум.

Потом читаем пост с Solidity Developer. Спасибо @SovaSlava, что показал мне ее.

И в конце, получаем небольшой разбор с операциями со скрина.

Надеюсь, после этого вам, как и мне, станет более понятна логики таких действий.

#bitmap #bit

Интервью с Zach Obront

Недавно вышло интервью с Заком, тем самым аудитором, который вместе с Trust нашел крутой критический баг в сети Optimism.

Мне нравятся подобные истории, так как они показывают, сколько времени человек потратил на свой путь, а также порой можно услышать дельные советы.

В данном интервью больше всего мне понравилось то, как он учился делать аудит и как проводил работу над ошибками. Учитывая то, что он является одним из топовых аудиторов, послушать нужно всем.

Смотрим видео и вдохновляемся!

Приятного просмотра.

#obront

Not So-Famous Solidity Attack Vectors

Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.

Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.

Тем не менее, видео достойное для изучения.

#security #ethdubai

5 стадий обучения аудитора

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

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

Поэтому тут я скорее за разделение профессий. Фокус на чем-то одном, будет быстрее продвигать вас в обучении.

Во-вторых, для себя я определил 5 глобальных стадий обучения аудитора.

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

2. Решение задач. Ethernaut, dvd, CTE и любые другие задачи будут невероятно качественным подспорьем на этой стадии. Тут для аудитора важно будет начать определять участки кода с возможной проблемой и находить варианты взлома.

3. Аудиторские отчеты. Только после того, как вы научитесь решать задачи, стоит преступать к чтению отчетов. Можно брать отчеты с популярных площадок, типа c4, или от профессиональных аудиторов, типа obront. На этом этапе нужно понять, что уязвимости в контрактах выходят за рамки обычных задача. Будет не лишним и самому повторять доказательные тесты в своей ide.

4. Конкурсы. После того, как вы потратите некоторое время на изучение отчетов, можно и самим попробовать зарегистрироваться на конкурсных площадках и начать проводить аудиты. Тут вы научитесь подготавливать проект для аудита, устанавливать его зависимости и писать первые отчеты.

5. Отчеты по своим конкурсным проектам. На этой стадии вы уже читаете отчеты или находки других участников на проектах, которые вы аудировали. Очень важно просматривать каждый отчет внимательно и думать, как вы могли пропустить этот момент, и на что обращать внимание в следующий раз.

Вполне вероятно, чуть позже я добавлю еще пару стадий. Но сейчас я сам на последней из них.

Фокус и практика сделают вас прекрасным специалистом.

#audit

Как читать аудиторские отчеты

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

Есть несколько видов отчетов, которые я разделяю для себя:

1) Отчеты от конкурсных площадок, типа с4 или Шерлок;
2) Отчеты от компаний, типа trail of bits;
3) Отчеты от соло-аудиторов, типа trust;
4) Отчеты по взломам, типа блога Immunefi;

Для каждого из них у меня слегка различный подход цели изучения. Но сначала об общих чертах.

1. Самое главное - не весь отчет (не все баги) иногда можно понять и разобрать. Это абсолютно нормально, если вы не понимаете какой-либо момент или описание уязвимости. Особенно в High Risk разделе.

Очень часто там приводятся примеры уязвимости характерные только для данного проекта и его реализации. И вам потребовалось бы разобрать и усвоить всю кодовую базу протокола, чтобы понять, в чем была суть проблемы.

Смело пропускайте такие описания.

2. Для меня в чтении отчетов важно понимать суть уязвимости. Для этого вы можете завести свою небольшую таблицу, куда записывать баги по разделам: Access control, reentrancy, division, и т.д. И потом добавлять записи туда, например, "забыли поставить модификатор", "из-за того, что деление идет раньше умножения теряется точность" и все в этом духе.

Вы даже можете завести свой канал в Телеграме и скидывать туда пример кода и краткое описание. Для вашего личного обучение - это будет очень хорошо.

3. 99% всех проблем с газом и около 80% low-level популярных уязвимостей можно уместить в список из 50 пунктов. Звучит странно, но так и есть. Вы вполне можете составить свой из отчетов на code4rena и просто выучить его. Это проще, чем кажется. Зато в отчетах вы сможете бегло просматривать эти разделы и обращать внимание только на что-то уникальное.

4. High и Med уязвимости нужно изучать, открывая ссылки с кодом или примером в описании бага. Здесь важно получить "насмотренность" в коде, чтобы научиться определять такие же моменты в других проектах.

5. Обращайте внимание на то, как именно составлены описания уязвимостей, в смысле формат текста: что пишут в "impact", что в "PoC", что в "Recommendation". Это будет важно, когда вам потребуется самим отправлять отчеты. На эту темы позже будет еще один пост.

Теперь пройдемся по различиям в аудиторских отчетах.

1. На конкурсных площадках я обращаю внимание на формат описания уязвимостей, на их подачу. Это сложно объяснить словами, но, прочитав хотя бы по 20 отчетов с code4rena и Шерлока, вы сможете увидеть некоторую разницу. То, что на одной площадке может проходить как Med, на другой пойдет, как High.

2. В "соло" отчетах мне всегда было интересно следить за ходом мысли аудитора. Прочитав отчеты trust, можно начать понимать, на что он обращает внимание и как ведет свой процесс аудита.

3. В разборах уязвимостей от Immunefi мне было интересно те нюансы, из-за которых происходили взломы. Более того, очень часто они выставляют код для теста взлома. Будет очень хорошо, если вы повторите его у себя в Ремиксе или другом ide. Тесты крайне важны в аудите! А Immunefi дают прекрасные примеры!

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

Один-два отчета в день - будет лучшей практикой, чем если бы вы решили "засесть" с ними на несколько часов.

Надеюсь, этот длиннопост поможет вам наладить свой процесс с обучением.

#audit #report

ERC4626: Tokenized vaults

Очередное прекрасное видео от Ильи. Как вы поняли из названия, в этот раз мы поговорим о стандарте ERC4626, какие проблемы он решает и как стоит его использовать в свои проектах.

Приятного просмотра!

#erc4626

Аудитор, продавай свои баги

Написать этот пост меня сподвигла ситуация, которая происходила со мной на площадках code4rena и sherlock. Можно прочитать сотни аудиторских отчетов, понять важные уязвимости и методы их предотвращения, но упустить из виду один важный момент: то, как пишутся сами отчеты.

Поначалу, я думал, что баг есть баг: если ты его нашел, то молодец, получай оплату. Но не тут-то было.

Помимо того, что тебе нужно порой написать доказательные тесты, также очень важно "продать" свой баг в его описании.

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

Тем не менее, его отклонили. Однако этот репорт пометили, как High, а сам аудитор получил $2382.89 USDC, хотя суть проблемы такая же: доступ к функциям для всех.

Другая находка из аудита протокола Kairos, которую отклонили судьи, особо не вникая.

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

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

Для себя я вынес несколько правил по работе с конкурсными площадками, да и в целом, по работе аудитора:

1. Нужно уметь продать свой баг. В одном из интервью на ютуб аудитор сказал, что он сначала находит проблемное место, а потом, грубо говоря, "раздувает" его. Поэтому когда вы находите даже самый маленький баг, нужно описать его максимально "страшно" с приведенными доказательствами и участками кода;

2. Даже если баг валидный, его могут отклонить, просто потому, что судья или другой разработчик не увидят проблемы в нем. Ваша находка может быть единственной в отчете, но не принятой из-за недостаточного описания.

3. Очень часто на конкурсах ставится флажок, что админ \ модератор по-умолчанию хорошие ребята и все связанные с ними бага исключаются. Старайтесь не приплетать админов протокола к ответственности, даже когда проблема напрямую зависит от них. Старайтесь описывать проблему, а не качества админа.

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

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

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

#audit #report

Шаблон для форка и тестов в Foundry

В Твиттере поделились новой библиотекой для простого форка EVM совместимых сетей и написания тестов.

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

#foundry #fork

Honeypot или Jackpot?

Потрясающая задачка из Твиттера! Я не сразу понял, в чем тут дело и пришлось лезть в документацию и Ремикс, чтобы разобраться.

А что вы скажете?

Ответ опубликую чуть позже в комментах.

#task #types

По следам одного теста

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

Просто перечислю некоторые факты:

1) StaticCall не может приводить к изменениям в storage, как это может быть с Call, CallCode и DelegateCall;
2) View и pure не могут порождать события, так как это, по сути, модификация storage;
3) Pure функции не могут читать переменные state;
4) Помимо type(T).min и type(T).max есть еще type(c).name, type(c).creationCode, type(c).runtimeCode, type(i).interfaceId;
5) Конструктор контракта не может принимать calldata как параметр;
6) Комментарии не учитываются в байткоде контракта;

Надеюсь, это однажды поможет вам.

P.S. Если у вас были интересные вопросы на собеседовании, прошу поделиться ими в комментариях. Очень поможете для создания подборки!

#solidity #tips

Немного нового для общего развития

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

Знаете ли вы такие понятия как: Bloom Filter, Intrinsic Gas или Liquidity Bootstrap? Об этом тоже могут спросить на собеседовании...

Начнем с более простого: Liquidity Bootstrap. Об этом можно узнать в небольшой ветке в Твиттере от GabrielGFoo тут.

Далее огромная популярная статья, на которую стоит потратить время What happens when you send 1 DAI. Автор в деталях описывает все внутренние процессы, которые происходят при пересылке токена с одного кошелька на другой. Примечательно то, что он рассказывает и про работу узлов, и про действия валидаторов, и описывает, какие опкоды применяются в той или иной ситуации. Помимо того, что отсюда вы узнаете, что такое Intrinsic Gas, так еще и получите массу другой интересно инфы: например, какой может быть максимальный размер транзакции?

В завершении, можно еще чуть углубиться в работу EVM и узнать про работу Bloom Filter из этой статьи.

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

Бонусом будет изложение Ethereum Yellow Papers в человекопонятном изложении. Там автор убрал достаточно большое количество математических формул и постарался описать все нормальным языком. Если вы не смогли осилить оригинал, то начать с этого будет верным решением.

Приятного изучения!

#yellowpapers #yellow #bloom #bloomfilter #intristic #gas #bootstrap

Заметка по Access List и Transaction types

В статье про пересылку 1 DAI я встретил упоминание стандартов EIP-2930 (Access List) и EIP-2718 (Transaction types).

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

Итак, кратко говоря, ERP-2930 позволяет сэкономить немного газа при вызовах из одного контракта в другой, определяя наперед, какие контракты и слоты памяти будут нужны.

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

С помощью этого EIP, например, вместо холодного обращения стоимостью 2600 газа за Call и 2100 газа SLOAD, транзакция потребует 2400 и 1900 газа за холодный вызов сразу и после только 100 газа за уже теплые обращения.

Что же касается EIP-2718, то вы могли встречать такую строку при формировании транзакции:

0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])

так вот, 0х02 - это и есть один из типов транзакций.

Всего, с новым предложением, их может быть 128 - от 0х00 до 0x7f. Я нашел описание трех:

0х00 - Legacy type, где требовались параметры nonce, gasPrice, gasLimit, to, value, data, v, r, и s.

0х01 - такой же как и legacy, но добавляется accessList из EIP-2930.

0х02 - транзакции представленные во время Лондонского форка с предложением EIP-1559. Пример был выше.

0x03 - в разработке в предложении EIP-4844

P.S. Про другие типы пока не нашел, если у вас есть ссылки про них, буду рад почитать и потом написать пост.

#2930 #2718 #tx #accesslist #access

Немного чисел EVM и Solidity

Максимальный размер транзакции - 124kb.

Максимальный размер контракта - 24kb.

Максимальное кол-во аргументов в функции - 16.

Максимальный размер слота памяти - 32 байта.

Максимальный размер storage - 2**256 слотов.

Максимальный размер stack - 1024.

Максимальное кол-во суб-вывовов в транзакции - 1024.

Максимальное кол-во типов транзакций - 128.

Количество опкодов - 140, максимально - 256.

Последний EIP (на момент поста) - 6913.

Hard limit of type(uint64).max (0xffffffffffffffff) for the free memory pointer.

P.S. Вспомните что-то еще, добавляйте в комментарии.

#numbers

Сборник заметок по Solidity

На некоторых каналах и в чатах промелькнул прекрасный сборник заметок от Chinmaya, который он сам собирал продолжительное время.

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

Для себя я перекинул его в Google документы, чтобы можно было быстро удалять или комментировать некоторые пункты.

В общем, советую всем присмотреться на него: и начинающим разработчикам, и продвинутым аудиторам.

#solidity #hint

Немного вечерней рефлексии

Уже скоро будет год, как я веду данный канал, а посты и обучение все никак не заканчиваются.

Для всех тех, кто хотел выучить Solidity "по быстрому", на курсах за 30 дней или по видео на ютуб за 60 - знайте, это невозможно. Нет, конечно, научиться писать простые контракты можно, как и запустить свой токен или залить NFT на OpenSea, но для чего-то серьезного учиться придется постоянно.

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

Ноябрь - я решил стать аудитором смарт контрактов и проходил популярные CTF, типа Ethernaut, Damn Vulnerable Defi, Capture the Ether и другие.

Декабрь - Углубление в тему безопасности и изучение популярных уязвимостей.

Январь - первый заход на конкурсные площадки. Тогда я понял, что умею писать тесты не так хорошо.

Февраль - обучение написанию тестов на Foundry и изучение основных моментов в проведении аудита.

Март - второй заход на конкурсные площадки. Изучение механик аудита и основных нюансов.

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

Май - сейчас я планирую подтянуть знания для прохождения тестов и собеседований. Как оказалось, нужно знать куда больше "моментов", чтобы устроиться в хорошую зарубежную компанию.

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

Думаете, теперь я много знаю? Много. Но и этого не достаточно для того, чтобы попасть в хорошую зарубежную компанию.

Ну, что же, посмотрим, что будет дальше.

Продолжаем учиться вместе!

#thoughts

RACE #17 Of The Secureum Bootcamp

Недавно прошел очередной тест Race, который достоин обратить на себя внимание начинающих аудиторов.

Во-первых, вы поймете различия в ++i от i++ на примере.

Во-вторых, узнаете чуть больше об одном популярном контракте OZ.

В-третьих, напомните себе о том, как работает approve.

Очень классный тест!

P.S. у меня получилось только два правильных "чистых ответа". Остальные 6 - были и правильней и не правильней ответы в каждом вопросе.

#race #i++

Foundry Safer Log

Небольшая библиотека от Philogy для повышения качества работы с Foundry, а точнее с логированием событий.

По словам Philogy, стандартные настройки Foundry модифицируют память, что порой мешает дебагу low-level assembly в последствии. С данным решением об этом можно не беспокоиться.

P.S. Скоро придется делать пост "Работаем с Foundry: с 0 до pro"!

#foundry #forge