Lucky Strike v3 security audit report

ETH_LuckyStrikeV3_report.md

Lucky Strike v3 security audit report

Summary

This is the report from a security audit performed on Lucky Strike v3 by gorbunovperm.

Lucky Strike, based fully in Ethereum smart-contract, is bringing the core philosophy of blockchain to the gambling industry – enhancing it with an ICO model we’re calling ‘Bet & Own.’

In scope

1. LuckyStrike
2. LuckyStrikeTokens

Findings

In total, 4 issues were reported including:

• 0 high severity issue.

• 2 medium severity issues.

• 2 low severity issues.

• 0 minor observations.

Security issues

1. Known vulnerabilities of ERC-20 token

Severity: low

Description

• It is possible to double withdrawal attack. More details here

• Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here

2. Possibility of minting more than hardCap

Severity: low

Code snippet

• LuckyStrikeTokens, line 345

Description

Function mint allows owner to mint more tokens than hardCap.

Recommendation

You should check (invested + _invested) > hardCap before minting and if it's true, mint only hardCap - invested number of tokens and return remainder to investor.

3. Owner Privileges

Severity: medium

Code snippet

• LuckyStrike, line 1575

Description

adjustAllocation function allows the owner to reset the rates of the different jackpots and income rate.

4. It is possible to use Ahead of The Curve stategy

Severity: medium

Code snippet

• LuckyStrike, line 1936

Description

Formula of the random calculation is:

    bytes32 seed = keccak256(
        block.blockhash(lastInstantGameBlockNumber[player])
    );

    uint256 randomNumber = uint256(seed) % ticketsInTheInstantGame;

The result of the player's fight with the King of the hill is known immediately after the player has placed a bet. But the result will be applied only after calling the play method. This way different players can use information about bets(and block hashes) for their own profit.

• For example, the King of the hill can choose to fight with the enemy(among the few players who made bets) which will lose(the king knows the result in advance) and call play(looser_address) method. Thus, he can choose the order of battles, first collecting winnings, and then losing.

• Another case if attacker is player. Knowing that he will win the King of the mountain(and he can find out), attacker initiates a fight with King ahead of other players. Further acting in accordance with paragraph 1. Or if attacker knows he's going to lose to the King, that he can wait for someone to fight with King and when the new King comes up the hill, fight him.

Recommendation

There should not be a gap between reliable information that someone won between the fact of this. A good solution would be to play all the instant games in the first block after the any bet. Even if there were several bets in one block, they all need to be played at the first next appeal to the contract.

Conclusion

There is some vulnerabilities that should be fixed.