Chuyển tiêu đề ban đầu '技术详解 | 链上打新局中局，大规模Rug Pull手法解密’

Gần đây, các chuyên gia bảo mật của CertiK đã thường xuyên phát hiện nhiều trường hợp của cùng một phương thức lừa đảo thoát, thường được gọi là Rug Pull. Sau khi điều tra thêm, chúng tôi phát hiện ra rằng một số trường hợp của cùng một phương pháp chỉ ra cùng một nhóm, cuối cùng liên quan đến hơn 200 trò gian lận thoát Token. Điều này cho thấy rằng chúng tôi có thể đã phát hiện ra một nhóm hacker tự động quy mô lớn thu thập tài sản thông qua các trò gian lận thoát. Trong các trò gian lận thoát này, kẻ tấn công tạo mã thông báo ERC20 mới và sử dụng mã thông báo được khai thác trước cùng với một lượng WETH nhất định để tạo nhóm thanh khoản Uniswap V2. Sau khi bot hoặc người dùng trên chuỗi thực hiện một số lần mua mã thông báo mới nhất định từ nhóm thanh khoản, kẻ tấn công sẽ làm cạn kiệt tất cả WETH trong nhóm với các mã thông báo được tạo ra từ không khí. Vì các mã thông báo mà kẻ tấn công thu được từ không khí mỏng không được phản ánh trong tổng nguồn cung và không kích hoạt các sự kiện Chuyển khoản, chúng không hiển thị trên etherscan, khiến người ngoài khó phát hiện. Những kẻ tấn công không chỉ xem xét việc che giấu mà còn thiết kế một kẻ lừa đảo để đánh lừa người dùng có kỹ năng kỹ thuật cơ bản kiểm tra etherscan, sử dụng một vấn đề nhỏ để che giấu ý định thực sự của họ...

Đi sâu vào lừa đảo

Scam Độ sâu

Sử dụng một trong những trường hợp làm ví dụ, hãy đi sâu vào chi tiết của vụ lừa đảo này. Điều chúng tôi phát hiện là một giao dịch trong đó kẻ tấn công đã sử dụng một lượng lớn token (được tạo ra một cách im lặng) để cạn kiệt hồ bơi thanh khoản và lợi nhuận. Trong giao dịch này, nhóm dự án đã trao đổi khoảng 416,483,104,164,831 (khoảng 416 tỷ tỷ) token MUMI để được khoảng 9.736 WETH, làm cạn kiệt thanh khoản của hồ bơi. Tuy nhiên, giao dịch này chỉ là phần cuối cùng của toàn bộ vụ lừa đảo. Để hiểu rõ toàn bộ vụ lừa đảo, chúng ta cần tiếp tục theo dõi lời giải thích.

Triển khai token

Vào ngày 6 tháng 3 vào lúc 7:52 sáng (giờ UTC, giống nhau cho các thời điểm sau đó), địa chỉ của kẻ tấn công (0x8AF8) triển khai một token ERC20 có tên MUMI (tên đầy đủ là MultiMixer AI) tại địa chỉ 0x4894 và đào trước 420.690.000 (khoảng 420 triệu) token, tất cả đều được phân bổ cho người triển khai hợp đồng.

Số lượng token được đào trước tương ứng với mã nguồn hợp đồng.

Thêm thanh khoản

Lúc 8 giờ chính xác (8 phút sau khi token được tạo), địa chỉ của kẻ tấn công (0x8AF8) bắt đầu thêm thanh khoản. Địa chỉ của kẻ tấn công (0x8AF8) gọi hàm openTrading trong hợp đồng token, tạo một hồ bơi thanh khoản MUMI-WETH thông qua nhà máy uniswap v2, thêm tất cả các token được đào trước và 3 ETH vào hồ bơi thanh khoản, và cuối cùng thu được khoảng 1.036 LP token.

Có thể thấy từ chi tiết giao dịch rằng trong số 420.690.000 (khoảng 420 triệu) token ban đầu được sử dụng để thêm thanh khoản, khoảng 63.103.500 (khoảng 63 triệu) token đã được gửi trở lại hợp đồng token (địa chỉ 0x4894). Bằng cách xem mã nguồn hợp đồng, ta thấy rằng hợp đồng token sẽ tính một khoản phí xử lý nhất định cho mỗi giao dịch, và địa chỉ để thu khoản phí xử lý là hợp đồng token chính nó (được thực hiện cụ thể trong hàm "_transfer").

