Trendande ämnen
#
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å jag fick reda på att det är ännu finare. Jag observerade att frontrunning tx (av angriparna) anropar "initiera" och protokoll anropar också _framgångsrikt_ "initiera" efter (så de tror att allt är normalt). Men vänta, hur är detta ens möjligt? Jag var tvungen att titta mycket djupt på ändringarna i lagringsplatsen och gissa vad jag hittade: de _återställer_ värdet för "_initialized" lagringsplatsen i slutet av den frontrunning tx (efter att de bytte till det skadliga implementeringskontraktet). Det innebär att proxylagringen nu ser ut som om den aldrig initierades.
Det relevanta lagringsfacket att titta på är 'keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00'
Detta är ondska på nästa nivå.
10 juli 22:13
Det blir ännu mer tjusigt: sättet som Etherscan lurades att visa fel implementeringskontrakt bygger på att ställa in 2 olika proxyplatser i samma frontrunning tx. Så Etherscan använder en viss heuristik som innehåller olika lagringsplatser för att hämta implementeringskontraktet.
Det finns en gammal proxy från OpenZeppelin som använde följande plats: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3'
Vi har nu också standard EIP-1967-platsen 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc'
Så vad som hände är att den gamla OpenZeppelin-proxyplatsen skrevs till med den godartade implementeringsadressen _och_ standardplatsen EIP-1967 skrevs också till med den skadliga implementeringsadressen. Eftersom Etherscan först frågar efter den gamla proxyplatsen, hämtade den den godartade först och visade den på så sätt.
21,55K
Topp
Rankning
Favoriter