#HACK

Как потерять средства:
⁃ Дать erc20 аппрув не проверенному контракту
⁃ Использовать в своем контракте проверку доступа по tx.origin, а не msg.sender и отправить левому контракту транзакцию, который абузит tx.origin
⁃ Посетить фишинговый сайт
⁃ Подхватить вирус-стилер-логгер который может узнать пароль и скопировать данные расширения metamask для последующей дешифровки
⁃ Хранить сидфразу в одном месте, к которому потерян доступ
⁃ Идти во фьючерсы с плечом без опыта

#DEFI
Централизованные стейблкоины (USDC,USDT) содержат функционал черного списка адресов во всех блокчейнах, где они представлены.

Когда userA передает свои 100usdc к userB, эти 100usdc не покидают контракта USDC, просто меняется владелец 100$ в пределах контракта, поэтому контракт способен решать, кто имеет право распоряжаться своими средствами, а кого можно забанить.

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

В теории можно забанить пользователей одной страны, пойдя по цепочке CEX->KYC->конкретная_страна_Х->кошельки, которые однозначно трактуются как «владеет гражданин страны Х» и значительно так ограничить свободы в большинстве своем невинных граждан.

Пример наличия функционала, смотреть вкладки «Code», «Read Contract», «Read as Proxy»
USDC «isBlacklisted»
USDT «isBlacklisted»

#EVM #DEFI
Про апрув

Для начала ERC20 обмена нужно разрешить dex.router распоряжаться вашим конкретным erc20 токеном, потому что при транзакции обмена роутер сам передает необходимое количество токенов пользователя на адрес первой пары в пути обмена, которая по цепочке передает второй токен роутеру.

Поэтому важно проверять, кому дается approve (фишинговый страницы могут просить на свой адрес дать апрув)

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

Snowman-протокол консенсуса
WYS - Snowman успокаивающая песенка на заставке одного инфлюенсера))

#FR_BR

Так выглядит успешный обмен BackRunning стратегии.
- Занять 12.16$
- Перелить ликвидность между парами
- На контракте 12.59$WAVAX
- Вернуть заем 12.20$

- Прибыль транзакции 12.59$-12.20$=0.39$

#FR_BR

Back running (BR) - стратегия стремится извлечь выгоду после транзакции обмена. Идеально, чтобы целевая транзакция имела позицию X, а BR X+1.

Теоретически, такая стратегия «переливает» ликвидность между DEX парами. Когда пользователь делает существенный для пары обмен, возникает дисбаланс цен и бот может выгодно перелить ликвидность между парами и немного заработать.

Внутри блокчейнов (eth, bsc, avax) происходят сотни успешных BR транзакций, если бы все BR в одной сети выиграл один бот, то его суточная прибыльность примерно такая:
⁃ В ETH >100000 $
⁃ В BSC >10000 $
⁃ В AVAX >100-1000$ в сутки

#DEFI
В июне выбирал, на каком блокчейне реализовать backrunning стратегию. Критерии выбора:
⁃ Количество DEX
⁃ Наличие внятного explorer (etherscan)
⁃ Количество торговых пар
⁃ Количество стабильных токенов, где нет скрытых комиссий
⁃ Консенсус и гео-распределение валидаторов/майнеров
⁃ Позднее количество активных BR контрактов (их нет в таблице, но в BSC >300, AVAX >60)
Todo uni-forks table as attachment

#FR_BR

Новости за 1-9 июля по BR

