#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 они синронизируются.

Внутри etherscan и его форков (bscscan, snowtrace, и другие), наиболее распространенные методы транзакций имеют человеческие названия: transferFrom вместо 0x23b872dd сигнатуры, которая получается так `bytes4(keccak256(bytes('transferFrom(address,address,uint256)’)))` (4 байта хеша)

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

*НО*
Для одной сигнатуры могут существовать разные версии исходного текста. Возможно подобрать такую строку, что ее хеш будет совпадать с 0x23b872dd, например joinHere_tg_tttt__saltXXX
где
- tttt короткая рекламная ссылка
- saltXXX набор случайных символов, которые позволят получить нужную сигнатуру.

*Проверка #1*
У 1inch протокола функция обмена с хешем 0x7c025200 означает метод swap(…), но в bscscan отображается Swap With Junion On Youtube XD_oninrjpouzas. В этом примере не ясно, откуда bscscan взял альтернативное название, возможно есть другие базы сигнатур.

*Проверка #2*
Встретилась сигнатура 0xfb0f3ee1, где есть JunionYoutubeXD

Навигация

О чем этот канал?

#DEFI - uniswapV2, пары, боты
Пример ethers+js
Blockscan
Uni форки
AMM
Pancakeswap.allPairsLength
Про кошельки
EVM,CEX,DEX
Токен
Landing protocol
Как шортить через landing
Uniswap
USDT,USDC
ERC20.approve
Автоматизация dune
4byte.directory
Rpc.batch
Bsc gasPrice=1gwei

#EVM - нюансы работы evm-блокчейнов
EVM,CEX,DEX
TokenChecks
ERC20.approve
Контракт 2015 года с 130eth
Evm.solidity.fn.signature
Pair.skim
Profanity https://t.me/invmru/71 https://t.me/invmru/76
4byte.directory
Структура байткода
Rpc.batch
1inch.router вывод любых токенов
TOTP на bsc

#HACK - разбор взломов и скам токенов
Обман в дискорде
Что за скам токен
Harmony.one-ethereum
Как теряют деньги мамонты
Solana, 8000 кошельков
Исса. Скам
Исса. Вероятный вектор обхода
Profanity
Celsius
Eth POW
Honeypot
OlympusDao
Frontrun bot потерял 80$
Frontrun. Детали атаки 1/2
Frontrun. Детали атаки 2/2

#FR_BR - frontrun, backrun боты
Пример успешного обмена
Что такое BR
Свой Backrun бот https://t.me/invmru/51 https://t.me/invmru/53 https://t.me/invmru/77

#GETH - как устроена внутри работа главной fullnode eth/bsc
EstimateGas
Flashbots.simulate

#FULLNODE - Как запустить fullnode
Eth
Bsc

#FLASHBOTS
Eth.flashbots.simulate
Polygon.flashbots

Trading view
Про создателей tradingview
Гадание на кейной гуще
VRVP

Личные проекты
TokenChecks https://t.me/invmru/21 https://t.me/invmru/73
Signature Profanity
abi-guesser-webserver

Не всем проектам нашлось место с тегом, продублирую их здесь, но они классные:
Copilot
Blockscan
Chainlist, defilama
Deepface live
Electric capital report
MidJourney
Dune
4byte.directory
Sublime text 3
Сколько занято ГБ на накопителе кубиками

#EVM
pair.skim(to)

Внутри uniswapV2.pair/pancakeswap есть функция pair.skim(to). 578 строка

Она состоит из двух* строк, задача которых перевести все излишки токенов пары к to. Если token0.balanceOf(pair) > _reserve0, то излишки можно получить на свой кошелек.

Количество пыли обнуляется после mint, burn, swap, потому что вызывается _update().

Если просканировать все доступные пары в bsc и avax на количество токенов после skim, встречаются такие заброшенные пары, из которых можно забрать noname токен (через skim) или второй токен, который зачастую wBNB/wAVAX.

Но их количество в 99% случаев не окупит затрат на транзакцию. И очень много скам-токенов, поэтому важно качество симуляции своих транзакций.

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

#DEFI
Как создать особенный адрес кошелька в EVM-сети

Существует утилита Profanity (остерегайтесь форков), которая написана в далеком 2019 году. Она ищет такой privateKey, что address совпадает с искомым паттерном. Например 10 ноликов вначале адреса, или ..dead.., ..ded.., ..bed…, на что хватит фантазии))

