Запомним

Последние, почти 2 месяца, занимался новым стартапов.
Аггрегатор предкшн маркетов
premarket.me
В чем идея.
Polymarket ончейн долгое время был царь и король, т.к. основной конкурент Kalshi работает оффчейн. Но в 25-м году многие увидели рост Polymarket за 24-й год и начали активном пилить свои маркеты.
В результате их сейчас около 8-10. Активных не больше 5.
Но рост идет бурный, поэтому ожидаем по несколько площадок на каждом чейне.
Различные площадки для предкшенов дают такие же неэффективности, как и кексы. Например, где лучше прайсы или как уменьшить слиппадж.
В первой версии я это реализовал.
4 площадки:
- Polymarket(Polygon)
- Opinion(BNB)
- PredictFun(BNB)
- Probable(BNB)

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

Это сырая альфа. Полный Кристиан DYOR. Но если вам не жалко 10-20 долларов, купите продайте что-нибудь плиз, дадите фидбэк.

Два момента, кто захочет попользовать.
1. Метамаск будет вас предупреждать, что это страшная скамина, ничего не подписывай. Он в чем то прав, поэтому не используйте основной кошелек
2. Индексация чейнов идет не прям онфлоу, поэтому после покупки информация о вашем балансе появится через 1-2 минуты

Ну еще на твиттер подпишитесь
https://x.com/pre_markets

Ну и как говорил классик: “Стартуем!”

Взлом Cross Curve Bridge на 1.4кк$

Пост основан на разборе атаки от QuillAudits, статье о взломе от MixBytes и гитхабе Axelar GMP SDK

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

Атака была направлена на контракт ReceiverAxelar, интегрированный с Axelar. Сам контракт я не нашел, но он наследуется от AxelarValuedExpressExecutable, в нем есть функция expressExecute(), являющаяся публичной и не имеющая ограничений по доступу

    function expressExecute(
        bytes32 commandId,
        string calldata sourceChain,
        string calldata sourceAddress,
        bytes calldata payload
    ) external payable virtual {
        if (gateway().isCommandExecuted(commandId)) revert AlreadyExecuted();

        address expressExecutor = msg.sender;
        bytes32 payloadHash = keccak256(payload);

        emit ExpressExecuted(commandId, sourceChain, sourceAddress, payloadHash, expressExecutor);

        _setExpressExecutor(commandId, sourceChain, sourceAddress, payloadHash, expressExecutor);

        {
            (address tokenAddress, uint256 value) = contractCallValue(sourceChain, sourceAddress, payload);
            _transferFromExecutor(expressExecutor, tokenAddress, value);
        }

        _execute(commandId, sourceChain, sourceAddress, payload);
    }

Атакующий сгенерировал commandId, подделал sourceChain и sourceAddress, чтобы вызов выглядел легитимным.
Зловредный payload нёс в себе информацию о целевом контракте, количестве токенов (почти миллиард $EYWA) и инструкции по трансферу на свой адресс,

Единственная проверка, которую осуществляет expressExecute() это проверка на то, исполнялся ли такой commandId, а проверки внутри _execute() проверяли только соответствуют ли sourceChain и sourceAddress друг другу. Такая проверка не давала какого-либо эффекта, поскольку эти данные предоставляет инициатор транзакции.

Кроме того, сonfirmation threshold был установлен на значении 1, что означает очень быструю конфирмацию, ведь требуется одобрение только одного валидатора. Обычно транзакции должны пройти validation process от Axelar Gateway, но для экспресс функции эта часть пропускалась.

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

https://t.me/web3securityresearch

CPIMP атака на 1kk$ или почему аудит скрипта деплоя важен

Итак, представьте, ваш код проходит два аудита, вы исправляете то, что считаете важным (а что считаете неважным помечаете known), но это не делает ваш протокол безопасным, потому что уязвимость в другом месте, а вот проекту UPD_io и представлять не нужно

