According to blockchain security company PeckShield security shield wind control platform DAppShield monitoring news, on April 10 at 23:02, the hacker launched 1,203 attacks on the wave field quiz game TronWow, a total of 2,167,377 TRX (about $57,148). PeckShield security personnel immediately analyzed that hackers earned 1,940 TRXs in return for 20 TRX, with a return rate of 97 times . Eventually, through this attack, hackers totaled 23,004 TRX and made 2,167,377 TRX.
Since then, PeckShield security personnel have further in-depth analysis found that the TronWow contract has flaws in checking the betting range, allowing users to construct malicious input when non-page bets, thus achieving a win-win game outcome.
TronWow is a classic dice game. The player performs a round of play by selecting the bet number and the bet.
- I understand the current status of blockchain games: To what extent is it going to happen, will there be hope in the future?
- DApp Ecology | Halo is snatched away by DeFi, how do the left-wing chain tour developers break through?
- Viewpoint | Blockchain game is not the future
- Knowing that playing Just.Game has a high probability of losing money, why are there still many people who "get into the pit"?
- The death of chain travel: Are they born for entertainment, or are they born for trading?
- Quiz, pyramid scheme, Ponzi scheme? Be careful with the blockchain game these "pits"
As shown in the figure below, when the user participates in the game on the TronWow game page, regardless of whether the Under mode or the Over mode is selected, the range and winning percentage of the bet number are limited. among them
- Under mode can bet the number is [2, 95],
- The over mode can be bet number [6, 99],
- The game randomly generates a range of numbers [1, 100],
The Under and Over modes have a winning percentage of [2%, 95%] and the bonus multiple is [97 / Win percentage].
PeckShield security staff found in a deep reverse analysis of the TronWow contract that the TronWow contract was flawed when checking the betting range, allowing users to construct malicious input when non-page bets. In other words, once the user avoids the game page and directly calls the betting function of the game contract, he can try to bypass the betting range check condition in the contract, achieving 100% winning percentage and maximum return multiple (97 times).
The contract vulnerabilities are described below in normal betting transactions and malicious betting transactions.
In the TronWow contract code, the function placeBet(uint24 _betMask, uint256 _commit, bytes32 _r, bytes32 _s) is the bet function, and the parameter uint24 _betMask is the player's bet information.
Where the normal bet transaction calls the placeBet function, enter the following:
This is a normal trade with Under mode and a bet number of 95. In other words, the player wins when the random number generated by the game is less than or equal to 95.
In this transaction, the value 24321 of the parameter _betMask is converted to hexadecimal 0x005F01, which we split into three bytes, as follows:
- 0x00 is decimal 0;
- 0x5F is decimal 95;
- 0x01 is decimal 1.
The first part of 0x00 means that if the random number calculation result generated by the round game is between [0x01, 0x5f], the player wins; on the contrary, the first two digits are not 0x00, indicating that if the random number calculation result of the round game is at In addition to [0x01, 0x5f], the player wins.
In the reverse process, we restore some of the assembly instructions of the bet function to pseudocode, as shown in the following figure:
Reading the above-mentioned bet function pseudocode, it can be found that the contract only checks the percentage of winning percentage in the player's bet information, requiring it to be less than or equal to 95, but does not limit the number of bets. Therefore, the player can bypass the check by constructing a bet number.
The following image shows one of many attack transactions initiated by an attacker:
The _betMask parameter is constructed as 130971 and hexadecimal is 0x01FF9B. The first two digits 0x01 indicate that if the random number calculation result generated by the round of the game is outside [0x9B, 0xFF], the player wins. The decimals corresponding to 0x9B and 0xFF are 155 and 255 respectively. According to the winning percentage percentage calculation rule written by the contract, winRate = 100 – (0xFF – 0x9B) + 1, which is equal to 1, thus successfully bypassing the bet range checking function, and Set the bonus multiple of this transaction to 97. It is important to emphasize that in the page bet, the bonus multiplier is only 48.5 times.
Next, we restore the compilation function of the winning game settleBet (uint256 _reveal, bytes32 _txHash) to the pseudo code:
The rollResult is the random number calculation result of this round of games, and the value range is [1,100]. In the malicious parameters set by the attacker, the rollResult must be outside the [155, 255] interval, satisfying the conditions for winning the current game, thus ensuring that the attacker's game results are stable.
to sum up:
For the TronWow contract attack, PeckShield security analysts found that the TronWow contract was flawed when checking the betting range, allowing users to construct malicious input when non-page bets, achieving a 100% win rate. It should be noted that the vulnerability has been fixed in the new version of TronWow's online version of the contract, the game side added a constraint check on the betting range.
Here, PeckShield security personnel reminded the project parties and exchanges to pay attention to any security issues in the blockchain world to ensure the security of the project side and users' assets. Security is no small matter, and the act of not publishing the source code to defend against hacking attacks is ineffective in front of hackers. DApp developers should put an end to luck and make necessary security measures and known attack signature checks before the contract goes online. If necessary, contact a third-party security company for vulnerability investigation to avoid unnecessary loss of digital assets.