轉發原文標題：《技術詳解 | 鏈上打新局中局，大規模Rug Pull手法解密》

近日，CertiK安全專家團隊頻繁檢測到多起手法相同的“退出騙局”，也就是我們俗稱的Rug Pull。

在我們進行深入挖掘後發現，多起相同手法的事件都指向同一個團夥，最終關聯到超過200個Token退出騙局。這預示着我們可能發現了一個大規模自動化的，通過“退出騙局”方式進行資產收割的黑客團隊。在這些退出騙局中，攻擊者會創建一個新的ERC20代幣，並用創建時預挖的代幣加上一定數量的WETH創建一個Uniswap V2的流動性池。當鏈上的打新機器人或用戶在該流動性池購買一定次數的新代幣後，攻擊者則會通過憑空產生的代幣，將流動性池中的WETH全部耗盡。由於攻擊者在憑空獲取的代幣沒有體現在總供應量中（totalSupply），也不觸發Transfer事件，在etherscan是看不到的，因此外界難以感知。攻擊者不僅考慮了隱蔽性，還設計了一個局中局，用來麻痹擁有初級技術能力，會看etherscan的用戶，用一個小的問題來掩蓋他們真正的目的……

深入騙局

我們以其中一個案例爲例，詳解一下該退出騙局的細節。被我們檢測到的實際上是攻擊者用巨量代幣（偷偷mint的）耗幹流動性池並獲利的交易，在該交易中，項目方共計用416,483,104,164,831（約416萬億）個MUMI兌換出了約9.736個WETH，耗幹了池子的流動性。然而該交易只是整個騙局的最後一環，我們要了解整個騙局，就需要繼續往前追溯。

部署代幣

3月6日上午7點52分（UTC時間，下文同），攻擊者地址（0x8AF8）Rug Pull部署了名爲MUMI（全名爲MultiMixer AI）的ERC20代幣（地址爲0x4894），並預挖了420,690,000（約4.2億）個代幣且全部分配給合約部署者。

預挖代幣數量與合約源碼相對應。

添加流動性

8點整（代幣創建8分鍾後），攻擊者地址（0x8AF8）開始添加流動性。攻擊者地址（0x8AF8）調用代幣合約中的openTrading函數，通過uniswap v2 factory創建MUMI-WETH流動性池，將預挖的所有代幣和3個ETH添加到流動性池中，最後獲得約1.036個LP代幣。

從交易細節可以看出，原本用於添加流動性的420,690,000（約4.2億）個代幣中，有63,103,500（約6300萬）約個代幣又被發送回代幣合約（地址0x4894），通過查看合約源碼發現，代幣合約會爲每筆轉帳收取一定的手續費，而收取手續費的地址正是代幣合約本身（具體實現在“_transfer函數中”）。

奇怪的是，合約中已經設置了稅收地址0x7ffb（收取轉帳手續費的地址），最後手續費卻被發到代幣合約自身。

因此最後被添加到流動性池的MUMI代幣數量爲扣完稅的357,586,500（約3.5億），而不是420,690,000（約4.3億）。

鎖定流動性

8點1分（流動性池創建1分鍾後），攻擊者地址（0x8AF8）鎖定了通過添加流動性獲取的全部1.036個LP代幣。

LP被鎖定後，理論上攻擊者地址（0x8AF8）擁有的所有的MUMI代幣便被鎖定在流動性池內（除開作爲手續費的那部分），因此攻擊者地址（0x8AF8）也不具備通過移除流動性進行Rug Pull的能力。爲了讓用戶放心購買新推出的代幣，許多項目方都是將LP進行鎖定，意思就是項目方在說：“我不會跑路的，大家放心買吧！”，然而事實真的是這樣嗎？顯然不是，這個案例便是如此，讓我們繼續分析。

Rug Pull

8點10分，出現了新的攻擊者地址②（0x9DF4），Ta部署了代幣合約中聲明的稅收地址0x7ffb。

