‘Forward the Original Title’技术详解 | 链上打新局中局，大规模Rug Pull手法解密’

Baru-baru ini, para ahli keamanan CertiK sering mendeteksi beberapa kasus menggunakan metode penipuan keluar yang sama, yang umumnya dikenal sebagai Rug Pull. Setelah penyelidikan lebih lanjut, kami menemukan bahwa beberapa kasus yang sama menunjuk pada kelompok yang sama, akhirnya terkait dengan lebih dari 200 penipuan keluar Token. Hal ini menunjukkan bahwa kami mungkin telah mengungkap kelompok peretas otomatis berskala besar yang mengumpulkan aset melalui penipuan keluar. Dalam penipuan keluar ini, penyerang membuat token ERC20 baru dan menggunakan token yang telah ditambang sebelumnya bersama dengan sejumlah WETH untuk membuat kolam likuiditas Uniswap V2. Setelah bot atau pengguna di rantai melakukan sejumlah pembelian token baru dari kolam likuiditas, penyerang akan menghabiskan semua WETH di kolam dengan token yang dihasilkan dari udara. Karena token yang diperoleh oleh penyerang dari udara tidak tercermin dalam pasokan total dan tidak memicu peristiwa Transfer, mereka tidak terlihat di etherscan, membuat sulit bagi pihak luar untuk mendeteksinya. Penyerang tidak hanya mempertimbangkan penyembunyian tetapi juga merancang suatu tipuan untuk menipu pengguna dengan keterampilan teknis dasar yang memeriksa etherscan, menggunakan masalah kecil untuk menyembunyikan niat sebenarnya...

Selami penipuan

Penipuan Kedalaman

Menggunakan salah satu kasus sebagai contoh, mari kita telusuri detail dari penipuan ini. Apa yang kami deteksi adalah transaksi di mana penyerang menggunakan sejumlah besar token (dibuat secara diam-diam) untuk menguras kolam likuiditas dan mendapatkan keuntungan. Dalam transaksi ini, tim proyek menukar sekitar 416,483,104,164,831 (sekitar 416 kuadriliun) token MUMI dengan sekitar 9.736 WETH, menguras likuiditas kolam. Namun, transaksi ini hanya bagian akhir dari seluruh penipuan. Untuk memahami seluruh penipuan, kita perlu melanjutkan melacak ke belakang.

Menerapkan token

Pada 6 Maret pukul 7:52 AM (waktu UTC, sama untuk selanjutnya), alamat penyerang (0x8AF8) mendeploy token ERC20 bernama MUMI (nama lengkap MultiMixer AI) di alamat 0x4894 dan melakukan pre-mining sebanyak 420.690.000 (sekitar 420 juta) token, semuanya dialokasikan kepada pengembang kontrak.

Jumlah token pra-ditambang sesuai dengan kode sumber kontrak.

Tambahkan likuiditas

Pukul 8 tepat waktu (8 menit setelah token dibuat), alamat penyerang (0x8AF8) mulai menambahkan likuiditas. Alamat penyerang (0x8AF8) memanggil fungsi openTrading dalam kontrak token, membuat kolam likuiditas MUMI-WETH melalui pabrik uniswap v2, menambahkan semua token yang telah ditambang sebelumnya dan 3 ETH ke kolam likuiditas, dan akhirnya mendapatkan sekitar 1,036 token LP.

Dari rincian transaksi dapat dilihat bahwa dari 420.690.000 (sekitar 420 juta) token yang awalnya digunakan untuk menambah likuiditas, sekitar 63.103.500 (sekitar 63 juta) token dikirim kembali ke kontrak token (alamat 0x4894). Dengan melihat kode sumber kontrak, ditemukan bahwa kontrak token akan mengenakan biaya penanganan tertentu untuk setiap transfer, dan alamat untuk mengumpulkan biaya penanganan adalah kontrak token itu sendiri (diimplementasikan secara khusus dalam fungsi "_transfer").

