Recently, the CertiK security expert team has frequently detected multiple exit scams with the same tactics, which is commonly known as Rug Pull.
After further digging, we found that multiple incidents with the same tactics pointed to the same gang, and were ultimately linked to more than 200 Token exit scams. This indicates that we may have discovered a large-scale automated hacking team that harvests assets through exit scams.
In these exit scams, the attacker will create a new ERC 20 token and create a Uniswap V2 liquidity pool with the token pre-mined at the time of creation plus a certain amount of WETH.
When the new robot on the chain or the user purchases new tokens in the liquidity pool for a certain number of times, the attacker will use the tokens generated out of thin air to exhaust all the WETH in the liquidity pool.
Since the tokens obtained by the attacker out of thin air are not reflected in the total supply (totalSupply) and do not trigger the Transfer event, they are not visible on etherscan, so it is difficult for the outside world to perceive them.
The attackers not only considered stealth, but also designed a game-within-a-game to paralyze users with basic technical skills and the ability to read etherscan, using a small problem to cover up their true purpose...
Deep into the scam
Let’s take one of the cases as an example to explain the details of this exit scam.
What we detected was actually a transaction in which the attacker used a huge amount of tokens (secretly minted) to drain the liquidity pool and make a profit. In this transaction, the project party used a total of 416, 483, 104, 164, 831 ( Approximately 416 trillion) MUMI was exchanged for approximately 9.736 WETH, draining the liquidity of the pool.
However, this transaction is only the last link of the entire scam. To understand the entire scam, we need to continue to trace forward.
Deploy tokens
At 7:52 am on March 6 (UTC time, the same below), the attackers address (0x 8 AF 8) Rug Pull deployed an ERC 20 token named MUMI (full name MultiMixer AI) (the address is 0x 4894 ), and 420, 690, 000 (approximately 420 million) tokens were pre-mined and all distributed to contract deployers.
The number of pre-mined tokens corresponds to the contract source code.
Add liquidity
At 08:00 sharp (8 minutes after the token was created), the attacker address (0x 8 AF 8) started adding liquidity.
The attackers address (0x 8 AF 8) calls the openTrading function in the token contract, creates the MUMI-WETH liquidity pool through uniswap v2 factory, adds all pre-mined tokens and 3 ETH to the liquidity pool, and finally obtains About 1.036 LP tokens.
It can be seen from the transaction details that of the 420,690,000 (approximately 420 million) tokens originally used to add liquidity, approximately 63,103,500 (approximately 63 million) tokens were sent back to the tokens Contract (address 0x 4894), by looking at the contract source code, we found that the token contract will charge a certain handling fee for each transfer, and the address that charges the handling fee is the token contract itself (specifically implemented in the _transfer function).
What is strange is that the tax address 0x 7 ffb (the address for collecting transfer fees) has been set in the contract, but the final fee was sent to the token contract itself.
Therefore, the final number of MUMI tokens added to the liquidity pool was 357,586,500 (approximately 350 million), tax-free, instead of 420,690,000 (approximately 430 million).
Lock in liquidity
At 8:01 (1 minute after the liquidity pool was created), the attacker address (0x 8 AF 8) locked up all 1.036 LP tokens obtained by adding liquidity.
After LP is locked, theoretically all MUMI tokens owned by the attackers address (0x 8 AF 8) are locked in the liquidity pool (except for the part used as handling fees), so the attackers address (0x 8 AF 8) There is also no ability to perform a Rug Pull by removing liquidity. In order to allow users to purchase newly launched tokens with confidence, many project parties lock LP, which means that the project parties are saying: I will not run away, everyone can buy with confidence! However, is this really the case? ? Obviously not, this is the case, let us continue the analysis.
Rug Pull
At 8:10, a new attacker address ② (0x 9 DF 4) appeared, and Ta deployed the tax address 0x 7 ffb declared in the token contract.
There are three points worth mentioning here:
1. The address where the tax address is deployed is not the same as the address where tokens are deployed. This may indicate that the project party is intentionally reducing the correlation between each operation and the address, making it more difficult to trace the behavior.
2. The contract of the tax address is not open source, which means that there may be hidden operations in the tax address that you do not want to expose.
3. The tax contract is deployed later than the token contract, and the tax address in the token contract has been hard-coded, which means that the project party can predict the address of the tax contract. Since the CREATE instruction determines the creator address and nonce, deployment The contract address is determined, so the project team simulated the contract address in advance using the creator’s address.
In fact, many exit scams are conducted through tax addresses, and the deployment mode characteristics of tax addresses comply with points 1 and 2 above.
At 11am (3 hours after the token was created), the attacker address ② (0x 9 DF 4) performed a Rug Pull. By calling the swapExactETHForTokens method of the tax contract (0x 77 fb), he exchanged 416, 483, 104, 164, 831 (approximately 416 trillion) MUMI tokens in the tax address for approximately 9.736 ETH, and consumed Exhausted the liquidity in the pool.
Since the tax contract (0x 77 fb) is not open source, we decompiled its bytecode and the decompilation results are as follows: https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c After viewing the tax contract (0x 77 fb) After decompiling the code of the swapExactETHForTokens method, we found that the main function of this function is to exchange the MUMI tokens owned by the tax contract (0x 77 fb) with the amount xt (specified by the caller) through uniswap V2 router into ETH and sent to the _manualSwap address declared in the tax address.
The storage address where the _manualSwap address is located is 0x 0. After querying with the getStorageAt command of json-rpc, we found that the address corresponding to _manualSwap is exactly the deployer of the tax contract (0x 77 fb): attacker ② (0x 9 DF 4).
The input parameter xt of this RugPull transaction is 420, 690, 000, 000, 000, 000, 000, 000, corresponding to 420, 690, 000, 000, 000 (approximately 420 trillion) MUMI tokens (MUMI tokens decimal is 9).
In other words, in the end, the project used 420, 690, 000, 000, 000 (approximately 420 trillion) MUMI to drain the WETH in the liquidity pool and complete the entire exit scam.
However, there is a crucial question here, which is where did the tax contract (0x 77 fb) come from so many MUMI tokens?
From the previous content, we know that the total supply of MUMI tokens at the time of deployment of the token contract is 420, 690, 000 (approximately 420 million), and after the exit scam is over, we query in the MUMI token contract The total supply is still 420, 690, 000 (shown as 420, 690, 000, 000, 000, 000 in the figure below, you need to subtract the 0 corresponding to the decimal, the decimal is 9), the tax contract (0x 77 fb) far exceed the total supply of tokens (420, 690, 000, 000, 000, about 420 trillion) as if they appeared out of thin air. You must know that, as mentioned above, 0x 77 fb as a tax address even The fees generated during the transfer of MUMI tokens are not used to receive the tax, and the tax is received by the token contract.
Technique Revealed
Where did the tax contract come from?
To explore the token origin of the tax contract (0x 7 ffb), we looked at its ERC 20 transfer event history.
It was found that among all 6 transfer events related to 0x 77 fb, there were only transfer events from the tax contract (0x 7 ffb), and there were no transfer events of any MUMI tokens. At first glance, the tax contract (0x 7 ffb) ) tokens really appeared out of thin air.
So the huge MUMI tokens that appeared out of thin air in the tax contract (0x 7 ffb) address have two characteristics:
1. Has no impact on the totalSupply of the MUMI contract
2. The increase in tokens does not trigger the Transfer event
Then the idea is very clear, that is, there must be a backdoor in the MUMI token contract. This backdoor directly modifies the balance variable, and when modifying balabce, it does not modify totalSupply, nor does it trigger the Transfer event.
In other words, this is a non-standard, or malicious, implementation of ERC 20 tokens, and users cannot detect that the project side is secretly minting tokens from changes in the total supply and events.
The next step is to verify the above idea. We directly search for the keyword balance in the MUMI token contract source code.
As a result, we found that there is a private type swapTokensForEth function in the contract, and the input parameter is tokenAmount of uint 256 type. In the 5th line of the function, the project party directly changes _taxWallet, which is the tax contract (0x 7 ffb) The MUMI balance is modified to tokenAmount * 10**_decimals, which is 1, 000, 000, 000 (approximately 1 billion) times the tokenAmount, and then the tokenAmount amount of MUMI is converted into ETH from the liquidity pool and stored in the token contract ( 0x 4894).
Then search for the keyword swapTokenForEth.
The swapTokenForEth function is called in the _transfer function. If you look closely at the calling conditions, you will find:
1. When the transfer receiving address is the MUMI-WETH liquidity pool.
2. When other addresses purchase MUMI tokens in the liquidity pool for more than _preventSwapBefore (5 times), the swapTokenForEth function will be called
3. The incoming tokenAmount is the smaller value between the MUMI token balance owned by the token address and _maxTaxSwap
That is to say, when the contract detects that the user has exchanged WETH for MUMI tokens in the pool more than 5 times, it will secretly mint a huge amount of tokens for the tax address, and convert part of the tokens into ETH and store them in the token contract.
On the one hand, the project party ostensibly collects taxes and automatically exchanges them for a small amount of ETH regularly and puts them into the token contract. This is shown to users and makes everyone think that this is the source of the project party’s profits.
On the other hand, what the project team is really doing is to directly modify the account balance and drain all the liquidity pool after the users number of transactions reaches 5 times.
How to make profit
After executing the swapTokenForEth function, the _transfer function will also execute sendETHToFee to send the ETH obtained from tax collection in the token address to the tax contract (0x 77 fb).
The ETH in the tax contract (0x 77 fb) can be taken out by the rescue function implemented in its contract.
Now look back at the redemption record of the last profitable transaction in the entire exit scam.
A total of two exchanges were made in the profitable transaction. The first exchange was 4,164,831 (approximately 4.16 million) MUMI tokens for 0.349 ETH, and the second exchange was 416, 483, 100, 000, 000 (approximately 4.16 million) billion) MUMI tokens for 9.368 ETH. The second exchange is the exchange initiated within the swapExactETHForTokens function in the tax contract (0x 7 ffb). The number is the same as the 420, 690, 000, 000, 000 (approximately 420 trillion) tokens represented by the input parameters. The reason for the discrepancy is that some tokens are sent to the token contract (0x 4894) as taxes, as shown in the figure below:
The first exchange corresponds to the second exchange process. When the token is sent from the tax contract (0x 7 ffb) to the router contract, the trigger condition of the backdoor function in the token contract is met, causing The exchange initiated by the swapTokensForEth function is not a critical operation.
The scythe behind
As can be seen from the above, the entire exit scam cycle from deployment, to creation of liquidity pool, to Rug Pull of MUMI tokens only takes about 3 hours, but at a cost of less than about 6.5 ETH (3 ETH for To add liquidity, 3 ETH was used to exchange MUMI from the liquidity pool for induction, and less than 0.5 ETH was used to deploy contracts and initiate transactions) and obtained 9.7 ETH, with a profit of more than 50%.
There were 5 transactions in which the attacker exchanged ETH for MUMI, which were not mentioned in the previous article. The transaction information is as follows:
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
By analyzing the eoa addresses operating in the liquidity, we found that a considerable part of the addresses are new robots on the chain. Combined with the characteristics of the entire scam, which is fast in and out, we have reason to believe that the target of this entire scam is the right one. It is a variety of new robots and new scripts that are very active on the chain.
Therefore, whether it is the seemingly unnecessary but complicated contract design, contract deployment, and liquidity locking process of the token, or the suspicious behavior of the attackers related address actively exchanging ETH for MUMI tokens, it can be understood that the attacker is trying to deceive Disguised through the anti-fraud procedures of various new robots on the chain.
By tracking the capital flow, we found that all the proceeds from the attack were finally sent to the address fund settlement address (0x DF 1 a) by the attack address ② (0x 9 dF 4).
In fact, the initial source of funds and the final destination of funds for many exit scams we have detected recently point to this address, so we have conducted a rough analysis and statistics on the transactions at this address.
It was ultimately discovered that the address became active about 2 months ago, has initiated over 7,000 transactions as of today, and has interacted with over 200 tokens.
We analyzed about 40 of the token transaction records and found that in the liquidity pools corresponding to almost all the tokens we looked at, there would eventually be an exchange transaction with an input amount that was much larger than the total supply of the token. The ETH in is depleted, and the entire exit scam period is shorter.
The deployment transactions of some of the tokens (Mingyan China) are as follows:https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17
https://etherscan.io/tx/0x 0 ca 86151 3d c 68 eaef 3017 e 7118 e 7538 d 999 f 9 b 4 a 53 e 1 b 477 f 1 f 1 ce 07 d 98 2d c 3 f
Therefore, we can conclude that this address is actually a large-scale automated exit scam harvester, and the target of harvesting is the new robot on the chain.
This address is still active.
write at the end
If a token does not modify the totalSupply when mint, and does not trigger the Transfer event, then it is difficult for us to detect whether the project side is secretly minting tokens. This will also exacerbate the problem that whether the token is safe or not depends entirely on the project side. Conscious or not status quo.
Therefore, we may need to consider improving the existing token mechanism or introducing an effective token total detection solution to ensure the openness and transparency of token quantity changes. Currently, it is not enough to capture token status changes with events.
And what we need to be alert to is that although everyones anti-fraud awareness is improving, attackers anti-fraud methods are also improving. This is a never-ending game. We need to keep learning and thinking to be able to do this. Protect yourself in the game.
Tools used in this article
View basic transaction information:https://etherscan.io/
Contract decompilation:app.dedaub.com/decompilejson-rpc：
