#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»

Celsius требовал KYC
Celsius обанкротился
Celsius опубликовал 14к данных пользователей (имя, дата, сделка) по решению суда

https://twitter.com/0xfoobar/status/1578168737529794561

Правда ли KYC так необходим повсюду?

Upd:
«требовал» и «опубликовал» связаны
«требовал» и «обранкротился» не связано, просто хронология))

Вчера вышел 8й пакет санкций ЕС, если коротко, то все биржи, которые ввели 10к евро лимит, теперь понижают этот лимит до 0

Будьте осторожны

В момент перехода eth на PoS в середине сентября, появился минимум один форк: ETHW.

Часть майнеров отказалась принимать большое обновление и их цепочка блоков отделилась от оригинального еth. Тоесть все транзакции до блока Х связаны с eth сетью, но после блока X баланс пользователей раздвоился. Если у пользователя было 1eth,100dai, то такой баланс будет в сетях ETH,ETHW.

И в первые часы существовало много арбитражных возможностей в форкнутой сети.

Например, оракл chainlink, который раз в несколько минут обновляет рыночную цену eth(нативного токена) перестал обновляться в сети ethw. Следовательно, aave и другие landing протоколы не могут корретно соотносить ценность займа и залога.

Более практичный пример, правда когда его проверял, вся ликвидность на aave уже выжата:
1. 1ethw в «реальном» мире стоил 14$, у CEX такой курс был.
2. Цена нативного токена в сети ethw от chainlink 1300$(1ethw)
3. В uniswap 1ethw=36k$

Стратегия:
1000$CEX меняем на ethw
71ethw (1000$CEX)
71*36000=2 556 000$ (ethw меняем на $ в сети ethw через uniswap)
Вносим обеспечение 2.5kk$ в aave (в сети ethw)
Так как у aave старые цены оракла, то он считает что 1ethw стоит 1300$, значит при нашем залоге в 2.5kk$ выдаст 1572ethw при 80% обеспечения.
Выводим 1572ethw на биржу, продаем по 14$, получаем 22008$CEX

Другое направление в том, чтобы нормализовать курсы обмена пар в пределах dex’ов, вероятно там есть пары, которые еще не уравновешены между собой. Задача для BR бота, с последующим выходом в ethw.

Через несколько часов после форка все токены кроме ethw стали фантиками без привязки к реальным ценам. Субъективное ощущение, что все, что позволяет получать ethw уже выжато.

Специфика подобного поиска еще в том, что никакого интерфейса нет, нужно обращаться на прямую к смарт-контрактам, а это значительно сужает порог входа.

Вероятно инициаторы форка неплохо заработали, так как хорошо понимали подобные направления.

#GETH
EstimageGas метод использует тот же инструментарий что и во время создания блоков. Только применятся меньше правил.

Общие моменты:
- берут состояние state на запрошенный блок Х
- подготавливают EVM контекст для исполнения транзакций

Разные моменты:
- EstimateGas ограничивается исполнением транзакции и взятием только GasUsed (/internal/ethapi/api.go:1056 DoEstimateGas)
- Во время создания блока исполняются все транзакции и формируется их receipt с сохранением нового состояния state. (Копать от core/state_processor.go:95 applyTransaction)

В теории возможно производить симуляцию своих транзакций *без signTransaction* и получать tx.Logs и прочие детали будто транзакция смайнена.