Yang aneh adalah bahwa alamat pajak 0x7ffb (alamat untuk mengumpulkan biaya transfer) telah diatur dalam kontrak, tetapi biaya akhirnya dikirim ke kontrak token itu sendiri.

Oleh karena itu, jumlah akhir token MUMI yang ditambahkan ke kolam likuiditas adalah 357.586.500 (sekitar 350 juta) setelah pajak, bukan 420.690.000 (sekitar 430 juta).

Kunci likuiditas

Pada pukul 8:01 (1 menit setelah kolam likuiditas dibuat), alamat penyerang (0x8AF8) mengunci semua 1.036 token LP yang diperoleh dengan menambahkan likuiditas.

Setelah LP dikunci, secara teoritis semua token MUMI yang dimiliki oleh alamat penyerang (0x8AF8) terkunci di kolam likuiditas (kecuali bagian yang digunakan sebagai biaya penanganan), jadi alamat penyerang (0x8AF8) tidak memiliki kemampuan untuk menghapusnya melalui kemampuan Likuiditas untuk melakukan Rug Pull. Agar pengguna dapat membeli token yang baru diluncurkan dengan percaya diri, banyak pihak proyek mengunci LP, yang berarti pihak proyek mengatakan: "Saya tidak akan lari, semua orang bisa membeli dengan percaya diri!", tetapi apakah ini benar-benar kasus ini? ? Jelas tidak, ini adalah kasus, mari kita lanjutkan analisisnya.

Rug Pull

Pada pukul 8:10, alamat penyerang baru ② (0x9DF4) muncul, dan dia mendeploy alamat pajak 0x7ffb yang dideklarasikan dalam kontrak token.

Ada tiga poin yang layak disebutkan di sini: 1. Alamat tempat alamat pajak digunakan dan alamat tempat token digunakan tidak sama. Ini mungkin menunjukkan bahwa pihak proyek sengaja mengurangi korelasi antara setiap operasi dan alamat, sehingga lebih sulit untuk melacak perilaku. 2. Kontrak alamat pajak bukan open source, yang berarti mungkin ada operasi tersembunyi di alamat pajak yang tidak ingin diekspos. 3. Kontrak pajak digunakan lebih lambat dari kontrak token, dan alamat pajak dalam kontrak token telah dikodekan secara keras, yang berarti alamat kontrak pajak dapat diprediksi oleh tim proyek terlebih dahulu. Karena instruksi CREATE menentukan alamat pembuat dan nonce, alamat kontrak penyebaran ditentukan. Oleh karena itu, tim proyek menggunakan alamat pembuat untuk mensimulasikan dan menghitung alamat kontrak terlebih dahulu. Faktanya, banyak penipuan keluar dilakukan melalui alamat pajak, dan karakteristik mode penyebaran alamat pajak sesuai dengan poin 1 dan 2 di atas. Pada pukul 11 pagi (3 jam setelah token dibuat), alamat penyerang (2) (0x9DF4) melakukan Rug Pull. Dengan memanggil metode "swapExactETHForTokens" dari kontrak pajak (0x77fb), ia menukar 416.483.104.164.831 (sekitar 416 triliun) token MUMI di alamat pajak untuk sekitar 9,736 ETH, dan menghabiskan likuiditas di kumpulan.

Karena kontrak pajak (0x77fb) bukan open source, kami mendekompilasi bytecode-nya dan hasil dekompilasi adalah sebagai berikut:

https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c

Setelah mendekompilasi metode “swapExactETHForTokens” dari kontrak pengumpulan pajak (0x77fb), kami menemukan bahwa fungsionalitas utama yang diimplementasikan oleh fungsi ini adalah menukar jumlah yang ditentukan “xt” (ditentukan oleh pemanggil) dari token MUMI yang dimiliki oleh kontrak pengumpulan pajak (0x77fb) menjadi ETH menggunakan router UniswapV2 dan kemudian mengirimkannya ke alamat yang dinyatakan sebagai “_manualSwap” di alamat pajak.

