Тому я з'ясувала, що це ще вишуканіше. Я помітив, що передній tx (зловмисники) викликає 'initialize', а протоколи також викликають _successfully_ 'initialize' після (таким чином вони думають, що все нормально). Але стривайте, як таке взагалі можливо? Мені довелося дуже глибоко заглянути в зміни слотів сховища і здогадатися, що я знайшов: вони _скинули_ значення слота сховища '_initialized' в кінці frontrunning tx (після того, як вони перейшли на шкідливий контракт на реалізацію). Це означає, що проксі-сховище тепер виглядає так, ніби воно ніколи не було ініціалізоване. Відповідний слот для зберігання, на який варто звернути увагу: 'keccak256(abi.encode(uint256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' Це зло наступного рівня.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10 лип., 22:13
Це стає ще більш вигадливим: спосіб, яким Etherscan був обдурений, показавши неправильний контракт на впровадження, заснований на налаштуванні 2 різних проксі-слотів в одному передньому TX. Таким чином, Etherscan використовує певну евристику, яка включає різні слоти для зберігання для отримання контракту на реалізацію. Існує старий проксі від OpenZeppelin, який використовував наступний слот: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Тепер ми також маємо стандартний слот EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Отже, сталося те, що старий проксі-слот OpenZeppelin був записаний з доброякісною адресою реалізації _і_ стандартний слот EIP-1967 також був записаний з адресою шкідливої реалізації. Оскільки Etherscan спочатку запитує старий проксі-слот, він спочатку витягує той, що виглядає доброякісно, і таким чином відображає його.
21,53K