День задач на канале

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

Итак, первая: была помечена как High Risk на code4rena. Сможете понять в чем тут дело?

Решение

В этой задаче стоит обратить внимание не только на саму подпись (мы же помним, что с ними существует достаточное количество проблем?), но и на nonce.

Вроде бы, все правильно написано в коде. Но нет одной единственной проверки. Уже догадались?

Разработчики не проверяют return с call вызова. Это значит, что в случае неудачного вызова, nonce останется прежним, и хакер может использовать подпись с еще действующим nonce в своих целях.

Вот описание с code4rena.

#task #nonce

Более сложная задача от Immunefi

При аудите всегда следует обращать внимание на переменные и "откуда растут ноги" у токена. Получилось решить?

Решение

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

#task #token

Еще одна с code4rena

Данный баг был обозначен как Medium risk. Поняли в чем дело?

Решение

Функция lendToProject может стать не доступной, если количество задач (tasks) будет слишком большим, что приведет к стопорению проекта.

Это происходит из-за того, что цикл расходует весь газ из функции. Такая вот DoS атака.

#task

Простая, но серьезная

Данная задача одна из самых легких среди тех, что я видел. Тем не менее, она была помечена как High Risk. Решили?

Решение

Функция заканчивает свое действие на return и не доходит до проверки require. К чему это может привести, вы и сами знаете.

#task

Задача на знание нюансов

Задача была помечена как Medium Risk. Ошибка не столько в самом коде, сколько в логике и знании, как работает язык. Поняли, о чем идет речь?

Решение

Проблема все в том же extcodesize. Нельзя полагаться на него при проверке "Контракт ли это?". В первом случае, хакер может все сделать через конструктор контакта, а в более сложном - поиграться с create2 и selfdestruct(). Т.е. проверку довольно просто обойти.

#task

И последняя на сегодня

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

Решение

Заметили маппинги в начале? Как вы думаете, зачем они были указаны?

Да, их значения не обновляются при переводе. А значит, что пользователь может делать перевод несколько раз по одному id и опустошить контракт. Будьте внимательны в своих контрактах!

#task

Нет, не задача

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

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

ERC4626, объясняю своими словами, используется тогда, когда вам нужно выдать пользователям вашего проекта некоторое количество shares взамен их токенов, которые они внесли. Он используется и в играх, и в Dao, и на биржах. При аудитах он встречается довольно часто. 

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

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

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

Видео разбор.

#erc4626

Хэширование в EIP712

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

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

И сегодня разберем, как шифруются структуры. Возьмем такой код:

struct Parent {
    uint s;
    Child[] children;
}

Child {
   uint a;
   uint b;
}

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

В самом конце, берется S и хеш структуры и высчитывается уже конечный хеш Parent.

#erc712 #struct

Читаем отчеты вместе. 1

Я тут подумал, а давайте читать аудиторские отчеты вместе всем каналом? За месяц у нас получится около 25 прочитанных отчетов (не считая выходные дни), что точно повысит наши знания.

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

Для сегодняшнего вечера я выбрал отчет от Sherlock.

Кто что думает?

#report #audit

Новый скам в NFT

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

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

Дело в том, что практически все переводы NFT порождают событие transfer, которое и отлавливается биржами и другими сервисами. Однако, в случае скама, никакой транзакции не происходит. Злоумышленник просто в своем контракте override функцию transferFrom / safeTransferFrom, оставляя только emit event.

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

Будьте аккуратны, и не подписывайте подозрительные сообщения в кошельках.

#nft #scam

Внимание на decimals в аудитах

Короткий пост для привлечения внимания разработчиков и аудиторов к проблеме decimals в Solidity и расчетах.

Очень и очень часто встречаются ошибки, в которых разработчики учитывали только 18 (WETH) или 6 (USDT) decimals в токенах. При этом их количество в разных токенах варьируется от 1 до 20 (максимальный, который я встречал), но, вполне вероятно, что может быть и больше.