Подходит для любой сети, которую поддерживает metamask, или адрес состоит из 40 hex символов

Вторая фишка для ценителей, это поиск privateKey, что его первая транзакция сдеплоит контракт с нужным партерном адреса. nonce=0

На 4-12 rtx3090 возможно в течении часа подобрать несколько адресов с 10 ноликами вначале.
Пример запуска «./profanity.x64 --leading 0»

Мне удавалось найти даже 13ти ноликовый адрес смарт-контракта, который после деплоя передает права на контракт моему кошельку.

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

Пытливые умы могут предположить, что так можно сбрутфорсить любой адрес, но это не так. Каждый следующий нолик после 13 искать гораздо дольше чем предидущий, иными словами невозможно подобрать в разумных временных рамках null адрес с 40ка ноликами.

#EVM
Подготовил утилиту для поиска сигнатур под заданную функцию. Например fn_example_name_1872aff099(address) 0x00000003
github

Обновление:
- Поддерживается больше блокчейнов и dex’ов.
- Добавлен новый способ проверки токенов, что можно купить и продать без затрат на оплату траназкции. Раньше eth_call + перезапись состояния (контракт его нужно виртуально задеплоить и потом к нему обратиться в пределах одного eth_call). Теперь достаточно только eth_call. Вот место в контракте. Это позволяет покрыть больше блокчейнов, в том числе avax-c.

С помощью https://dune.com можно взаимодействовать с eth/bsc/matic/optimism блокчейнами через sql запросы и упаковывать в инфографики, например «прирост деплоев смарт-контрактов по месяцам».

Мне сильно пригодился для того, чтобы выгрузить все адреса еth контрактов, за 15млн блоков и пару часов)) Вышел файл на 2ГБ и 50млн адресов. Не без ухищрений конечно для ускорения сбора, но это все равно в десятки раз быстрее, чем собирать данные через провайдера типа infura/ankr и читать транзакции каждого блока, где есть создание нового контракта.

Вот кто-то заморочился и сделал дашборд про нфт https://dune.com/impossiblefinance/nft-lending-aggregated-dash , да, оказывается есть landing для nft.

Интересно, какие такие ухищрения для ускорения сбора? Ставьте 🔥

Что почитать, чтобы лучше разбираться в сортах NFT, как не попасть на скам минт?

Перед тем, как расскажу про «ухищрения» введу в курс дела.
На dune.com создал запрос на извлечение всех созданных адресов из eth. Вот сам SQL-запрос:

SELECT address
from ethereum.traces
where 
    block_number>={{tillBlock}}-{{step}}
    and block_number<={{tillBlock}}
    and success=true
    and  type='create'

Переменные внутри {{}} подставляются снаружи.
Есть кнопка RUN, которая создает задачу и ждет ее завершения.
Но сканировать все 15млн блоков руками неблагодарное дело, в том числе из-за того, что когда адресов в ответе больше 1млн, это дико лагает. И нельзя извлечь все адреса простым копированием, нет такой кнопки.

А теперь про то, как это ускорить:

Если открыть инспектор браузера(f12->network) и посмотреть, что творится при клике на RUN, увидим, что создается task через http.post.graphql запрос, и раз в несколько секунд проверяется статус task’а. Когда статус меняется, результат работы выгружается отдельным graphql запросом.

Заголовки (Authorization,X-Dune-Access-Token
) истекают очень быстро, поэтому нужно часто выполнять http.post./session с куками авторизованного юзера, чтобы обновить их.

Итого, общая структура (nodejs,typescript,got) скрипта такая:
⁃ Обновляем токены сессии перед каждым graphql запросам
⁃ Создаем task, передаем tillBlock, step
⁃ Ждем окончания выполнения задачи
⁃ Запрашиваем результаты выполнения и выделяем адреса
⁃ Сохраняем в файл (fs.appendFileSync) одна строка = 1 адрес.

Скрипт однопоточный, чтобы не перегрузить dune, который бесплатно дает извлекать такие данные.

#HACK
Profanity уязвим, найден вектор атаки когда становится возможным восстановить приватный ключ зная публичный ключ из транзакции и некоторого брутфорса, подробнее в блоге 1inch . Адреса кошельков и контрактов, созданных с помощью profanity в опасности

