CREATE2 是以太坊在“君士坦丁堡”这次硬分叉升级中引入的一个新操作码，不同于 CREATE，它使用新的方式来计算合约地址，让生成的合约地址更具有可控性。通过 CREATE2 可以延伸出很多有意思的玩法，在 CTF 中最常见的就是利用这种可控性，在同一个地址先后部署字节码完全不同的合约。
原理
CREATE
如果利用外部账户或者使用 CREATE 操作码的合约账户创建一个合约，那么很容易就能确定被创建合约的地址。每个账户都有一个与之关联的 nonce：对外部账户而言，每发送一个交易，nonce 就会随之 +1；对合约账户而言，每创建一个合约，nonce 就会随之 +1。新合约的地址由创建合约交易的发送者账户地址及其 nonce 值计算得到，其具体公式如下：
keccak256(rlp.encode(address, nonce))[12:]
CREATE2
不同于原来的 CREATE 操作码，在合约地址的计算方法上，CREATE2 不再依赖于账户的 nonce，而是对以下参数进行哈希计算，得出新的地址：
具体的计算公式如下：
keccak256(0xff ++ address ++ salt ++ keccak256(init_code))[12:]
一个需要注意的重要细节是，计算合约地址所需的最后一个参数并非合约代码，而是其创建代码。该代码是用来创建合约的，合约创建完成后将返回运行时字节码。
这意味着，如果我们控制了合约的创建代码并使其保持不变，然后控制合约构造函数返回的运行时字节码，那么我们很容易就能做到在同一个地址上，反复部署完全不同的合约。事实上 CREATE2 这种让合约在部署后可以被重新更改的特性存在着潜在的安全问题，也引起了人们对其的。
在 CTF 中，这种特性往往会被用来作为一个技巧，通过在同一个地址上部署不同的合约用来 bypass 不同的校验。
例子
以 2019 Balsn CTF 的 Creativity 的 WP 提供的 PoC 作为例子，讲解一下 CREATE2 的巧妙使用：
pragma solidity ^0.5.10;
contract Deployer {
bytes public deployBytecode;
address public deployedAddr;
function deploy(bytes memory code) public {
deployBytecode = code;
address a;
// Compile Dumper to get this bytecode
bytes memory dumperBytecode = hex'6080604052348015600f57600080fd5b50600033905060608173ffffffffffffffffffffffffffffffffffffffff166331d191666040518163ffffffff1660e01b815260040160006040518083038186803b158015605c57600080fd5b505afa158015606f573d6000803e3d6000fd5b505050506040513d6000823e3d601f19601f820116820180604052506020811015609857600080fd5b81019080805164010000000081111560af57600080fd5b8281019050602081018481111560c457600080fd5b815185600182028301116401000000008211171560e057600080fd5b50509291905050509050805160208201f3fe';
assembly {
a := create2(callvalue, add(0x20, dumperBytecode), mload(dumperBytecode), 0x9453)
}
deployedAddr = a;
}
}
contract Dumper {
constructor() public {
Deployer dp = Deployer(msg.sender);
bytes memory bytecode = dp.deployBytecode();
assembly {
return (add(bytecode, 0x20), mload(bytecode))
}
}
}
当我们每次利用 deploy(code) 函数来部署预期构造的合约时，由于实际上的 init_code 都是同样的 dumperBytecode，再加上确定的合约地址以及 salt，所以通过 deploy(code) 部署的合约最终会部署在同一个地址上。然后被加载的合约在构造函数执行的时候，会跳转到调用函数时传入的 code 上，所以不管我们用 deploy(code) 函数部署什么合约，其最终都会部署到同一个地址上。
在知道 Deployer 合约地址是 0x99Ed0b4646a5F4Ee0877B8341E9629e4BF30c281 的情况下，我们可以计算部署合约的地址为 0x4315DBef1aC19251d54b075d29Bcc4E81F1e3C73：
function getAddress(address addr, bytes memory bytecode, uint salt) public view returns (address) {
bytes32 hash = keccak256(
abi.encodePacked(
bytes1(0xff),
addr,
salt,
keccak256(bytecode)
)
);
// NOTE: cast last 20 bytes of hash to address
return address(uint160(uint256(hash)));
}
利用该合约，我们成功地在同一个地址上先后上部署了两个不同的合约：
题目
Balsn 2019
QWB 2020
参考
