This set of tasks is part of the Pessimistic Junior Solidity smart contracts security educational initiative. Learn more here: https://medium.com/pessimistic-security/pessimistic-launches-junior-program-de0fcc4f4097
Solutions need to be posted to gist and sent to us as individuall links for each task! Send your solutions to [email protected], and we will publish and link to the best ones! In addition, we will invite you to the subsequent Pessimistic Junior!
The version in Russian language can be found here.
Write a small description of how the code works. You also need to write out the vulnerabilities, fix them in the code and send a corrected version of the code.
Note: you don't need to rewrite the whole code, it should be small edits.
You need to compare the implementation of BEP20 token with standard and write out the differences.
Example: If the implementation of the approve
function does not meet the formal requirements of the standard, write this inconsistency as an issue.
If it complies, write nothing.
Imagine that each contract is deployed separately. You need to understand the code and answer the following questions:
- How is the
_placementRegistry
from the ManagerStorage contract initialized? (Write a mini-contract with 3 variants of initialization. For instance, you can design it as 3 functions). - Are the items at line 73 in the Placements contract added correctly? Why? (Give a detailed explanation).
- What is the purpose of
using Items for ItemtId
in Items library? (Give an extended explanation and specify the line in the code). - How is the placement fee deducted? Who is it paid from and to whom? How are
msg.sender
andaddress(this)
changed with each external call? (Give a detailed explanation)
You need to understand the code, write out issues and send a contract with fixes.
Note: you don't need to rewrite the whole code, it should be small edits.
You need to figure out how to run slither on this contract, and check the occurrences of all severity levels except informational
. Write out all the ones you confirm (with your brief description/comment).
Important: occurrences for OpenZeppelin contracts do not need to be validated!
The following command can be used to run slither (do not exclude OpenZeppelin contracts via flags, as some occurrences may not display):
slither . --solc-disable-warnings --exclude-informational
You are given a foundry
project. Your task is to install it, run tests on an arbitrum fork and explain why exactly they fail.
Please, send the following as a solution:
- Results of the running test.
- Why the test does not pass (use the
-vv
flag to get the detailed result). Describe the reason in detail. - Find a specific line in the code where calculations occur that were not expected when the test was written.
-
documentation foundry
-
It is recommended to run tests with the following command:
forge test -vv --fork-url <your-arbitrum-rpc-url>
- you can get a free rpc for arbitrum here.
It is a complex chain of contract calls. You need to understand the code and answer the questions:
- Which contract is the entry point?
- Where in the code is the
onERC721Received
function from Vault called? You need to write out the call chain. - What are
address(this)
andmsg.sender
equal to whenController.transferAssetToVault
is called? - Will
require
ofmodifier whenAssetDepositAllowed
(Vault contract) be reverted or not? Why? - Will
modifier onlyDelegatecall
from Controller contract correctly work out? Why? - How many contracts are being deployed? Which ones?
There is a game of King of the Ether:
- The contract is initialized with
1 ether
on the balance; - The objective of the game is to make more
ether
than the other users. - Each person has the right to add
ether
to the contract. - 30 days after the contract is created, the game is considered to be over. And the person who has staked the most
ether
gets anotherether
as a reward. - A person is not allowed to take out an
ether
until the game is over. - When the game is over, each person can call the
withdraw
function to take hisether
.
You need to write a contract for this game that is vulnerable to reentrancy, and also write an attacking contract.
You need to compare the implementation of ERC20 token with standard and write out the differences.
Example: If the implementation of approve
function does not meet the formal requirements of the standard, write out this inconsistency as an issue.
If it complies, write out nothing.
You need to understand the code and write out all possible issues in the following format: Contract.function L25 - description.
KYC - The recommended version of OpenZeppelin 4.9.
What minimal checks/operations should be added to the code to avoid signature malleability for ecrecover(). It is necessary to handle edge cases so that possible reverts are as rare as possible.
🔐 Pessimistic delivers trusted security audits since 2017.
Require expert oversight for your project safety?
Explore our services at pessimistic.io.