#FR_BR
Каков функционал бота сейчас:
- Код бота встроен в avax state-sync ноду, а точнее в плагин coreth. Это позволяет исключить задержки на транспортировку данных от ноды до бота по rpc/ws/... о состоянии резервов пар прямо после блока.
- Так как state-sync нода в основном получает только блоки, а не pendingTransactions как bsc, то поиск арбитража сводится к поиску недоизъятого арбитража среди пар по итогу блока. Тоесть backrun бот ищет, какие еще резервы univ2 пар не сбаланисораны между собой по итогу блока, а не каждой транзакции, как возможно сделать имея fullnode валидатора.
- Попадать в тот же блок, что и потенциальная целевая транзакция невозможно с помощью state-sync ноды. Для этого нужно быть валидатором и оповещать о своем видении порядка блоков сильнее, чем это делают другие валидаторы в момент распространения блоков (если 700/1000 валидаторов за Х вариант блока, то скорее всего его и примут, где может быть нужный нам порядок транзакций)
- Транзакция бота попадает во 2-3 блок после целевой транзакции. Никак ускорить не вышло. Пробовал 2-6 разных локаций одновременно, не помогло.
- Бот жертвует 50-60% чистой прибыли на более высокую комиссию транзакции, чтобы быть раньше в блоке
- Chi токен в avax-c не котируется, не реализован частичный манибек за удаление контракта.

Финансовые показатели бота:
- Условно 10$ ушло на транзакции, 5$ заработано. ROI -50% в среднем, поднять не получилось
- Сервер aws не окупается, spot.c5.large обходится примерно в 1.2$/d

Как сэкономить на стоимости содержания state-sync ноды avalanche:
- Взять spot instance у aws и поставить в настройках "любая цена бида" и "спящий режим при нехватке ресурсов". Это снижает ежедневные затраты в 2-4 раза
- Поселить avalanchego в systemctl демона, чтобы он сам стартовал при перезапуске инстанса

Опыт получен интересный, но бота следует остановить. В нынешней реализации он не показывает признаков окупаемости.

На примере с bsc, нода может 2 месяца работать в минус но потом пара транзакций покроют большоую часть затрат. К сожалению в сети avax так не вышло.

В avax-c существуют активные backrun боты, которые попадают в тот же блок что и целевая транзакция, они извлекают 80% прибыли. А остатки извлекают боты из блоков.

#EVM #DEFI
11кк abi собрано, если обогащать базу сигнатур функций, то тут на 10% больше, чем в 4byte.directory

Большинство контрактов на solidity, попадаются vyper.

Чаще всего попадаются такие опкоды для идентификации сигнатур в байткоде:
// aa bb cc dd = сигнатура
// 63 = PUSH4 означает что длина сигнатуры 4 байта (минимум 1 байт, поэтому 1+3)функции
80 63 aa bb cc dd …

или
80 62 aa bb cc …. // 62 = PUSH3
80 61 aa bb ….
80 60 aa ….

Живой пример weth (байткод внизу)
06fdde03 = name()
095ea7b3 = approve(address,uint256)

#EVM
После компиляции .sol в bytecode внутренняя структура начинается с выбора корректной функции для старта.

что-то вроде «если сигнатура X, то JUMP на Y позицию»

Следовательно, возможно обращаться к контрактам, у которых нет объявленного abi, зная их внутренние функции.

Если умеем выделять сигнатуры в коде, то можно попытаться подобрать аргументы вызова функции в слепую, наиболее распространенные transfer(address,uint256) и тд

#EVM #DEFI
Rpc запросы к evm провайдерам можно делать пачками, не один eth_call а сразу тысяча в одном запросе.

Пример curl

curl --request GET \
  --url https://eth-mainnet.public.blastapi.io/ \
  --header 'Content-Type: application/json' \
  --data '[{"jsonrpc":"2.0","id":0,"method":"eth_blockNumber","params":[]},{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]},{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}]'

- Важно менять ‘id’
- Максимум 1000 элементов, зависит от провайдера
- Если внутри заменить eth_blockNumber на etc_call + свой контракт, то можно повысить емкость одного запроса еще в 10-100 раз
- На один eth_call ограничение в несколько млн газа
- Гуглить список rpc api так «eth eth_call»