
Некоторые команды не публикуют код смарт-контракта в расчёте, что так его труднее сломать. 24 октября разработчик Shaw (@shawmakesmagic) показал, чего этот расчёт стоит. Он скачал из блокчейна Solana закрытую программу daos.fun, восстановил её исходный код, который при сборке совпадает с оригиналом байт в байт, и нашёл в нём критическую уязвимость. По его словам, всё заняло меньше часа и было полностью автоматизировано.
Вывод в его посте резкий: security by obscurity, защиты через непрозрачность кода, больше нет.
Смарт-контракт попадает в блокчейн не исходником, а скомпилированным байткодом. Этот байткод публичен по определению: его исполняет каждый узел сети, и любой может его скачать. «Закрытый» контракт означает лишь, что команда не выложила исходники на Solidity или Rust. Сама логика лежит в открытом виде, просто в форме, которую человеку читать тяжело.
Тяжело, но возможно. Дизассемблер превращает байты в инструкции виртуальной машины. Декомпилятор поднимается выше и восстанавливает структуру: функции, ветвления, циклы. Из байткода нельзя вернуть имена переменных и функций и комментарии, компилятор их выбрасывает. Получается рабочий, но безымянный код. Раньше распутывать его вручную было долго и дорого, поэтому команды и надеялись, что до их логики никто не доберётся. AI снимает этот барьер: модель переписывает дизассемблированный код в читаемый исходник гораздо быстрее человека.
Делает ли восстановленный код то же, что оригинал, проверяют воспроизводимой сборкой. Берём восстановленный исходник, компилируем его тем же компилятором с теми же настройками и сравниваем результат с байткодом из блокчейна. Если байты совпадают, восстановленный код эквивалентен исходному. Так поступил и Shaw: по README репозитория пересобранный бинарник daos.fun совпал с оригинальным побайтово, оба размером 1 120 784 байта и с одинаковым SHA-256.
На той же идее держится верифицированная сборка. В Solana инструмент solana-verify собирает программу из открытого исходника в докер-контейнере и сравнивает хэш с хэшем программы в блокчейне, а результат записывает в отдельный аккаунт на цепочке. В EVM тем же занимаются Etherscan и Sourcify. Там помогает устройство Solidity: компилятор дописывает в конец байткода хэш метаданных, своего рода отпечаток всей сборки. Как поясняет Sourcify, стоит изменить один байт исходника, и хэш метаданных в байткоде меняется. Поэтому полное совпадение доказывает, что перед вами ровно тот код, что развёрнут в сети, вплоть до комментариев.
Разница в направлении. Верификация подтверждает, что открытый код соответствует развёрнутому. Реверс-инжиниринг восстанавливает исходник там, где его не публиковали. Техника одна и та же, и доступна она теперь не только автору.
Что именно нашёл Shaw, видно в аудите из его репозитория. Аудит описывает шесть находок в восстановленной программе: одну критическую, четыре средних и одну низкую. Критическая (в репозитории она помечена BM-1) в инструкции finalize_meteora_bonding. Один из аккаунтов, которые передают в инструкцию, не привязан проверкой к конкретному DAO. Из-за этого при переносе ликвидности комиссию можно направить не туда и заодно испортить состояние чужого DAO. Атакующему при этом не нужны права администратора жертвы.
Два уточнения, чтобы не раздувать историю. Во-первых, аудит проводился в локальном симуляторе на захваченной копии программы, а не против живого мейннета, и его авторы прямо пишут, что это воспроизведение уязвимого поведения, а не доказательство атаки в реальной сети. Во-вторых, репозиторий намеренно сохраняет уязвимости, это не исправленная версия. Уведомили ли команду daos.fun и закрыта ли дыра, из публичного треда неясно. Поэтому мы описываем технику и не приводим шаги атаки, тем более что в открытом виде их нет.
Случай daos.fun не единичный. В декабре 2025 года Frontier Red Team из Anthropic опубликовала исследование о том, как AI-агенты эксплуатируют реальные смарт-контракты. Команда собрала бенчмарк SCONE-bench из 405 контрактов, которые взломали в 2020–2025 годах, и оценивала результат суммой, украденной в симуляции.
На контрактах, взломанных уже после даты обучения моделей (так исключили подсказки из обучающих данных), Claude Opus 4.5, Claude Sonnet 4.5 и GPT‑5 вместе построили эксплойты на 4,6 миллиона долларов. Anthropic называет это нижней оценкой возможного ущерба, а не прибылью: контракты в бенчмарк заранее отбирали из числа уязвимых, поэтому прибыль настоящей атаки по ним оценить нельзя. Отдельно агентов Sonnet 4.5 и GPT‑5 запустили на 2 849 недавно развёрнутых контрактов без известных уязвимостей. Вместе они нашли две новые уязвимости нулевого дня и собрали эксплойты на 3 694 доллара, причём GPT‑5 потратил на API 3 476 долларов. Всё тестировалось только в симуляторах блокчейна, реальные средства не трогали. Тот же агент, как пишет команда, работает и в обратную сторону: проверяет контракт на уязвимости до того, как его выложат в сеть.
Восстановить закрытый код стало дёшево, и найти в нём уязвимость агенту тоже по силам. Непрозрачность кода больше не даёт заметной форы.
Первое: перестаньте считать закрытый код защитой. Байткод всё равно публичен, а восстановить из него логику теперь дёшево. Прятать стоит ключи и секреты, но не саму логику контракта. Раз её всё равно прочитают, разумнее открыть код самим и получить за это доверие пользователей.
Второе: откройте исходники и сделайте верифицированную сборку. В Solana запустите solana-verify, в EVM верифицируйте контракт в Etherscan и Sourcify. Тогда любой пользователь сам проверит, что развёрнутый байткод собран из опубликованного исходника. При этом верификация доказывает соответствие кода, но не его безопасность. В документации Solana об этом сказано прямо: верифицировано не значит проверено аудитом.
Третье: аудит и программа выплат за найденные уязвимости остаются обязательными. Если дыру всё равно найдут, пусть её найдёт белый хакер за вознаграждение, а не атакующий. Раз инструменты поиска подешевели, исследователей, скорее всего, станет больше, и открытый контракт с понятной программой выплат привлечёт часть из них на свою сторону.
Четвёртое: добавьте агента в собственную проверку кода. Та же техника, что находит дыры в чужом контракте, проверит и ваш до релиза. Прогоняйте агента по коду перед деплоем как ещё один слой проверки, не заменяя им аудит и тесты. Находки проверяйте на своей копии в симуляторе, а не в мейннете.
Пятое: следите за контрактом после запуска. Отслеживайте необычные транзакции и вызовы инструкций, которые меняют состояние и двигают средства. Если атаковать контракты стало проще и дешевле, то замечать атаку надо раньше.
Реверс-инжиниринг байткода, верифицированные сборки, аудит и программы выплат разбираем на курсе по разработке смарт-контрактов на Solidity.


