Переслати оригінальний заголовок’技术详解 | Ланцюговий новий спосіб гри відкриває нову главу, розшифровується шахрайство великого масштабу’

Останнім часом експерти з безпеки CertiK часто виявляли кілька випадків одного і того ж методу шахрайства на виході, широко відомого як Rug Pull. Під час подальшого розслідування ми виявили, що кілька випадків одного і того ж методу вказують на одну і ту ж групу, в кінцевому підсумку пов'язану з більш ніж 200 шахрайствами з виходом з Token. Це говорить про те, що ми, можливо, викрили масштабну автоматизовану хакерську групу, яка збирає активи за допомогою шахрайства з виходом. У цих шахрайствах на виході зловмисники створюють новий токен 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, отриманих шляхом додавання ліквідності.

Після того, як LP заблоковано, теоретично всі токени MUMI, що належать адресі атакуючого (0x8AF8), заблоковані в ліквідному пулі (крім частини, використаної як комісійні), тому адреса атакуючого (0x8AF8) не має можливості видалити її через Ліквідність можливість виконати шахрайство. Щоб дозволити користувачам купувати нові випущені токени з впевненістю, багато проектних сторін блокують LP, що означає, що проектна сторона каже: «Я не втечу, всі можуть купувати з впевненістю!», Але чи дійсно це так? Очевидно, що ні, це так, продовжимо аналіз.

Шахрайство

О 8:10 з'явилася нова адреса атакування ② (0x9DF4), і він розгорнув адресу оподаткування 0x7ffb, заявлену в контракті токену.

Тут варто згадати три моменти: 1. Адреса, на якій розгорнута податкова адреса, і адреса, на якій розгортаються токени, не збігаються. Це може свідчити про те, що сторона проекту навмисно зменшує кореляцію між кожною операцією та адресою, що ускладнює відстеження поведінки. 2. Договір податкової адреси не є відкритим вихідним кодом, а це означає, що в податковій адресі можуть бути приховані операції, які не хочуть бути викритими. 3. Податковий контракт розгортається пізніше, ніж контракт токена, а податкова адреса в контракті токена була жорстко закодована, що означає, що адреса податкового контракту може бути передбачена командою проекту заздалегідь. Оскільки інструкція CREATE визначає адресу творця та nonce, визначається адреса контракту розгортання. Тому команда проекту використовувала адресу творця, щоб заздалегідь змоделювати та розрахувати адресу контракту. Насправді, багато шахрайств на виході здійснюються через податкові адреси, а характеристики режиму розгортання податкових адрес відповідають пунктам 1 і 2 вище. Об 11 годині ранку (через 3 години після створення токена) адреса зловмисника (2) (0x9DF4) провела Rug Pull. Назвавши метод «swapExactETHForTokens» податкового контракту (0x77fb), він обміняв 416 483 104 164 831 (приблизно 416 трильйонів) токенів 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 цієї транзакції Rug Pull становить 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 мільйонів). Однак після закінчення схеми перетягування килима, коли ми запитали загальну пропозицію токенів у контракті на токен 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. Це не вплинуло на загальнупропозицію контракту MOMI. 2. Збільшення токенів не ініціювало подію Transfer. З огляду на це, стає очевидним, що в контракті токена MUMI повинен бути бекдор, який безпосередньо змінює змінну балансу без відповідних змін у totalSupply або запуску подій Transfer. Іншими словами, це нестандартна або зловмисна реалізація токена ERC20, де користувачі не можуть сприймати приховане карбування токенів командою проєкту зі зміни загальної пропозиції або подій. Наступним кроком є перевірка цієї ідеї шляхом безпосереднього пошуку ключового слова "balance" у вихідному коді контракту токена MUMI.

В результаті ми виявили, що в контракті є приватна функція типу «swapTokensForEth», а вхідний параметр - tokenAmount типу uint256. У 5-му рядку функції проектна сторона безпосередньо змінює _taxWallet, яке є балансом MUMI контракту податків (0x7ffb) для tokenAmount 10*_десятков, яке становить 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 (приблизно 420 трильйонів) токенів, що представлені вхідними параметрами, полягає в тому, що деякі токени використовуються як податок, відправлений на контракт токенів (0x4894), як показано на малюнку нижче:

Перший обмін відповідає другому процесу обміну. Коли токен надсилається з податкового контракту (0x7ffb) на контракт маршрутизатора, виконується умова спрацьовування функції бекдору в контракті токена, що призводить до спрацьовування "swapTokensForEth". Обмін, ініційований функцією, не є критичною операцією.

• Збирач за шахрайством

