Задача 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
Запрет на delegatecall
Небольшой сниппет кода, который позволяет запретить другим контрактам делать delegate call в вашем контракте с помощью простого модификатора.
Этот способ используется в Uniswap V3.
#nodelegate #delegate
Небольшой сниппет кода, который позволяет запретить другим контрактам делать delegate call в вашем контракте с помощью простого модификатора.
Этот способ используется в Uniswap V3.
#nodelegate #delegate
👍7❤1
Пример упаковки структур в маппинге
В отчетах можно часто найти информационный пункт о том, что переменные в структурах следует правильно паковать. В этом примере автор решил пойти дальше и еще больше оптимизировать хранение структуру в контракте.
С помощью двух функций, упаковки и распаковки, и побитовых операций переменные в структуре размещаются в uint256, который в свою очередь сохраняется в маппинге с ключом адресата.
Не уверен, что с практической точки зрения это может быть часто применимо, однако вполне вероятно такой способ упаковки можно будет встретить в проектах при аудите.
#mapping #struct
В отчетах можно часто найти информационный пункт о том, что переменные в структурах следует правильно паковать. В этом примере автор решил пойти дальше и еще больше оптимизировать хранение структуру в контракте.
С помощью двух функций, упаковки и распаковки, и побитовых операций переменные в структуре размещаются в uint256, который в свою очередь сохраняется в маппинге с ключом адресата.
Не уверен, что с практической точки зрения это может быть часто применимо, однако вполне вероятно такой способ упаковки можно будет встретить в проектах при аудите.
#mapping #struct
❤2👍1
Немного о фантомных функциях
Уже несколько раз в различных статьях видел упоминания о фантомных функциях в контрактах. И вот еще одна прекрасная статья, рассказывающая о том, что в контрактах токенов могут быть подобные функции, которые могут привести к взлому.
Сама статья на английском языке, но ее суть в том, что если в контракте токена, как например в WETH, нет функции permit(), но есть fallback(), то вызывая из вашего контракта weth.premit() - транзакция не откатится с ошибкой.
Это может быть уязвимостью, как было в примере с AnySwap/MultiChain.
Подробнее читаем в статье.
#phantom #fallback #permit
Уже несколько раз в различных статьях видел упоминания о фантомных функциях в контрактах. И вот еще одна прекрасная статья, рассказывающая о том, что в контрактах токенов могут быть подобные функции, которые могут привести к взлому.
Сама статья на английском языке, но ее суть в том, что если в контракте токена, как например в WETH, нет функции permit(), но есть fallback(), то вызывая из вашего контракта weth.premit() - транзакция не откатится с ошибкой.
Это может быть уязвимостью, как было в примере с AnySwap/MultiChain.
Подробнее читаем в статье.
#phantom #fallback #permit
❤3
Аудит вживую
Сейчас на Шерлоке проходит конкурсный аудит для проекта GMX. Один из аудиторов, Owen Thurm из Solidity Lab, уже ранее работал с этой компанией и сейчас выкладывает некоторые свои наработки в помощь участникам.
Он также записал небольшое видео, как происходит аудит одной из функций контракта. В нем Owen показывает ход своих мыслей и обращает внимание зрителей на некоторые моменты, которые кажутся ему наиболее интересными.
В общем, рекомендую всем начинающим аудиторам.
Смотрим видео вместе.
Кстати, кто-нибудь из участников участвует в данном конкурсе?
#audit
Сейчас на Шерлоке проходит конкурсный аудит для проекта GMX. Один из аудиторов, Owen Thurm из Solidity Lab, уже ранее работал с этой компанией и сейчас выкладывает некоторые свои наработки в помощь участникам.
Он также записал небольшое видео, как происходит аудит одной из функций контракта. В нем Owen показывает ход своих мыслей и обращает внимание зрителей на некоторые моменты, которые кажутся ему наиболее интересными.
В общем, рекомендую всем начинающим аудиторам.
Смотрим видео вместе.
Кстати, кто-нибудь из участников участвует в данном конкурсе?
#audit
YouTube
Live Audit Of GMX V2 | Withdrawals
Interested in getting hands-on training to become an expert security researcher in a matter of months?
Get the guide to becoming a senior auditor in 6 months here: https://www.intogateway.com/guide
Looking for a Smart Contract Audit? Apply to work with the…
Get the guide to becoming a senior auditor in 6 months here: https://www.intogateway.com/guide
Looking for a Smart Contract Audit? Apply to work with the…
❤5🔥2
Аудит вне рамок - 0
Хочу сделать некоторую серию постов, в которых будут описаны не столько уязвимости в коде, сколько моменты, на которые стоит акцентировать внимание при проведении аудита.
Через данные посты я хочу сформировать такой метод проведения аудита, в котором у проверяющего с самого начала будет видна общая картина проекта, и он сможет понимать вектор потенциальных атак.
Возможно, это звучит несколько сумбурно, но я попытаюсь объяснить, что хочу сделать.
На канале однажды была задача, в которой уязвимость крылась в том, что разработчик забыл обновить данные в маппинге, что позволяло вызывать withdraw() несколько раз и опустошить таким образом пул.
В задаче, на 20-30 строк кода, это понять достаточно просто. Но когда дело касается проекта, где обновление информации в маппинге может быть в совсем другом контракте - заметить это будет проблематично.
И вот я хочу, чтобы у меня, или у любого другого начинающего аудитора, с самого начала проведения аудита в памяти фиксировалось: "Ага, вот маппинг отвечающий за состояние счета владельца. Он должен обновляться в ключевых функциях". И потом в течение всего периода исследований, это держалось в голове.
Это самый банальный пример логического бага в контракте, когда код кажется написанным верно, но все равно есть проблемы.
В общем, надеюсь в таких постах вы тоже сможете найти для себя много нового.
#audit #outofbox
Хочу сделать некоторую серию постов, в которых будут описаны не столько уязвимости в коде, сколько моменты, на которые стоит акцентировать внимание при проведении аудита.
Через данные посты я хочу сформировать такой метод проведения аудита, в котором у проверяющего с самого начала будет видна общая картина проекта, и он сможет понимать вектор потенциальных атак.
Возможно, это звучит несколько сумбурно, но я попытаюсь объяснить, что хочу сделать.
На канале однажды была задача, в которой уязвимость крылась в том, что разработчик забыл обновить данные в маппинге, что позволяло вызывать withdraw() несколько раз и опустошить таким образом пул.
В задаче, на 20-30 строк кода, это понять достаточно просто. Но когда дело касается проекта, где обновление информации в маппинге может быть в совсем другом контракте - заметить это будет проблематично.
И вот я хочу, чтобы у меня, или у любого другого начинающего аудитора, с самого начала проведения аудита в памяти фиксировалось: "Ага, вот маппинг отвечающий за состояние счета владельца. Он должен обновляться в ключевых функциях". И потом в течение всего периода исследований, это держалось в голове.
Это самый банальный пример логического бага в контракте, когда код кажется написанным верно, но все равно есть проблемы.
В общем, надеюсь в таких постах вы тоже сможете найти для себя много нового.
#audit #outofbox
❤2👍2
Аудит вне рамок - 1
Посмотрите на данный отчет о найденной уязвимости в контрактах проекта Ajna.
Когда пользователь закрывает свой стейкинг, то система удаляет информацию о takes[tokenId_], однако упускает удаление snapshot, который хранится в маппинге в структуре StakeInfo. В конечном итоге это может привести к тому, что хакер, зная об этой уязвимости, может использовать информацию из не удаленного snapshot повторно для получения extra rewards.
Если нужны детали, можете смело погружаться в отчет. Я лишь хочу отметить вот что.
Обращаем внимание при аудите
Если при стейкинге используются сложные структуры и маппинги, где сохраняются дополнительные данные, как например snapshot, то следует проверять функции в коде на предмет обновления всех необходимых данных. Если удаляется основа - должны удалять и остальные связанные данные, то же с обновлением и созданием.
Т.е. в началае аудита фиксируем в голове, блокноте или комментарии в коде, какие параметры за что отвечают и когда должны обновляться.
#audit #outofbox
Посмотрите на данный отчет о найденной уязвимости в контрактах проекта Ajna.
Когда пользователь закрывает свой стейкинг, то система удаляет информацию о takes[tokenId_], однако упускает удаление snapshot, который хранится в маппинге в структуре StakeInfo. В конечном итоге это может привести к тому, что хакер, зная об этой уязвимости, может использовать информацию из не удаленного snapshot повторно для получения extra rewards.
Если нужны детали, можете смело погружаться в отчет. Я лишь хочу отметить вот что.
Обращаем внимание при аудите
Если при стейкинге используются сложные структуры и маппинги, где сохраняются дополнительные данные, как например snapshot, то следует проверять функции в коде на предмет обновления всех необходимых данных. Если удаляется основа - должны удалять и остальные связанные данные, то же с обновлением и созданием.
Т.е. в началае аудита фиксируем в голове, блокноте или комментарии в коде, какие параметры за что отвечают и когда должны обновляться.
#audit #outofbox
❤4
Один нюанс про библиотеки
На основе ветки в Твиттере от philogy.
До недавнего времени я был уверен, что в библиотеках могут быть только internal функции, но в одном из конкурсных аудитов было огромное количество библиотек с внешними функциями. Хоть напрямую пользователю их использовать нельзя (только контракты), они несут в себе некоторые неудобства по газу.
Функции в библиотеки используются через delegatecall в других контрактах, что стоит минимум 100 газа за каждый вызов. Более того единоразово к вызову внешней функции добавляется еще 2500 газа.
Таким образом, вызывающий заплатит не менее 2600 газа при вызове external функции из библиотеки.
Это одна из причин, почему в библиотеках рекомендуют использовать только internal функции.
#library #gas
На основе ветки в Твиттере от philogy.
До недавнего времени я был уверен, что в библиотеках могут быть только internal функции, но в одном из конкурсных аудитов было огромное количество библиотек с внешними функциями. Хоть напрямую пользователю их использовать нельзя (только контракты), они несут в себе некоторые неудобства по газу.
Функции в библиотеки используются через delegatecall в других контрактах, что стоит минимум 100 газа за каждый вызов. Более того единоразово к вызову внешней функции добавляется еще 2500 газа.
Таким образом, вызывающий заплатит не менее 2600 газа при вызове external функции из библиотеки.
Это одна из причин, почему в библиотеках рекомендуют использовать только internal функции.
#library #gas
❤2
Аудит вне рамок - 2
Интересный пример, где нужно держать в голове несколько действующих лиц при тестировании функции.
Если кратко, то функция отвечает за оплату займа для пользователя. Она без каких-либо модификаторов и ограничений.
Обращаем внимание при аудите
Тут хочу отметить два момента.
1. Из опыта прочтения аудиторских отчетов, всегда нужно обращать внимание на строгие равенства, типа "==". Очень часто можно наткнуться на баг и выявить условие при котором это равенство "ломает" логику.
2. Кто может обращаться к функции? Да, все пользователи. Но если попробовать разбить их по ролям, то выходит: заемщик, который платит займ, администратор протокола, заниматель, хакер, случайный пользователь и т.д.
Если предположить, что сам админ заинтересован в потере пользователем своего залога, или хакер просто хочет напакостить, то кто-либо из них может отправить небольшой repaid, чем сломает выполнение функции, и займ будет невозможно погасить вовремя. Тут также возможен и фронтран данной функции.
Возможно, придумывать роли пользователей для вас будет не нужной тратой времени, но для меня это помогает найти новые векторы аудита.
#audit #outofbox
Интересный пример, где нужно держать в голове несколько действующих лиц при тестировании функции.
Если кратко, то функция отвечает за оплату займа для пользователя. Она без каких-либо модификаторов и ограничений.
Обращаем внимание при аудите
Тут хочу отметить два момента.
1. Из опыта прочтения аудиторских отчетов, всегда нужно обращать внимание на строгие равенства, типа "==". Очень часто можно наткнуться на баг и выявить условие при котором это равенство "ломает" логику.
2. Кто может обращаться к функции? Да, все пользователи. Но если попробовать разбить их по ролям, то выходит: заемщик, который платит займ, администратор протокола, заниматель, хакер, случайный пользователь и т.д.
Если предположить, что сам админ заинтересован в потере пользователем своего залога, или хакер просто хочет напакостить, то кто-либо из них может отправить небольшой repaid, чем сломает выполнение функции, и займ будет невозможно погасить вовремя. Тут также возможен и фронтран данной функции.
Возможно, придумывать роли пользователей для вас будет не нужной тратой времени, но для меня это помогает найти новые векторы аудита.
#audit #outofbox
❤2👍2
Интересная библиотека SSTORE2
На основе ветки в Твиттере от chrisdior.eth.
В августе прошлого года в проекте Solady появилась новая библиотека SSTORE2, которая, по задумке, была призвана заменить использование дорогого по газу опкода SSTORE.
Например, когда мы хотим сохранить что-то в память, мы используем SSTORE, при этом затрачиваем минимум 20 000 газа за каждые 32 байта.
Библиотека SSTORE2 позволяет нам передавать данные в виде байткода контракта, используя опкод CREATE и затем читать данные через опкод EXTCODECOPY.
Вы также могли бы подумать, что в таблице опкодов стоимость CREATE составляет 32 000 газа, что в разы больше SSTORE. Но дело тут немного в другом.
С SSTORE2 вы передаете данные как байты, которые будут интерпретироваться как переменные, которые вы хотите объявить в новом контракте, а затем вы читаете этот байткод с помощью EXTCODECOPY, что стоит всего 2600 газа.
Таким образом, если вы хотите сохранить 8 переменных в памяти, с обычным опкодом SSTORE это будет стоить около 200 000 газа для записи плюс 20 000 для чтения. А с библиотекой SSTORE2 вы заплатите 88 000 газа для записи плюс 3200 для чтения. Существенная экономия, не так ли?
#opcode #sstore #sstore2 #library
На основе ветки в Твиттере от chrisdior.eth.
В августе прошлого года в проекте Solady появилась новая библиотека SSTORE2, которая, по задумке, была призвана заменить использование дорогого по газу опкода SSTORE.
Например, когда мы хотим сохранить что-то в память, мы используем SSTORE, при этом затрачиваем минимум 20 000 газа за каждые 32 байта.
Библиотека SSTORE2 позволяет нам передавать данные в виде байткода контракта, используя опкод CREATE и затем читать данные через опкод EXTCODECOPY.
Вы также могли бы подумать, что в таблице опкодов стоимость CREATE составляет 32 000 газа, что в разы больше SSTORE. Но дело тут немного в другом.
С SSTORE2 вы передаете данные как байты, которые будут интерпретироваться как переменные, которые вы хотите объявить в новом контракте, а затем вы читаете этот байткод с помощью EXTCODECOPY, что стоит всего 2600 газа.
Таким образом, если вы хотите сохранить 8 переменных в памяти, с обычным опкодом SSTORE это будет стоить около 200 000 газа для записи плюс 20 000 для чтения. А с библиотекой SSTORE2 вы заплатите 88 000 газа для записи плюс 3200 для чтения. Существенная экономия, не так ли?
#opcode #sstore #sstore2 #library
👍4❤3
Аудит вне рамок - 3
Вот еще один пример неочевидного бага в коде, который подтверждает предыдущий пост из серии: аудитору нужно понимать роли пользователей в протоколе.
Обращаем внимание при аудите
Иногда проект разрешает своим пользователям создавать пул и контролировать там сумму комиссии за проведенную сделку. Нужно держать в голове, что администратором пула может стать и "плохой" пользователь, который сначала получит доверие других пользователей, а потом неожиданно повысит комиссию на максимум.
Или в другом случае, администратор может делать фронтран (бургер) транзакции с повышением комиссии перед переводом пользователя.
Говоря кратко, если у какого-либо пользователя есть больше привилегий в протоколе, особенно в отношении активов, то нужно обязательно искать варианты его недобросовестного поведения.
#audit #outofbox
Вот еще один пример неочевидного бага в коде, который подтверждает предыдущий пост из серии: аудитору нужно понимать роли пользователей в протоколе.
Обращаем внимание при аудите
Иногда проект разрешает своим пользователям создавать пул и контролировать там сумму комиссии за проведенную сделку. Нужно держать в голове, что администратором пула может стать и "плохой" пользователь, который сначала получит доверие других пользователей, а потом неожиданно повысит комиссию на максимум.
Или в другом случае, администратор может делать фронтран (бургер) транзакции с повышением комиссии перед переводом пользователя.
Говоря кратко, если у какого-либо пользователя есть больше привилегий в протоколе, особенно в отношении активов, то нужно обязательно искать варианты его недобросовестного поведения.
#audit #outofbox
❤4👍1
Foundry для продвинутых
Постепенно у меня в закладках скапливается много статей, которые я хочу разобрать, но, чувствую, что это может занять много времени. Поэтому, чтобы оставаться в фокусе обучения аудиторству, я буду делать порой сборные посты с подборками.
И сегодня в очереди первый пост со статьями для тех, кто хочет повысить свои навыки работы с Foundry.
1. Подготовка и проведение тестов инвариантов с WETH. Крутая статья от одного из разработчиков самого Foundry о том, что такое инварианты, как проводятся тесты, и на что обращать внимание. Прекрасный пошаговый гайд.
2. Создание моста с Foundry. Интересная статья на Медиуме с примерами, как разработчику можно создать свой простой мост между сетями блокчейна.
3. Тулкит для работы с Chainlink в Foundry. Рассказывается, как правильно создать свой узел, сделать первоначальную настройку и подготовить среду для работы.
Повторюсь, данные статьи вряд ли будут понятны для начинающих разработчиков и тех, кто никогда не работал с Foundry. Для других же они могут значительно повысить навыки работы.
#foundry #forge #scope
Постепенно у меня в закладках скапливается много статей, которые я хочу разобрать, но, чувствую, что это может занять много времени. Поэтому, чтобы оставаться в фокусе обучения аудиторству, я буду делать порой сборные посты с подборками.
И сегодня в очереди первый пост со статьями для тех, кто хочет повысить свои навыки работы с Foundry.
1. Подготовка и проведение тестов инвариантов с WETH. Крутая статья от одного из разработчиков самого Foundry о том, что такое инварианты, как проводятся тесты, и на что обращать внимание. Прекрасный пошаговый гайд.
2. Создание моста с Foundry. Интересная статья на Медиуме с примерами, как разработчику можно создать свой простой мост между сетями блокчейна.
3. Тулкит для работы с Chainlink в Foundry. Рассказывается, как правильно создать свой узел, сделать первоначальную настройку и подготовить среду для работы.
Повторюсь, данные статьи вряд ли будут понятны для начинающих разработчиков и тех, кто никогда не работал с Foundry. Для других же они могут значительно повысить навыки работы.
#foundry #forge #scope
👍4❤2🔥1
Подборка статей для самообучения - 1
Еще небольшая подборка из различных источников, которая идеально подходит для неспешного самообучения. Можно брать по одному источнику в день и продвигаться вместе с каналом.
1. Выпущена новая версия Sol2Uml v2.5.0, которая позволяет, вроде как, читать слоты памяти в публичных контрактах.
2. Побитовые операции в Assembly. Простая и полезная статья от одного из крутых разработчиков 0xWeiss. В аудитах я все чаще встречаю участки кода, где используются сдивиги и маскирование? (masking), поэтому хорошо бы разбираться в этом.
3. Как разбить строку в Solidity на насколько линий. Даже не могу представить случай, когда это может потребоваться, но, возможно, вам будет интересно просто прочитать про то, как разработчик решил эту проблему для себя.
4. Немного о стандарте EIP712, работа с подписями. Все больше багов и уязвимостей находится в не правильной работе с подписями в контрактах. Эта статья простым языком старается объяснить принципы работы.
5. Как работает ECDSA. Техническая статья о работе библиотеки. Очень много формул, расчетов и подробностей. Возможно, будет интересна тем, кто познает шифрование.
6. Все о стеке и памяти. Популярная и мега полезная статья о работе памяти в языке. Понять все нюансы можно, только прочитав ее несколько раз.
7. Пост про MEV. О ней сказать ничего не могу, так как еще очень давно сохранил ее и даже не просмотрел. Ее рекомендовал pashov в своем блоге.
8. Хорошая статьи от Officer CIA об AAVE v3. Там же можно найти ссылки по подобным постам про Convex, Curve V1, Balancer V1 и много чего еще. Простое и понятное объяснение многих моментов.
Если некоторые статьи у вас не будут открываться, то попробуйте использовать VPN.
В комментариях можете поделиться своими статьями и постами, которые рекомендуете к прочтению другим участникам.
#scope #eip712 #mev #ecdsa #aave #bit #sol2uml
Еще небольшая подборка из различных источников, которая идеально подходит для неспешного самообучения. Можно брать по одному источнику в день и продвигаться вместе с каналом.
1. Выпущена новая версия Sol2Uml v2.5.0, которая позволяет, вроде как, читать слоты памяти в публичных контрактах.
2. Побитовые операции в Assembly. Простая и полезная статья от одного из крутых разработчиков 0xWeiss. В аудитах я все чаще встречаю участки кода, где используются сдивиги и маскирование? (masking), поэтому хорошо бы разбираться в этом.
3. Как разбить строку в Solidity на насколько линий. Даже не могу представить случай, когда это может потребоваться, но, возможно, вам будет интересно просто прочитать про то, как разработчик решил эту проблему для себя.
4. Немного о стандарте EIP712, работа с подписями. Все больше багов и уязвимостей находится в не правильной работе с подписями в контрактах. Эта статья простым языком старается объяснить принципы работы.
5. Как работает ECDSA. Техническая статья о работе библиотеки. Очень много формул, расчетов и подробностей. Возможно, будет интересна тем, кто познает шифрование.
6. Все о стеке и памяти. Популярная и мега полезная статья о работе памяти в языке. Понять все нюансы можно, только прочитав ее несколько раз.
7. Пост про MEV. О ней сказать ничего не могу, так как еще очень давно сохранил ее и даже не просмотрел. Ее рекомендовал pashov в своем блоге.
8. Хорошая статьи от Officer CIA об AAVE v3. Там же можно найти ссылки по подобным постам про Convex, Curve V1, Balancer V1 и много чего еще. Простое и понятное объяснение многих моментов.
Если некоторые статьи у вас не будут открываться, то попробуйте использовать VPN.
В комментариях можете поделиться своими статьями и постами, которые рекомендуете к прочтению другим участникам.
#scope #eip712 #mev #ecdsa #aave #bit #sol2uml
❤5👍2🔥2
Новый тест от Secureum
Хотел поучаствовать хоть в одном таком конкурсе, но, почему-то думал, что они проводятся редко, поэтому отключал все уведомление в Дискорде. Следующую я точно не пропущу!
Тут как обычно 8 вопросов к контракту. Сделано очень удобно: отмечаете галочки, потом открываете ответы и читаете разбор вопроса.
В этот раз у меня получилось 4 полных ответа, 3 частично и 1 мимо.
Пройти тест RACE #15 Of The Secureum Bootcamp.
Много сильных аудиторов и разработчиков участвуют в нем, а потом делятся результатами в Твиттере. Какой-никакой, но тоже бонус к репутации, если вы прошли с высоким баллом.
#secureum #test
Хотел поучаствовать хоть в одном таком конкурсе, но, почему-то думал, что они проводятся редко, поэтому отключал все уведомление в Дискорде. Следующую я точно не пропущу!
Тут как обычно 8 вопросов к контракту. Сделано очень удобно: отмечаете галочки, потом открываете ответы и читаете разбор вопроса.
В этот раз у меня получилось 4 полных ответа, 3 частично и 1 мимо.
Пройти тест RACE #15 Of The Secureum Bootcamp.
Много сильных аудиторов и разработчиков участвуют в нем, а потом делятся результатами в Твиттере. Какой-никакой, но тоже бонус к репутации, если вы прошли с высоким баллом.
#secureum #test
❤2👍1
Подборка статей для самообучения - 2
Вторая подборка статей из моего архива.
1. Немного о библиотеке Solmate's SafeTransferLib. Ее реализация немного отличается от привычной нам библиотеке от OpenZeppelin. При аудите следует обращать на некоторые особенные моменты, которые описываются в данной статье.
2. DAO Voting Vulnerabilities. Хорошая статья от MixBytes, которая рассказывает о популярных уязвимостях в проектах DAO.
3. Кратко о SMTChecker в Solidity и его конфигурации в Foundry. Еще не совсем разобрался, для каких практических целей это может потребоваться, но где-то чую, что может быть полезно для изучения.
4. gasLeft() exploit. Показан пример решения одной из задач в Ethernaut альтернативным способом через внутреннюю функцию проверки остатков газа. Не обычный способ, показывающий, что всегда есть как минимум еще один способ для решения любой задачи. P.S. Обратите внимание на другие статьи от данного автора.
5. Видео об уязвимости в ZK. Популярная сейчас тема, поэтому основы знать нужно.
6. Опкоды с необычным "поведением". Ветка от jtriley, где собраны описания опкодов, которые могут вести себя не так, как запланировано. Будет сложно даже для продвинутых разработчиков.
7. 35 репозиториев для разработчиков. Простая подборка с полезными репо.
Как вы видите, очень много материала можно найти в зарубежных источниках. Если кто-то делает их перевод, дайте мне знать, обязательно будут делиться на канале.
#scope #dao #zk #solmate #opcode
Вторая подборка статей из моего архива.
1. Немного о библиотеке Solmate's SafeTransferLib. Ее реализация немного отличается от привычной нам библиотеке от OpenZeppelin. При аудите следует обращать на некоторые особенные моменты, которые описываются в данной статье.
2. DAO Voting Vulnerabilities. Хорошая статья от MixBytes, которая рассказывает о популярных уязвимостях в проектах DAO.
3. Кратко о SMTChecker в Solidity и его конфигурации в Foundry. Еще не совсем разобрался, для каких практических целей это может потребоваться, но где-то чую, что может быть полезно для изучения.
4. gasLeft() exploit. Показан пример решения одной из задач в Ethernaut альтернативным способом через внутреннюю функцию проверки остатков газа. Не обычный способ, показывающий, что всегда есть как минимум еще один способ для решения любой задачи. P.S. Обратите внимание на другие статьи от данного автора.
5. Видео об уязвимости в ZK. Популярная сейчас тема, поэтому основы знать нужно.
6. Опкоды с необычным "поведением". Ветка от jtriley, где собраны описания опкодов, которые могут вести себя не так, как запланировано. Будет сложно даже для продвинутых разработчиков.
7. 35 репозиториев для разработчиков. Простая подборка с полезными репо.
Как вы видите, очень много материала можно найти в зарубежных источниках. Если кто-то делает их перевод, дайте мне знать, обязательно будут делиться на канале.
#scope #dao #zk #solmate #opcode
❤2🔥2
Передача ownership
Очень часто в отчетах можно встретить пункт, что передача прав владения другому человеку должна занимать минимум два шага, для соблюдения мер безопасности.
На скрине выше, вы можете видеть самый простой пример реализации данной логики в двух шагах.
#dao #ownership
Очень часто в отчетах можно встретить пункт, что передача прав владения другому человеку должна занимать минимум два шага, для соблюдения мер безопасности.
На скрине выше, вы можете видеть самый простой пример реализации данной логики в двух шагах.
#dao #ownership
❤4
Соберем воркшоп / шеринг / конфу?
Поймал себя на мысли, что, уйдя с головой в аудит, я перестал следить за другой актуальной информацией о блокчейне. Ее так много, и она так часто появляется, что переработать все и найти долю уникальности бывает очень сложно.
Вот я и подумал, может бросить клич по чатам и каналам, собрать спикеров и провести онлайн созвон с презентациями? Типа, за этот месяц бла бла бла...
Темы самые разнообразные:
- Общие новости в блокчейне;
- Разборы контрактов;
- Последние хаки;
- Инструменты для разработки;
- Вопросы по кодингу;
и много других. Главное с презентациями! Для спикеров это будет дополнительной рекламой (деятельности, каналов, проектов), а для интересующихся - отличный способ быть в теме.
Запись будем делать и на ютуб, и в телеграм каналы, и в подкасты, если будет подходить.
Что думаете? Для первого раза было бы хорошо собрать человек 7-8.
Можете скопировать тест поста (или сделать репост, если вам норм), и спросить у своих участников в каналах / чатах.
#conf
Поймал себя на мысли, что, уйдя с головой в аудит, я перестал следить за другой актуальной информацией о блокчейне. Ее так много, и она так часто появляется, что переработать все и найти долю уникальности бывает очень сложно.
Вот я и подумал, может бросить клич по чатам и каналам, собрать спикеров и провести онлайн созвон с презентациями? Типа, за этот месяц бла бла бла...
Темы самые разнообразные:
- Общие новости в блокчейне;
- Разборы контрактов;
- Последние хаки;
- Инструменты для разработки;
- Вопросы по кодингу;
и много других. Главное с презентациями! Для спикеров это будет дополнительной рекламой (деятельности, каналов, проектов), а для интересующихся - отличный способ быть в теме.
Запись будем делать и на ютуб, и в телеграм каналы, и в подкасты, если будет подходить.
Что думаете? Для первого раза было бы хорошо собрать человек 7-8.
Можете скопировать тест поста (или сделать репост, если вам норм), и спросить у своих участников в каналах / чатах.
#conf
👍14🔥3❤1
Аудит вне рамок - 4
Интересная логическая ошибка, которая была найдена в протоколе NounsDAO.
Работая со временем, аудитор должен изучать все проверки времени. Очень часто бывает, когда разработчики предусматриваю развитие ситуации только в одном ключе.
Обращаем внимание при аудите
Если в контракте есть функции, которые учитывают тайминг (когда событие может начаться, когда оно должно закончиться, и что происходит при его отмене), то аудитор должен иметь ввиду, что указание временных рамок должно проходить все необходимые проверки.
Как например в данном баге, при создании события stoptime не должен быть меньше block.timestamp, иначе событие будет невозможно отменить в будущем.
Более того, при работе со временем разработчики зачастую упускают тот факт, что пользователь может создать метки времени в прошлом, что может привести к критическим уязвимостям.
#audit #outofbox
Интересная логическая ошибка, которая была найдена в протоколе NounsDAO.
Работая со временем, аудитор должен изучать все проверки времени. Очень часто бывает, когда разработчики предусматриваю развитие ситуации только в одном ключе.
Обращаем внимание при аудите
Если в контракте есть функции, которые учитывают тайминг (когда событие может начаться, когда оно должно закончиться, и что происходит при его отмене), то аудитор должен иметь ввиду, что указание временных рамок должно проходить все необходимые проверки.
Как например в данном баге, при создании события stoptime не должен быть меньше block.timestamp, иначе событие будет невозможно отменить в будущем.
Более того, при работе со временем разработчики зачастую упускают тот факт, что пользователь может создать метки времени в прошлом, что может привести к критическим уязвимостям.
#audit #outofbox
❤1