The File Pattern
Понравилась одна статья на Mirror, где автор рассказывает про необычный паттерн, который замел в одном из аудиторских контрактов.
Сам пост довольно подробный с примерами, поэтому тут я обозначу общую идею.
Вместо того, чтобы создавать кучу разных event и порождать однотипные события в ключевых функциях, предлагается создать некий общий шаблон для порождения событий, который может быть использован между разными наследуемыми контрактами.
После первого прочтения, возможно, часть будет не понятна, советую в своем файле / проекте это повторить для большей наглядности.
#hint #event #file
Понравилась одна статья на Mirror, где автор рассказывает про необычный паттерн, который замел в одном из аудиторских контрактов.
Сам пост довольно подробный с примерами, поэтому тут я обозначу общую идею.
Вместо того, чтобы создавать кучу разных event и порождать однотипные события в ключевых функциях, предлагается создать некий общий шаблон для порождения событий, который может быть использован между разными наследуемыми контрактами.
После первого прочтения, возможно, часть будет не понятна, советую в своем файле / проекте это повторить для большей наглядности.
#hint #event #file
❤2👍2
Сводный пост про биржи
На прошлой неделе я хотел разобраться, как работают современные биржи, и сделал пару постов про Uniswap (V1, V2, V3), что дало мне достаточно много базовой информации.
Дальше, все выходные, понедельник и вторник, я смотрел статьи и видео о работе других бирж: Compound, Aave, Curve, Tornado Cash, dYdX, Balancer и пары других. И знаете что? Не смотря на некоторые различия и тонкости реализации кода, идеи и смысл практических всех один и тот же. Хотя, чего я ожидал...
Сначала я искал их контракты на GitHub. Но с ходу было немного сложно разобраться, что к чему. Поэтому я решил посмотреть видео о том, как вообще работают эти биржи, как используют их код в пользовательских проектах, на чем основываются расчеты пулов и с чего все это начиналось.
И вот на пятый день, у меня уже сложилась некоторая картина работы большинства бирж.
Я напишу список тем, на которые следует обратить внимание, чтобы вам было проще понимать исходных код самих бирж.
Итак, что же стоит освоить в первую очередь:
1) Формирование цены в пулах;
2) Добавление ликвидности, расчет ее пропорций при добавлении;
3) Вывод ликвидности: условия и ограничения;
4) Что такое collateral;
5) Что такое over collateralized и under collateralized;
6) Что такое flashloan;
7) Что такое loan;
8) Что такое flash swap;
9) Как работают callbacks в swap / mint / borrow;
10) Как работает возврат займов;
11) Что такое ликвидация займа;
12) Что такое аукцион ликвидации займа;
13) Как работают collateral токены;
14) Как работают DAO токены;
15) Процент DAO токенов для проведения голосования;
16) Как работают reward токены?
17) Как работает средняя цена и оракулы?
18) Как работают функции collect fees;
Когда вы сможете ответить для себя на все эти вопросы, можно будет сказать, что "первое касание" с биржами прошло удачно и дальше можно уже вникать в работу самих смарт контрактов.
Больше всего мне помог поиск в Youtube по запросу: "Как работает биржа..." (How compound works), а также следующие плейлисты:
Плейлист 1, плейлист 2.
Повторюсь, что после этого вы не станете экспертами по биржам, а всего лишь начнете разбираться в базовых аспектах их работы.
Далее приведу ссылки на GitHub репо некоторых бирж:
Compound v2, compound v3, curve (vyper), aave core, Tornado cash, Balancer
При рассмотрении данных проектов советую обращать внимание, как сформирован сам проект, расположение и наименование файлов. Это пригодиться в будущем, когда вы начнете проводить аудиты и будете видеть некоторые "схожести" проектов, так как очень часто новые сервисы просто копируют контракты данных бирж.
В последующих постах про биржи, по мере своего обучения, я уже буду описывать какие-либо точечные моменты, поэтому рекомендую вам просмотреть все видео из плейлистов, чтобы понимать, о чем будет идти речь.
#compound #curve #aave #balancer #tornado
На прошлой неделе я хотел разобраться, как работают современные биржи, и сделал пару постов про Uniswap (V1, V2, V3), что дало мне достаточно много базовой информации.
Дальше, все выходные, понедельник и вторник, я смотрел статьи и видео о работе других бирж: Compound, Aave, Curve, Tornado Cash, dYdX, Balancer и пары других. И знаете что? Не смотря на некоторые различия и тонкости реализации кода, идеи и смысл практических всех один и тот же. Хотя, чего я ожидал...
Сначала я искал их контракты на GitHub. Но с ходу было немного сложно разобраться, что к чему. Поэтому я решил посмотреть видео о том, как вообще работают эти биржи, как используют их код в пользовательских проектах, на чем основываются расчеты пулов и с чего все это начиналось.
И вот на пятый день, у меня уже сложилась некоторая картина работы большинства бирж.
Я напишу список тем, на которые следует обратить внимание, чтобы вам было проще понимать исходных код самих бирж.
Итак, что же стоит освоить в первую очередь:
1) Формирование цены в пулах;
2) Добавление ликвидности, расчет ее пропорций при добавлении;
3) Вывод ликвидности: условия и ограничения;
4) Что такое collateral;
5) Что такое over collateralized и under collateralized;
6) Что такое flashloan;
7) Что такое loan;
8) Что такое flash swap;
9) Как работают callbacks в swap / mint / borrow;
10) Как работает возврат займов;
11) Что такое ликвидация займа;
12) Что такое аукцион ликвидации займа;
13) Как работают collateral токены;
14) Как работают DAO токены;
15) Процент DAO токенов для проведения голосования;
16) Как работают reward токены?
17) Как работает средняя цена и оракулы?
18) Как работают функции collect fees;
Когда вы сможете ответить для себя на все эти вопросы, можно будет сказать, что "первое касание" с биржами прошло удачно и дальше можно уже вникать в работу самих смарт контрактов.
Больше всего мне помог поиск в Youtube по запросу: "Как работает биржа..." (How compound works), а также следующие плейлисты:
Плейлист 1, плейлист 2.
Повторюсь, что после этого вы не станете экспертами по биржам, а всего лишь начнете разбираться в базовых аспектах их работы.
Далее приведу ссылки на GitHub репо некоторых бирж:
Compound v2, compound v3, curve (vyper), aave core, Tornado cash, Balancer
При рассмотрении данных проектов советую обращать внимание, как сформирован сам проект, расположение и наименование файлов. Это пригодиться в будущем, когда вы начнете проводить аудиты и будете видеть некоторые "схожести" проектов, так как очень часто новые сервисы просто копируют контракты данных бирж.
В последующих постах про биржи, по мере своего обучения, я уже буду описывать какие-либо точечные моменты, поэтому рекомендую вам просмотреть все видео из плейлистов, чтобы понимать, о чем будет идти речь.
#compound #curve #aave #balancer #tornado
👍12❤5
Storage Structs
Еще одна потрясающая статья от автора The File Pattern, в которой он разбирает вопрос использования структур для хранения данных при использовании прокси контрактов.
Статья мне приглянулась еще тем, что я сам участвовал в конкурсных аудитах Astaria и Drips. Тогда я хоть и понял, что данные берутся из определённого слота, но не понимал зачем это сделано.
В общем, тут рассказывается о том, что в обновляемых контрактах часто встречается проблема коллизии данных в слотах памяти, а также случайной обновление переменных.
Этот паттерн предлагает создавать структуру данных (struct) и помещать ее в слот "далеко" в памяти при помощи формулы EIP-1967, о которой писалось выше.
В статье приводятся примеры использовании в реальных контрактах, а также некоторые проблемы, которые могут возникнуть.
Прочитать статью будет полезно не только аудиторам, но и разработчикам, которые хотят повысить свои скиллы.
#storage #eip1967 #struct
Еще одна потрясающая статья от автора The File Pattern, в которой он разбирает вопрос использования структур для хранения данных при использовании прокси контрактов.
Статья мне приглянулась еще тем, что я сам участвовал в конкурсных аудитах Astaria и Drips. Тогда я хоть и понял, что данные берутся из определённого слота, но не понимал зачем это сделано.
В общем, тут рассказывается о том, что в обновляемых контрактах часто встречается проблема коллизии данных в слотах памяти, а также случайной обновление переменных.
Этот паттерн предлагает создавать структуру данных (struct) и помещать ее в слот "далеко" в памяти при помощи формулы EIP-1967, о которой писалось выше.
В статье приводятся примеры использовании в реальных контрактах, а также некоторые проблемы, которые могут возникнуть.
Прочитать статью будет полезно не только аудиторам, но и разработчикам, которые хотят повысить свои скиллы.
#storage #eip1967 #struct
❤2👍1
Проверка покрытия тестами
Только для пользователей Linux, как я понял, есть новый инструмент для проверки покрытия тестами какого-либо контракта с использованием команды forge coverage.
Самое интересное в нем, что вам в файле контракта будут подсвечиваться строки, для которых уже были написаны тесты и те, которые пропустили. Пример на скрине.
В этой статье можно почитать про настройку и проведение тестов.
#linux #coverage #forge #foundry
Только для пользователей Linux, как я понял, есть новый инструмент для проверки покрытия тестами какого-либо контракта с использованием команды forge coverage.
Самое интересное в нем, что вам в файле контракта будут подсвечиваться строки, для которых уже были написаны тесты и те, которые пропустили. Пример на скрине.
В этой статье можно почитать про настройку и проведение тестов.
#linux #coverage #forge #foundry
❤4
Подборка проектов с новостями
Встретил на просторах Твиттера прекрасную подборку проектов, которые пишут статьи или делают новостную рассылку о последних взломах и вопросах безопасности в блокчейне.
Secureum
Blockchain Threat Intelligence
Week in Ethereum News
NotOnlyOwner
Vulnerability Research by Samczsun
Noxx
Faith's Blog
Cygaar’s Substack
Rekt
DeFiHackLabs’s Substack
Если вас не раздражают емайл рассылки, то эти будут как нельзя кстати!
#email #security #news
Встретил на просторах Твиттера прекрасную подборку проектов, которые пишут статьи или делают новостную рассылку о последних взломах и вопросах безопасности в блокчейне.
Secureum
Blockchain Threat Intelligence
Week in Ethereum News
NotOnlyOwner
Vulnerability Research by Samczsun
Noxx
Faith's Blog
Cygaar’s Substack
Rekt
DeFiHackLabs’s Substack
Если вас не раздражают емайл рассылки, то эти будут как нельзя кстати!
#email #security #news
👍5🔥2❤1
Необычный тест для участников
Недавно в Дискорде нашел интересные тесты, которые проводятся один-два раза в год хорошо известной всем компанией. Посмотрев последний из них, я решил пройти их все.
Предлагаю и вам пройти их вместе со мной. Если узнали, откуда они, то не рассказывайте никому. В этот раз попробуем сами.
Ответы пишем в комментариях с функцией "спойлер" (на телефонах в приложении выделить текст, нажать на три точки в правом вернем углу и выбрать опцию Спойлер. На компьютере: выделить текст, нажать правую кнопку мыши и выбрать опцию Спойлер).
Ответы я напишу в конце дня также в комментариях.
Для просмотра контракта вам потребуется скачать файл выше.
1. В данном контракте:
а) Не стандартное значение decimals;
б) Не стандартные decreaseAllowance и increaseAllowance;
в) Не стандартный transfer;
г) Ничего из перечисленного;
2. В данном контракте:
а) decimals() могут быть pure вместо view;
б) _burn() может быть external вместо internal;
в) _mint() должен быть internal вместо external;
г) Ничего из перечисленного;
3. В функции transferFrom():
а) Есть вероятность integer underflow;
б) Не правильная проверка allowance;
в) Есть вероятность неограниченных approvals;
г) Ничего из перечисленного;
4. В данном контракте:
а) В increaseAllowance есть вероятность integer overflow;
б) В decreaseAllowance есть вероятность integer overflow;
в) В decreaseAllowance не возможно нулевой allowance;
г) decreaseAllowance может быть оптимизирован с unchecked{};
5. В функции _transfer():
а) Отсутствует проверка на нулевой адрес;
б) Есть вероятность integer overflow;
в) Есть вероятность integer overflow;
г) Ничего из перечисленного;
6. В функции _mint():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
7. В функции _burn():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
8. В функции _approve():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное сообщение об ошибке;
в) Не правильное обновление allowance аккаунта;
г) Ничего из перечисленного;
Первый тест довольно простой и больше на внимательность. Дальше будет интереснее.
#test
Недавно в Дискорде нашел интересные тесты, которые проводятся один-два раза в год хорошо известной всем компанией. Посмотрев последний из них, я решил пройти их все.
Предлагаю и вам пройти их вместе со мной. Если узнали, откуда они, то не рассказывайте никому. В этот раз попробуем сами.
Ответы пишем в комментариях с функцией "спойлер" (на телефонах в приложении выделить текст, нажать на три точки в правом вернем углу и выбрать опцию Спойлер. На компьютере: выделить текст, нажать правую кнопку мыши и выбрать опцию Спойлер).
Ответы я напишу в конце дня также в комментариях.
Для просмотра контракта вам потребуется скачать файл выше.
1. В данном контракте:
а) Не стандартное значение decimals;
б) Не стандартные decreaseAllowance и increaseAllowance;
в) Не стандартный transfer;
г) Ничего из перечисленного;
2. В данном контракте:
а) decimals() могут быть pure вместо view;
б) _burn() может быть external вместо internal;
в) _mint() должен быть internal вместо external;
г) Ничего из перечисленного;
3. В функции transferFrom():
а) Есть вероятность integer underflow;
б) Не правильная проверка allowance;
в) Есть вероятность неограниченных approvals;
г) Ничего из перечисленного;
4. В данном контракте:
а) В increaseAllowance есть вероятность integer overflow;
б) В decreaseAllowance есть вероятность integer overflow;
в) В decreaseAllowance не возможно нулевой allowance;
г) decreaseAllowance может быть оптимизирован с unchecked{};
5. В функции _transfer():
а) Отсутствует проверка на нулевой адрес;
б) Есть вероятность integer overflow;
в) Есть вероятность integer overflow;
г) Ничего из перечисленного;
6. В функции _mint():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
7. В функции _burn():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
8. В функции _approve():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное сообщение об ошибке;
в) Не правильное обновление allowance аккаунта;
г) Ничего из перечисленного;
Первый тест довольно простой и больше на внимательность. Дальше будет интереснее.
#test
🔥5❤1
Немного о переменных
В смарт контракте можно указать только 16 локальных переменных. Если их будет больше, то возникнет ошибка StackTooDeepException. Для того, чтобы избежать этого можно использовать так называемые block scoping.
Вообще, scope в Solidity это область видимости, которых, как мы знаем, может быть четыре: internal, external, private, public.
А block scoping - это такая техника, которая позволяет создать новый scope внутри функции, чтобы сократить число локальных переменных в стеке функции.
На скрине выше вы можете увидеть пример block scoping.
Переменные указанные в фигурных скобках не будут доступны для действий внутри функции вне блока, однако в самом блоке можно использовать переменные функции, например, для каких-либо расчетов.
Чуть больше об этом можно прочитать в официальной документации Solidity, а реальный пример посмотреть тут, в контракте Uniswap.
#variable
В смарт контракте можно указать только 16 локальных переменных. Если их будет больше, то возникнет ошибка StackTooDeepException. Для того, чтобы избежать этого можно использовать так называемые block scoping.
Вообще, scope в Solidity это область видимости, которых, как мы знаем, может быть четыре: internal, external, private, public.
А block scoping - это такая техника, которая позволяет создать новый scope внутри функции, чтобы сократить число локальных переменных в стеке функции.
На скрине выше вы можете увидеть пример block scoping.
Переменные указанные в фигурных скобках не будут доступны для действий внутри функции вне блока, однако в самом блоке можно использовать переменные функции, например, для каких-либо расчетов.
Чуть больше об этом можно прочитать в официальной документации Solidity, а реальный пример посмотреть тут, в контракте Uniswap.
#variable
👍6❤4🔥1
Тест 2 (ERC-1155)
Предлагаю к вниманию второй тест для самостоятельной проверки. На этот раз для разбора стандарта ERC-1155.
Вообще, сегодня я выложу 3 поста для проверки своих знаний: текущий тест, пример экзамена для аудитора и контракты из реального собеседования, где нужно будет найти все возможные ошибки.
На выходных вы сможете в спокойной обстановке проверить свои знания.
Итак, вопросы для второго теста. Сам контракт можно скачать выше.
1. В данном контракте функция balanceOf():
а) Может быть оптимизирована кэшированием переменной состояния в локальную переменную;
б) Может быть оптимизирована изменением с view на pure;
в) Может быть оптимизирована изменением на external;
г) Ничего из перечисленного;
2. В данном контракте проверка array lengths mismatch отсутствует в функциях:
а) balanceOfBatch();
б) _safeBatchTransferFrom();
в) _mintBatch();
г) _burnBatch();
3. Проблемы в безопасности функции _safeTransferFrom():
а) Не правильная область видимости;
б) Возможность integer underflow;
в) Отсутствие проверки на нулевой адрес;
г) Ничего из перечисленного;
4. Проблемы в безопасности функции _safeBatchTransferFrom():
а) Отсутствие проверки array lengths mismatch;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
5. Проблемы в безопасности функции _mintBatch():
а) Отсутствие проверки array lengths mismatch;
б) Не правильное порождение события;
в) Возможность сжигания токенов;
г) Ничего из перечисленного;
6. Проблемы в безопасности функции _burn():
а) Отсутствие проверки на нулевой адрес;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
7. Проблемы в безопасности функции _doSafeTransferAcceptanceCheck():
а) Не правильная проверка адреса в isContract;
б) Не правильная проверка значения return;
в) Не правильй call вызов в isContract;
г) Ничего из перечисленного;
8. Проблемы в безопасности функции isContract():
а) Не правильная видимость;
б) Не правильный оператор сравнения;
в) Проблем нет, так как в Ethereum есть только адреса контрактов;
г) Ничего из перечисленного;
Как обычно ответы для этого теста выложу в конце дня.
Свои ответы вы можете писать в комментариях, но под функцией "Спойлер".
#test
Предлагаю к вниманию второй тест для самостоятельной проверки. На этот раз для разбора стандарта ERC-1155.
Вообще, сегодня я выложу 3 поста для проверки своих знаний: текущий тест, пример экзамена для аудитора и контракты из реального собеседования, где нужно будет найти все возможные ошибки.
На выходных вы сможете в спокойной обстановке проверить свои знания.
Итак, вопросы для второго теста. Сам контракт можно скачать выше.
1. В данном контракте функция balanceOf():
а) Может быть оптимизирована кэшированием переменной состояния в локальную переменную;
б) Может быть оптимизирована изменением с view на pure;
в) Может быть оптимизирована изменением на external;
г) Ничего из перечисленного;
2. В данном контракте проверка array lengths mismatch отсутствует в функциях:
а) balanceOfBatch();
б) _safeBatchTransferFrom();
в) _mintBatch();
г) _burnBatch();
3. Проблемы в безопасности функции _safeTransferFrom():
а) Не правильная область видимости;
б) Возможность integer underflow;
в) Отсутствие проверки на нулевой адрес;
г) Ничего из перечисленного;
4. Проблемы в безопасности функции _safeBatchTransferFrom():
а) Отсутствие проверки array lengths mismatch;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
5. Проблемы в безопасности функции _mintBatch():
а) Отсутствие проверки array lengths mismatch;
б) Не правильное порождение события;
в) Возможность сжигания токенов;
г) Ничего из перечисленного;
6. Проблемы в безопасности функции _burn():
а) Отсутствие проверки на нулевой адрес;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
7. Проблемы в безопасности функции _doSafeTransferAcceptanceCheck():
а) Не правильная проверка адреса в isContract;
б) Не правильная проверка значения return;
в) Не правильй call вызов в isContract;
г) Ничего из перечисленного;
8. Проблемы в безопасности функции isContract():
а) Не правильная видимость;
б) Не правильный оператор сравнения;
в) Проблем нет, так как в Ethereum есть только адреса контрактов;
г) Ничего из перечисленного;
Как обычно ответы для этого теста выложу в конце дня.
Свои ответы вы можете писать в комментариях, но под функцией "Спойлер".
#test
👍2❤1
Экзамен для аудитора
В Дискорд сообществе Solidity Lab есть интересный мини экзамен для проверки навыков аудитора. Состоит всего из нескольких вопросов, но на выполнение отводится 1 час 20 минут.
Предлагаю и вам попробовать свои силы. При этом, если вы не состоите в сообществе, то НЕ ОТПРАВЛЯЙТЕ ФОРМУ! Посмотрите задания, решите их за отведенное время.
Я не уверен еще, как работают ссылки приглашения в Дискорде, но можете попробовать эту ссылку, чтобы вступить в группу. Если захотите позже, вы сможете отправить свои ответы и получить результаты.
Как проходить экзамен:
1) Открываете ссылку экзамена;
2) Вписываете свой ник (если вы в сообществе, пишите ник в Дискорде);
3) Нажимаете старт и просматриваете вопросы;
4) Повторюсь, НЕ ОТПРАВЛЯЙТЕ ОТВЕТЫ, если вы не в сообществе;
Экзамен для аудитора.
Тут каждый сам за себя, поэтому свои ответы и вопросы не рекомендуется писать в комментах к посту. Но ваши впечатления буду рад услышать.
Приятного экзамена.
#test #audit
В Дискорд сообществе Solidity Lab есть интересный мини экзамен для проверки навыков аудитора. Состоит всего из нескольких вопросов, но на выполнение отводится 1 час 20 минут.
Предлагаю и вам попробовать свои силы. При этом, если вы не состоите в сообществе, то НЕ ОТПРАВЛЯЙТЕ ФОРМУ! Посмотрите задания, решите их за отведенное время.
Я не уверен еще, как работают ссылки приглашения в Дискорде, но можете попробовать эту ссылку, чтобы вступить в группу. Если захотите позже, вы сможете отправить свои ответы и получить результаты.
Как проходить экзамен:
1) Открываете ссылку экзамена;
2) Вписываете свой ник (если вы в сообществе, пишите ник в Дискорде);
3) Нажимаете старт и просматриваете вопросы;
4) Повторюсь, НЕ ОТПРАВЛЯЙТЕ ОТВЕТЫ, если вы не в сообществе;
Экзамен для аудитора.
Тут каждый сам за себя, поэтому свои ответы и вопросы не рекомендуется писать в комментах к посту. Но ваши впечатления буду рад услышать.
Приятного экзамена.
#test #audit
👍2❤1
Контракт из собеседования
В конце сегодняшнего дня предлагаю вам заняться поиском проблем в контракте из реального собеседования.
Если вы также проходили его, то, прошу, не пишите об этом в комментариях, не называйте компанию и не говорить о проблемах в контракте. Позвольте участникам нашего канала самим попрактиковаться.
Думаю, будет здорово, если позже мы устроим небольшой голосовой чат, где обсудим данные контракты и тесты.
Все, что могу сказать по данному заданию это то, что тут есть три серьезные уязвимости, несколько средних и также пара мелких замечаний.
Приятного обучения!
#test #audit
В конце сегодняшнего дня предлагаю вам заняться поиском проблем в контракте из реального собеседования.
Если вы также проходили его, то, прошу, не пишите об этом в комментариях, не называйте компанию и не говорить о проблемах в контракте. Позвольте участникам нашего канала самим попрактиковаться.
Думаю, будет здорово, если позже мы устроим небольшой голосовой чат, где обсудим данные контракты и тесты.
Все, что могу сказать по данному заданию это то, что тут есть три серьезные уязвимости, несколько средних и также пара мелких замечаний.
Приятного обучения!
#test #audit
❤5
Я в пути, не теряйтесь
Уже третий день в дороге. С перебоями инета не получается сделать нормальные посты для канала.
Не теряйтесь, скоро продолжим. Для тех, кому понравились тесты, то поищите Secureum Race Test. В их Дискорде выложены с 4 по 14. В последнем из них pashov, популярный аудитор, занял первое место.
Кстати, поделитесь в комментах, какими программами для аудита и смарт контрактов вы пользуетесь. За исключением популярных, типа Inline bookmarks, Solidity Visual Developer, Surya, Slither и Solhint (который у меня почему-то не срабатывает).
Всем приятного дня!
Уже третий день в дороге. С перебоями инета не получается сделать нормальные посты для канала.
Не теряйтесь, скоро продолжим. Для тех, кому понравились тесты, то поищите Secureum Race Test. В их Дискорде выложены с 4 по 14. В последнем из них pashov, популярный аудитор, занял первое место.
Кстати, поделитесь в комментах, какими программами для аудита и смарт контрактов вы пользуетесь. За исключением популярных, типа Inline bookmarks, Solidity Visual Developer, Surya, Slither и Solhint (который у меня почему-то не срабатывает).
Всем приятного дня!
👍7❤5🔥3
Ошибки в смарт контрактах
Я все еще нахожусь в дороге и надеюсь на следующей неделе уже вернуться к регулярному ведению канала. А пока что, я читаю много аудиторских отчетов и примеров взломов. Для себя выделил несколько типов ошибок, которые присутствуют в контрактах.
1. Типичные low/gas ошибки
Такие баги находятся проще всего, даже при беглом изучении кода. Примером может случить простая потеря indexed в событиях, не нужные чтения переменных из памяти или использование calldata вместо memory.
2. Ошибки при делении
Одни из самых популярных ошибок в смарт контрактах. Начисление бонусных токенов, расчет долей, свапы - везде может быть проблема с округлением, decimals или логическими расчетами.
3. Ошибки "на внимательность"
Такие ошибки часто попадаются в раздел Med Risk issues в отчетах. Тут уже не получится бегло просмотреть код и потребуется время на его изучение, чтобы понять действия, которые в нем совершаются.
4. Ошибки непредвиденных действий
Самые сложные для нахождения баги, так как чаще всего с кодом все в порядке: т.е. он написан правильно и с необходимыми проверками. Однако, чтобы выявить этот баг аудитору нужно иметь хороший опыт и воображение. Привести пример тут достаточно сложно, так как для каждого проекта они будут индивидуальными.
На что нужно обращать внимание при аудите?
1. Проверки if, require и модификаторы
Иногда такие проверки оказываются недостаточными, что позволяет обходить их с определенными условиями. Обращайте на них внимание с позиции "а как их можно обойти?";
2. Память и ее обновления
Также в некоторых отчетах я встречал баги, которые основывались на недостаточном / некорректном / избыточном обновлении в памяти контракта. Тут могут быть и ошибки с маппингами, и memory-storage, да и обычные обновления переменных. Для меня в этом случае бывает полезным контроль слотов и понимание логики функции.
3. Действующие лица
Редко встречается этот пункт в каких-либо статьях или постах в Твиттере. Аудитору нужно понимать, что в смарт контрактах не два уникальных действующих лица: разработчик и пользователь. Их может быть много, в зависимости от направления проекта, как например: разработчик, администратор, модератор, заемщик средств, заниматель средств, инвестор в пул, продавец токена, покупатель токена, мошенник и т.д. При хорошем аудите нужно рассматривать код на предмет взлома от каждого из действующих лиц.
4. Возможные атаки
Составляйте свой список атак в начале аудита после прочтения документации. Постарайтесь вспомнить все атаки, которые вы встречали в подобных проектах. Это помогает увидеть более развернутую картину потенциальных атак и позже прицельно смотреть в контракт, который аудируете.
Вот такой длиннопост получился по итогам моего чтения отчетов. Надеюсь и вам поможет взглянуть на этот процесс аудита с новой стороны.
Приятного обучения и практики!
#audit
Я все еще нахожусь в дороге и надеюсь на следующей неделе уже вернуться к регулярному ведению канала. А пока что, я читаю много аудиторских отчетов и примеров взломов. Для себя выделил несколько типов ошибок, которые присутствуют в контрактах.
1. Типичные low/gas ошибки
Такие баги находятся проще всего, даже при беглом изучении кода. Примером может случить простая потеря indexed в событиях, не нужные чтения переменных из памяти или использование calldata вместо memory.
2. Ошибки при делении
Одни из самых популярных ошибок в смарт контрактах. Начисление бонусных токенов, расчет долей, свапы - везде может быть проблема с округлением, decimals или логическими расчетами.
3. Ошибки "на внимательность"
Такие ошибки часто попадаются в раздел Med Risk issues в отчетах. Тут уже не получится бегло просмотреть код и потребуется время на его изучение, чтобы понять действия, которые в нем совершаются.
4. Ошибки непредвиденных действий
Самые сложные для нахождения баги, так как чаще всего с кодом все в порядке: т.е. он написан правильно и с необходимыми проверками. Однако, чтобы выявить этот баг аудитору нужно иметь хороший опыт и воображение. Привести пример тут достаточно сложно, так как для каждого проекта они будут индивидуальными.
На что нужно обращать внимание при аудите?
1. Проверки if, require и модификаторы
Иногда такие проверки оказываются недостаточными, что позволяет обходить их с определенными условиями. Обращайте на них внимание с позиции "а как их можно обойти?";
2. Память и ее обновления
Также в некоторых отчетах я встречал баги, которые основывались на недостаточном / некорректном / избыточном обновлении в памяти контракта. Тут могут быть и ошибки с маппингами, и memory-storage, да и обычные обновления переменных. Для меня в этом случае бывает полезным контроль слотов и понимание логики функции.
3. Действующие лица
Редко встречается этот пункт в каких-либо статьях или постах в Твиттере. Аудитору нужно понимать, что в смарт контрактах не два уникальных действующих лица: разработчик и пользователь. Их может быть много, в зависимости от направления проекта, как например: разработчик, администратор, модератор, заемщик средств, заниматель средств, инвестор в пул, продавец токена, покупатель токена, мошенник и т.д. При хорошем аудите нужно рассматривать код на предмет взлома от каждого из действующих лиц.
4. Возможные атаки
Составляйте свой список атак в начале аудита после прочтения документации. Постарайтесь вспомнить все атаки, которые вы встречали в подобных проектах. Это помогает увидеть более развернутую картину потенциальных атак и позже прицельно смотреть в контракт, который аудируете.
Вот такой длиннопост получился по итогам моего чтения отчетов. Надеюсь и вам поможет взглянуть на этот процесс аудита с новой стороны.
Приятного обучения и практики!
#audit
👍6❤2🔥1
Нас уже 501!
Я вернулся с поездки, захожу на канал и вижу, что нас уже 501 участник! Здорово, что этот канал находят все больше людей, которые хотят войти в web3 и получить новые знания!
Напомню, что фокус канал сейчас смещен в сторону аудита и безопасности смарт контрактов. Я верю, что эта профессия станет одной из самых нужных в ближайшие несколько лет. Даже в русскоговорящих странах начинает расти интерес в web3, проводятся митапы, конференции и хакатоны. Будет появляться все больше разработчиков и компаний со своими проектами, которым будет необходим аудит перед публичным запуском.
До этого мы решали задачи, читали отчеты и познавали различные нюансы языка, а теперь я хочу сделать акцент именно на практической части аудита.
Когда, во время поездки, я читал отчеты, меня не покидала мысль, как профессиональные аудиторы могут находить логические баги, или знают места, в которые нужно смотреть в первую очередь. Опыт - само собой. Но нужно еще понимать, как правильно просматривать код.
В общем, по ходу событий вы поймете, что я имею ввиду.
А на сегодня у нас по плану пара задач и небольшой пост.
Всем приятной недели и легкого обучения!
#intro
Я вернулся с поездки, захожу на канал и вижу, что нас уже 501 участник! Здорово, что этот канал находят все больше людей, которые хотят войти в web3 и получить новые знания!
Напомню, что фокус канал сейчас смещен в сторону аудита и безопасности смарт контрактов. Я верю, что эта профессия станет одной из самых нужных в ближайшие несколько лет. Даже в русскоговорящих странах начинает расти интерес в web3, проводятся митапы, конференции и хакатоны. Будет появляться все больше разработчиков и компаний со своими проектами, которым будет необходим аудит перед публичным запуском.
До этого мы решали задачи, читали отчеты и познавали различные нюансы языка, а теперь я хочу сделать акцент именно на практической части аудита.
Когда, во время поездки, я читал отчеты, меня не покидала мысль, как профессиональные аудиторы могут находить логические баги, или знают места, в которые нужно смотреть в первую очередь. Опыт - само собой. Но нужно еще понимать, как правильно просматривать код.
В общем, по ходу событий вы поймете, что я имею ввиду.
А на сегодня у нас по плану пара задач и небольшой пост.
Всем приятной недели и легкого обучения!
#intro
❤12👍2🐳1
Задача 38
И первая задача на сегодня из задачника Quill CTF. Если вы решали задачи Damn Vulnerable Defi, то скорее всего сможете быстро понять, в чем тут дело.
Если же нет, то маленькой подсказкой будет: не полагайтесь на баланс контракта в таких действиях.
Решение
UPD. Изначальное решение было не правильным. Смотрите обновленный пост ниже.
#task
И первая задача на сегодня из задачника Quill CTF. Если вы решали задачи Damn Vulnerable Defi, то скорее всего сможете быстро понять, в чем тут дело.
Если же нет, то маленькой подсказкой будет: не полагайтесь на баланс контракта в таких действиях.
Решение
UPD. Изначальное решение было не правильным. Смотрите обновленный пост ниже.
#task
👍4❤2👎1
Задача с shares
Достаточно распространенная проблема в контрактах. Как я помню, немного похожая задача уже была на канале ранее. Вряд ли ее сможет понять или решить новичок, так как тут уже нужно знать про возможную проблему.
Решение
По сути это очередная задача, где первый депозитор может сломать всю систему минта новых shares. Из-за того, что расчет самых первых shares идет по формуле Math.sqrt(baseTokenAmount * fractionalTokenAmount), хакер может добавить вначале, например, по 1 baseToken и 1 quoteToken, в итоге минт будет всего 1, исходя из формулы. Затем хакер добавляет 1е9 токенов каждого вида, из чего получает стоимость 1 wei LP токена равную 1е9 токенов base или quote.
И если нормальный пользователь захочет добавить свои токены в пул, то ему нужно будет указывать количество не менее 1е9 токенов, чтобы получить минт больше 0.
В таких случаях, при первом добавлении в пул рекомендуют делать минт 1000 токенов на нулевой адрес, чтобы избежать данной уязвимости.
#task
Достаточно распространенная проблема в контрактах. Как я помню, немного похожая задача уже была на канале ранее. Вряд ли ее сможет понять или решить новичок, так как тут уже нужно знать про возможную проблему.
Решение
И если нормальный пользователь захочет добавить свои токены в пул, то ему нужно будет указывать количество не менее 1е9 токенов, чтобы получить минт больше 0.
В таких случаях, при первом добавлении в пул рекомендуют делать минт 1000 токенов на нулевой адрес, чтобы избежать данной уязвимости.
❤4
Комментарий к задаче 38 от Quill CTF
Спасибо @SovaSlava за бдительность в решении задач на канале! В задаче 38, та, в которой я решил, что уязвимость в флеш займе, однако все оказалось куда сложнее.
Я сначала решил, что это просто выжимка из задачи, но оказалось, что это полноценный контракт для практики взлома, где по условию на контракте были 10 Эфиров, а у вас 1, и нужно было забрать все себе. Вот ссылка на задачу.
Даже не знаю, нужно ли расписывать все решение по шагам. Оставлю пока на самостоятельное изучение. Мало ли, кто-то проходит данный задачник сам и не хочет получить готовое решение.
Для остальных подсказка под спойлером.
Уязвимость здесь скрывается не в функции execute, как можно подумать при первом взгляде, а в withdrawAll. Грубо говоря, нам сначала нужно написать контракт атаки, с функциями receive() и отправки эфира обратно владельцу. Далее, делая депозит в 1 эфир и "жонглируя апрувами и перекидыванием баланса эфира" с нашего адреса на контракт атаки и обратно, получить весь баланс weth после нескольких итераций. Звучит немного запутано, но понять вы сможете только после хорошего вникания в задачу.
#ctf #quill #task
Спасибо @SovaSlava за бдительность в решении задач на канале! В задаче 38, та, в которой я решил, что уязвимость в флеш займе, однако все оказалось куда сложнее.
Я сначала решил, что это просто выжимка из задачи, но оказалось, что это полноценный контракт для практики взлома, где по условию на контракте были 10 Эфиров, а у вас 1, и нужно было забрать все себе. Вот ссылка на задачу.
Даже не знаю, нужно ли расписывать все решение по шагам. Оставлю пока на самостоятельное изучение. Мало ли, кто-то проходит данный задачник сам и не хочет получить готовое решение.
Для остальных подсказка под спойлером.
❤5
Странные ERC20
Нашел интересный репо, где описываются все странные и не стандартные реализации токенов ERC20. Привожу краткий перевод.
1. Reentrant Calls. Некоторые токены позволяют делать reentrancy в функции перевода, например ERC777.
2. Missing Return Values. Некоторые токены, типа USDT, BNB, OMG не возвращают булево значение. Здесь можно найти весь список таких токенов.
Также есть токены, типа BNB, которые возвращают булево значение для одних методов, и НЕ возвращают для других.
Другие токены, типа Tether Gold, хоть и заявляют про возврат булево значения, но на самом деле возвращают false, даже когда транзакция проходит успешно.
3. Fee on Transfer. Токена, типа STA, PAXG берут комиссию за перевод.
4. Balance Modifications Outside of Transfers (rebasing / airdrops). Некоторые токены могут делать изменения в балансе без вызова функции transfer.
5. Upgradable Tokens. Токены, типа USDC, USDT являются обновляемыми, т.е. администраторы могут менять логику исполнения некоторых функций в любой момент.
6. Flash Mintable Tokens. Токены, типа DAI, пользователи могут минтить для выполнения какой-либо одной транзакции.
7. Tokens with Blocklists. Токены, типа USDC, USDT, имеют свои функции добавления пользователей в черный список. Если адрес заблокирован, то транзакция будет постоянно откатываться.
8. Pausable Tokens. Токены, типа BNB, ZIL, могут быть приостановлены администраторами, что делает их перевод невозможным.
9. Approval Race Protections. Токены, типа USDT, KNC, имеют защиту от фронтрана функции approve.
10. Revert on Approval To Zero Address. Токены, типа OpenZeppelin, будут откатывать транзакцию, если approve вызывается на нулевой адрес.
11. Revert on Zero Value Transfers. Токены LEND откатывают транзакции, если указано нулевое количество токенов.
12. Multiple Token Addresses. Некоторые токены используют прокси контракты, что открывает путь для атак double entry point.
13. Low Decimals. Некоторые токены имеют маленькое количество decimals (USDC - 6, Gemini USD - 2).
14. High Decimals. Другие токены, наоборот, очень большое количество decimals (YAM-V2 - 24).
15. transferFrom with src == msg.sender. Некоторые токены, типа DSToken, не будут пытаться уменьшить allowance пользователя, если они использует свой адрес в transferFrom(), другие, типа OpenZeppelin, Uniswap-v2, наоборот.
16. Non string metadata. Токены, типа MKR, шифруют свои name/symbol в bytes32, вместо string.
17. Revert on Transfer to the Zero Address. Некоторые токены откатывают транзакцию, если перевод идет на нулевой адрес.
18. No Revert on Failure. Токены, типа ZRX, не откатят вашу транзакцию, если она провалится, а просто вернут false.
19. Revert on Large Approvals & Transfers. Токены, типа UNI, COMP, откатят транзакцию, если число при approve или transfer будет больше чем uint96.
20. Code Injection Via Token Name. Некоторые вредоносные токены могут включать специальные JavaScript код в атрибуте name, которые позволяет хакерам вытягивать приватные ключи пользователей, которые взаимодействуют с токенами через фронтенд.
21. Unusual Permit Function. Токены, типа (DAI, RAI, GLM, STAKE, CHAI, HAKKA, USDFL, HNY, имеют permit() функцию, которая не следует стандарту EIP2612.
Надеюсь, вы тоже узнали сегодня о токенах чуточку больше.
#token #erc20
Нашел интересный репо, где описываются все странные и не стандартные реализации токенов ERC20. Привожу краткий перевод.
1. Reentrant Calls. Некоторые токены позволяют делать reentrancy в функции перевода, например ERC777.
2. Missing Return Values. Некоторые токены, типа USDT, BNB, OMG не возвращают булево значение. Здесь можно найти весь список таких токенов.
Также есть токены, типа BNB, которые возвращают булево значение для одних методов, и НЕ возвращают для других.
Другие токены, типа Tether Gold, хоть и заявляют про возврат булево значения, но на самом деле возвращают false, даже когда транзакция проходит успешно.
3. Fee on Transfer. Токена, типа STA, PAXG берут комиссию за перевод.
4. Balance Modifications Outside of Transfers (rebasing / airdrops). Некоторые токены могут делать изменения в балансе без вызова функции transfer.
5. Upgradable Tokens. Токены, типа USDC, USDT являются обновляемыми, т.е. администраторы могут менять логику исполнения некоторых функций в любой момент.
6. Flash Mintable Tokens. Токены, типа DAI, пользователи могут минтить для выполнения какой-либо одной транзакции.
7. Tokens with Blocklists. Токены, типа USDC, USDT, имеют свои функции добавления пользователей в черный список. Если адрес заблокирован, то транзакция будет постоянно откатываться.
8. Pausable Tokens. Токены, типа BNB, ZIL, могут быть приостановлены администраторами, что делает их перевод невозможным.
9. Approval Race Protections. Токены, типа USDT, KNC, имеют защиту от фронтрана функции approve.
10. Revert on Approval To Zero Address. Токены, типа OpenZeppelin, будут откатывать транзакцию, если approve вызывается на нулевой адрес.
11. Revert on Zero Value Transfers. Токены LEND откатывают транзакции, если указано нулевое количество токенов.
12. Multiple Token Addresses. Некоторые токены используют прокси контракты, что открывает путь для атак double entry point.
13. Low Decimals. Некоторые токены имеют маленькое количество decimals (USDC - 6, Gemini USD - 2).
14. High Decimals. Другие токены, наоборот, очень большое количество decimals (YAM-V2 - 24).
15. transferFrom with src == msg.sender. Некоторые токены, типа DSToken, не будут пытаться уменьшить allowance пользователя, если они использует свой адрес в transferFrom(), другие, типа OpenZeppelin, Uniswap-v2, наоборот.
16. Non string metadata. Токены, типа MKR, шифруют свои name/symbol в bytes32, вместо string.
17. Revert on Transfer to the Zero Address. Некоторые токены откатывают транзакцию, если перевод идет на нулевой адрес.
18. No Revert on Failure. Токены, типа ZRX, не откатят вашу транзакцию, если она провалится, а просто вернут false.
19. Revert on Large Approvals & Transfers. Токены, типа UNI, COMP, откатят транзакцию, если число при approve или transfer будет больше чем uint96.
20. Code Injection Via Token Name. Некоторые вредоносные токены могут включать специальные JavaScript код в атрибуте name, которые позволяет хакерам вытягивать приватные ключи пользователей, которые взаимодействуют с токенами через фронтенд.
21. Unusual Permit Function. Токены, типа (DAI, RAI, GLM, STAKE, CHAI, HAKKA, USDFL, HNY, имеют permit() функцию, которая не следует стандарту EIP2612.
Надеюсь, вы тоже узнали сегодня о токенах чуточку больше.
#token #erc20
❤7👍2🔥1