Be vigilant of hidden Rug Pulls, as well as exit scams caused by contract storage.

Beware of hidden Rug Pulls and exit scams from contract storage.

By: Kong

Background

From the DeFi summer to now, after experiencing various means such as vulnerabilities, backdoors, and exit scams, we have finally learned to check the permissions of token contracts, token distribution, and contract code on DEX before participating in new projects to protect our asset security. However, the malicious tactics of bad actors have become more sophisticated and covert. Recently, the SlowMist Security Team received help from a user in the LianGuaincakeSwap community who observed that a large amount of tokens were stolen from the pool by malicious users who used undisclosed token minting without any record of token issuance. The SlowMist Security Team followed up and analyzed this incident, and the results are shared below:

Attack Details

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

• LianGuairadigm proposes ten potential trends, and intent-centric ranks first. What is intent-centric?
• Web3 Mobile Review Can the encryption industry usher in an iPhone moment?
• Another example of a flash loan attack, analysis of the LianGuailmswap security incident

By further examining the source of these tokens, we found that these tokens only have outgoing transactions but no incoming transactions in 0x00002b9b0748d575CB21De3caE868Ed19a7B5B56.

We all know that the EIP20 standard[2] stipulates that the Transfer event must be implemented when transferring tokens, including when minting tokens, and transfer from the 0x0 address must also be recorded. Block explorers rely on these standard event records for data statistics. Therefore, when the token total in the block explorer does not match the actual quantity, it indicates that the token minting was not recorded during the minting process, resulting in the block explorer only accounting for the balance changes of related addresses after transfers, without any token minting records. Based on this, we can determine that there must be malicious code for minting tokens in the token contract.

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

Since no code for directly increasing the balance was found, how did the project team mint tokens? Let’s review the basics of smart contracts. We know that the change in user token balances essentially modifies the data state stored by the contract on the chain. Therefore, as long as the data slot corresponding to _balances for a specific address in the contract is modified, the token balance can be changed.

Let’s briefly review the basic knowledge of calculating the storage location of contract data in the EVM. For the mapping type _balances, it will obtain the offset by keccak256 after the key value k and its occupied position p, which serves as the storage slot location, namely keccak256(k,p). By analyzing the data storage location of the IEGT contract, we can find that the position of the _balances parameter is slot0, so the storage location of the user’s balance is keccak256(address,0).

By substituting the malicious address for calculation, we can obtain the balance storage location as 0x9d1f25384689385576b577f0f3bf1fa04b6829457a3e65965ad8e59bd165a716. Then, by looking up the data changes in this slot, we can find that it has been changed to a huge value during contract deployment.

Therefore, we can determine that the project party discreetly issued a large amount of tokens during the deployment and initialization of the IEGT contract, preparing for the rug. Next, let’s follow its initialization function and analyze that it modifies the contract storage through inline assembly when performing the _LianGuaithSet operation, without formatting the code to reduce its readability.

By following the calculation, it is found that the value of y is 2b9b0748d575cb21de3cae868ed19a7b5b56. By using two mstore operations, the memory positions from 0 to 64 bytes are filled with 00000000000000000000000000002b9b0748d575cb21de3cae868ed19a7b5b56. 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 obtain the target address under their control. Therefore, we can also find this calculation result of the “address” that has not been filled in the compiled bytecode.

Then, by using keccak256 to hash the data in memory positions 0 to 64 bytes, the balance storage slot position of the malicious user, 0x9d1f25384689385576b577f0f3bf1fa04b6829457a3e65965ad8e59bd165a716, is obtained. This is also the reason why the _balances is placed in slot0 in the contract, which greatly facilitates the calculation of the actual storage location of balances in inline assembly. Then, using sstore, the value of this storage location in the contract is modified to the 6th power of the current time, thus 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 modified the balance of a specified address through inline assembly during contract initialization, secretly minting a large number of tokens that were not known to other users, causing users to be rug pulled when participating in the project.

Tracking Analysis

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

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, lowered code readability by using unformatted code, and used inline assembly to write code that directly modifies the user’s balance storage slot data, increasing the threshold for code analysis. They used various means to hide their wrongdoings and ultimately emptied the pool. It can be observed that as users’ security awareness increases, the means used by malicious actors become increasingly covert and sophisticated. According to SlowMist Hacked[4] statistics, as of now, the losses caused by rug pulls are close to 500 million USD. 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.

Reference links:

[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!