Mystery Box

Description

In the MysteryBox contract, there is a significant inconsistency between the reward values initialized in the constructor and the values assigned during the reward distribution in the openBox function. Specifically:

• Constructor Initialization:

• Reward Distribution in openBox:

The comments highlight that the magic numbers used for “Silver Coin” and “Gold Coin” in the openBox function do not align with the intended values set in the constructor. Specifically:

• “Silver Coin” is initialized with 0.25 ether but distributed as 0.5 ether.

• “Gold Coin” is initialized with 0.5 ether but distributed as 1 ether.

Impact

This discrepancy leads to the contract distributing rewards with higher values than intended, effectively doubling the payout for “Silver Coin” and doubling the payout for “Gold Coin.” The immediate consequences include:

1. Financial Drain: The contract’s Ether reserves will deplete faster than anticipated, especially if a significant number of users open boxes and receive high-value rewards.

2. User Trust Erosion: Users may lose trust in the contract’s reliability and fairness, especially if high-value rewards become scarce or if the contract becomes unable to honor reward claims.

3. Sustainability Risks: The imbalance between box prices and reward payouts jeopardizes the contract’s long-term sustainability, potentially leading to its failure to support the ecosystem it aims to foster.

4. Potential Exploitation: Malicious actors might exploit this inconsistency to drain the contract’s funds by repeatedly obtaining high-value rewards, further exacerbating the financial risks.

PoC

1. Deployment:

• Deploy the MysteryBox contract with the initial rewards set in the constructor:

• “Gold Coin” at 0.5 ether

• “Silver Coin” at 0.25 ether

• “Bronze Coin” at 0.1 ether

• “Coal” at 0 ether

2. Box Purchase and Opening:

• A user purchases a box by sending 0.1 ether via the buyBox function.

• The user then opens the box by calling the openBox function.

3. Reward Distribution:

• If the random value falls within the range for “Silver Coin” (95-98), the user receives a reward of 0.5 ether instead of the intended 0.25 ether.

• Similarly, if the random value falls within the range for “Gold Coin” (99), the user receives 1 ether instead of 0.5 ether.

4. Outcome:

• The contract sends higher-than-intended rewards, leading to a rapid depletion of its Ether balance.

• Subsequent users attempting to claim high-value rewards may encounter failed transactions due to insufficient funds, undermining the contract’s functionality and user trust.

Tools Used

• **Manual Code Review: **Analyzing the smart contract’s source code to identify inconsistencies between the constructor and the openBox function.

Recommendations

• **Remove Magic Numbers: **Eliminate hard-coded values by referencing the rewardPool. This reduces the risk of discrepancies and makes the code more maintainable and less error-prone.