這裏有三個值得一提的點：1.部署稅收地址的地址和部署代幣的地址並不是同一個，這可能說明項目方在有意減少各個操作之間與地址的關聯性，提高行爲溯源的難度2.稅收地址的合約不開源，也就是說稅收地址中可能隱藏有不想暴露的操作3.稅收合約比代幣合約晚部署，而代幣合約中稅收地址已被寫死，這意味着項目方可以預知稅收合約的地址，由於CREATE指令在確定創建者地址和nonce的情況下，部署合約地址是確定的，因此項目方提前就使用創建者地址模擬計算出了合約地址實際上有不少退出騙局都是通過稅收地址進行，且稅收地址的部署模式特徵符合上述的1、2點。上午11點（代幣創建3小時後），攻擊者地址②（0x9DF4）進行了Rug Pull。他通過調用稅收合約（0x77fb）的“swapExactETHForTokens”方法，用稅收地址中的416,483,104,164,831（約416萬億）個MUMI代幣兌換出了約9.736個ETH，並耗盡了池子中流動性。

由於稅收合約（0x77fb）不開源，我們對其字節碼進行反編譯，反編結果如下：https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c查看完稅收合約（0x77fb）的“swapExactETHForTokens”方法反編譯代碼後，我們發現實際上該函數實現的主要功能就是通過uniswapV2 router將數量爲“xt”（調用者指定）的稅收合約（0x77fb）擁有的MUMI代幣兌換成ETH，並發送給稅收地址中聲明的“_manualSwap”地址。

_manualSwap地址所處的storage地址爲0x0，用json-rpc的getStorageAt命令進行查詢後發現_manualSwap對應的地址正是稅收合約（0x77fb）的部署者：攻擊者②（0x9DF4）。

該筆Rug Pull交易的輸入參數xt爲420,690,000,000,000,000,000,000，對應420,690,000,000,000（約420萬億）個MUMI代幣（MUMI代幣的decimal爲9）。

也就是說，最終項目方用420,690,000,000,000（約420萬億）個MUMI將流動性池中的WETH耗幹，完成整個退出騙局。然而這裏有一個至關重要的問題，就是稅收合約（0x77fb）哪來的這麼多MUMI代幣？從前面的內容我們得知，MUMI代幣在部署時的代幣合約時的總供應量爲420,690,000（約4.2億），而在退出騙局結束後，我們在MUMI代幣合約中查詢到的總供應量依舊是420,690,000（下圖中顯示爲420,690,000,000,000,000，需要減去decimal對應位數的0，decimal爲9），稅收合約（0x77fb）中的遠超總供應量的代幣（420,690,000,000,000，約420萬億）就仿佛憑空出現的一樣，要知道，如上文所提，0x77fb作爲稅收地址甚至沒有被用於接收MUMI代幣轉帳過程中產生的手續費，稅收被代幣合約接收了。

手法揭祕

• 稅收合約哪來的代幣

爲了探究稅收合約（0x7ffb）的代幣來源，我們查看了它的ERC20轉帳事件歷史。

結果發現在全部6筆關於0x77fb的轉帳事件中，只有從稅收合約（0x7ffb）轉出的事件，而沒有任何MUMI代幣轉入的事件，乍一看，稅收合約（0x7ffb）的代幣還真是憑空出現的。所以稅收合約（0x7ffb）地址中憑空出現的巨額MUMI代幣有兩個特點：1.沒有對MUMI合約的totalSupply產生影響2.代幣的增加沒有觸發Transfer事件那麼思路就很明確了，即MUMI代幣合約中一定存在後門，這個後門直接對balance變量進行修改，且在修改balabce的同時不對應修改totalSupply，也不觸發Transfer事件。也就是說，這是一個不標準的、或者說是惡意的ERC20代幣實現，用戶無法從總供應量的變化和事件中感知到項目方在偷偷mint代幣。接着就是驗證上面的想法，我們直接在MUMI代幣合約源碼中搜索關鍵字“balance”。

