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));
}

题目

与以太坊的存储相关的攻击一般分为两类：

利用以太坊上存储本质上都是公开的这一特性，任意读取声明为 private 的变量。
结合任意写的漏洞，覆盖以太坊上的特定位置的存储

XCTF_final 2019

题目名称 Happy_DOuble_Eleven

Balsn 2019

题目名称 Bank

参考

PreviousFunction Selector and Argument Encoding Nextattacks

Last updated 2 years ago