AI Arena - xchen1130's results

In AI Arena you train an AI character to battle in a platform fighting game. Imagine a cross between PokΓ©mon and Super Smash Bros, but the characters are AIs, and you can train them to learn almost any skill in preparation for battle.

General Information

Platform: Code4rena

Start Date: 09/02/2024

Pot Size: $60,500 USDC

Total HM: 17

Participants: 283

Period: 12 days

Judge:

Id: 328

League: ETH

AI Arena

Findings Distribution

Researcher Performance

Rank: 231/283

Findings: 3

Award: $1.22

🌟 Selected for report: 0

πŸš€ Solo Findings: 0

Lines of code

https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/FighterFarm.sol#L346 https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/FighterFarm.sol#L363

Vulnerability details

Impact

In FighterFarm.sol, fighter nft can not be transferred if the nft has already been staked or the receiver has already 'MAX_FIGHTERS_ALLOWED' number of fighters. But the check is only present in "transferFrom(address from, address to, uint256 tokenId)" and "safeTransferFrom(address from, address to, uint256 tokenId)", while there is another public function "safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data)" in 'https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.9.5/contracts/token/ERC721/ERC721.sol#L167' which can be used to transfer fighter nfts. Thus, the safety check can be bypassed. If an user trades his/her staked fighter nft to a new owner, the new owner can steal staked NRN tokens from the old owner by calling 'unstakeNRN()' in 'RankedBattle.sol'.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

Tools Used

In FighterFarm.sol, override the function "safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data)" defined in ERC721.sol to add the check '_ableToTransfer()'.

Assessed type

Token-Transfer

#0 - c4-pre-sort

2024-02-23T04:14:59Z

raymondfam marked the issue as insufficient quality report

#1 - c4-pre-sort

2024-02-23T04:15:10Z

raymondfam marked the issue as duplicate of #54

#2 - c4-pre-sort

2024-02-23T04:47:03Z

raymondfam marked the issue as duplicate of #739

#3 - c4-pre-sort

2024-02-23T04:49:36Z

raymondfam marked the issue as sufficient quality report

#4 - c4-judge

2024-03-11T02:33:54Z

HickupHH3 marked the issue as satisfactory

Lines of code

https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/GameItems.sol#L291

Vulnerability details

Impact

Even if a game item is NOT transferable, the game NFT token can still be transferred by calling the function 'safeBatchTransferFrom()' defined at "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v5.0.1/contracts/token/ERC1155/ERC1155.sol#L120".

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

Tools Used

In GameItems.sol, override the function 'safeBatchTransferFrom()' defined in ERC1155.sol to add a check to see if the game item is transferable.

Assessed type

Token-Transfer

#0 - c4-pre-sort

2024-02-22T03:25:49Z

raymondfam marked the issue as sufficient quality report

#1 - c4-pre-sort

2024-02-22T03:25:57Z

raymondfam marked the issue as duplicate of #18

#2 - c4-pre-sort

2024-02-26T00:27:09Z

raymondfam marked the issue as duplicate of #575

#3 - c4-judge

2024-03-05T04:47:39Z

HickupHH3 changed the severity to 3 (High Risk)

#4 - c4-judge

2024-03-05T04:49:15Z

HickupHH3 marked the issue as satisfactory

#5 - c4-judge

2024-03-05T04:50:09Z

HickupHH3 removed the grade

#6 - c4-judge

2024-03-05T04:50:13Z

HickupHH3 marked the issue as satisfactory

Lines of code

https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/FighterFarm.sol#L370 https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/FighterFarm.sol#L372 https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/FighterFarm.sol#L380 https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/FighterFarm.sol#L385

Vulnerability details

Impact

Based on the code in '_createNewFighter()', if fighterType == 1, then fighters.dendroidBool = true; if fighterType == 0, then fighters.dendroidBool = false. A malicious user can call the function 'reRoll()' with a malicious 'fighterType' parameter(which is inconsistent with 'fighters[tokenId].dendroidBool') to create invalid/inconsistent fighter data: fighters[tokenId].dendroidBool is not changed, but fighter 'element/weight/physicalAttributes' are re-calculated based on wrong fighterType and they may impact the fighter winning rate and rewards in battles.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

Tools Used

Add a check in 'reRoll()' to make sure parameter 'fighterType' is consistent with fighters[tokenId].dendroidBool.

Assessed type

Other

#0 - c4-pre-sort

2024-02-21T23:53:51Z

raymondfam marked the issue as insufficient quality report

#1 - c4-pre-sort

2024-02-21T23:53:58Z

raymondfam marked the issue as duplicate of #17

#2 - c4-pre-sort

2024-02-22T00:31:16Z

raymondfam marked the issue as sufficient quality report

#3 - c4-pre-sort

2024-02-22T00:31:21Z

raymondfam marked the issue as not a duplicate

#4 - c4-pre-sort

2024-02-22T00:31:39Z

raymondfam marked the issue as duplicate of #305

#5 - c4-pre-sort

2024-02-22T01:04:51Z

raymondfam marked the issue as duplicate of #306

#6 - c4-judge

2024-03-05T04:30:48Z

HickupHH3 marked the issue as satisfactory

#7 - c4-judge

2024-03-19T09:05:00Z

HickupHH3 changed the severity to 3 (High Risk)

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax Β© 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter