Populære emner
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
så jeg fant ut at det er enda mer avansert. Jeg observerte at frontrunning tx (av angriperne) kaller 'initialize' og protokoller kaller også _vellykket_ 'initialize' etter (dermed tror de at alt er normalt). Men vent, hvordan er dette i det hele tatt mulig? Jeg måtte se veldig dypt inn i endringene i lagringssporene og gjette hva jeg fant: de _tilbakestiller_ '_initialized' lagringssporverdien på slutten av frontrunning tx (etter at de byttet til den ondsinnede implementeringskontrakten). Dette betyr at proxy-lagringen ser ut nå som den aldri ble initialisert.
Det relevante lagringssporet å se på er 'keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00'
Dette er ondskap på neste nivå.
10. juli, 22:13
Det blir enda mer fancy: måten Etherscan ble lurt på ved å vise feil implementeringskontrakt er basert på å sette 2 forskjellige proxy-spor i samme frontrunning tx. Så Etherscan bruker en viss heuristikk som inneholder forskjellige lagringsspor for å hente implementeringskontrakten.
Det er en gammel proxy av OpenZeppelin som brukte følgende spor: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3'
Vi har nå også standard EIP-1967-sporet 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc'
Så det som skjedde er at det gamle OpenZeppelin-proxy-sporet ble skrevet til med den godartede implementeringsadressen _og_ standard EIP-1967-sporet ble også skrevet til med den ondsinnede implementeringsadressen. Siden Etherscan først spør etter det gamle proxy-sporet, hentet den den godartede utseendet først og viste den dermed.
21,49K
Topp
Rangering
Favoritter