Hub de informações
Criptoverso
Arena de Trading
Criptopédia
Sorteio
Eco hub
Explore o Sorteio Web3 para mais recompensas entusiasmantes
discoveryBanners
Tópicos populares
#
Bonk Eco continues to show strength amid $USELESS rally
Hosico
Hosico+4%
USELESS
USELESS-8,66%
IKUN
IKUN+16,84%
gib
gib+16,34%
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
Bonk
Bonk-1,08%
ALON
ALON+1,61%
LAUNCHCOIN
LAUNCHCOIN+4,05%
GOONC
GOONC-6,18%
KLED
KLED+4,88%
#
Boop.Fun leading the way with a new launchpad on Solana.
BOOP
BOOP-3,02%
Boopa
Boopa+0,12%
PORK
PORK+7,13%
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /
13/07, 03:22·
então descobri que é ainda mais sofisticado. Observei que a transação de frontrunning (pelos atacantes) chama `initialize` e os protocolos também chamam _com sucesso_ `initialize` depois (assim eles pensam que está tudo normal). Mas espere, como isso é até possível? Tive que olhar muito profundamente nas mudanças dos slots de armazenamento e adivinha o que encontrei: eles _resetaram_ o valor do slot de armazenamento `_initialized` no final da transação de frontrunning (depois de trocarem para o contrato de implementação malicioso). Isso significa que o armazenamento do proxy agora parece que nunca foi inicializado. O slot de armazenamento relevante a ser observado é `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` Isto é maldade de nível superior.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10/07, 22:13
Fica ainda mais sofisticado: a forma como o Etherscan foi enganado a mostrar o contrato de implementação errado baseia-se na definição de 2 slots de proxy diferentes na mesma transação de frontrunning. Assim, o Etherscan utiliza uma certa heurística que incorpora diferentes slots de armazenamento para recuperar o contrato de implementação. Há um proxy antigo da OpenZeppelin que usou o seguinte slot: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Agora também temos o slot padrão EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` O que aconteceu foi que o slot do proxy antigo da OpenZeppelin foi escrito com o endereço de implementação benigno _e_ o slot padrão EIP-1967 também foi escrito com o endereço de implementação malicioso. Como o Etherscan consulta primeiro o slot do proxy antigo, ele recuperou o que parecia benigno primeiro e, assim, o exibiu.
21,5K