Поэтому, если вы не ограничиваете работу своего смарт контракта whitelist токенами с конкретным значением decimals, то следует учитывать и другие варианты.

Вот один из примеров такого бага в контракте.

#decimals #audit

Прочитать mapping в Foundry

Просто оставлю тут небольшую заметку про работу с памятью.

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

Допустим есть такой маппинг:

mapping (uint256 => structInt) internal BlaBlaSt;

Я перерыл весь foundry и гугл, но так и не понял есть ли какие-нибудь команды, чтобы прочитать значения по нужному id.

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

Получили значения из функции => сохранили в переменные => вывели в консоль.

Мне сегодня это стоило пары часов.

Если знаете более простой способ или команду, буду рад, если поделитесь в комментариях.

#foundry #mapping

Читаем отчеты вместе. 2

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

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

А пока, вечерний отчет для чтения вместе!

#report #audit

Тесты в обучении и аудите. Часть 1

Сегодня хочу поднять тему проведения тестов. В частности на Foundry, но подойдет и для HardHat.

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

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

Что можно найти в серьезных проектах?

Во-первых, в папке с тестами чаще всего лежит не один файл, а несколько.

Во-вторых, там же еще присутствуют и другие папки.

В-третьих, появляются некие контракты хелперы.

И вот после простеньких тестов, с которыми мы игрались на своем проекте, в первый раз такое собрание файлов вызывает некоторую панику.

#tests

Тесты в обучении и аудите. Часть 2

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

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

Если есть какие либо библиотеки или сторонние файлы, которые требуют тестов, то также создаем отдельную папку для них (например, utils) и проверяем.

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

При встрече с ними, крайне рекомендую начинать изучение именно с них.

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

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

И только потом начинаем писать свои тесты.

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

Очень жаль, что нет полноценного курса по проведению тестов.

#tests

Про внешние контракты в Foundry

И еще один момент для проведения тестов. Мне сегодня попался контракт для аудита, в котором был внешний контракт токена, т.е. уже задеплоенный в mainnet.

Требовалось сделать форк mainnet к себе в рабочую среду и уже оттуда проводить тесты.

Для форка потребуется зарегистрировать на Alchemy или Infura и получить специальную ссылку, которую позже записать в .env файл, например, под переменной ETH_RPC_URL.

Но сейчас не об этом.

В общем, у меня была переменная:

IMainToken internal  _token;

которая в SetUp функции определялась внешним контрактом:

_token = IMainToken (0x84385v475473...);

и импортировалась из файла интерфейса:

import { IMainToken} from "./utils/IMainToken.sol";

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

Нужно просто скопировать задеплоенный контракт, сохранить его в папке проекта и затем импортировать:

import { MainToken} from "./utils/MainToken.sol";

далее можно через

ptoken = new MainToken();

создать объект и работать с ним.

Однако, если в связанных с IMainToken других файлах есть обращения к токену, то они могут выкидывать ошибку при попытке провести тест. Поэтому потребуется немного доработать:

Оставить оба импорта:

import { MainToken} from "./utils/MainToken.sol";
import { IMainToken} from "./utils/IMainToken.sol";

Затем создать новый контракт токена:

ptoken = new MainToken();

и уже к к токену в файле определить созданный контракт:

_token = address(ptoken);

Тогда все будет работать. Проверил на двух проектах. Надеюсь и вам поможет.

#foundry

Читаем отчеты вместе. 3

На сегодня у нас отчет с code4reana, которые делали аудит для Olympus DAO. Он слегка сложноват, но можно читать и пытаться понять общий смысл того, что хотели донести аудиторы.

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

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

Читаем новый аудит и делаем заметки!

#report #audit

Как стать web3 разработчиком? Часть 1

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

1. Какие профессии есть в web3?

Из вакансий, что я просматривал на зарубежных площадках, могу выделить следующие направления:

