Vitalik account "hacked" to post phishing information, these fraudulent methods of obtaining funds should be a concern for users.

On September 10th, Ethereum co-founder Vitalik Buterin's X platform (formerly Twitter) account was hacked and a phishing link was posted. The content of the link was about Danksharding and a commemorative NFT free claim link. Although the tweet was quickly deleted, the hacker still stole about $700,000.

Earlier in July, Uniswap founder Hayden Adams' X platform (formerly Twitter) account was also hacked and a tweet containing a phishing link was posted. This shows that there are still frequent security incidents, such as phishing attacks, in the recent blockchain ecosystem.

Previously, Beosin provided a detailed analysis of phishing attacks, which you can read here: UNIBOT is booming, how to prevent phishing and scams related to Telegram bots?
Signature stolen? Please be cautious if you have used Uniswap! Exposing the Permit 2 signature phishing

In addition to phishing attacks, what other ways should users be wary of for fund scams? Recently, the Beosin team discovered that rug pulls and price manipulation events have also caused significant losses to users' funds.

As the blockchain technology becomes more mature, the occurrence of problems at the code level is decreasing, making it more inclined towards scams and issues in business logic. In this article, we will list some of the common fund security issues that have recently occurred, and help users avoid falling victim to some fund scams.

Recently, there have been cases of scams and frauds, where manipulators mainly deceive funds through backdoors in contracts and pyramid schemes. However, users can actually avoid these types of scams by understanding how contracts operate and the principles behind the code. We will illustrate this with recent projects and summarize the characteristics of such scams.

I. Precautions for project backdoors

1. Modifying balance with privileged address

Generally, projects involved in scams will have a privileged address, which can freely mint, burn, or modify the balances of others. Such projects carry the risk of running away, where after users have used a large amount of funds to purchase project tokens, the project party directly exchanges all the valuable coins through the privileged function, causing the value of the project tokens to become zero.

Take the CUZK project code as an example:

In the CUZK token contract, there is a backdoor where the privileged address can directly set tokens for their own account exceeding the total supply, as shown in the following code:

The function ccvipaaaqqq() will add a massive amount of CUZK tokens to the caller's account and finally check if the caller is ciyuAdmintmrr. This address is set by the creator of the contract during initialization (0xf719).

The project party added a massive amount of tokens to themselves (0xf719) by calling the ccvipaaaqqq() function. 

Subsequently, the privileged address uses the set tokens to fully exchange WBNB in the pair, causing the value of CUZK tokens to become zero.

2. Hidden Backdoor, Indirectly Adding Balance

There are also some projects that do not directly manipulate the balance of token addresses, but privileged addresses can indirectly obtain a large number of tokens, thus exchanging all valuable coins and causing the token price to drop to zero.

Take Flashmall project on BNB chain as an example:

FlashMall contract has a 'setPointRate' function used to set the exchange rate, which can only be called by privileged addresses.

This running-away event mainly consists of the following steps:

Set exchange rate -> Exchange -> Set exchange rate -> Exchange

The detailed steps are as follows:

1. The privileged address sets the rate to 10000.

2. Address 0x613 C can exchange MUSD for 10 times the value of MCoin.

3. The privileged address sets the rate to 1000.

4.0x 613 C address can exchange MCoin for the same amount of MUSD.

5.By multiple conversions, 0x 613 C has accumulated a large amount of MUSD, and finally exchanged all USDT out. 

The following is the code for the exchange between MCoin and MUSD, with the quantity determined by pointRate. 

Summary: Whether a contract has a backdoor mainly depends on whether there is a privileged function that can manipulate tokens of any address, or whether there is a logic function for privileged address token issuance. In addition, if the project party owns the majority of liquidity certificates, there may also be a potential risk of running away. Users can judge the degree of risk by examining whether the contract has given up privileged addresses or whether the privileged address is a normal business contract address, and by checking whether the liquidity certificates are owned by an EOA account or a normal business contract.

II. Pixiu Plate Scam

Characteristics of this type of project mainly include being able to purchase project tokens, but when users want to sell them, the transaction will fail. The main manifestation of such scam contract code is that some contract states will be set during the first token transfer, and no further transfers can be made afterwards, causing users to buy tokens, set the contract states, and then become unable to sell them.

Take the fake EDU token project as an example:

The project contract address is 0x 4749, which is the same name as the EDU project. The token owner (0x ac 15) buys and sells tokens in the EDU pair contract address 0x E 3 f 2, and sends the held tokens to Binance wallet and exchanges, creating an illusion of many participants (shown in the figure below).

The code below, after the first transfer of the coins, sets tokenGreylist[to] (where to is the user's address) to true. However, due to the undisclosed status of the whitelist addresses in the code, the transfer function cannot be called a second time. The switch status and whitelist addresses are controlled by the owner. For users participating in this project, by default, they cannot sell the tokens.

Summary: The characteristic of the Pixiu Plate project is that you can buy but cannot sell. Check the actual logic of the transfer and transferfrom functions to see if there are any restrictive conditions. If you have the technical capability, you can locally simulate the execution of the relevant functions.