Остановил свой выбор на AVAX, потому что:
⁃ Экосистема быстро развивается (количество новых пар и токенов в сутки), блокчейн игры тут выходят.
⁃ Консенсус масштабируемый, децентрализованный, сравнительно быстрый (майнинг транзакции за 1-2блока(<4секунд), для сравнения BSC 3 блока (~9секунд)
⁃ Сравнительно дешевая стоимость содержания одной ноды без стейка, около 20$ (для сравнения BSC бода стоит от 214$ до 700$ в месяц
⁃ Низкая цена классического обмена (avax 0.20$, bsc 0.60$, eth 1$+)
⁃ Низкая цена проигрышной транзакции бота (avax 0.03$, bsc 0.10$, eth 0.1$+)

Собрал DEX, dex.fees, dex.pairs, адреса токенов без скрытых комиссий

Адаптировал бота из BSC сети, написанного на golang и способного делать обмены с 2,3,4 парами без необходимости владения сотнями тысяч капитала, потому что используется flashswap прием, когда у отдельный пары берется заем на одну транзакцию (такое правда возможно, но обхитрить не выйдет)

Вот готов бот, контракты задеплоены, и 2 ноды в РФ и Германии. На очереди нода в США

Тестирую шанс извлечь выгоду,
4 июля 2%(7 раз) из 300+ попыток
6 июля ~0%(1 раз) из 300+ попыток
7 июля 0% из 300+ попыток
8 июля 0% из 300+ попыток
Оказаться в том же блоке что и цель удалось лишь пару раз, зачастую удачные транзакции про сбор остатков, а не пирога

Некоторым ботам «конкурентов» удается оказываться ровно после целевой транзакции. В теории так способны делать лишь валидаторы. Но неужели горстка владельцев ботов содержит сотни валидаторов(цена одного валидатора около 30k$) только для правильной ротации транзакций в одном блоке? Или может валидаторы подключены к аналогу Flashbots сети ETH? Ответом у меня нет

#EVM
Обнаружил два идентичных по логике контракта, созданных в 2015 году

Они вызвали интерес тем, что они старые и на них есть ETH, может авторы допустили ошибку в коде и забыли про существование своих поделок, потому что в 2015 году 1ETH<1$ 😄

130ETH
9ETH

Принцип их работы в подражании реферальной системе с уровнями. Один уровень это условно 10 ставок. Чем выше в пирамиде, тем дольше будут начисления. Тот уровень пирамидки, где мы можем занять место, разделит 130eth между более ранними уровнями, а нам ничего не достанется, пока не задонатят больше пользователей, которые создадут новый уровень пирамидки

Так вот, возможно 100% вызвать создание нового слоя пирамидки и один из кошельков получит больше 100ETH, потому что он много участвовал, но мне так не выгодно, я только пожертвую 10ETH и может через 50лет мне что-то вернется 😄

9-21 июля, BR
⁃ Сменил вектор анализа с «одна транзакция пользователя в вакууме» на анализ «сколько выгоды можно извлечь из целого сманеного блока». Потому что шансов быть следующим после целевой транзакции очень мало.
⁃ Заметил, что из avalanchego+coreth события доходят с задержкой в 10-100мс до golang(avaxBot), поэтому объединил coreth+avaxBot. Теперь бот встроен в код ноды узла и минимизированы задержки на передачу полезной нагрузки к боту, потому что взаимодействие идет не через ethclient а напрямую с локальным state блокчейна. В том числе, когда нода получает новый блок, transaction.receipts подгружаются для последующего анализа. По умолчанию такого нет в eth_* namespace.
⁃ Выигрываются транзакции с около-нулевой прибыльностью
⁃ При ставке в 50gwei, выигрывались 17% транзакций (стандартная ставка 25gwei)
⁃ При ставке в 35gwei, выигрывались 10% транзакций
⁃ Но по итогу выигранные транзакции не выводят в положительный ROI. В обоих случаях ROI -50%

17-21 июля
⁃ Изучал, что такое Flashbots проект, который объединил 90%+ ethereum майнеров с помощью форка geth -> mev-geth. Любой пользователь может формировать «бандлы транзакций» в нужном порядке, но понадобится поделиться прибылью с майнером. Во время майнинга блока, бандлы комбинируются так, чтобы извлечь максимум выгоды для майнера. Если в двух бандлах есть общая транзакция, то будет выбран тот бандл, что дает майнеру больше ETH.
⁃ Нашел статью, которой 1.5 года, в ней рассказывается о том, как перехитрить FR бота с помощью самодельного ERC20 токена, который в определенный момент не дает FR боту зафиксировать прибыль. Повторил такую штуковину в AVAX сети, и один бот так пожертвовал в мою пару 600$ через 7 транзакций. Позднее пробовал аналогично сделать в BSC,HECO,KCC сетях, но без результатно. В BSC сети FR бот настолько прошареный, что обнаруживает любые потенциально опасные для него транзакции и перезаписывает свою BUY транзакцию (которая уже в mempool), чтобы не потерять средства. BSC бот делает evaluate(FR1, targetTx, FR2) и вместе с этим способен обнаружить, что humanTx123 может обломать его извлечение выгоды.
- Если научиться определять из solidity контракта контекст, в симуляции транзакции ли мы или в майнинге блока, то есть шанс перехитрить BSC FR ботов

В сети solana пострадало около 8000 кошельков, их скомпроментировали и вывели под 10$млн.

Вероятные векторы атаки:
1. Как полагает decenter, это nft-маркетплейс Magic Eden
2. Так как постарадали кошельки разных приложений (Phantom, Trust Wallet и Slope) есть вероятность что была фишинг атака

Не встретил мнения про такой вектор:
Вероятно найден баг внутри ключевой библиотеки по подписыванию транзакций. В случае с ecdsa, например, если подписать одну и ту же транзакцию (общие nonce,data и ‘k’(до нее еще добраться нужно) и прочие поля) два раза с одинаковым числом k (оно очень больше, псевдорандомное), то на выходе, транзакция будет содержать r,s,v поля, и r будет одинаковым в обеих транзакциях. И становится возможным вычислить приватный ключ кошелька.

Пример работающего бота, который такое эксплуатирует, сканируя мемпул транзакций https://etherscan.io/address/0x9997d91a31aa0ed1f619e025b65e92c39fa4b968

#HACK
Как устроен скам токен Tech от инфлюенсера Исса (55к подписчиков в тг)

Контракт:
1. Позволяет покупать Tech в любое время
2. Продать можно через 48 часов с момента последней покупки.
3. Владелец контракта может продавать без задержки в 48 часов.
4. Напечатать больше монет нельзя
5. Похож на грубый copy-paste, когда комментарии одни а реальные параметры другие и заложены в коде

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

Как подготавливалась аудитория:
1. В течении 1-6 месяцев публиковались посты про торговлю и обзор токенов. (только после Tech в комментах выясняется что 6 месяцев назад были подобные инциденты)
2. Закупалась реклама в тг каналах
3. Автор провел голосование и решил, что надо бы завести публичный портфель для инвестиций
4. Купить btc, etc потому что ... на 10%
5. Купить Tech на 50% и 40% от депозита, потому что фейковый твит от twitter@cz_binance говорит что "я в Tech"
6. Показывать как круто растет токен. Действительно, если никто кроме админа не может продать за 24часа, то рост будет стремительным). И если админ не продает кучу tech за busd а изымает собственную ликвидность, то красивый график роста цены не прерывается

Токеномика:
1. Всего напечатано 100кк монет
2. Разделить на 4 кошелька, по 25кк каждый (холдеры, кошелек1, 2, 3, 4)
3. Создать pancakeswap пару ~1kk busd к 80kk Tech (в пике было 2.4kk busd, потом 1.5kk busd)
4. Дождаться х2-х3 и продать половину LP токенов и получить обратно свои 1kk+ busd

Мысли вслух:
1. Люди могут купить такую шляпу по усталости
2. Но обычно потому что факт-чекинг для лохов.
3. Легче переложить отвественность за выбор и проверку на какого-то инфлюенсера
4. На момент поста 1972 холдера и 3461 транзакций на общую сумму более 1kk busd.
5. Если большинство покупателей не способно проверить первые 20 строк кода контракта, то они легкая мишень для подобных обманов..

Продолжение следует…

Ликвидность из пары изъята, с 1.8кк busd сейчас 6к.

Появилась единственная продажа токенов от владельца скамины https://bscscan.com/tx/0x5e562602336a37ad41be40ad35de43b34821e03a0fea41dfd7e027c716606603 на 77173 busd

Пара

#HACK
Вероятный вектор обхода блокировки на продажу до роста цены:

Контекст:
1. Так как пара токена добавлена в исключения, она всегда отправляет мгновенно, потому что все пользователи могут покупать много раз (пара отправляет токены к пользователю)
2. Как только пользователь захочет продать токены (отправить к паре), его адрес не в исключениях и нужно выждать 48часов

Что, если создать такой контракт, который купит токены, но оставит на паре и добавит ликвидность в пару?

- Отправили 100$, претендуем на X токенов, но заказать получение swap(..to=pair..) вместо swap(..to=wallet..). У пары появляются на балансе Xткенов, на которые не распространяется доля LP токенов.
- Вычисляем соотношение $-Xтокенов и добавляем ликвидности в пару. Допустим Xтокенов-102$.
- Отправляем в пару 102$
- Суммарно паре отдано 202$.
- Запрашиваем mint() LP токенов, пара видит излишки на своих балансах 102$, Xтокенов и выдает LP токены. К этому момент 99.99% токенов пары снова покрыты LP.
- В любой момент можно обменять LP токены на нынешнее соотношение $-токен.
- Ждем х3 в цене. Наши LP стоят 300$-Yтокенов
- Заказываем вывод LP
- Получаем 300$ при затратах в 100$+102$=202$

Нюансы:
- Минимальный рост токена для окупаемости нужен от х2
- Возможно ли в функции pair.swap(to=pair) отправлять токены той же паре? В коде вроде не запрещено

Upd: идея понравилась и решил затестить через hardhat. Концепт ломает такой момент, что после вызова swap() любые излишки токенов на паре становятся учтенными в резервах. Есть token0.balance(pair) и pair.reserves0 и вот после swap они синронизируются.