$METеорщики становитесь раком. ща ЧЕКЕРить вас будем.

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

@meteora_check_bot
@meteora_check_bot
@meteora_check_bot

📟 Прилетело из @marcelkow_crypto

$MET AntiDrain
Metora анонсировали чекер дропа
Дата клейма - 23 октября

Если ваш кошелек был украден и на нем стоит Авто-Вывод, то команда Degen Software готова помчь вам с клеймом аирдропа

У нас уже было три успешных кейса на подобных клеймах:
• WormHole — 45000 $W (success ~95%)
• TNSR — 25000 $TNSR (success ~95%)
• GRASS — 23156 $GRASS (success ~95%)

Что требуется от вас:
• Предоставить приватный ключ кошелька, который доступен для клейма дропа

Правила (обяз. к прочтению):
• Не отправляйте кошельки, которые не подходят под критерии дропа, я их просто пропущу

Условия работы:
• В случае УСПЕШНОГО клейма дропа команда забирает себе 30% от ваших токенов!
• Отправка ваших токенов на ваши кошельки займет Время! Это будет проходить НЕ МОМЕНТАЛЬНО

Обратите внимание:
• Мы не даем никаких гарантий на успешность клейма этого дропа
• Кто первый отправит приватные ключи, тому в случае УСПЕХА и будут отправлены токены, никаких выяснений о том, кто же на самом деле владелец кошелька ПРОХОДИТЬ НЕ БУДЕТ

Подача заявок на АнтиДрейн
В ЛС - @crose212
Форма - https://forms.gle/hE3A5Q6FHt4iXmre9

📟 Прилетело из @n4z4v0d

бля..

📟 Прилетело из @marcelkow_crypto

Насколько хороши аудиторские отчеты?

Вы когда-ниодь задумывались о том, насколько развернутыми и качественными бывают аудиторские отчеты для смарт-контрактов? За последние четыре месяца я собрал и проанализировал базу из более чем двадцати четырех тысяч уязвимостей, извлеченных из отчетов частных аудиторов, компаний и конкурсных платформ. Эта работа стала фундаментом для создания интеллектуального ассистента, призванного помогать в аудите. Ключевым этапом была оценка информационной ценности каждого отдельного отчета.

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

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

Статистический анализ полученных данных выявил любопытные закономерности. Средний вес по всем отчетам составил 0.32 при медианном значении 0.27. Это означает, что половина всех проанализированных отчетов имеет оценку ниже 0.27. Распределение весов является скошенным, с явным пиком в области низких значений, что указывает на преобладание относительно кратких или неполных описаний уязвимостей.

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

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

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

#notsosmart

📟 Прилетело из @solidityset

Мои #новости этой недели: разработка нового бота, исправление в Price informer Bot и другое.

1. Недели 3 назад сделал скрипт, который позволяет указать X аккаунты, а затем отфильтровать их по разным параметрам:
Moni score (минимальный и максимальный), количество смартов, минимум упоминаний, мин. упоминаний смартами, минимальный тир и число постов.
В понедельник сделал Telegram бота @moniCheckerBot. Теперь вы можете запустить, указать список, оплатить Telegram Stars, а затем получить результат.
Повторный анализ бесплатный в течение часа.

Новый опыт - получение Telegram Stars от пользователей с открытием доступа.

2. Опять перевёл статью на Английский при помощи одного сервиса и опубликовал на Medium.
В начале опубликовал в виде страницы на своём сайте, но почему-то не получилось полностью. Пришлось загружать html файл. Но в итоге опубликовал.

3. Разузнал про то, как внедрять ИИ в проект. Как буду один свой обновлять, сделаю.

4. В @price_informerBot исправил ошибку с редактированием сообщений.
После обновления ID коллбеков при нажатии стали создаваться новые сообщения вместо изменения текущего. Оказалось, что я не указал ID сообщения. Теперь всё норм.

Всё. Благодарю за внимание. Хороших выходных!

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Replay атака. Часть 1

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

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

1. Nonce («одноразовое число»): в блокчейне nonce — это уникальный последовательный счетчик, привязанный к адресу пользователя. Требуя, чтобы каждое подписанное действие включало текущее nonce пользователя, контракт может гарантировать, что каждое действие будет выполнено только один раз. После обработки nonce увеличивается, поэтому подпись не может быть использована повторно.

2. Параметры, специфичные для цепочки: с появлением нескольких блокчейнов, совместимых с Ethereum Virtual Machine (EVM) (например, Ethereum, Polygon, Arbitrum и т. д.), приватный ключ и адрес пользователя часто одинаковы во всех сетях. Подпись, созданная для контракта на Ethereum, может быть действительна для идентичного контракта на Polygon, если она не содержит данных, специфичных для этой сети. Включение block.chainid в подписанные данные связывает подпись с одной конкретной сетью, предотвращая межсетевые атаки повторного воспроизведения.

3. Разделитель домена: это криптографический механизм, стандартизированный в EIP-712, который связывает подпись с конкретным контекстом приложения. Это уникальный хеш, содержащий такую информацию, как название контракта, версия, адрес и chainid. Это гарантирует, что подпись, предназначенная для одного децентрализованного приложения (DApp), не может быть повторно использована в другом, обеспечивая надежную защиту как от межсетевых, так и от cross-DApp атак повторного воспроизведения.

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

Существуют ли меры защиты от атак повторного воспроизведения для неудачных транзакций?

Эта проверка сосредоточена на распространенном недостатке реализации: увеличение nonce пользователя только после успешного завершения транзакции. Если транзакция завершается неудачно из-за временных обстоятельств (например, в контракте недостаточно средств), nonce остается неизменным. Подписанное сообщение по-прежнему остается действительным и может быть повторно использовано любым лицом после устранения обстоятельств.

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

