跳转至

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`
-----------------------------------------------------
|                        ...                        |   ......
-----------------------------------------------------

字节数组和字符串

如果 bytesstring 的数据很短,那么它们的长度也会和数据一起存储到同一个插槽。具体地说:如果数据长度小于等于 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
-----------------------------------------------------

对于结构 SafeBoxFailedAttempt,每个结构占据的存储布局如下:

# 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

参考