# Quiz

{% embed url="<https://ventral.digital/posts/2021/11/14/secureum-bootcamp-security-pitfalls-amp-best-practices-201-quiz>" %}
Slot 5 Quiz
{% endembed %}

Note: All 8 questions in this quiz are based on the InSecureumToken contract shown below. This is the same contract you see for all the 8 questions in this quiz. The InSecureumToken contract implements a token contract which allows users to buy tokens by depositing Ether (at a certain conversion ratio), and transfer tokens.

```solidity
pragma solidity 0.7.0;

contract InSecureumToken {

mapping(address => uint) private balances;

uint public decimals = 10**18; // decimals of the token
uint public totalSupply; // total supply
uint MAX_SUPPLY = 100 ether; // Maximum total supply

event Mint(address indexed destination, uint amount);

function transfer(address to, uint amount) public {
   // save the balance in local variables
   // so that we can re-use them multiple times
   // without paying for SLOAD on every access
   uint balance_from = balances[msg.sender];
   uint balance_to = balances[to];
   require(balance_from >= amount);
   balances[msg.sender] = balance_from - amount;
   balances[to] = safeAdd(balance_to, amount);
}


/// @notice Allow users to buy token. 1 ether = 10 tokens
/// @dev Users can send more ether than token to be bought, to donate a fee to the protocol team.
function buy(uint desired_tokens) public payable {
   // Check if enough ether has been sent
   uint required_wei_sent = (desired_tokens / 10) * decimals;
   require(msg.value >= required_wei_sent);

   // Mint the tokens
   totalSupply = safeAdd(totalSupply, desired_tokens);
   balances[msg.sender] = safeAdd(balances[msg.sender], desired_tokens);
   emit Mint(msg.sender, desired_tokens);
}


/// @notice Add two values. Revert if overflow
function safeAdd(uint a, uint b) pure internal returns(uint) {
   if (a + b < a) {
      revert();
   }
   return a + b;
}
}
```

***

**Q1 The InSecureumToken contract strictly follows the specification of**

* [ ] A) ERC20
* [ ] B) ERC777
* [ ] C) ERC721
* [x] D) None of the above

**Comment:**

Since decimals was defined as `uint` (same as `uint256`) and not as `uint8` as ERC20 or ERC777 standardized, it can't strictly be either of them. And since this is clearly a fungible token contract, it can't be ERC721.

**Q2 To avoid lock of funds, the following feature(s) MUST be implemented before contract deployment**

* [ ] A) A `transferFrom()` function
* [ ] B) A `burn()` function
* [x] C) A way to withdraw/exchange/use Ether from the contract
* [ ] D) None of the above

**Q3 Which of the following assertion(s) is/are true (without affecting the security posture of the contract)?**

* [ ] A) `buy()` does not need payable keyword
* [ ] B) balances must be private
* [x] C) `transfer()` can be external
* [x] D) `safeAdd()` can be public

**Q4 The total supply is limited by**

* [ ] A) 10\*\*18
* [ ] B) 100 \* 10\*\*18
* [ ] C) 100
* [x] D) None of the above -> `MAX_SUPPLY` is not used in the code

**Q5 The following issue(s) is/are present in the codebase**

* [ ] A) An integer underflow allows one to drain Ether
* [x] B) Unsafe rounding allows one to receive new tokens for free -> `uint required_wei_sent = (desired_tokens / 10) * decimals`
* [ ] C) A division by zero allows one to trap/freeze the system
* [ ] D) None of the above

<mark style="color:red;">**Q6 The following issue(s) is/are present in the codebase**</mark>

* [ ] A) A front-running allows one to pay less than expected for tokens
* [ ] B) A lack of access control allows one to receive tokens for free
* [x] C) Incorrect balance update allows one to receive new tokens for free
* [ ] D) None of the above

**Comment:**

No requests made before/after a function call would be able to change the token price. All of the functions are intended to be used by users, so no "access control" would be possible without excluding users. A user can send all of their tokens to themselve, which will double their balance due to the pre-loaded variable reuse.

**Q7 The following issue(s) is/are present in the codebase**

* [ ] A) A reentrancy allows one to drain Ether
* [ ] B) A reentrancy allows one to drain the tokens
* [ ] C) A reentrancy allows one to receive new tokens for free
* [x] D) None of the above

**Q8 The following issue(s) is/are present in the codebase**

* [ ] A) An integer overflow allows one to drain Ether
* [ ] B) An integer overflow allows one to receive new tokens for free
* [ ] C) An integer overflow allows one to trap/freeze the system
* [x] D) None of the above

**Comment:**

While it is indeed possible to exploit an overflow at the multiplication (`(desired_tokens / 10) * decimals`), it doesn't allow you to receive FREE tokens (although it makes them a bargain).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ret2basic.gitbook.io/ctfnote/web3-security-research/secureum/epoch-0/slot-5-pitfalls-and-best-practices-201/quiz.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.