Пересылка оригинального заголовка '技术详解 | 链上打新局中局,大规模Rug Pull手法解密'
В последнее время эксперты по безопасности CertiK часто обнаруживают несколько случаев одного и того же метода мошенничества при выходе, широко известного как Rug Pull. При дальнейшем расследовании мы обнаружили, что несколько экземпляров одного и того же метода указывают на одну и ту же группу, что в конечном итоге связано с более чем 200 мошенничеством с выходом токенов. Это говорит о том, что мы, возможно, раскрыли крупномасштабную автоматизированную хакерскую группу, которая собирает активы с помощью мошенничества с выходом. В этих аферах злоумышленники создают новый токен ERC20 и используют предварительно добытые токены вместе с определенным количеством WETH для создания пула ликвидности Uniswap V2. После того, как боты или пользователи в цепочке совершат определенное количество покупок нового токена из пула ликвидности, злоумышленник истощит все WETH в пуле токенами, сгенерированными из воздуха. Поскольку токены, полученные злоумышленником из воздуха, не отражаются в общем предложении и не запускают события Transfer, они не видны на etherscan, что затрудняет их обнаружение посторонними. Злоумышленники не только думают о сокрытии, но и придумывают уловки, чтобы обмануть пользователей с базовыми техническими навыками, которые проверяют etherscan, используя незначительную проблему, чтобы скрыть свои истинные намерения...
Углубленное мошенничество
Используя один из случаев в качестве примера, давайте поглубже вникнем в детали этого мошенничества на выходе. То, что мы обнаружили, это транзакция, в которой злоумышленник использовал огромное количество токенов (тихо созданных) для истощения пула ликвидности и извлечения прибыли. В этой транзакции команде проекта обменяли примерно 416 483 104 164 831 (около 416 квадриллионов) токенов MUMI на примерно 9.736 WETH, исчерпывая ликвидность пула. Однако эта транзакция является лишь последней частью всего мошенничества. Чтобы понять всю суть мошенничества, нам нужно продолжить отслеживание в обратном направлении.
6 марта в 7:52 (по времени UTC, так же и далее) адрес атакующего (0x8AF8) развернул токен ERC20 под названием MUMI (полное название MultiMixer AI) по адресу 0x4894 и предварительно добыл 420 690 000 (около 420 миллионов) токенов, все выделены для развертывателя контракта.
Количество заранее добытых токенов соответствует исходному коду контракта.
В точку в 8 часов (8 минут после создания токена) адрес атакующего (0x8AF8) начал добавлять ликвидность. Адрес атакующего (0x8AF8) вызывает функцию openTrading в контракте токена, создает пул ликвидности MUMI-WETH через фабрику uniswap v2, добавляет все предварительно добытые токены и 3 ETH в пул ликвидности, и в конечном итоге получает примерно 1,036 токен LP.
Из деталей транзакции видно, что изначально для добавления ликвидности было использовано 420 690 000 (приблизительно 420 миллионов) токенов, и примерно 63 103 500 (приблизительно 63 миллиона) токенов были отправлены обратно в контракт токена (адрес 0x4894). Просмотрев исходный код контракта, было обнаружено, что контракт токена будет взимать определенную комиссию за каждую трансфер, и адрес для сбора комиссии является сам контракт токена (конкретно реализовано в функции «_transfer»).
Странно то, что адрес налога 0x7ffb (адрес для сбора комиссии за трансфер) был установлен в контракте, но конечная комиссия была отправлена самому контракту токена.
Таким образом, окончательное количество токенов MUMI, добавленных в пул ликвидности, составляет 357 586 500 (приблизительно 350 миллионов) после уплаты налогов, а не 420 690 000 (приблизительно 430 миллионов).
В 8:01 (через 1 минуту после создания пула ликвидности) адрес атакующего (0x8AF8) заблокировал все 1,036 токенов LP, полученных при добавлении ликвидности.
После блокировки ЛП теоретически все токены MUMI, принадлежащие адресу атакующего (0x8AF8), блокируются в пуле ликвидности (за исключением той части, которая используется в качестве комиссионных сборов), поэтому адрес атакующего (0x8AF8) не имеет возможности удалить его через возможность ликвидности для выполнения Раг-Пулла. Чтобы позволить пользователям покупать только что запущенные токены с уверенностью, многие проектные стороны блокируют ЛП, что означает, что проектная сторона говорит: «Я не убегу, все могут покупать с уверенностью!», но так ли это на самом деле? Очевидно, что нет, это так, давайте продолжим анализ.
В 8:10 появился новый адрес атакующего ② (0x9DF4), и он развернул налоговый адрес 0x7ffb, объявленный в контракте токена.
Здесь стоит упомянуть три момента: 1. Адрес, по которому развернут налоговый адрес, и адрес, по которому развернуты токены, не совпадают. Это может указывать на то, что сторона проекта намеренно уменьшает корреляцию между каждой операцией и адресом, что затрудняет отслеживание поведения. 2. Контракт налогового адреса не является открытым исходным кодом, а это означает, что в налоговом адресе могут быть скрытые операции, которые не хотят быть раскрытыми. 3. Налоговый контракт разворачивается позже, чем токен-контракт, а налоговый адрес в токен-контракте жестко закодирован, что означает, что адрес налогового контракта может быть заранее предсказан командой проекта. Так как инструкция CREATE определяет адрес создателя и одноразовый номер, определяется адрес контракта развертывания. Поэтому команда проекта использовала адрес создателя для моделирования и расчета адреса контракта заранее. На самом деле, многие аферы с выходом осуществляются через налоговые адреса, а характеристики режима развертывания налоговых адресов соответствуют пунктам 1 и 2 выше. В 11 часов утра (через 3 часа после создания токена) по адресу злоумышленника (2) (0x9DF4) был проведен Rug Pull. Вызвав метод «swapExactETHForTokens» налогового контракта (0x77fb), он обменял 416 483 104 164 831 токенов MUMI по налоговому адресу примерно на 9,736 ETH и исчерпал ликвидность в пуле.
Поскольку налоговый договор (0x77fb) не является открытым исходным кодом, мы декомпилировали его байткод, и результаты декомпиляции следующие:
https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c
После декомпиляции метода «swapExactETHForTokens» контракта по сбору налогов (0x77fb) мы обнаружили, что основная функциональность, реализованная этой функцией, заключается в обмене указанной суммы «xt» (указанной вызывающим) токенов MUMI, принадлежащих контракту по сбору налогов (0x77fb), на ETH с использованием маршрутизатора UniswapV2, а затем отправке ее на адрес, объявленный как «_manualSwap» в адресе налога.
Адрес хранения адреса _manualSwap - 0x0. После запроса с помощью команды getStorageAt json-rpc мы узнали, что адрес, соответствующий _manualSwap, точно соответствует развертывателю налогового контракта (0x77fb): атакующий ② (0x9DF4).
Параметр ввода xt этой транзакции по мошенничеству составляет 420 690 000 000 000 000 000 000, что соответствует 420 690 000 000 000 (приблизительно 420 триллионам) токенов MUMI (десятичная доля токенов MUMI составляет 9).
Другими словами, в итоге проект использовал 420 690 000 000 000 (примерно 420 триллионов) MUMI, чтобы слить WETH в пуле ликвидности и завершить всю аферу с выходом. Однако здесь возникает важный вопрос: откуда контракт о сборе налогов (0x77fb) взял столько токенов MUMI? Из предыдущего контента мы узнали, что общее количество токенов MUMI на момент развертывания составляло 420 690 000 (примерно 420 миллионов). Однако после окончания схемы rug pull, когда мы запросили общее предложение токенов в контракте токена MUMI, оно осталось на уровне 420 690 000 (как показано на рисунке ниже, отображается как 420 690 000 000 000 000, что требует вычитания конечных нулей, соответствующих десятичной дроби, где десятичная дробь равна 9). Токены в контракте на сбор налогов (0x77fb), намного превышающие общее предложение (420 690 000 000 000, примерно 420 триллионов), кажется, появились из воздуха. Стоит отметить, что, как уже упоминалось ранее, адрес 0x77fb, выступающий в качестве налогового адреса, даже не использовался для получения комиссий за транзакции, генерируемых в процессе перевода токенов MUMI; Налог получил сам токен-контракт.
Для изучения исходного токена налогового контракта (0x7ffb) мы рассмотрели историю событий передачи его ERC20.
Результаты показали, что из всех 6 событий перевода, связанных с 0x77fb, наблюдались только события, когда токены были переведены из договора о взыскании налогов (0x7ffb), при этом ни одного случая передачи токенов MUMI не было. На первый взгляд действительно кажется, что токены в договоре о взыскании налогов (0x7ffb) появились на пустом месте. Таким образом, значительное количество токенов MUMI, появляющееся, казалось бы, из воздуха в договоре о сборе налогов (0x7ffb), имеет две характеристики: 1. Это не повлияло на общее предложение контракта MUMI. 2. Увеличение количества токенов не привело к возникновению события Transfer. Имея это в виду, становится очевидным, что в контракте токена MUMI должен быть бэкдор, напрямую модифицирующий переменную balance без соответствующих изменений totalSupply или запуска событий Transfer. Другими словами, это нестандартная или вредоносная реализация токена ERC20, где пользователи не могут воспринять скрытую минтинг токенов командой проекта от изменений в общем предложении или событиях. Следующим шагом является проверка этой идеи путем прямого поиска ключевого слова «balance» в исходном коде контракта токена MUMI.
В результате мы обнаружили, что в контракте есть частная функция типа “swapTokensForEth”, и входным параметром является tokenAmount типа uint256. На 5-й строке функции проектная сторона напрямую изменяет _taxWallet, который является балансом MUMI налогового контракта (0x7ffb) для tokenAmount 10*_decimals, которые в 1,000,000,000 (приблизительно 1 миллиард) раз превышают tokenAmount, а затем конвертировать количество токенов MUMI в ETH из пула ликвидности и сохранить его в контракте токена (0x4894). Затем искать ключевое слово “swapTokenForEth”.
Функция «swapTokenForEth» вызывается внутри функции «_transfer». При ближайшем рассмотрении условий вызова наблюдается следующее: 1. Когда адрес получателя (адрес назначения) трансфера является пулом ликвидности MUMI-WETH. 2. Функция «swapTokenForEth» вызывается только тогда, когда количество токенов MUMI, купленных другими адресами в пуле ликвидности, превышает «_preventSwapBefore» (5 раз). 3. Параметр «tokenAmount», передаваемый в функцию, является минимальным значением между балансом токенов MUMI, принадлежащих адресу токена, и «_maxTaxSwap».
То есть, когда контракт обнаруживает, что пользователь обменял WETH на токены MUMI в пуле более 5 раз, он тайно чеканит огромное количество токенов для налогового адреса и преобразует часть токенов в ETH, сохраняя их в токен-контракте. С одной стороны, проектная команда явно собирает налоги и автоматически обменивает их на небольшое количество ETH регулярно, и помещает их в токен-контракт. Это показывается пользователям и заставляет всех думать, что это источник прибыли для проектной команды. С другой стороны, то, что на самом деле делает команда проекта, - это непосредственное изменение баланса счета и слив всего пула ликвидности после того, как количество пользовательских транзакций достигает 5 раз.
После выполнения функции «swapTokenForEth» функция «_transfer» также выполнит sendETHToFee для отправки ETH, полученного из сбора налогов на адрес токена, в налоговый контракт (0x77fb).
ETH в налоговом контракте (0x77fb) можно извлечь с помощью функции «спасения», реализованной в его контракте.
Теперь посмотрите на запись о погашении последней прибыльной сделки во всей схеме мошенничества при выходе.
Всего в прибыльной сделке было совершено два обмена. В первый раз было 4 164 831 (примерно 4,16 миллиона) токенов MUMI за 0,349 ETH, а во второй раз — 416 483 100 000 000 (примерно 416 триллионов) токенов MUMI за 9,368 ETH. Второй обмен – это обмен, инициированный в рамках функции "swapExactETHForTokens" в налоговом контракте (0x7ffb). Причина, по которой это число не соответствует 420 690 000 000 000 000 (примерно 420 триллионов) токенов, представленных входными параметрами, заключается в том, что некоторые из токенов используются в качестве налога, отправляемого в контракт токена (0x4894), как показано на рисунке ниже:
Первая биржа соответствует процессу второй биржи. Когда токен отправляется из налогового контракта (0x7ffb) в контракт маршрутизатора, выполняется условие срабатывания функции задней двери в контракте токена, вызывая срабатывание “swapTokensForEth”. Обмен, инициированный функцией, не является критической операцией.
Как видно из предыдущего контента, весь цикл токена MUMI, от развертывания до создания пула ликвидности, а затем до Мошенничества, занял всего около 3 часов. Тем не менее, он смог получить более 50% прибыли с затратами менее примерно 6,5 ETH (3 ETH на добавление ликвидности, 3 ETH на обмен MUMI из пула ликвидности в качестве приманки и менее 0,5 ETH на развертывание контракта и инициирование транзакций), что привело к 9,7 ETH. Атакующий совершил пять транзакций обмена ETH на MUMI, о которых ранее не упоминалось. Детали транзакций следующие:
При анализе внешнеуправляемых счетов (EOA), работающих в пределах ликвидности, было обнаружено, что значительная часть адресов принадлежала онлайн-ботам. Учитывая быстрое проведение всей аферы, можно предположить, что целью этой аферы были различные активные боты и скрипты на цепочке. Поэтому как сложное, кажущееся ненужное, но сложное проектирование контракта, развертывание контракта, процесс блокировки ликвидности, так и подозрительное поведение атакующих, активно обменивающих ETH на токены MUMI посередине, можно понимать как попытки атакующих обмануть различные анти-мошеннические механизмы онлайн-ботов. Следя за движением средств, было обнаружено, что все полученные от атаки прибыли в конечном итоге были отправлены атакующим адресом ② (0x9dF4) на адрес 0xDF1a.
На самом деле как исходные источники финансирования, так и конечные пункты назначения нескольких недавних мошенничеств указывали на этот адрес. Поэтому был проведен грубый анализ и статистика транзакций этого адреса. Было обнаружено, что адрес стал активным приблизительно 2 месяца назад и с тех пор инициировал более 7 000 транзакций, взаимодействуя с более чем 200 токенами. Из примерно 40 проанализированных записей о транзакциях токенов было обнаружено, что практически все токены, когда их просматривают в соответствующих пулах ликвидности, имеют одну крупную биржевую транзакцию, которая истощает весь ETH в пуле ликвидности, и весь цикл мошенничества завершается быстро. Вот транзакции развертывания некоторых токенов (например, китайские сигареты):
https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17
https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f
Таким образом, можно сделать вывод, что этот адрес, фактически, является крупным автоматизированным сборщиком "exit scam", нацеленным на бот-операции on-chain. Этот адрес все еще активен.
В заключение, если процесс эмиссии токенов не соответствует изменению totalSupply или запуску событий Transfer, нам сложно определить, майнит ли команда проекта токены втайне. Это ухудшает текущую ситуацию, когда безопасность токенов полностью зависит от сознательности команды проекта. Поэтому может потребоваться рассмотреть улучшение существующих механизмов токенов или внедрение эффективной схемы мониторинга общего объема токенов для обеспечения прозрачности изменений в количестве токенов. Основываться только на событиях для отслеживания изменений состояния токенов недостаточно. Более того, нужно понимать, что хотя осведомленность людей о предотвращении мошенничества растет, методы атакующих в области противодействия мошенничеству также совершенствуются. Это бесконечная игра, и нам нужно продолжать учиться и размышлять, чтобы защитить себя.
Просмотр базовой информации о транзакции: https://etherscan.io/
Декомпиляция контракта: app.dedaub.com/decompilejson-rpc: https://www.quicknode.com/docs/ethereum/eth_getStorageAt
Compartir
Пересылка оригинального заголовка '技术详解 | 链上打新局中局,大规模Rug Pull手法解密'
В последнее время эксперты по безопасности CertiK часто обнаруживают несколько случаев одного и того же метода мошенничества при выходе, широко известного как Rug Pull. При дальнейшем расследовании мы обнаружили, что несколько экземпляров одного и того же метода указывают на одну и ту же группу, что в конечном итоге связано с более чем 200 мошенничеством с выходом токенов. Это говорит о том, что мы, возможно, раскрыли крупномасштабную автоматизированную хакерскую группу, которая собирает активы с помощью мошенничества с выходом. В этих аферах злоумышленники создают новый токен ERC20 и используют предварительно добытые токены вместе с определенным количеством WETH для создания пула ликвидности Uniswap V2. После того, как боты или пользователи в цепочке совершат определенное количество покупок нового токена из пула ликвидности, злоумышленник истощит все WETH в пуле токенами, сгенерированными из воздуха. Поскольку токены, полученные злоумышленником из воздуха, не отражаются в общем предложении и не запускают события Transfer, они не видны на etherscan, что затрудняет их обнаружение посторонними. Злоумышленники не только думают о сокрытии, но и придумывают уловки, чтобы обмануть пользователей с базовыми техническими навыками, которые проверяют etherscan, используя незначительную проблему, чтобы скрыть свои истинные намерения...
Углубленное мошенничество
Используя один из случаев в качестве примера, давайте поглубже вникнем в детали этого мошенничества на выходе. То, что мы обнаружили, это транзакция, в которой злоумышленник использовал огромное количество токенов (тихо созданных) для истощения пула ликвидности и извлечения прибыли. В этой транзакции команде проекта обменяли примерно 416 483 104 164 831 (около 416 квадриллионов) токенов MUMI на примерно 9.736 WETH, исчерпывая ликвидность пула. Однако эта транзакция является лишь последней частью всего мошенничества. Чтобы понять всю суть мошенничества, нам нужно продолжить отслеживание в обратном направлении.
6 марта в 7:52 (по времени UTC, так же и далее) адрес атакующего (0x8AF8) развернул токен ERC20 под названием MUMI (полное название MultiMixer AI) по адресу 0x4894 и предварительно добыл 420 690 000 (около 420 миллионов) токенов, все выделены для развертывателя контракта.
Количество заранее добытых токенов соответствует исходному коду контракта.
В точку в 8 часов (8 минут после создания токена) адрес атакующего (0x8AF8) начал добавлять ликвидность. Адрес атакующего (0x8AF8) вызывает функцию openTrading в контракте токена, создает пул ликвидности MUMI-WETH через фабрику uniswap v2, добавляет все предварительно добытые токены и 3 ETH в пул ликвидности, и в конечном итоге получает примерно 1,036 токен LP.
Из деталей транзакции видно, что изначально для добавления ликвидности было использовано 420 690 000 (приблизительно 420 миллионов) токенов, и примерно 63 103 500 (приблизительно 63 миллиона) токенов были отправлены обратно в контракт токена (адрес 0x4894). Просмотрев исходный код контракта, было обнаружено, что контракт токена будет взимать определенную комиссию за каждую трансфер, и адрес для сбора комиссии является сам контракт токена (конкретно реализовано в функции «_transfer»).
Странно то, что адрес налога 0x7ffb (адрес для сбора комиссии за трансфер) был установлен в контракте, но конечная комиссия была отправлена самому контракту токена.
Таким образом, окончательное количество токенов MUMI, добавленных в пул ликвидности, составляет 357 586 500 (приблизительно 350 миллионов) после уплаты налогов, а не 420 690 000 (приблизительно 430 миллионов).
В 8:01 (через 1 минуту после создания пула ликвидности) адрес атакующего (0x8AF8) заблокировал все 1,036 токенов LP, полученных при добавлении ликвидности.
После блокировки ЛП теоретически все токены MUMI, принадлежащие адресу атакующего (0x8AF8), блокируются в пуле ликвидности (за исключением той части, которая используется в качестве комиссионных сборов), поэтому адрес атакующего (0x8AF8) не имеет возможности удалить его через возможность ликвидности для выполнения Раг-Пулла. Чтобы позволить пользователям покупать только что запущенные токены с уверенностью, многие проектные стороны блокируют ЛП, что означает, что проектная сторона говорит: «Я не убегу, все могут покупать с уверенностью!», но так ли это на самом деле? Очевидно, что нет, это так, давайте продолжим анализ.
В 8:10 появился новый адрес атакующего ② (0x9DF4), и он развернул налоговый адрес 0x7ffb, объявленный в контракте токена.
Здесь стоит упомянуть три момента: 1. Адрес, по которому развернут налоговый адрес, и адрес, по которому развернуты токены, не совпадают. Это может указывать на то, что сторона проекта намеренно уменьшает корреляцию между каждой операцией и адресом, что затрудняет отслеживание поведения. 2. Контракт налогового адреса не является открытым исходным кодом, а это означает, что в налоговом адресе могут быть скрытые операции, которые не хотят быть раскрытыми. 3. Налоговый контракт разворачивается позже, чем токен-контракт, а налоговый адрес в токен-контракте жестко закодирован, что означает, что адрес налогового контракта может быть заранее предсказан командой проекта. Так как инструкция CREATE определяет адрес создателя и одноразовый номер, определяется адрес контракта развертывания. Поэтому команда проекта использовала адрес создателя для моделирования и расчета адреса контракта заранее. На самом деле, многие аферы с выходом осуществляются через налоговые адреса, а характеристики режима развертывания налоговых адресов соответствуют пунктам 1 и 2 выше. В 11 часов утра (через 3 часа после создания токена) по адресу злоумышленника (2) (0x9DF4) был проведен Rug Pull. Вызвав метод «swapExactETHForTokens» налогового контракта (0x77fb), он обменял 416 483 104 164 831 токенов MUMI по налоговому адресу примерно на 9,736 ETH и исчерпал ликвидность в пуле.
Поскольку налоговый договор (0x77fb) не является открытым исходным кодом, мы декомпилировали его байткод, и результаты декомпиляции следующие:
https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c
После декомпиляции метода «swapExactETHForTokens» контракта по сбору налогов (0x77fb) мы обнаружили, что основная функциональность, реализованная этой функцией, заключается в обмене указанной суммы «xt» (указанной вызывающим) токенов MUMI, принадлежащих контракту по сбору налогов (0x77fb), на ETH с использованием маршрутизатора UniswapV2, а затем отправке ее на адрес, объявленный как «_manualSwap» в адресе налога.
Адрес хранения адреса _manualSwap - 0x0. После запроса с помощью команды getStorageAt json-rpc мы узнали, что адрес, соответствующий _manualSwap, точно соответствует развертывателю налогового контракта (0x77fb): атакующий ② (0x9DF4).
Параметр ввода xt этой транзакции по мошенничеству составляет 420 690 000 000 000 000 000 000, что соответствует 420 690 000 000 000 (приблизительно 420 триллионам) токенов MUMI (десятичная доля токенов MUMI составляет 9).
Другими словами, в итоге проект использовал 420 690 000 000 000 (примерно 420 триллионов) MUMI, чтобы слить WETH в пуле ликвидности и завершить всю аферу с выходом. Однако здесь возникает важный вопрос: откуда контракт о сборе налогов (0x77fb) взял столько токенов MUMI? Из предыдущего контента мы узнали, что общее количество токенов MUMI на момент развертывания составляло 420 690 000 (примерно 420 миллионов). Однако после окончания схемы rug pull, когда мы запросили общее предложение токенов в контракте токена MUMI, оно осталось на уровне 420 690 000 (как показано на рисунке ниже, отображается как 420 690 000 000 000 000, что требует вычитания конечных нулей, соответствующих десятичной дроби, где десятичная дробь равна 9). Токены в контракте на сбор налогов (0x77fb), намного превышающие общее предложение (420 690 000 000 000, примерно 420 триллионов), кажется, появились из воздуха. Стоит отметить, что, как уже упоминалось ранее, адрес 0x77fb, выступающий в качестве налогового адреса, даже не использовался для получения комиссий за транзакции, генерируемых в процессе перевода токенов MUMI; Налог получил сам токен-контракт.
Для изучения исходного токена налогового контракта (0x7ffb) мы рассмотрели историю событий передачи его ERC20.
Результаты показали, что из всех 6 событий перевода, связанных с 0x77fb, наблюдались только события, когда токены были переведены из договора о взыскании налогов (0x7ffb), при этом ни одного случая передачи токенов MUMI не было. На первый взгляд действительно кажется, что токены в договоре о взыскании налогов (0x7ffb) появились на пустом месте. Таким образом, значительное количество токенов MUMI, появляющееся, казалось бы, из воздуха в договоре о сборе налогов (0x7ffb), имеет две характеристики: 1. Это не повлияло на общее предложение контракта MUMI. 2. Увеличение количества токенов не привело к возникновению события Transfer. Имея это в виду, становится очевидным, что в контракте токена MUMI должен быть бэкдор, напрямую модифицирующий переменную balance без соответствующих изменений totalSupply или запуска событий Transfer. Другими словами, это нестандартная или вредоносная реализация токена ERC20, где пользователи не могут воспринять скрытую минтинг токенов командой проекта от изменений в общем предложении или событиях. Следующим шагом является проверка этой идеи путем прямого поиска ключевого слова «balance» в исходном коде контракта токена MUMI.
В результате мы обнаружили, что в контракте есть частная функция типа “swapTokensForEth”, и входным параметром является tokenAmount типа uint256. На 5-й строке функции проектная сторона напрямую изменяет _taxWallet, который является балансом MUMI налогового контракта (0x7ffb) для tokenAmount 10*_decimals, которые в 1,000,000,000 (приблизительно 1 миллиард) раз превышают tokenAmount, а затем конвертировать количество токенов MUMI в ETH из пула ликвидности и сохранить его в контракте токена (0x4894). Затем искать ключевое слово “swapTokenForEth”.
Функция «swapTokenForEth» вызывается внутри функции «_transfer». При ближайшем рассмотрении условий вызова наблюдается следующее: 1. Когда адрес получателя (адрес назначения) трансфера является пулом ликвидности MUMI-WETH. 2. Функция «swapTokenForEth» вызывается только тогда, когда количество токенов MUMI, купленных другими адресами в пуле ликвидности, превышает «_preventSwapBefore» (5 раз). 3. Параметр «tokenAmount», передаваемый в функцию, является минимальным значением между балансом токенов MUMI, принадлежащих адресу токена, и «_maxTaxSwap».
То есть, когда контракт обнаруживает, что пользователь обменял WETH на токены MUMI в пуле более 5 раз, он тайно чеканит огромное количество токенов для налогового адреса и преобразует часть токенов в ETH, сохраняя их в токен-контракте. С одной стороны, проектная команда явно собирает налоги и автоматически обменивает их на небольшое количество ETH регулярно, и помещает их в токен-контракт. Это показывается пользователям и заставляет всех думать, что это источник прибыли для проектной команды. С другой стороны, то, что на самом деле делает команда проекта, - это непосредственное изменение баланса счета и слив всего пула ликвидности после того, как количество пользовательских транзакций достигает 5 раз.
После выполнения функции «swapTokenForEth» функция «_transfer» также выполнит sendETHToFee для отправки ETH, полученного из сбора налогов на адрес токена, в налоговый контракт (0x77fb).
ETH в налоговом контракте (0x77fb) можно извлечь с помощью функции «спасения», реализованной в его контракте.
Теперь посмотрите на запись о погашении последней прибыльной сделки во всей схеме мошенничества при выходе.
Всего в прибыльной сделке было совершено два обмена. В первый раз было 4 164 831 (примерно 4,16 миллиона) токенов MUMI за 0,349 ETH, а во второй раз — 416 483 100 000 000 (примерно 416 триллионов) токенов MUMI за 9,368 ETH. Второй обмен – это обмен, инициированный в рамках функции "swapExactETHForTokens" в налоговом контракте (0x7ffb). Причина, по которой это число не соответствует 420 690 000 000 000 000 (примерно 420 триллионов) токенов, представленных входными параметрами, заключается в том, что некоторые из токенов используются в качестве налога, отправляемого в контракт токена (0x4894), как показано на рисунке ниже:
Первая биржа соответствует процессу второй биржи. Когда токен отправляется из налогового контракта (0x7ffb) в контракт маршрутизатора, выполняется условие срабатывания функции задней двери в контракте токена, вызывая срабатывание “swapTokensForEth”. Обмен, инициированный функцией, не является критической операцией.
Как видно из предыдущего контента, весь цикл токена MUMI, от развертывания до создания пула ликвидности, а затем до Мошенничества, занял всего около 3 часов. Тем не менее, он смог получить более 50% прибыли с затратами менее примерно 6,5 ETH (3 ETH на добавление ликвидности, 3 ETH на обмен MUMI из пула ликвидности в качестве приманки и менее 0,5 ETH на развертывание контракта и инициирование транзакций), что привело к 9,7 ETH. Атакующий совершил пять транзакций обмена ETH на MUMI, о которых ранее не упоминалось. Детали транзакций следующие:
При анализе внешнеуправляемых счетов (EOA), работающих в пределах ликвидности, было обнаружено, что значительная часть адресов принадлежала онлайн-ботам. Учитывая быстрое проведение всей аферы, можно предположить, что целью этой аферы были различные активные боты и скрипты на цепочке. Поэтому как сложное, кажущееся ненужное, но сложное проектирование контракта, развертывание контракта, процесс блокировки ликвидности, так и подозрительное поведение атакующих, активно обменивающих ETH на токены MUMI посередине, можно понимать как попытки атакующих обмануть различные анти-мошеннические механизмы онлайн-ботов. Следя за движением средств, было обнаружено, что все полученные от атаки прибыли в конечном итоге были отправлены атакующим адресом ② (0x9dF4) на адрес 0xDF1a.
На самом деле как исходные источники финансирования, так и конечные пункты назначения нескольких недавних мошенничеств указывали на этот адрес. Поэтому был проведен грубый анализ и статистика транзакций этого адреса. Было обнаружено, что адрес стал активным приблизительно 2 месяца назад и с тех пор инициировал более 7 000 транзакций, взаимодействуя с более чем 200 токенами. Из примерно 40 проанализированных записей о транзакциях токенов было обнаружено, что практически все токены, когда их просматривают в соответствующих пулах ликвидности, имеют одну крупную биржевую транзакцию, которая истощает весь ETH в пуле ликвидности, и весь цикл мошенничества завершается быстро. Вот транзакции развертывания некоторых токенов (например, китайские сигареты):
https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17
https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f
Таким образом, можно сделать вывод, что этот адрес, фактически, является крупным автоматизированным сборщиком "exit scam", нацеленным на бот-операции on-chain. Этот адрес все еще активен.
В заключение, если процесс эмиссии токенов не соответствует изменению totalSupply или запуску событий Transfer, нам сложно определить, майнит ли команда проекта токены втайне. Это ухудшает текущую ситуацию, когда безопасность токенов полностью зависит от сознательности команды проекта. Поэтому может потребоваться рассмотреть улучшение существующих механизмов токенов или внедрение эффективной схемы мониторинга общего объема токенов для обеспечения прозрачности изменений в количестве токенов. Основываться только на событиях для отслеживания изменений состояния токенов недостаточно. Более того, нужно понимать, что хотя осведомленность людей о предотвращении мошенничества растет, методы атакующих в области противодействия мошенничеству также совершенствуются. Это бесконечная игра, и нам нужно продолжать учиться и размышлять, чтобы защитить себя.
Просмотр базовой информации о транзакции: https://etherscan.io/
Декомпиляция контракта: app.dedaub.com/decompilejson-rpc: https://www.quicknode.com/docs/ethereum/eth_getStorageAt