Điều lạ là địa chỉ thuế 0x7ffb (địa chỉ để thu phí chuyển khoản) đã được đặt trong hợp đồng, nhưng phí cuối cùng đã được gửi đến chính hợp đồng token.

Do đó, số lượng token MUMI cuối cùng được thêm vào giao diện thanh khoản là 357.586.500 (khoảng 350 triệu) sau thuế, không phải là 420.690.000 (khoảng 430 triệu).

Khóa thanh khoản

Lúc 8:01 (1 phút sau khi hồ chứa thanh khoản được tạo), địa chỉ tấn công (0x8AF8) đã khóa tất cả 1.036 token LP thu được thông qua việc thêm thanh khoản.

Sau khi LP bị khóa, lí thuyết, tất cả các token MUMI mà địa chỉ của kẻ tấn công sở hữu (0x8AF8) đều bị khóa trong hồ bơi thanh khoản (ngoại trừ phần được sử dụng làm phí xử lý), vì vậy địa chỉ của kẻ tấn công (0x8AF8) không có khả năng loại bỏ nó thông qua khả năng Thanh khoản để thực hiện Rug Pull. Để cho phép người dùng mua token mới được ra mắt một cách tự tin, nhiều bên dự án khóa LP, điều này có nghĩa là bên dự án đang nói: “Tôi sẽ không bỏ chạy, mọi người có thể mua một cách tự tin!”, nhưng liệu điều này có đúng không? Rõ ràng không phải vậy, đây là trường hợp, chúng ta hãy tiếp tục phân tích.

Rug Pull

Lúc 8:10, một địa chỉ attacker mới ② (0x9DF4) đã xuất hiện, và anh ta triển khai địa chỉ thuế 0x7ffb được khai báo trong hợp đồng token.

Có ba điểm đáng nói ở đây: 1. Địa chỉ nơi địa chỉ thuế được triển khai và địa chỉ nơi mã thông báo được triển khai không giống nhau. Điều này có thể chỉ ra rằng bên dự án đang cố tình giảm mối tương quan giữa từng hoạt động và địa chỉ, khiến việc theo dõi hành vi trở nên khó khăn hơn. 2. Hợp đồng của địa chỉ thuế không phải là nguồn mở, có nghĩa là có thể có các hoạt động ẩn trong địa chỉ thuế không muốn bị lộ. 3. Hợp đồng thuế được triển khai muộn hơn hợp đồng mã thông báo và địa chỉ thuế trong hợp đồng mã thông báo đã được mã hóa cứng, có nghĩa là địa chỉ của hợp đồng thuế có thể được nhóm dự án dự đoán trước. Vì lệnh CREATE xác định địa chỉ người tạo và nonce, địa chỉ hợp đồng triển khai được xác định. Do đó, nhóm dự án đã sử dụng địa chỉ người tạo để mô phỏng và tính toán trước địa chỉ hợp đồng. Trên thực tế, nhiều vụ lừa đảo xuất cảnh được thực hiện thông qua địa chỉ thuế, đặc điểm chế độ triển khai của địa chỉ thuế thực hiện theo điểm 1 và 2 nêu trên. Vào lúc 11 giờ sáng (3 giờ sau khi mã thông báo được tạo), địa chỉ của kẻ tấn công (2) (0x9DF4) đã tiến hành Kéo thảm. Bằng cách gọi phương pháp "swapExactETHForTokens" của hợp đồng thuế (0x77fb), ông đã trao đổi 416.483.104.164.831 (khoảng 416 nghìn tỷ) token MUMI trong địa chỉ thuế cho khoảng 9.736 ETH và làm cạn kiệt tính thanh khoản trong nhóm.

Vì hợp đồng thuế (0x77fb) không phải là mã nguồn mở, chúng tôi đã giải mã bytecode của nó và kết quả giải mã như sau:

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

Sau khi giải mã phương thức “swapExactETHForTokens” của hợp đồng thuế (0x77fb), chúng tôi đã phát hiện ra rằng chức năng chính được thực hiện bởi hàm này là trao đổi lượng cụ thể “xt” (do người gọi chỉ định) của token MUMI mà hợp đồng thuế (0x77fb) sở hữu thành ETH bằng cách sử dụng bộ định tuyến UniswapV2 và sau đó gửi nó đến địa chỉ được khai báo là “_manualSwap” trong địa chỉ thuế.

