Be vigilant of the hidden rug pull caused by contract storage leading to a run-off.

Beware of contract storage causing a sudden drop.

Background

From the DeFi summer to now, after experiencing various vulnerabilities, backdoors, and scams, we have finally learned to protect our asset security by checking the token contract’s permissions, token distribution, and contract code before participating in new projects on DEX. However, the bad actors have become more sophisticated and covert in their malicious methods. Recently, SlowMist Security Team received a request for help from a user in the LianGuaincakeSwap community, who noticed that a large amount of tokens were taken from the pool by a malicious user through undisclosed token minting, even though there was no record of token minting in the project. SlowMist Security Team followed up and analyzed the incident, and the results are shared below:

Attack Details

The malicious token IEGT’s deployment address on BSC is 0x8D07f605926837Ea0F9E1e24DbA0Fb348cb3E97D[1]. By observing its Holders through a block explorer, we found that despite the presence of a large amount of IEGT tokens held by dead and LianGuaiir addresses, the contract recorded totalSupply as 5,000,000.

• Variant Partner Why is UniswapX said to be a boost for Uniswap?
• Another case of flash loan attack Analysis of the LianGuailmswap security incident
• Why is Musk’s Twitter reform said to have a profound impact on cryptocurrencies?

By further examining the source of these tokens, we found that there were only transfer-out records for these tokens in 0x00002b9b0748d575CB21De3caE868Ed19a7B5B56 and no transfer-in records.

We all know that the EIP-20 standard[2] specifies that the Transfer event must be implemented when transferring tokens, including recording events when minting tokens and transferring from the 0x0 address. Block explorers rely on these standard event records for data statistics. Therefore, when the token totalSupply does not match the actual quantity in a block explorer, it indicates that there was no event record of token minting during the increase in supply, causing the block explorer to only track the balance changes of relevant addresses after transfers, without any record of token minting. Based on this, we can confirm that there is malicious code in the token contract that mints tokens.

The source code of this token contract is open-source, presumably to increase the project’s credibility. Next, we will analyze its source code. Generally, the simplest way to mint tokens is by implementing a method that directly increases the balance of a specified address. In the current contract, this is achieved by defining a mapping called _balances to record the token balance of users. However, upon inspection, we did not find any code that modifies the _balances of a specified address.

Since we did not find any code that directly increases the balance, how did the project team mint tokens? Let’s review the basics of smart contract knowledge. The change in user token balance is essentially a modification of the data state stored by the contract on the chain. Therefore, by modifying the slot data corresponding to the _balances of a specific address in the contract, the token balance can be modified.

Let’s briefly review the basic knowledge of calculating contract data storage locations in the EVM. For the mapping type _balances, it calculates the slot position based on its key value k and its occupied position p by performing keccak256, which serves as the slot position for storage, i.e., keccak256(k,p). By analyzing the data storage location of the IEGT contract, we can find that the _balances parameter is located in slot0, so the storage location of a user’s balance is keccak256(address,0).

By inputting a malicious address for calculation, we can obtain the balance storage location of the remaining tokens as 0x9d1f25384689385576b577f0f3bf1fa04b6829457a3e65965ad8e59bd165a716. Subsequently, by examining the changes in this slot data, we can find that it has been modified to a huge value during contract deployment.

Therefore, we can determine that during the initialization of the IEGT contract deployment, the project party secretly increased a large amount of tokens, preparing for the rug pull. Next, we follow its initialization function and analyze that it modifies the contract storage through inline assembly when performing the _LianGuaithSet operation, and does not format the code to reduce its readability.

By following the calculation, we find that the value of y is 2b9b0748d575cb21de3cae868ed19a7b5b56. Through two mstore operations, the memory position of 0 to 64 bytes is filled with 00000000000000000000000000002b9b0748d575cb21de3cae868ed19a7b5b56, and the address that maliciously increases the token balance is 0x00002b9b0748d575CB21De3caE868Ed19a7B5B56. It can be seen that the malicious user constructs a series of data calculations to exactly obtain the target address under their control. Therefore, we can also find this “address” that is not padded after the calculation from the compiled bytecode.

Then, by hashing the data in memory positions 0 to 64 bytes using keccak256, we exactly obtain the balance storage slot location of the malicious user as 0x9d1f25384689385576b577f0f3bf1fa04b6829457a3e65965ad8e59bd165a716. This is also the reason why the _balances is placed at slot0 in the contract, which greatly facilitates the calculation of the actual storage location of the balance in inline assembly. Then, sstore is used to modify the value at this storage location in the contract to the 6th power of the current time, completing the modification of the balance for the specified address. The subsequent inline assembly operations are similar and will not be elaborated here.

So far, we know that the project party, during contract initialization, secretly increased a large amount of tokens by modifying the balance of the specified address through inline assembly, which was not known by other users, leading to a rug pull when users participated in the project.

Tracking Analysis

Through MistTrack[3], the profit addresses in this incident on the BSC chain are 0x000000481F40f88742399A627Cbc2Afb6Ec34FeD and 0x00002b9b0748d575CB21De3caE868Ed19a7B5B56, with a total profit of 1.14 million USDT. The source of the transaction fees for the transfer of profits from the profit addresses is Binance exchange withdrawals.

The current fund transfer situation is as shown in the following figure:

In addition, the fee address of the malicious contract creator, 0xb795ad917DAF9A1c98eE18E03E81FBBfb6D54355, also has a large number of traces.

Summary

In this incident, the project party open-sourced the contract code to increase user trust, reduced code readability by using unformatted code, and used inline assembly to write code that directly modifies user balance storage slot data, raising the threshold for code analysis. They used various means to hide malicious traces and eventually emptied the pool. It can be seen that as user security awareness increases, the means used by malicious actors become more concealed and sophisticated. According to SlowMist Hacked[4] statistics, as of now, the loss caused by Rug Pull is close to $500 million. Therefore, when participating in new projects, users should focus on analyzing whether there is suspicious code in their contracts and try to avoid participating in projects that are not open source and have not been audited. The MistTrack team will continue to follow up and monitor this incident.

References:

[1] https://bscscan.com/address/0x8d07f605926837ea0f9e1e24dba0fb348cb3e97d

[2] https://eips.ethereum.org/EIPS/eip-20

[3] https://misttrack.io/

[4] https://hacked.slowmist.io/

We will continue to update Blocking; if you have any questions or suggestions, please contact us!