📟 Прилетело из @solidityset

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.0;


import "openzeppelin-contracts/contracts/access/Ownable.sol";
contract RewardSystem is Ownable {
    mapping(address => uint256) public rewards;
    mapping(address => uint256) public nonces;


    constructor() Ownable(msg.sender) {}


    // For PoC simplicity, we don't use real signatures
    function claimReward(address user, uint256 amount, uint256 nonce, bytes memory signature) external {
        require(rewards[user] >= amount, "Insufficient reward balance");
        require(nonces[user] == nonce, "Invalid nonce");


        // Vulnerability: Signature can be replayed once contract has funds
        bytes32 messageHash = keccak256(abi.encode(
            user,
            amount,
            nonce
        ));


        // For PoC, use a simple signature check
        bytes32 signedHash = abi.decode(signature, (bytes32));
        require(signedHash == messageHash, "Invalid signature");


        // Attempt to transfer reward
        rewards[user] -= amount;
        (bool success,) = msg.sender.call{value: amount}("");


        // Vulnerability: Nonce is only incremented if transfer succeeds
        if (success) {
            nonces[user]++;
        } else {
            revert("Transfer failed");
        }
    }


    // Helper function to add rewards - only owner can call
    function addReward(address user, uint256 amount) external onlyOwner {
        rewards[user] += amount;
    }


    // Helper function to receive ETH
    receive() external payable {}
}

Функция claimReward увеличивает значение nonce пользователя только в случае успешного перевода ETH. Если в контракте нет ETH, msg.sender.call завершится с ошибкой, транзакция будет отменена, а значение nonces[user] не будет увеличено. Подпись пользователя, которая была действительна для этого значения nonce, остается действительной.

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

Как исправить: используйте nonce в каждом пути выполнения!

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

// Corrected claimReward function (inside RewardSystem)
function claimReward(address user, uint256 amount, uint256 nonce, bytes memory signature) external {
    require(rewards[user] >= amount, "Insufficient reward balance");
    require(nonces[user] == nonce, "Invalid nonce");


    // For PoC, use a simple signature check
    bytes32 messageHash = keccak256(abi.encode(user, amount, nonce));
    bytes32 signedHash = abi.decode(signature, (bytes32));
    require(signedHash == messageHash, "Invalid signature");


    // REMEDIATION 1: Consume nonce right after validating it
    nonces[user]++;


    rewards[user] -= amount;
    (bool success,) = msg.sender.call{value: amount}("");


    if (!success) {
        // Revert the reward deduction if transfer failed
        rewards[user] += amount;
    }
    // REMEDIATION 2: No revert to ensure nonce is consumed
}

С этим исправлением, даже если передача не удалась, nonce становится недействительным. Злоумышленник не может повторно использовать подпись, поскольку контракт теперь будет ожидать nonce + 1.

#replay

📟 Прилетело из @solidityset

Всем привет
В среду, 22 октября в 18:00 по мск, будем разбирать очень полезный и редкий по содержанию кейс. Не сухая теория, а разбор реального проекта Resupply.fi — от архитектуры до хака.

Часто видите у проекта надпись «аудит пройден» и думаете, что всё безопасно? А зря. Мы вместе с крутым специалистом посмотрим, как это работает изнутри.

На стриме разберем реальный кейс проекта Resupply.fi
От детального анализа архитектуры и поиска уязвимостей до разбора хака, который случился после аудита.
Посмотрим, как проходит процесс due diligence, какие красные флаги можно заметить заранее, как анализировать уже имеющиеся аудиты у проектов.
Вести стрим будет Олег, аудитор из MixBytes с 15-летним опытом разработки.
Олег проводит стримы по аудиту в Guide Dao

Guide Dao это образовательное комьюнити в сфере web3 разработки с 1400+ активными участниками, где можно совместно расти и билдить проекты с опытными ребятами

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

2. Web-3 разработка, Solidity-разработка, DeFi-аналитика, аудит смарт-контрактов, создание AI-агентов

3. Спикеры из 1inch, Nomis, Parity, MixBytes, Pessimistic Security и др

4. Ежедневные стримы - АМА, лайвкодинги и пр.

5. Разработка собственных проектов и возможности будущего трудоустройства

Изучить подробнее и получить бесплатные бонусы можно в боте @GuideDAO_hallo_bot

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

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

Жду вас 22 октября (среда) в 18:00 по мск. Не пропустите

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Сегодня разберём стандарты ERC-734 и ERC-735: основу ончейн-идентичности ONCHAINID. Это цифровой паспорт в блокчейне, который хранит ключи, роли и подтверждения (claims). Через него можно управлять доступами, делегировать права и проходить KYC прямо в смарт-контрактах.

ERC-734 отвечает за управление ключами и мультисиг-действиями, а ERC-735 - за работу с утверждениями: кто подтвердил, что ты прошёл верификацию, получил лицензию или право владения активом. https://youtube.com/live/lWXQne3MNTU?feature=share

📟 Прилетело из @dev_in_ruby_colors

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

📟 Прилетело из @dev_in_ruby_colors

Сегодня у интернета выходной

AWS (Amazon Web Services) дал массовый сбой, что привело к неисправной работе множества сервисов: Zoom, Steam, Docker и другие. А также эта проблема не обошла крипто мир - Coinbase и множество других бирж имели сбои.

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

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

Чат | Support | Market
Pelican | HiddenCode [EN]

📟 Прилетело из @hidden_coding