Inzichtenhub
Cryptoverse
Handelsarena
Cryptopedia
Giveaway
Eco hub
Verken Web3-giveaway voor meer spannende beloningen
discoveryBanners
Populaire onderwerpen
#
Bonk Eco continues to show strength amid $USELESS rally
Hosico
Hosico+3,22%
USELESS
USELESS-4,14%
IKUN
IKUN+20,17%
gib
gib+17,72%
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
Bonk
Bonk+3,36%
ALON
ALON+7,77%
LAUNCHCOIN
LAUNCHCOIN-1,4%
GOONC
GOONC+1,35%
KLED
KLED+1%
#
Boop.Fun leading the way with a new launchpad on Solana.
BOOP
BOOP+3,93%
Boopa
Boopa+0,06%
PORK
PORK+20,9%
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /
13 jul, 03:22·
dus ik ontdekte dat het nog fancier is. Ik observeerde dat de frontrunning tx (door de aanvallers) `initialize` aanroept en protocollen ook _succesvol_ `initialize` aanroepen daarna (dus denken ze dat alles normaal is). Maar wacht, hoe is dit zelfs mogelijk? Ik moest heel diep kijken naar de veranderingen in de opslagslot en raad eens wat ik vond: ze _resetten_ de waarde van de `_initialized` opslagslot aan het einde van de frontrunning tx (nadat ze naar het kwaadaardige implementatiecontract waren overgestapt). Dit betekent dat de proxy-opslag er nu uitziet alsof het nooit was geïnitialiseerd. Het relevante opslagslot om naar te kijken is `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` Dit is next-level kwaad.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10 jul, 22:13
Het wordt nog fancier: de manier waarop Etherscan werd misleid om het verkeerde implementatiecontract te tonen, is gebaseerd op het instellen van 2 verschillende proxy slots in dezelfde frontrunning tx. Etherscan gebruikt een bepaalde heuristiek die verschillende opslagslots incorporeert om het implementatiecontract op te halen. Er is een oude proxy van OpenZeppelin die de volgende slot gebruikte: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` We hebben nu ook de standaard EIP-1967 slot `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Wat er gebeurde, is dat de oude OpenZeppelin proxy slot werd geschreven met het onschuldige implementatieadres _en_ de standaard EIP-1967 slot ook werd geschreven met het kwaadaardige implementatieadres. Aangezien Etherscan eerst de oude proxy slot opvraagt, haalde het eerst het onschuldige uitziende adres op en toonde het dus.
21,52K