Địa chỉ lưu trữ của địa chỉ _manualSwap là 0x0. Sau khi truy vấn với lệnh getStorageAt của json-rpc, chúng tôi phát hiện rằng địa chỉ tương ứng với _manualSwap chính xác là người triển khai hợp đồng thuế (0x77fb): kẻ tấn công ② (0x9DF4).

Tham số đầu vào xt của giao dịch Rug Pull này là 420,690,000,000,000,000,000,000, tương ứng với 420,690,000,000,000 (khoảng 420 nghìn tỷ) token MUMI (phần thập phân của token MUMI là 9).

Nói cách khác, cuối cùng, dự án đã sử dụng 420.690.000.000.000.000 (khoảng 420 nghìn tỷ) MUMI để rút WETH trong nhóm thanh khoản và hoàn thành toàn bộ trò lừa đảo thoát. Tuy nhiên, có một câu hỏi quan trọng ở đây: hợp đồng thu thuế (0x77fb) lấy đâu ra nhiều token MUMI như vậy? Từ nội dung trước đó, chúng ta được biết tổng nguồn cung token MUMI tại thời điểm triển khai là 420.690.000 (xấp xỉ 420 triệu). Tuy nhiên, sau khi kết thúc sơ đồ kéo thảm, khi chúng tôi truy vấn tổng nguồn cung mã thông báo trong hợp đồng mã thông báo MUMI, nó vẫn ở mức 420.690.000 (như thể hiện trong hình bên dưới, được hiển thị là 420.690.000.000.000.000, cần trừ đi các số không ở cuối tương ứng với số thập phân, trong đó số thập phân là 9). Các mã thông báo trong hợp đồng thu thuế (0x77fb), vượt xa tổng nguồn cung (420.690.000.000.000, khoảng 420 nghìn tỷ), dường như đã xuất hiện ngoài không khí. Điều đáng chú ý là, như đã đề cập trước đó, 0x77fb địa chỉ, đóng vai trò là địa chỉ thuế, thậm chí không được sử dụng để nhận phí giao dịch được tạo ra trong quá trình chuyển mã thông báo MUMI; Thuế đã được nhận bởi chính hợp đồng mã thông báo.

Tiết lộ Kỹ thuật

• Hợp đồng thuế đến từ đâu?

Để khám phá nguồn gốc token của hợp đồng thuế (0x7ffb), chúng tôi đã xem xét lịch sử sự kiện chuyển ERC20 của nó.

Kết quả cho thấy rằng trong tất cả 6 sự kiện chuyển giao liên quan đến 0x77fb, chỉ có các sự kiện được quan sát trong đó các token được chuyển ra khỏi hợp đồng thuế thu nhập (0x7ffb), không có sự kiện nào về việc chuyển giao token MUMI vào trong. Ngay từ cái nhìn đầu tiên, dường như các token trong hợp đồng thuế thu nhập (0x7ffb) xuất hiện như từ hư vô. Do đó, lượng lớn các token MUMI dường như xuất hiện từ hư vô trong hợp đồng thuế thu nhập (0x7ffb) có hai đặc điểm: 1. Nó không ảnh hưởng đến tổng cung cấp của hợp đồng MUMI. 2. Sự tăng về token không kích hoạt một sự kiện Chuyển giao. Với điều này trong tâm trí, trở nên rõ ràng rằng phải có một lối ra sau trong hợp đồng token MUMI, trực tiếp sửa đổi biến cân đối mà không có các thay đổi tương ứng đến tổng cung cấp hoặc kích hoạt sự kiện Chuyển giao. Nói cách khác, đây là một cách triển khai ERC20 không chuẩn hoặc độc hại, nơi người dùng không thể nhận biết việc đội ngũ dự án kín đáo tạo ra token từ sự thay đổi trong cung cấp tổng hoặc các sự kiện. Bước tiếp theo là xác minh ý tưởng này bằng cách tìm kiếm trực tiếp từ khóa "balance" trong mã nguồn của hợp đồng token MUMI.

Kết quả, chúng tôi phát hiện rằng có một hàm loại riêng tư “swapTokensForEth” trong hợp đồng, và tham số đầu vào là tokenAmount kiểu uint256. Ở dòng thứ 5 của hàm, bên dự án trực tiếp sửa đổi _taxWallet, đó là số dư MUMI của hợp đồng thuế (0x7ffb) cho tokenAmount10*_decimals, đó là 1.000.000.000 (khoảng 1 tỷ lần) lần số lượng mã thông báo, sau đó chuyển đổi số lượng mã thông báo MUMI thành ETH từ hồ bơi thanh khoản và lưu trữ nó trong hợp đồng mã thông báo (0x4894). Sau đó tìm kiếm từ khóa “swapTokenForEth”.