Clandestine Proxy In the Middle Proxy — "скрытый/подпольный прокси посередине". Это сложная атака, включающая в себя фронтраннинг (посты про MEV не теряют актуальности: раз, два), направленная на upgradable контракты. Суть её заключается во вставке посредника между proxy и implementation контрактами. Эта вставка по сути является man in the middle. Известна стала в июле 2025 года.

В первом приближении схема upgradable контрактов выглядит так:
Прокси -> Имплементация
После CPIMP получается так:
Прокси -> Атакующий -> Имплементация

Что случилось
- 16 сентября 2025 года команда деплоила неинициализированный прокси-контракт
- В окне между деплоем и инициализацией (36 секунд) атакующий опередил команду с помощью Multicall3-транзакции, первым вызвал функцию initialize и захватил права администратора
- Атакующий установил свой malicious proxy, который перенаправлял вызовы на легитимный (аудированный) код, но позволял манипулировать транзакциями
- Для маскировки использовались манипуляции с событиями (events) и слотами хранения, чтобы на блок-эксплорерах (типа Etherscan) всё выглядело нормально — показывался легитимный код
- Атакующий ждал 78 дней, пока протокол набирал ликвидность, и только в декабре активировал эксплойт.

Почему его никто не заметил?
Потому что он гений. Строго говоря, заметить атаку можно было, если бы был проведен анализ логов сразу после деплоя, на это указывают и объясняют Chain Argos. Были подозрительные раздачи ролей на несвязанные с командой адреса, была инициализация контрактов.

А вот после деплоя для маскировки использовались две тактики:
1) Самовосстановление (self-restoration). После делегирования каждого вызова легитимному implementation-контракту CPIMP перезаписывал свой собственный адрес обратно в слот implementation до завершения транзакции. Пытаешься апгрейдить прокси, чтобы избавиться от него? Не сработает, такие дела
2) Подделка слотов для Etherscan (spoofing). Etherscan и другие блок-эксплореры определяют, какой код показывать для upgradeable-прокси, так:
- Читают стандартный слот хранения ERC1967/EIP-1967 (конкретный keccak-хэш), где лежит адрес implementation.
- Показывают верифицированный исходный код по этому адресу.

В реальности слот указывает на malicious-контракт. Но malicious-контракт специально написан так, чтобы перехватывать чтение этого самого слота: Когда кто-то (включая Etherscan) вызывает геттер implementation() или напрямую читает слот, malicious возвращает адрес легитимного контракта (тот, который команда задеплоила и верифицировала).
Поэтому на Etherscan всё выглядит идеально: показывается правильный, аудированный код, как будто ничего не случилось.
Сам malicious-контракт остаётся «в тени» — его код не отображается, и он не верифицирован. Атакующий изучил, как именно работают блок-эксплореры, и встроил эту подделку, чтобы даже внимательный осмотр на Etherscan не вызывал подозрений.

Всё это привело к тому, что 4 декабря 2025 года команда USPD сообщила о взломе. Атакующий сминтил около 98 миллионов токенов USPD и вывел ликвидность из пулов — примерно 232–237 stETH (около $1 млн на тот момент).

Тема прокси достаточно объемная, писать про них посты? Ставь реакцию, если да (и если просто понравился пост)

Источники для подготовки поста:
- Пост на rekt.news
- Разбор теории атаки от Nevermind
- Критика и разбор от chain argos
- Анализ от safe edges
- Анализ от halborn

https://t.me/web3securityresearch

uniswap v4 vulnerability disclosed - link

@EthSecurity1

С ии нашли. Думаю, скоро новые протоколы станут куда безопаснее

Я купил новый ноут, поставил всё с нуля (не люблю переносить автоматически со старого) и теперь боюсь ставить расширение для солидити в vscode из маркета

А вот прикольная тулза – https://impersonator.xyz/. Позволяет к любому даппу подключиться через WalletConnect от имени любого адреса. У него есть браузерное расширение ещё, но у меня не сработало. А через WC сработало, всё норм

