quindi ho scoperto che è ancora più sofisticato. Ho osservato che la tx di frontrunning (da parte degli attaccanti) chiama `initialize` e i protocolli chiamano anche _con successo_ `initialize` dopo (quindi pensano che tutto sia normale). Ma aspetta, come è possibile? Ho dovuto esaminare molto a fondo le modifiche agli slot di memoria e indovina cosa ho trovato: _resettano_ il valore dello slot di memoria `_initialized` alla fine della tx di frontrunning (dopo che hanno scambiato il contratto di implementazione malevolo). Questo significa che la memoria del proxy appare ora come se non fosse mai stata inizializzata. Lo slot di memoria rilevante da esaminare è `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` Questo è un livello di malvagità superiore.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10 lug, 22:13
It gets even more fancy: the way Etherscan was tricked showing the wrong implementation contract is based on setting 2 different proxy slots in the same frontrunning tx. So Etherscan uses a certain heuristic that incorporates different storage slots to retrieve the implementation contract. There is an old proxy by OpenZeppelin who used the following slot: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` We now also have the standard EIP-1967 slot `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` So what happened is that the old OpenZeppelin proxy slot was written to with the benign implementation address _and_ the standard EIP-1967 slot was also written to with the malicious implementation address. Since Etherscan queries first the old proxy slot, it retrieved the benign looking one first and thus displayed it.
21,5K