以欺骗者角度分析蜜罐合约（上）

1 前言

很久没有发布区块链的相关内容了，今天偶然间我点开了很久之前部署的一个蜜罐合约，借助比赛推出去之后发现收获了9个以太币hhhh（就是骗到的，当然这个是测试节点并不是真正的以太币）

效果还挺好的于是我就以欺骗者的角度来分析一下整个合约的代码，包括代码的设计思路以及上当的原因。最后我将该题目的wp放上以便爱好者学习。

2 题目分析

最初始部分是一个FatherOwned，该合约中有修饰函数onlyOwner用来判断调用合约方是否等于合约创建者。而该合约创建时会将owner赋初值。

之后为HoneyLock重头戏，该合约继承了标准代币合约StandardToken与父合约FatherOwned（这里为后面的蜜罐打下基础）。

该合约为一个简易的银行合约。HoneyLock函数的作用是初始化合约；之后为takeMoney。该函数使得新用户可以提取airDrop空投资金。

之后为lock()函数，用于判断存储时间是否大于一年。

为了让合约能修改owner，我们设置了useCode函数，该函数中需要传入一个猜测code，如果code == 设置好的guessCode，并且传入的msg.value大于初始的guessValue，那么就将owner设置为新的用户。

withdraw()中判断是否为owner，若为owner则可以将余额清零。

最后为CaptureTheFlag用于获取flag。

3 蜜罐分析

站在欺骗者角度，我们来分析一下本题目的技巧。为了达到蜜罐的作用，我们需要领用户自愿传入一定数量的代币。改题目中让用户参与合约的方法就是获取flag，而获取flag又需要满足两个条件：

而要满足上述两个条件需要我们调用空投函数takeMoney()，而调用之后又需要满足合约余额为0 。正常的操作需要等1年才可以提取，所以很多人会瞄准useCode函数，而该函数需要猜测guessCode与guessValue，对于很多专业队员来说，这种链上的信息可以从区块链上直接获取到，所以会想当然的调用，并传入一定数量代币。然而事情并没有那么简单。

许多人会认为调用了useCode(uint256 code)函数之后会改变owner = msg.sender，而忽略的一个重要的地方是onlyOwner是继承来的，所以这里onlyOwner改变的是FatherOwned的owner，然而获取flag的要求是需要HoneyLock合约的owner被修改，但是我们并没有修改HoneyLockowner的地方，所以这个方法永远不可能成功。所有的钱就只是白白扔进去。

由于文章篇幅有限，下一份文章中我们分析如何攻破这到题目以及作为一个防御者应该如何更合理的部署自己的合约。

作者：Pinging   原创稿件