热门话题
#
Bonk 生态迷因币展现强韧势头
#
有消息称 Pump.fun 计划 40 亿估值发币，引发市场猜测
#
Solana 新代币发射平台 Boop.Fun 风头正劲
所以我发现这甚至更复杂。我观察到前置交易（由攻击者发起）调用了 `initialize`，而协议在之后也成功调用了 `initialize`（因此他们认为一切正常）。但是等等，这怎么可能呢？我不得不深入查看存储槽的变化，结果我发现：他们在前置交易结束时重置了 `_initialized` 存储槽的值（在他们切换到恶意实现合约之后）。这意味着代理存储现在看起来就像从未初始化过。
相关的存储槽是 `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00`
这真是下一层的邪恶。
7月10日 22:13
事情变得更加复杂：Etherscan 被欺骗显示错误的实现合约的方式是基于在同一个前置交易中设置两个不同的代理槽。因此，Etherscan 使用某种启发式方法，结合不同的存储槽来检索实现合约。
有一个旧的 OpenZeppelin 代理使用了以下槽：`keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3`
我们现在还有标准的 EIP-1967 槽 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
所以发生的事情是，旧的 OpenZeppelin 代理槽被写入了良性的实现地址 _和_ 标准的 EIP-1967 槽也被写入了恶意的实现地址。由于 Etherscan 首先查询旧的代理槽，因此它首先检索到了看起来良好的那个，从而显示了它。
21.49K
热门
排行
收藏