Ethernaut Solutions: 11-Elevator

The Elevator contract never lets the “top” state variable to be true and that’s what we want to defeat. This challenge highlights the problem with external contract referencing as the external contract may behave in unexpected ways. Here, we simply need to return “false” on the first call to building.isLastFloor() and “true” the next time. … Read more

Ethernaut Solutions: 10-Re-entrancy

Our donor contract mimics someone who has contributed some money into the Reentrance contract. Thereafter, our Attacker contract steals all the money by first making a small donation and then performs a re-entrancy attack by recursively calling the withdraw() function.

Ethernaut Solutions: 9-King

How to run: Deploy King contract with 5 wei. The deployer address is both the owner and the king and prize = 5 wei. Deploy both Player1 and Player2 contracts with 100 wei. Put King contract’s address in kingContract state variable. Take turns becoming king and winning the “prize” using the Player1 and Player2 contracts. … Read more

Ethernaut Solutions: 8-Vault

State variables declared “private” are hidden from other contracts but their values are still recorded on the blockchain and so can be read by anyone. See this to learn exactly how: In this case, simply reading the value of the private state variable “password” will let you unlock the contract by passing it to … Read more

Ethernaut Solutions: 7-Force

The “Force” contract does not have a “payable” function so we cannot transfer any Ether through usual means. We can however create another contract and call the selfdestruct() function that can send Ether to any address regardless of the payable status.

Ethernaut Solutions: 6-Delegation

The challenge is to deploy an instance of Delegation contract and takeover its ownership. The Delegation contract issues a delegatecall to the Delegate contract. What that does is execute the called function from Delegate but through the Delegation contract’s context i.e., the functions in Delegate contract can modify the state variables in the Delegation contract. … Read more

Ethernaut Solutions: 5-Token

Contracts written earlier than v0.8.1 were vulnerable to integer over/underflow attacks. For example, if you have uint8 x = 255 then x + 1 will evaluate to 0 (overflow). Similarly, for uint8 x = 0, (x-1) becomes 255. In this challenge we use this vulnerability to steal 50,000 tokens from this contract. Here are both … Read more

Ethernaut Solutions: 4-Telephone

We can simply become the owner of the Telephone contract if we can call the Telephone.changeOwner() from a contract (“Solution”) which in turn is called from another contract or EOA – thus satisfying the tx.origin != msg.sender criteria.

Ethernaut Solutions: 3-Coinflip

The Coinflip contract relies on the block number to generate a random coin flip. This contract can be defeated by knowing the block in which it gets mined. To do that we simply create another contract (say Solution) to call Coinflip.flip() so both transactions(the call to Coinflip.flip() and execution of Coinflip.flip() itself). The solution contract … Read more

Ethernaut Solutions: 2-Fallout

Earlier versions of Solidity assumed a function was a constructor if it had the same name as the contract. However, this is a security issue if (1) Contract name gets changed in future and the developer forgets to change the name of the constructor or (2) There is a typo in the constructor name making … Read more