# Закрытый смарт-контракт больше не защита

Как из байткода в блокчейне восстанавливают исходный код смарт-контракта, почему security by obscurity не работает против AI и что это меняет для аудиторов и команд.

- Автор: Guide DAO
- Опубликовано: 2026-10-24
- Теги: Безопасность смарт-контрактов, Solidity
- Страница: https://www.guidedao.xyz/blog/reverse-smart-kontraktov

Некоторые команды не публикуют код смарт-контракта в расчёте, что так его труднее сломать. 24 октября разработчик Shaw (@shawmakesmagic) [показал](https://x.com/shawmakesmagic/status/2113937272303505592), чего этот расчёт стоит. Он скачал из блокчейна Solana закрытую программу daos.fun, восстановил её [исходный код](https://github.com/lalalune/daosfun-source), который при сборке совпадает с оригиналом байт в байт, и нашёл в нём критическую уязвимость. По его словам, всё заняло меньше часа и было полностью автоматизировано.

Вывод в его посте резкий: security by obscurity, защиты через непрозрачность кода, больше нет.

## Почему закрытый код не прячет логику

Смарт-контракт попадает в блокчейн не исходником, а скомпилированным байткодом. Этот байткод публичен по определению: его исполняет каждый узел сети, и любой может его скачать. «Закрытый» контракт означает лишь, что команда не выложила исходники на Solidity или Rust. Сама логика лежит в открытом виде, просто в форме, которую человеку читать тяжело.

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

## Как проверяют, что восстановили правильно

Делает ли восстановленный код то же, что оригинал, проверяют воспроизводимой сборкой. Берём восстановленный исходник, компилируем его тем же компилятором с теми же настройками и сравниваем результат с байткодом из блокчейна. Если байты совпадают, восстановленный код эквивалентен исходному. Так поступил и Shaw: по [README репозитория](https://github.com/lalalune/daosfun-source) пересобранный бинарник daos.fun совпал с оригинальным побайтово, оба размером 1 120 784 байта и с одинаковым SHA-256.

На той же идее держится верифицированная сборка. В Solana инструмент `solana-verify` собирает программу из открытого исходника в докер-контейнере и сравнивает хэш с хэшем программы в блокчейне, а результат записывает в отдельный аккаунт на цепочке. В EVM тем же занимаются Etherscan и Sourcify. Там помогает устройство Solidity: компилятор дописывает в конец байткода хэш метаданных, своего рода отпечаток всей сборки. Как [поясняет Sourcify](https://docs.sourcify.dev/docs/full-vs-partial-match/), стоит изменить один байт исходника, и хэш метаданных в байткоде меняется. Поэтому полное совпадение доказывает, что перед вами ровно тот код, что развёрнут в сети, вплоть до комментариев.

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

## Уязвимость в daos.fun

Что именно нашёл Shaw, видно в [аудите из его репозитория](https://github.com/lalalune/daosfun-source/blob/main/audit/AUDIT.md). Аудит описывает шесть находок в восстановленной программе: одну критическую, четыре средних и одну низкую. Критическая (в репозитории она помечена BM-1) в инструкции `finalize_meteora_bonding`. Один из аккаунтов, которые передают в инструкцию, не привязан проверкой к конкретному DAO. Из-за этого при переносе ликвидности комиссию можно направить не туда и заодно испортить состояние чужого DAO. Атакующему при этом не нужны права администратора жертвы.

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

## AI уже находит и эксплуатирует уязвимости

Случай daos.fun не единичный. В декабре 2025 года Frontier Red Team из Anthropic [опубликовала исследование](https://red.anthropic.com/2025/smart-contracts/) о том, как 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.

Курс Guide DAO: [Solidity-разработчик/аудитор](https://www.guidedao.xyz/solidity)