在之前的内容中，学习到了storage中是使用插槽存储数据的。而delegatecall函数有个有趣的特点：当使用 delegatecall 函数进行外部调用涉及到 storage 变量的修改时是根据插槽位置来修改的而不是变量名。
举个例子：
合约A
合约B
当合约B调用testDelegatecall()函数时，合约B的地址c的值会变为合约A的地址，而地址a则是不变。因为合约A的函数test()改变的是插槽slot1的值，同样的在合约B中运行时，改变的也是插槽slot1的值，即地址c的值。
目标合约
漏洞分析
我们可以看到有两个合约，Lib 合约中只有一个 pwn 函数用来修改合约的 owner，在 HackMe 合约中存在 fallback 函数，fallback 函数的内容是使用 delegatecall 去调用 Lib 合约中的函数。我们需要利用 HackMe.fallback() 触发 delegatecall 函数去调用 Lib.pwn() 将 HackMe 合约中的 owner 改成自己。
攻击合约
现在我们来看看整个攻击的逻辑：
1.攻击者调用attack()发起攻击，attack 函数首先去调用 HackMe.pwn()；
2.HackMe 合约中并没有 pwn 函数，此时触发 HackMe.fallback()；
3.HackMe.fallback() 使用 deldegatecall 调用 Lib 合约中的函数，函数名取的是 msg.data 也就是 "pwn()"，而 Lib 合约中恰好有名为 pwn 的函数，于是便在HackMe 合约中运行了pwn函数；
4.pwn函数修改了插槽slot0位置（即HackMe 合约的拥有者）的值为msg.sender（即攻击者），最终导致了HackMe 合约的拥有者变成了攻击者。
修复建议
1. 在使用 delegatecall 时应注意被调用合约的地址不能是可控的；
2. 在较为复杂的合约环境下需要注意变量的声明顺序以及存储位置。因为使用 delegatecall 进行外部调时会根据被调用合约的数据结构来用修改本合约相应 slot 中存储的数据，在数据结构发生变化时这可能会造成非预期的变量覆盖。