- Разработчик смарт контрактов;
- Разработчик смарт контрактов + фронтэнд;
- Аудитор смарт контрактов;
- Блокчейн разработчик;
- Архитектор систем (для DAO, gameFi, DeFi);
- Экономист (токеномика);
- Комьюнити менеджер;
- Маркетолог;

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

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

2. Сколько платят разработчику?

Средняя з/п около 3к-4к долларов в месяц. Более опытные программисты могут получать и 8-10, а сеньоры и того больше.

3. Сложно ли найти работу?

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

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

4. Что нужно для поиска работы?

В идеале - портфолио на GitHub. Это могут быть как мелкие одностраничные проекты в web3, так и более крупные - своя игра, приложение обменник, dao и т.д. Главное показать, что вы можете писать сложные смарт контракты. Также будут огромным плюсом ваши статьи или посты по теме разработки. Страничка на LinkedIn, активный профиль в Твиттере или ваш персональный сайт тоже будут кстати.

Далее поговорим о навыках.

#start #web3 #newby

Как стать web3 разработчиком? Часть 2

5. Сколько уйдет времени на обучение?

Прежде всего не стоит верить, что разработчика из вас сделают курсы или гайды по типу: "В web3 за 30 дней". Это все полная чушь!

Да, например, сам язык Solidity или JS можно выучить за пару недель. Но вот научиться с ним обращаться...

Если у вас есть еще постоянная работа и на обучение вы будете готовы тратить пару часов в день, то закладывайте НЕ МЕНЕЕ полугода-года! Лично у меня уже были хорошие знания в php и js, когда я начал изучать Solidity. И вот стартовал я в начале прошлого года, а активно стал "задрачивать" с июля, когда и открыл этот канал. В день у меня уходило около 6-8 часов на уроки. И только сейчас я приступил к конкурсным аудитам.

Web3 разработчик - ЭТО ПОСТОЯННОЕ ОБУЧЕНИЕ ИЗО ДНЯ В ДЕНЬ! Тут вы никогда не сможете сказать, например, я уже все изучил и стал профи. Индустрия очень быстро развивается и нужно следовать технологиям, чтобы оставаться востребованным специалистом.

6. Какие знания потребуются, если начинать с полного нуля?

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

Хоть Rust и прекрасный язык, на котором написан блокчейн Solana и смарт контракты на нем, все же я считаю Solidity чуть более востребованным и перспективным, поэтому этот канал и посвящен ему.

Итак, на Solidity мы будем учиться писать смарт контракты, или программы для блокчейна Эфира. Из-за особенностей работы таких СК, нам потребуются сепциальные программы для их тестирования. И тут на сцену выходят два новых языка: JavaScript и Python.

Разработчики используют специальную среду разработки: это такой набор инструментов, которые облегчают проведение тестов и упрощают взаимодействие с контрактами. И вот для языка JavaScript это HardHat, для Python - Brownie. Но не огорчайтесь, для Solidity создали свою среду разработки - Foundry.

Именно поэтому, если вы захотите стать только разработчиками смарт контрактов, то Solidity будет вполне достаточно. Только таких вакансий пока еще маловато. Многие требуют навыков работы с фронтэндом, т.е. подключения смарт контрактов к web страничке.

Для этих целей чаще всего используют библиотеки написанные на JavaScript под названием ethers.js и  web3.js.

Более того, чтобы написать простейшую веб страничку, потребуются знания базовых языков HTML и CSS. И вот, что у нас получается:

Простой разработчик => достаточно знаний Solidity (шансы найти работу - низкие),
Разработчик умелый => знания Solidity и Foundry (или Hardhat с JS, или Brownie с Pyhton), шансы - средние,
Фулстек разработчик => Solidity, JS, HTML, CSS, Hardhat, Foundry, ethers.js (web3.js), а также знания популярных сервисов и бирж (Chainlink, Uniswap и т.д.) + портфолио, шансы - хорошие.

Для аудитора обязательно знать Solidity и Foundry (или Hardhat), пройти популярные задачи на поиск уязвимостей, да и знать как происходят взломы.       

Далее об источниках.   

#start #web3 #newby