Напоминание. В evm (а соответственно yul/assembly/huff) результат деления на ноль – ноль. И остаток от деления на ноль – тоже ноль. Без ошибок

https://evmresearch.io/evm-internals/yul+division+by+zero+returns+zero+rather+than+reverting+unlike+solidity+checked+arithmetic

На таком грустном рынке тестирую другие направления. Одним из них, с некоторой полезностью, оказался эвристический анализ смарт-контрактов.

Алгоритм поиска - тема для отдельного поста.

Veil - аналог Tornado Cash на ZK-SNARKs. Проверка подписи была реализована некорректно - оказалось возможным забрать чужие депозиты, передав слабую подпись (подробнее тут).

Атака на пул "0.1 ETH": basescan

Остальные пулы через 10 минут засекьюрил Defimon - я ограничил доступ проверкой на owner, но они обошли её и закрыли уязвимость: defimon

Через пару дней Defimon засекьюрили foom.cash от схожего бага:
- alert
- разбор от ZK Security

Какие были варианты:
- Whitehat - искать выход на команду, сабмитить баг-баунти репорт, рассчитывать на вознаграждение (ориентир 5–10% от суммы под риском). Но не факт, что этим путём удалось бы вовремя засекьюрить foom.
- Grayhat - сам определил размер комиссии за находку, не проверил другие пулы.
- Blackhat - мог не возвращать ничего.

Упущенный потенциал:
У foom.cash есть treasury на баг-баунти в размере $500K, а Defimon засекьюрили $1.1M - потенциал на выплату $110K+. Плюс Veil могли обнести blackhat'ы подчистую, повторив вектор.

Первый живой кейс. Действовал на адреналине, без чёткого плана. Позже вернул большую часть.

Ончейн-пруф с упоминанием этого канала (прочитать input data как UTF-8): basescan

Очередные приколы у кампаунда

Пару часов назад был любопытный свап 56m$aUSDT в 36000$aEthAave https://etherscan.io/tx/0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f

источник https://x.com/hklst4r/status/2032170722286563791?s=46

Был создан такой дисбаланс, что первый mev бот отправил bribe 26m$ валидатору titan builder и заработал чистыми 9m$, но было так много случаев и подсчет не окончательный. https://etherscan.io/tx/0x45388b0f9ff46ffe98a3124c22ab1db2b1764ecb3b61234e29e5c9732b7fd4ab

На фото какие bribe были отправлены titan builder в следующем блоке после 56m.

Хорошо наелись mev боты, у кого-то lifechange.

Подумал взлом случился или ММ у биржи отдохнуть отошел.

Будет забавно, что такой свап стал возможен через ai агента, который сделал обертку для апи cowswap и в качестве теста сванул все, а потом извинился, мол перепутал decimals 6-8-18, потому что на сайте есть warning об убыточном свапе, значит вероятнее всего программный свап, где недостаточно защиты от дурака. Или виноват openclaw через браузер.

Что за приколы с usdt на троне? Почему, если не застейкать трона на тысячи долларов, комиссия перевода на чистый кошелек около четырёх долларов? И все продолжают пользоваться

Или я не знаю способа уменьшить комиссию? Слишком экосистемой эфира был занят

Мы возвращаемся в темный лес? MEV-бота заскамили на 15 миллионов долларов

Что случилось
Вчера, 20го июня, один из самых известных игроков mev поля, Jared пострадал от атаки на его mev-бота, потери составили 15кк$. Джаред объявил 1кк$ баунти за возврат полной суммы + отказ от преследования. Атакован был JaredFromSubway.eth - это один из MEV-ботов Джареда, который специализируется на сендвич атаках.

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

Что случилось вообще подробно жесть
1) Атакующий разворачивает десятки контрактов, которые выглядят как стандартные обертки: fWETH, fUSDC, fUSDT + Uniswap пулы на эти токены. Точнее сказать, эти контракты имплементировали стандартные интерфейсы юнисвапа. Пары выглядели ликвидными. Пары были как фейк+нормальный токен, так и фейк+фейк.

