Ethereum Storage
原文地址: https://ctf-wiki.org/blockchain/ethereum/storage/
插槽
以太坊数据存储会为合约的每项数据指定一个可计算的存储位置，存放在一个容量为 2^256 的超级数组中，数组中每个元素称为插槽，其初始值为 0。虽然数组容量的上限很高，但实际上存储是稀疏的，只有非零(空值)数据才会被真正写入存储。
# 插槽式数组存储
----------------------------------
| 0 | # slot 0
----------------------------------
| 1 | # slot 1
----------------------------------
| 2 | # slot 2
----------------------------------
| ... | # ...
----------------------------------
| ... | # 每个插槽 32 字节
----------------------------------
| ... | # ...
----------------------------------
| 2^256-1 | # slot 2^256-1
----------------------------------
当数据长度是已知时，其具体的存储位置将在编译时指定，而对于长度不确定的类型（如动态数组、映射），则会按一定规则计算存储位置。以下是对不同类型变量的储存模型的具体分析。
值类型
除映射和动态数组之外的所有类型，其数据长度都是已知的，如定长整型(int/uint/...), 地址(address), 定长浮点型(fixed/ufixed/...), 定长字节数组(bytes1-bytes32)，编译时将严格根据字段排序顺序，从位置 0 开始连续放置在存储中。如果可能的话，大小少于 32 字节的多个变量会被打包到一个插槽中，而当某项数据超过 32 字节，则需要占用多个连续插槽（data.length / 32）。规则如下：
- 存储插槽的第一项会以低位对齐（即右对齐）的方式储存。
- 基本类型仅使用存储它们所需的字节。
- 如果存储插槽中的剩余空间不足以储存一个基本类型，那么它会被移入下一个存储插槽。
- 结构和数组数据总是会占用一整个新插槽（但结构或数组中的各项，都会以这些规则进行打包）。
如以下合约：
pragma solidity ^0.4.0;
contract C {
address a; // 0
uint8 b; // 0
uint256 c; // 1
bytes24 d; // 2
}
其存储布局如下：
-----------------------------------------------------
| unused (11) | b (1) | a (20) | <- slot 0
-----------------------------------------------------
| c (32) | <- slot 1
-----------------------------------------------------
| unused (8) | d (24) | <- slot 2
-----------------------------------------------------
映射
对于形如 mapping(address => uint) a; 的映射类型变量，就无法简单仿照值类型按顺序储存了。对于映射，其会根据上节提到的规则占据位置 p 处的一个插槽，但该插槽不会被真正使用。映射中的键 k 所对应的值会位于 keccak256(k . p)， 其中 . 是连接符。如果该值同时是一个非基本类型，则将 keccak256(k . p) 作为偏移量来找到具体的位置。
如以下合约：
pragma solidity ^0.4.0;
contract C {
mapping(address => uint) a; // 0
uint256 b; // 1
}
其存储布局如下：
-----------------------------------------------------
| reserved (a) | <- slot 0
-----------------------------------------------------
| b (32) | <- slot 1
-----------------------------------------------------
| ... | ......
-----------------------------------------------------
| a[addr] (32) | <- slot `keccak256(addr . 0)`
-----------------------------------------------------
| ... | ......
-----------------------------------------------------
动态数组
对于形如 uint[] b; 的动态数组，其同样会占用对应位置 p 处的插槽，用以储存数组的长度，而数组真正的起始点会位于 keccak256(p) 处（字节数组和字符串在这里是一个例外，见下文）。
如以下合约：
pragma solidity ^0.4.0;
contract C {
uint256 a; // 0
uint[] b; // 1
uint256 c; // 2
}
其存储布局如下：
-----------------------------------------------------
| a (32) | <- slot 0
-----------------------------------------------------
| b.length (32) | <- slot 1
-----------------------------------------------------
| c (32) | <- slot 2
-----------------------------------------------------
| ... | ......
-----------------------------------------------------
| b[0] (32) | <- slot `keccak256(1)`
-----------------------------------------------------
| b[1] (32) | <- slot `keccak256(1) + 1`
-----------------------------------------------------
| ... | ......
-----------------------------------------------------
字节数组和字符串
如果 bytes 和 string 的数据很短，那么它们的长度也会和数据一起存储到同一个插槽。具体地说：如果数据长度小于等于 31 字节， 则它存储在高位字节（左对齐），最低位字节存储 length * 2。如果数据长度超出 31 字节，则在主插槽存储 length * 2 + 1， 数据照常存储在 keccak256(slot) 中。
可见性
由于以太坊上的所有信息都是公开的，所以即使一个变量被声明为 private，我们仍能读到变量的具体值。
利用 web3 提供的 web3.eth.getStorageAt() 方法，可以读取一个以太坊地址上指定位置的存储内容。所以只要计算出了一个变量对应的插槽位置，就可以通过调用该函数来获得该变量的具体值。
调用：
// web3.eth.getStorageAt(address, position [, defaultBlock] [, callback])
web3.eth.getStorageAt("0x407d73d8a49eeb85d32cf465507dd71d507100c1", 0)
.then(console.log);
> "0x033456732123ffff2342342dd12342434324234234fd234fd23fd4f23d4234"
参数：
address：String - 要读取的地址position：Number - 存储中的索引编号defaultBlock：Number|String - 可选，使用该参数覆盖 web3.eth.defaultBlock 属性值callback：Function - 可选的回调函数, 其第一个参数为错误对象，第二个参数为结果。
例子
以 Balsn CTF 2019 的 Bank 一题为例，更为具体讲解以太坊的存储布局。题目中变量和结构的定义如下：
contract Bank {
address public owner;
uint randomNumber = 0;
struct SafeBox {
bool done;
function(uint, bytes12) internal callback;
bytes12 hash;
uint value;
}
SafeBox[] safeboxes;
struct FailedAttempt {
uint idx;
uint time;
bytes12 triedPass;
address origin;
}
mapping(address => FailedAttempt[]) failedLogs;
}
合约的变量按照以下布局存储在插槽 0 到 3 上：
-----------------------------------------------------
| unused (12) | owner (20) | <- slot 0
-----------------------------------------------------
| randomNumber (32) | <- slot 1
-----------------------------------------------------
| safeboxes.length (32) | <- slot 2
-----------------------------------------------------
| occupied by failedLogs but unused (32) | <- slot 3
-----------------------------------------------------
对于结构 SafeBox 和 FailedAttempt，每个结构占据的存储布局如下：
# SafeBox
-----------------------------------------------------
| unused (11) | hash (12) | callback (8) | done (1) |
-----------------------------------------------------
| value (32) |
-----------------------------------------------------
# FailedAttempt
-----------------------------------------------------
| idx (32) |
-----------------------------------------------------
| time (32) |
-----------------------------------------------------
| origin (20) | triedPass (12) |
-----------------------------------------------------
对于数组 safeboxes，数组内元素的起始点在 keccak256(2) 处，每个元素占据 2 个插槽；而对于映射 failedLogs，需要先通过 keccak256(addr . 3) 来得到特定地址 addr 对应数组的位置，该位置记录着数组的长度，而数组真正的起始点位于 keccak256(keccak256(addr . 3)) 处，每个元素占据 3 个插槽。
可以借助以下代码方便地计算数组和映射对应元素的真正位置：
function read_slot(uint k) public view returns (bytes32 res) {
assembly { res := sload(k) }
}
function cal_addr(uint k, uint p) public pure returns(bytes32 res) {
res = keccak256(abi.encodePacked(k, p));
}
function cal_addr(uint p) public pure returns(bytes32 res) {
res = keccak256(abi.encodePacked(p));
}
ethers 查询 slot 位置存储
await provider.getStorageAt("registrar.firefly.eth", 0)
// '0x000000000000000000000000314159265dd8dbb310642f98f50c066173c1259b'
hardhat 插件查看slot
该插件可以帮助在部署合约的时候获取到每个slot的存储布局
题目
与以太坊的存储相关的攻击一般分为两类：
- 利用以太坊上存储本质上都是公开的这一特性，任意读取声明为
private的变量。 - 结合任意写的漏洞，覆盖以太坊上的特定位置的存储
XCTF_final 2019
- 题目名称 Happy_DOuble_Eleven
Balsn 2019
- 题目名称 Bank