Hàm “swapTokenForEth” được gọi trong hàm “_transfer”. Khi kiểm tra cận thận điều kiện gọi, ta thấy rằng: 1. Khi địa chỉ người nhận (địa chỉ đến) của giao dịch là hồ chứa thanh khoản MUMI-WETH. 2. Hàm “swapTokenForEth” được gọi chỉ khi số lượng token MUMI mà các địa chỉ khác mua trong hồ chứa thanh khoản vượt quá “_preventSwapBefore” (5 lần). 3. Tham số “tokenAmount” được truyền vào hàm là giá trị tối thiểu giữa số dư token MUMI mà địa chỉ token sở hữu và “_maxTaxSwap”.

Nói cách khác, khi hợp đồng phát hiện người dùng đã trao đổi WETH để nhận token MUMI trong pool hơn 5 lần, nó sẽ bí mật tạo ra một lượng lớn token cho địa chỉ thuế, và chuyển đổi một phần token thành ETH và lưu trữ chúng trong hợp đồng token. Một mặt, dự án giả vờ thu thuế và tự động chuyển đổi chúng thành một số lượng nhỏ ETH đều đặn và đưa chúng vào hợp đồng token. Điều này được hiển thị cho người dùng và làm cho mọi người nghĩ rằng đây là nguồn lợi nhuận của dự án. Mặt khác, điều mà nhóm dự án đang làm thực sự là sửa đổi trực tiếp số dư tài khoản và rút hết pool thanh khoản sau khi số giao dịch của người dùng đạt 5 lần.

• Cách để có lợi nhuận

Sau khi thực thi chức năng “swapTokenForEth”, chức năng “_transfer” cũng sẽ thực thi sendETHToFee để gửi ETH thu được từ việc thuế trong địa chỉ token đến hợp đồng thuế (0x77fb).

ETH trong hợp đồng thuế (0x77fb) có thể được lấy ra bằng chức năng "giải cứu" được thực hiện trong hợp đồng của nó.

Bây giờ hãy nhìn lại vào bản ghi hoàn trả của giao dịch sinh lời cuối cùng trong toàn bộ lừa đảo thoát.

Tổng cộng có hai lần trao đổi được thực hiện trong giao dịch sinh lời. Lần đầu tiên là 4.164.831 (khoảng 4,16 triệu) token MUMI với 0,349 ETH, và lần thứ hai là 416.483.100.000.000 (khoảng 416 nghìn tỷ) token MUMI với 9,368 ETH. Lần trao đổi thứ hai là trao đổi được khởi tạo trong hàm “swapExactETHForTokens” trong hợp đồng thuế (0x7ffb). Lý do số không khớp với 420.690.000.000.000 (khoảng 420 nghìn tỷ) token được đại diện bởi các tham số đầu vào là vì một số token được sử dụng như thuế gửi cho hợp đồng token (0x4894), như được hiển thị trong hình dưới đây:

Sàn giao dịch đầu tiên tương ứng với quá trình giao dịch thứ hai. Khi mã thông báo được gửi từ hợp đồng thuế (0x7ffb) đến hợp đồng định tuyến, điều kiện kích hoạt chức năng cửa sau trong hợp đồng mã thông báo được đáp ứng, dẫn đến việc kích hoạt “swapTokensForEth”. Sàn giao dịch được khởi xướng bởi chức năng không phải là một hoạt động quan trọng.

• Người gặt hái đằng sau vụ lừa đảo

Nhìn từ nội dung trước đó, toàn bộ chu kỳ của token MUMI, từ triển khai đến việc tạo hồ bơi thanh khoản, và sau đó là Rug Pull, chỉ mất khoảng 3 giờ. Tuy nhiên, nó đã thể hiện được hơn 50% lợi nhuận với chi phí ít hơn khoảng 6.5 ETH (3 ETH để thêm thanh khoản, 3 ETH để đổi MUMI từ hồ bơi thanh khoản như mồi, và ít hơn 0.5 ETH để triển khai hợp đồng và khởi tạo giao dịch), dẫn đến 9.7 ETH. Kẻ tấn công đã thực hiện năm giao dịch trao đổi ETH lấy MUMI, mà trước đó không được đề cập. Chi tiết giao dịch như sau:

• 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

Sau khi phân tích các EOA (tài khoản thuộc sở hữu bên ngoài) hoạt động trong tính thanh khoản, người ta phát hiện ra rằng một phần đáng kể các địa chỉ thuộc về các hoạt động "bot" trên chuỗi. Xem xét bản chất vào và ra nhanh chóng của toàn bộ trò lừa đảo, thật hợp lý khi cho rằng mục tiêu của trò lừa đảo này là các "bot" và tập lệnh đang hoạt động khác nhau trên chuỗi. Do đó, cho dù đó là thiết kế hợp đồng dường như không cần thiết nhưng phức tạp, triển khai hợp đồng, quy trình khóa thanh khoản hay hành vi đáng ngờ của những kẻ tấn công chủ động hoán đổi ETH lấy token MUMI giữa chừng, tất cả đều có thể được hiểu là nỗ lực của những kẻ tấn công để đánh lừa các cơ chế chống gian lận của các bot on-chain khác nhau. Bằng cách theo dõi dòng tiền, người ta thấy rằng tất cả lợi nhuận thu được từ cuộc tấn công cuối cùng đã được gửi bởi địa chỉ tấn công (2) (0x9dF4) đến địa chỉ 0xDF1a.

Trong thực tế, cả nguồn tài trợ ban đầu và điểm đến cuối cùng của nhiều vụ lừa đảo gần đây đã chỉ đến địa chỉ này. Do đó, đã tiến hành một phân tích và thống kê sơ bộ về các giao dịch của địa chỉ này. Đã phát hiện rằng địa chỉ trở nên hoạt động khoảng 2 tháng trước và đã khởi xướng hơn 7.000 giao dịch cho đến nay, tương tác với hơn 200 mã thông báo. Trong số khoảng 40 hồ sơ giao dịch mã thông báo được phân tích, đã phát hiện rằng gần như tất cả các mã thông báo, khi xem trong các hồ bơi thanh khoản tương ứng của chúng, sẽ có một giao dịch trao đổi lớn duy nhất làm cạn kiệt tất cả ETH trong hồ bơi thanh khoản, và toàn bộ chu kỳ lừa đảo rút lui là ngắn. Dưới đây là các giao dịch triển khai của một số mã thông báo (ví dụ, thuốc lá Trung Quốc):

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

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

Do đó, có thể kết luận rằng địa chỉ này, trên thực tế, là một công cụ thu hoạch "lừa đảo thoát" tự động quy mô lớn, nhắm mục tiêu vào các hoạt động bot trên chuỗi. Địa chỉ này vẫn đang hoạt động.

Kết luận, nếu quá trình đúc token không tương ứng với việc sửa đổi totalSupply hoặc kích hoạt các sự kiện Transfer, thì khó khăn để chúng tôi nhận biết xem liệu nhóm dự án có đang đúc token một cách bí mật hay không. Điều này làm trầm trọng thêm tình hình hiện tại, khi an ninh của token hoàn toàn phụ thuộc vào ý thức của nhóm dự án. Do đó, có thể cần xem xét cải thiện cơ chế token hiện tại hoặc giới thiệu một hệ thống giám sát tổng cung token hiệu quả để đảm bảo sự minh bạch trong việc thay đổi số lượng token. Dựa chỉ vào các sự kiện để ghi lại các thay đổi trạng thái token không đủ. Hơn nữa, chúng ta cần nhận thức rằng mặc dù ý thức ngăn chặn gian lận của mọi người đang tăng, nhưng các phương pháp chống lại gian lận của kẻ tấn công cũng đang tiến triển. Đây là một trò chơi không ngừng, và chúng ta cần tiếp tục học hỏi và suy nghĩ để bảo vệ bản thân.

• Công cụ được sử dụng trong bài viết này

Xem thông tin giao dịch cơ bản: https://etherscan.io/

Giải mã hợp đồng: app.dedaub.com/decompilejson-rpc: https://www.quicknode.com/docs/ethereum/eth_getStorageAt

Tuyên bố từ chối:

1. Bài viết này được tái bản từ [CertiK], Chuyển tiếp Tiêu đề Gốc '技术详解 | 链上打新局中局，大规模Rug Pull手法解密'. Tất cả các bản quyền thuộc về tác giả gốc [.CertiK]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Học cửađội, và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này hoàn toàn là của tác giả và không cung cấp bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.