2) Эти пулы оценивались MEV-ботом как предоставляющие возможность для арбитража. Потому что они ее предоставляли! Атакующие специально создавали транзакции обмена, которые было выгодно бэкранить. Для каждого свапа на новом контракте бот апрувил свои реальные средства: WETH, USDC, USDT. И поначалу апрувы расходовались либо в ноль, либо частично. Контракт становился "проверенным".

3) Со временем бот соприкасался со всё большим количеством этих контрактов.

4) Контракты имели скрытый механизм. Поскольку токены фейковые, то изменения балансов стали производиться с помощью mint/burn операций, без transferFrom операций, на который давался апрув, т.е. апрувы копились.

Важно! Результат этих операций все равно оставался положительным для бота.

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

Что мы из этого можем вынести
Мы все обречены. Проблема по сути заключается в том, что MEV-бот не анализировал код смарт контрактов и транзакций. Это и не входило в его задачи, его задача - в течении 12 секунд определить возможность, симулировать её, запустить транзакцию и извлечь прибыль. Можно конечно сказать, что ему просто надо было следить за апрувами (как и всем нам), но так можно сказать про многие взломы. "Просто не пишите код, который можно сломать" - позиция, которая не приведет нас ни к чему хорошему.

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

Источники:
- тред от Quit
- пост от Startup Fortune
- транзакцию и адреса можно посмотреть в треде у Владимира officer_secret

https://t.me/web3securityresearch

Bonzo Lend (@bonzo_finance) hacked for $9M. The attacker deposited 3$ of collateral and walked out with $9M, without forging a single signature

RootCuase: Wallet A submitted a price update where the BLS signature field was [0,0].
A zeroed signature. No real committee ever signs a zero.
To verify a BLS signature you run a pairing check, roughly e(signature, G) == e(H(message), pubkey). Supra's verifier built that check and handed it to Hedera's alt_bn128 pairing precompile (system contract 0.0.8).

Both the submitted signature AND the referenced committee public key were the point at infinity (zero).
@EthSecurity1

Один из многих контрактов-ловушек: https://etherscan.io/address/0x68301fcc61c397e3e0420f2afba6be3125b947cf

Допустим, Вася решил поизучать существующие на чейне смарт-контракты. И каким-то своим анализатором нашел этот контракт – и анализ показал, что при отправке любой суммы Вася получит весь баланс контракта себе обратно – а это на 1 эфир больше!

Вася даже не поленился и сам симулировал deposit():

кинул 1 wei → контракт отвечает CALL на Васю на 1 ETH + 1 wei. Remix, eth_call, cast call --trace — всё зелёное, без реверта. На кончике как раз висит красивое 1.000000000000000005 ETH. Ну вот же он, забытый банк.

Вася шлёт живую транзакцию. Она проходит. В эксплорере метод Deposit, статус success, комиссия списана. Обратно — ноль. Его wei остался в контракте. Баланс стал 1 ETH + 6 wei.

В чём дело. Анализатор (и почти любой eth_call) по умолчанию кормит EVM gasPrice = 0. А в deposit() ровно это и проверяется:

GASPRICE
// == 0  →  msg.sender.call{value: 1 ether + msg.value}()
// != 0  →  emit Deposited; ETH остаётся

В каноническом блоке GASPRICE ≥ baseFee > 0, ветка с «халявным эфиром» недостижима. Приватный релей / Protect / MEV Blocker не помогут: нулевую цену газа майнер всё равно не включит.

Поэтому на etherscan и картина такая: пачка Deposit по 1 wei от разных адресов — боты, которые поверили симулятору. Эти пять wei до сих пор лежат сверху приманки. А «Claim / 0 ETH» у создателя 0x94ebc938… — это не пустой вызов: в колонке Amount внешний value, а эфир уходит internal. В контракт зашло ~30.6 ETH жертв (слали не только по одному вей), создателю ушло ~29.6, на крючке оставили ровно 1 ETH.