結果我們發現合約中有一個private類型的“swapTokensForEth”函數，傳入參數爲uint256類型的tokenAmount，在該函數的第5行，項目方直接將_taxWallet，也就是稅收合約（0x7ffb）的MUMI餘額修改爲tokenAmount 10*_decimals，也就是tokenAmount的1,000,000,000（約10億）倍，然後再從流動性池中將tokenAmount數量的MUMI兌換爲ETH並存在代幣合約（0x4894）中。再接着搜索關鍵字“swapTokenForEth“。

“swapTokenForEth”函數在“_transfer”函數中被調用，再細看調用條件，會發現：1.當轉帳的接收地址to地址爲MUMI-WETH流動性池。2.當有其他地址在流動性池中購買MUMI代幣的數量超過_preventSwapBefore（5次）時，“swapTokenForEth”函數才會被調用3.傳入的tokenAmount爲代幣地址所擁有的MUMI代幣餘額和_maxTaxSwap之間的較小值

也就是說當合約檢測到用戶在池子中用WETH兌換成MUMI代幣超過5次後，便會爲稅收地址偷偷mint巨量代幣，並將一部分代幣兌換成ETH存儲在代幣合約中。一方面，項目方表面上進行收稅並定期自動換成少量ETH放到代幣合約，這是給用戶看的，讓大家以爲這就是項目方的利潤來源。另一方面，項目方真正在做的，則是在用戶交易次數達到5次後，直接修改帳戶餘額，把流動性池全部抽幹。

• 如何獲利

執行完“swapTokenForEth”函數後，“_transfer”函數還會執行sendETHToFee將代幣地址中收稅獲得的ETH發送到稅收合約（0x77fb）。

稅收合約（0x77fb）中的ETH可以被其合約內實現的“rescue”函數取出。

現在再回看整個退出騙局中最後一筆獲利交易的兌換記錄。

獲利交易中共進行了兩次兌換，第一次是4,164,831（約416萬）個MUMI代幣換0.349個ETH，第二次是416,483,100,000,000（約416萬億）個MUMI代幣換9.368個ETH。其中第二次兌換即爲稅收合約（0x7ffb）中“swapExactETHForTokens”函數內發起的兌換，之所以數量與輸入參數代表的420,690,000,000,000（約420萬億）個代幣不符，是因爲有部分代幣作爲稅收發送給了代幣合約（0x4894），如下圖所示：

而第一次兌換對應的，則是在第二次兌換過程中，當代幣從稅收合約（0x7ffb）發送至router合約時，由因爲滿足代幣合約內的後門函數觸發條件，導致觸發“swapTokensForEth”函數所發起的兌換，並非關鍵操作。

• 背後的大鐮刀

從上文中可以看出，MUMI代幣從部署，到創建流動性池，再到Rug Pull，整個退出騙局週期才約3個小時，但是卻以不到約6.5個ETH的成本（3 ETH用於添加流動性，3 ETH用於從流動性池中兌換MUMI以作誘導，不到0.5 ETH用於部署合約和發起交易）獲得了9.7個ETH，利潤超過50%。攻擊者用ETH換MUMI的交易有5筆，前文中並沒有提到，交易信息如下：

• 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

因此我們可以認定，該地址實際上就是一個大規模的自動化“退出騙局”收割機，收割的對象就是鏈上的打新機器人。該地址現在仍在活躍。

寫在最後如果一個代幣在mint時不對應修改totalSupply，也不觸發Transfer事件，那麼我們是很難感知項目方是否有在偷偷mint代幣的，這也將加劇“代幣是否安全，完全依賴於項目方是否自覺”的現狀。因此我們可能需要考慮改進現有的代幣機制或者引入一種有效的代幣總量檢測方案，來保障代幣數量變更的公開透明，現在憑藉event來捕獲代幣狀態變更是不夠的。並且我們需要警醒的是，盡管現在大家的防騙意識在提高，但是攻擊者的反防騙手段也在提高，這是一場永不停息的博弈，我們需要保持不斷學習和思考，才能在這樣的博弈中保全自身。

聲明：

1. 本文轉載自[CertiK]，原文標題《技術詳解 | 鏈上打新局中局，大規模Rug Pull手法解密》，著作權歸屬原作者[ CertiK ]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。