Alamat penyimpanan dari alamat _manualSwap adalah 0x0. Setelah melakukan kueri dengan perintah getStorageAt dari json-rpc, kami menemukan bahwa alamat yang sesuai dengan _manualSwap adalah tepatnya pengimplementasian kontrak pajak (0x77fb): penyerang ② (0x9DF4).

Parameter input xt dari transaksi Rug Pull ini adalah 420,690,000,000,000,000,000,000, yang sesuai dengan 420,690,000,000,000 (sekitar 420 triliun) token MUMI (desimal dari token MUMI adalah 9).

Dengan kata lain, pada akhirnya, proyek menggunakan 420,690,000,000,000 (sekitar 420 triliun) MUMI untuk menguras WETH di kolam likuiditas dan menyelesaikan skema penipuan keluar sepenuhnya. Namun, ada pertanyaan penting di sini: dari mana kontrak pengumpulan pajak (0x77fb) mendapatkan begitu banyak token MUMI? Dari konten sebelumnya, kita belajar bahwa pasokan token total dari token MUMI pada saat peluncuran adalah 420,690,000 (sekitar 420 juta). Namun, setelah skema rug pull berakhir, ketika kita menanyakan pasokan token total dalam kontrak token MUMI, tetap pada 420,690,000 (seperti yang ditunjukkan dalam gambar di bawah, ditampilkan sebagai 420,690,000,000,000,000, yang perlu mengurangi nol di belakang yang sesuai dengan desimal, di mana desimal adalah 9). Token dalam kontrak pengumpulan pajak (0x77fb), jauh melebihi pasokan total (420,690,000,000,000, sekitar 420 triliun), nampaknya muncul dari udara. Perlu dicatat bahwa, seperti yang disebutkan sebelumnya, alamat 0x77fb, bertindak sebagai alamat pajak, bahkan tidak digunakan untuk menerima biaya transaksi yang dihasilkan selama proses transfer token MUMI; pajak diterima oleh kontrak token itu sendiri.

Mengungkapkan Teknik

• Dari mana kontrak pajak berasal?

Untuk mengeksplorasi sumber token dari kontrak pajak (0x7ffb), kami melihat sejarah acara transfer ERC20-nya.

Hasilnya mengungkapkan bahwa dari semua 6 acara transfer yang melibatkan 0x77fb, hanya acara yang diamati di mana token ditransfer keluar dari kontrak pengumpulan pajak (0x7ffb), tanpa ada acara token MUMI yang ditransfer masuk. Pada pandangan pertama, memang terlihat bahwa token dalam kontrak pengumpulan pajak (0x7ffb) muncul dari udara tipis. Oleh karena itu, jumlah signifikan token MUMI yang secara tampak muncul dari udara tipis dalam kontrak pengumpulan pajak (0x7ffb) memiliki dua karakteristik: 1. Itu tidak memengaruhi totalSupply dari kontrak MUMI. 2. Peningkatan token tidak memicu acara Transfer. Dengan ini diingat, menjadi jelas bahwa harus ada pintu belakang dalam kontrak token MUMI, langsung memodifikasi variabel saldo tanpa perubahan yang sesuai pada totalSupply atau memicu acara Transfer. Dengan kata lain, ini adalah implementasi ERC20 yang tidak standar atau jahat, di mana pengguna tidak dapat melihat pencetakan token yang samar-samar dari tim proyek dari perubahan dalam pasokan total atau acara. Langkah berikutnya adalah memverifikasi gagasan ini dengan langsung mencari kata kunci “saldo” dalam kode sumber kontrak token MUMI.

Sebagai hasilnya, kami menemukan bahwa ada fungsi tipe privat “swapTokensForEth” di kontrak, dan parameter inputnya adalah tokenAmount tipe uint256. Pada baris ke-5 dari fungsi tersebut, pihak proyek secara langsung memodifikasi _taxWallet, yang merupakan saldo MUMI dari kontrak pajak (0x7ffb) untuk tokenAmount 10*_desimal, yang 1.000.000.000 (sekitar 1 miliar) kali lipat dari tokenAmount, dan kemudian mengonversi jumlah tokenAmount MUMI ke ETH dari kolam likuiditas dan menyimpannya di kontrak token (0x4894). Kemudian cari kata kunci “swapTokenForEth”.