Як видно з попереднього контенту, весь цикл токену MUMI, від розгортання до створення пулу ліквідності, а потім до витягу шахраїв, зайняв всього близько 3 годин. Однак вдалося заробити понад 50% прибутку за вартістю менше, ніж приблизно 6.5 ETH (3 ETH для додавання ліквідності, 3 ETH для обміну MUMI з пулу ліквідності як приманки, і менше ніж 0.5 ETH для розгортання контракту та ініціювання транзакцій), що в результаті становить 9.7 ETH. Атакуючий здійснив п'ять транзакцій обміну ETH на MUMI, про які раніше не було згадано. Деталі транзакцій наступні:

• https://etherscan.io/tx/0x62a59ba219e9b2b6ac14a1c35cb99a5683538379235a68b3a607182d7c814817
• https://etherscan.io/tx/0x0c9af78f983aba6fef85bf2ecccd6cd68a5a5d4e5ef3a4b1e94fb10898fa597e
• https://etherscan.io/tx/0xc0a048e993409d0d68450db6ff3fdc1f13474314c49b734bac3f1b3e0ef39525
• https://etherscan.io/tx/0x9874c19cedafec351939a570ef392140c46a7f7da89b8d125cabc14dc54e7306
• https://etherscan.io/tx/0x9ee3928dc782e54eb99f907fcdddc9fe6232b969a080bc79caa53ca143736f75

Під час аналізу зовнішніх власниць облікових записів (EOA), які працюють у ліквідності, було виявлено, що значна частина адрес належала онлайн-операціям "ботів" на ланцюжку. Беручи до уваги швидку природу всього шахрайства, розумно припустити, що метою цього шахрайства були різні активні "боти" та сценарії на ланцюжку. Тому незалежно від того, чи це здається непотрібною, але складною конструкцією контракту, розгортанням контракту, процесом блокування ліквідності, або підозрілими діями нападників, які активно міняли ETH на токени MUMI посередині шляху, все це можна розглядати як спроби нападників обманути різноманітні антишахрайні механізми онлайн-ботів. Відстежуючи рух коштів, було виявлено, що всі прибутки, отримані в результаті атаки, нарешті були відправлені нападаючою адресою ② (0x9dF4) на адресу 0xDF1a.

Насправді як початкові джерела фінансування, так і кінцеві пункти множинних недавніх виходів з гришми вказують на цю адресу. Тому було проведено приблизний аналіз та статистика транзакцій цієї адреси. Виявлено, що адреса стала активною приблизно 2 місяці тому і до цього часу ініціювала понад 7 000 транзакцій, взаємодіючи з понад 200 токенами. З серед близько 40 проаналізованих записів про транзакції токенів було виявлено, що майже всі токени, коли їх розглядали в відповідних пулах ліквідності, мали одну велику обмінну транзакцію, що вичерпувала всі ETH в пулі ліквідності, і весь цикл шахрайства з виходом з гришми короткий. Ось транзакції розгортання деяких токенів (наприклад, китайські сигарети):

https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17

https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f

Отже, можна зробити висновок, що ця адреса фактично є великомасштабним автоматизованим «вихідним обманом», спрямованим на операції ботів on-chain. Ця адреса все ще активна.

У висновку, якщо процес емісії токенів не відповідає зміні totalSupply або спричиненню подій Transfer, нам важко усвідомити, чи таємно емітує токени команди проекту. Це ускладнює поточну ситуацію, де безпека токенів повністю залежить від свідомості команди проекту. Тому може бути необхідно розглянути покращення існуючих механізмів токенів або впровадження ефективної схеми моніторингу загального обсягу токенів, щоб забезпечити прозорість у змінах кількості токенів. Покладатися виключно на події для відстеження змін стану токенів недостатньо. Крім того, ми повинні усвідомлювати, що хоча усвідомлення про запобігання шахрайству збільшується, методи контршахрайства зловмисників також розвиваються. Це безкінечна гра, і нам потрібно продовжувати вчитися і думати, щоб захистити себе.

• Інструменти, використані в цій статті

Переглянути основну інформацію про транзакцію: https://etherscan.io/

Декомпіляція контракту: app.dedaub.com/decompilejson-rpc: https://www.quicknode.com/docs/ethereum/eth_getStorageAt

Disclaimer：

1. Ця стаття надрукована з [ CertiK], Переслати оригінальну назву'技术详解 | 链上打新局中局,大规模Rug Pull手法解密'. Усі авторські права належать оригінальному автору [CertiK]. Якщо є зауваження до цього перевидання, будь ласка, звертайтеся до Ворота Навчаннякоманди, і вони оперативно вирішать це.
2. Відповідальність за відмови: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодних інвестиційних порад.
3. Переклади статей на інші мови здійснює команда Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.