Hub informativ
Cryptoverse
Arena de tranzacționare
Cryptopedia
Cadou
Eco hub
The $ASP Buildkey Pre-TGE Trading is live on Aspecta platfrom
discoveryBanners
Subiecte populare
#
Bonk Eco continues to show strength amid $USELESS rally
Hosico
Hosico+8,42 %
USELESS
USELESS+13,03 %
IKUN
IKUN+18,94 %
gib
gib+10,15 %
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
Bonk
Bonk+4,13 %
ALON
ALON+10,92 %
LAUNCHCOIN
LAUNCHCOIN-8,45 %
GOONC
GOONC-4,38 %
KLED
KLED+14,84 %
#
Boop.Fun leading the way with a new launchpad on Solana.
BOOP
BOOP+3,3 %
Boopa
Boopa+3,09 %
PORK
PORK+20,25 %
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /
13 iul., 03:22·
așa că am aflat că este și mai elegant. Am observat că tx (de către atacatori) numește 'initialize' și protocoalele apelează și _successfully_ 'initialize' after (astfel ei cred că totul este normal). Dar stai, cum este posibil acest lucru? A trebuit să mă uit foarte adânc în modificările slotului de stocare și să ghicesc ce am găsit: au resetat valoarea slotului de stocare "_initialized" la sfârșitul tx-ului de rulare frontală (după ce au trecut la contractul de implementare rău intenționat). Aceasta înseamnă că stocarea proxy arată acum ca și cum nu a fost niciodată inițializată. Slotul de stocare relevant de analizat este 'keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' Acesta este răul de nivel următor.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10 iul., 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,53K