Fungsi “swapTokenForEth” dipanggil dalam fungsi “_transfer”. Setelah pemeriksaan lebih lanjut terhadap kondisi pemanggilan, diamati bahwa: 1. Ketika alamat penerima (alamat tujuan) transfer adalah kolam likuiditas MUMI-WETH. 2. Fungsi “swapTokenForEth” dipanggil hanya ketika jumlah token MUMI yang dibeli oleh alamat lain di dalam kolam likuiditas melebihi “_preventSwapBefore” (5 kali lipat). 3. Parameter “tokenAmount” yang dilewatkan ke dalam fungsi adalah nilai minimum antara saldo token MUMI yang dimiliki oleh alamat token dan “_maxTaxSwap”.

Artinya, ketika kontrak mendeteksi bahwa pengguna telah menukar WETH dengan token MUMI di kolam lebih dari 5 kali, itu akan diam-diam mencetak sejumlah besar token untuk alamat pajak, dan mengonversi sebagian token menjadi ETH dan menyimpannya di kontrak token. Di satu sisi, pihak proyek secara terang-terangan mengumpulkan pajak dan secara otomatis menukar mereka dengan sejumlah kecil ETH secara berkala dan menyimpannya di kontrak token. Ini ditunjukkan kepada pengguna dan membuat semua orang berpikir bahwa ini adalah sumber keuntungan pihak proyek. Di sisi lain, apa yang tim proyek benar-benar lakukan adalah langsung memodifikasi saldo akun dan menguras seluruh kolam likuiditas setelah jumlah transaksi pengguna mencapai 5 kali.

• Bagaimana cara mendapatkan keuntungan

Setelah menjalankan fungsi 'swapTokenForEth', fungsi '_transfer' juga akan menjalankan sendETHToFee untuk mengirim ETH yang diperoleh dari pengumpulan pajak di alamat token ke kontrak pajak (0x77fb).

ETH dalam kontrak pajak (0x77fb) dapat diambil oleh fungsi "penyelamatan" yang diimplementasikan dalam kontraknya.

Sekarang lihatlah catatan penebusan transaksi berprofit terakhir dalam seluruh penipuan keluar itu.

Sejumlah dua pertukaran dilakukan dalam transaksi menguntungkan. Pertama kali adalah 4,164,831 (sekitar 4,16 juta) token MUMI dengan 0,349 ETH, dan kedua kalinya adalah 416,483,100,000,000 (sekitar 416 triliun) token MUMI dengan 9,368 ETH. Pertukaran kedua adalah pertukaran yang dimulai dalam fungsi 'swapExactETHForTokens' dalam kontrak pajak (0x7ffb). Alasan mengapa jumlahnya tidak sesuai dengan 420,690,000,000,000 (sekitar 420 triliun) token yang diwakili oleh parameter input adalah karena beberapa token digunakan sebagai pajak yang dikirim ke kontrak token (0x4894), seperti yang ditunjukkan dalam gambar di bawah ini:

Pertukaran pertama sesuai dengan proses pertukaran kedua. Ketika token dikirim dari kontrak pajak (0x7ffb) ke kontrak router, kondisi pemicu fungsi pintu belakang dalam kontrak token terpenuhi, menyebabkan "swapTokensForEth" dipicu. Pertukaran yang dimulai oleh fungsi tersebut bukan operasi kritis.

• Petani di Balik Penipuan

Seperti yang terlihat dari konten sebelumnya, seluruh siklus token MUMI, mulai dari implementasi hingga penciptaan kolam likuiditas, dan kemudian ke Rug Pull, hanya memakan waktu sekitar 3 jam. Namun, berhasil mendapatkan lebih dari 50% keuntungan dengan biaya kurang dari sekitar 6,5 ETH (3 ETH untuk menambah likuiditas, 3 ETH untuk menukar MUMI dari kolam likuiditas sebagai umpan, dan kurang dari 0,5 ETH untuk implementasi kontrak dan memulai transaksi), menghasilkan 9,7 ETH. Penyerang melakukan lima transaksi pertukaran ETH ke MUMI, yang sebelumnya tidak disebutkan. Detail transaksi adalah sebagai berikut:

