Задача 35

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

Решение

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

#task

Задача 36

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

Решение

Проблема кроется в переводе uint256 amount в uint160, из-за чего транзакция может откатиться. В этом случае лучше использовать сторонние библиотеки, типа safeCast.

#task

Задача 37

И последняя на сегодня, снова же от Immunefi. Как подсказка: внимание на комментарий в коде!

Решение

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

#task

Чтение слотов памяти в контрактах

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

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

Проект Query Storage Slot.

Смотрим и применяем!

#storage #slot

Немного о EIP-1967

В предыдущем посте в сервисе для чтения слотов памяти присутствовала отдельная настройка для контрактов использующих ERC-1967. Мне не приходилось ранее сталкиваться с ним в работе, поэтому можете поправить меня в комментариях, если что будет не совсем точно.

Итак, EIP-1967 стандартизирует как Прокси контракты хранят информацию о контракте Исполнения и другие необходимые данные, такие как адреса beacon контрактов и админский функционал.

Особенностью данного стандарта является необычный расчет слота памяти. Если в обычной реализации формула:

bytes32(uint256(keccak256("eip1967.proxy.admin")))

то в EIP1967 она такая:

bytes32(uint256(keccak256("eip1967.proxy.admin")) -1 )

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

Preimage атака заключатся в том, чтобы найти изначальное "сообщение", которое было зашифровано одним из криптографических  способов (например, keccak или sha).

Больше о EIP-1967 можно почитать в обсуждениях на GitHub.

Я буду добавлять информацию об этом стандарте по мере работы с ним. Все будет также доступно по тегу #eip1967.

#eip1967

Шаблон для аудиторского отчета

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

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

Сохраните себе для работы в будущем.

P.S. Можно сделать перевод для своей страны и использовать для местных аудитов.

#audit #template

The File Pattern

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

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

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

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

#hint #event #file

Сводный пост про биржи

На прошлой неделе я хотел разобраться, как работают современные биржи, и сделал пару постов про 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

Storage Structs

Еще одна потрясающая статья от автора The File Pattern, в которой он разбирает вопрос использования структур для хранения данных при использовании прокси контрактов.

Статья мне приглянулась еще тем, что я сам участвовал в конкурсных аудитах Astaria и Drips. Тогда я хоть и понял, что данные берутся из определённого слота, но не понимал зачем это сделано.

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

Этот паттерн предлагает создавать структуру данных (struct) и помещать ее в слот "далеко" в памяти при помощи формулы EIP-1967, о которой писалось выше.

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

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

#storage #eip1967 #struct

Проверка покрытия тестами

Только для пользователей Linux, как я понял, есть новый инструмент для проверки покрытия тестами какого-либо контракта с использованием команды forge coverage.

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

В этой статье можно почитать про настройку и проведение тестов.

#linux #coverage #forge #foundry

Подборка проектов с новостями

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

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

Необычный тест для участников

Недавно в Дискорде нашел интересные тесты, которые проводятся один-два раза в год хорошо известной всем компанией. Посмотрев последний из них, я решил пройти их все.

Предлагаю и вам пройти их вместе со мной. Если узнали, откуда они, то не рассказывайте никому. В этот раз попробуем сами.

Ответы пишем в комментариях с функцией "спойлер" (на телефонах в приложении выделить текст, нажать на три точки в правом вернем углу и выбрать опцию Спойлер. На компьютере: выделить текст, нажать правую кнопку мыши и выбрать опцию Спойлер).

Ответы я напишу в конце дня также в комментариях.

Для просмотра контракта вам потребуется скачать файл выше.

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

Swapping variables

Вы знали, что в Solidity можно делать свапы переменных (не уверен, как в этом случае правильно перевести).

Посмотрите на пример выше.

#swap #variable

Немного о переменных

В смарт контракте можно указать только 16 локальных переменных. Если их будет больше, то возникнет ошибка StackTooDeepException. Для того, чтобы избежать этого можно использовать так называемые block scoping.

Вообще, scope в Solidity это область видимости, которых, как мы знаем, может быть четыре: internal, external, private, public.

А block scoping - это такая техника, которая позволяет создать новый scope внутри функции, чтобы сократить число локальных переменных в стеке функции.

На скрине выше вы можете увидеть пример block scoping.

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

Чуть больше об этом можно прочитать в официальной документации Solidity, а реальный пример посмотреть тут, в контракте Uniswap.

#variable

Тест 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

Экзамен для аудитора

В Дискорд сообществе Solidity Lab есть интересный мини экзамен для проверки навыков аудитора. Состоит всего из нескольких вопросов, но на выполнение отводится 1 час 20 минут.

Предлагаю и вам попробовать свои силы. При этом, если вы не состоите в сообществе, то НЕ ОТПРАВЛЯЙТЕ ФОРМУ! Посмотрите задания, решите их за отведенное время.

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

Как проходить экзамен:

1) Открываете ссылку экзамена;
2) Вписываете свой ник (если вы в сообществе, пишите ник в Дискорде);
3) Нажимаете старт и просматриваете вопросы;
4) Повторюсь, НЕ ОТПРАВЛЯЙТЕ ОТВЕТЫ, если вы не в сообществе;

Экзамен для аудитора.

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

Приятного экзамена.

#test #audit

Контракт из собеседования

В конце сегодняшнего дня предлагаю вам заняться поиском проблем в контракте из реального собеседования.

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

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

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

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

#test #audit

Я в пути, не теряйтесь

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

Не теряйтесь, скоро продолжим. Для тех, кому понравились тесты, то поищите Secureum Race Test. В их Дискорде выложены с 4 по 14. В последнем из них pashov, популярный аудитор, занял первое место.

Кстати, поделитесь в комментах, какими программами для аудита и смарт контрактов вы пользуетесь. За исключением популярных, типа Inline bookmarks, Solidity Visual Developer, Surya, Slither и Solhint (который у меня почему-то не срабатывает).

Всем приятного дня!