神奇的逻辑漏洞
该类蜜罐合约用2012年春晚小品《天网恢恢》中这么一段表现是及其合适的：
送餐员： 外卖一共 30 元
骗子 B： 没零的，100！
送餐员： 行，我找你 ......70!（送餐员掏出 70 给骗子 B）
骗子 A： 哎，等会儿等会儿，我这有零的，30 是吧，把那 100 给我吧！给，30！（骗子 A 拿走了 B 给送餐员的 100 元，又给了送餐员 30 元）
送餐员： 30 元正好，再见 !该类漏洞也是如此，在看起来正常的逻辑下，总藏着这样那样的陷阱。
1.天上掉下的馅饼：Gift_1_ETH
合约关键代码如下：
三个关键函数功能如下：
SetPass(): 在转账大于 1ether 并且 passHasBeenSet 为 false (默认值就是 false), 就可以设置密码 hashPass。
GetGift(): 在输入的密码加密后与 hashPass 相等的情况下，就可以取走合约里所有的以太币。
PassHasBeenSet()：如果输入的 hash 与 hashPass 相等，则 passHasBeenSet 将会被设置成 true
如果我们想取走合约里所有的以太币，只需要按照如下流程进行操作：
推特用户 Alexey Pertsev 还为此写了一个获取礼物的 EXP。
但实际场景中，受害者转入一个以太币后并没有获取到整个智能合约的余额，这是为什么呢？
这是因为在合约创立之后，任何人都可以对合约进行操作，包括合约的创建者：
合约创建者在合约 被攻击 前，设置一个只有创建者知道的密码并将passHasBeenSet置为 True，将只有合约创建者可以取出智能合约中的以太币。与之类似的智能合约还有 NEW_YEARS_GIFT：
2.合约永远比你有钱
合约关键代码如下：
对于multiplicate() 而言，只要你转账的金额大于账户余额，就可以把 账户余额 和 你本次转账的金额 都转给一个可控的地址。在这里我们需要知道：在调用 multiplicate() 时，账户余额 = 之前的账户余额 + 本次转账的金额。所以 msg.value >= this.balance 只有在原余额为 0，转账数量为 0 的时候才会成立。也就意味着，账户余额永远不会比转账金额小。
3.谁是合约主人：TestBank
关键代码如下：
根据关键代码的内容，如果我们可以通过useEmergencyCode() 中的判断，那就可以将 owner 设置为我们的地址，然后通过 withdraw() 函数就可以取出合约中的以太币。
如果你也有了上述的分析，那么就需要学习一下 Solidity 中继承的相关知识：Solidity 的继承原理是代码拷贝，因此换句话说，继承的写法总是能够写成一个单独的合约。
情况五：子类父类有相同名字的变量。 父类 A 的 test1 操纵父类中的 variable，子类 B 中的 test2 操纵子类中的 variable，父类中的 test2 因为没被调用所以不存在。 解释：对 EVM 来说，每个 storage variable 都会有一个唯一标识的 slot id。在下面的例子说，虽然都叫做 variable，但是从 bytecode 角度来看，他们是由不同的 slot id 来确定的，因此也和变量叫什么没有关系。
根据样例中的代码，我们将合约的核心代码修改如下：
变量 owner1 是父类 Owner 中的 owner 变量，而 owner2 是子类 TestBank 中的变量。useEmergencyCode() 函数只会修改 owner2，而非 owner1，自然无法调用withdraw()。 由于调用useEmergencyCode() 时需要转作者设置的 evalue wei 的以太币，所以只会造成以太币白白丢失。
下回我们将介绍以太坊蜜罐智能合约之新颖的赌博游戏，敬请期待
网友评论