• 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

Setelah menganalisis EOAs (akun yang dimiliki eksternal) yang beroperasi dalam likuiditas, ditemukan bahwa sebagian besar alamat tersebut milik operasi "bot" on-chain. Mengingat sifat cepat masuk dan keluar dari seluruh penipuan ini, wajar untuk mengasumsikan bahwa target dari penipuan ini adalah berbagai "bot" aktif dan skrip di rantai. Oleh karena itu, baik itu desain kontrak yang tampaknya tidak perlu namun kompleks, proses penguncian likuiditas, atau perilaku mencurigakan dari penyerang yang secara aktif menukar ETH dengan token MUMI di tengah jalan, semuanya dapat dipahami sebagai upaya oleh penyerang untuk menipu mekanisme anti-penipuan berbagai bot on-chain. Dengan melacak aliran dana, ditemukan bahwa semua keuntungan yang diperoleh dari serangan akhirnya dikirim oleh alamat penyerang ② (0x9dF4) ke alamat 0xDF1a.

Sebenarnya, baik sumber pendanaan awal maupun tujuan akhir dari beberapa penipuan keluar terbaru menunjuk ke alamat ini. Oleh karena itu, analisis kasar dan statistik transaksi alamat ini dilakukan. Ditemukan bahwa alamat tersebut menjadi aktif sekitar 2 bulan yang lalu dan telah memulai lebih dari 7.000 transaksi hingga saat ini, berinteraksi dengan lebih dari 200 token. Dari sekitar 40 catatan transaksi token yang dianalisis, ditemukan bahwa hampir semua token, ketika dilihat dalam kolam likuiditas mereka yang sesuai, akan memiliki satu transaksi pertukaran besar yang menghabiskan semua ETH dalam kolam likuiditas, dan seluruh siklus penipuan keluar adalah singkat. Berikut adalah transaksi penempatan beberapa token (misalnya, rokok Cina):

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

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

Oleh karena itu, dapat disimpulkan bahwa alamat ini sebenarnya adalah pemungut skema penipuan “exit scam” berskala besar yang otomatis, yang menargetkan operasi bot on-chain. Alamat ini masih aktif.

Sebagai kesimpulan, jika proses pencetakan token tidak sesuai dengan memodifikasi totalSupply atau memicu peristiwa Transfer, sulit bagi kami untuk memahami apakah tim proyek secara diam-diam mencetak token. Hal ini memperburuk situasi saat ini di mana keamanan token sepenuhnya bergantung pada kesadaran tim proyek. Oleh karena itu, mungkin perlu mempertimbangkan untuk meningkatkan mekanisme token yang ada atau memperkenalkan skema pemantauan pasokan total token yang efektif untuk memastikan transparansi dalam perubahan jumlah token. Hanya mengandalkan peristiwa untuk menangkap perubahan status token tidaklah cukup. Selain itu, kita perlu menyadari bahwa meskipun kesadaran masyarakat tentang pencegahan penipuan meningkat, metode penipuan lawan juga terus berkembang. Ini adalah permainan tak berujung, dan kita perlu terus belajar dan berpikir untuk melindungi diri.

• Alat yang digunakan dalam artikel ini

Lihat informasi transaksi dasar: https://etherscan.io/

Dekompilasi kontrak: app.dedaub.com/decompilejson-rpc: https://www.quicknode.com/docs/ethereum/eth_getStorageAt

Penafian：

1. Artikel ini dicetak ulang dari [CertiK]Teruskan Judul Asli ‘技术详解 | 链上打新局中局，大规模Rug Pull手法解密’. Semua hak cipta milik penulis asli [‘CertiK]Jika ada keberatan terhadap penggandaan ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan cepat.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang disampaikan dalam artikel ini semata-mata merupakan pandangan penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.