Центр аналитики
Cryptoverse
Торговая арена
Cryptopedia
Раздача
Экоцентр
Раздачи и награды Web3
discoveryBanners
Актуальные темы
#
Bonk Eco continues to show strength amid $USELESS rally
Hosico
Hosico-0,34 %
USELESS
USELESS-4,89 %
IKUN
IKUN+26,47 %
gib
gib+19,26 %
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
Bonk
Bonk+1,91 %
ALON
ALON+8,38 %
LAUNCHCOIN
LAUNCHCOIN+1,4 %
GOONC
GOONC+7,29 %
KLED
KLED+4,39 %
#
Boop.Fun leading the way with a new launchpad on Solana.
BOOP
BOOP+3,95 %
Boopa
Boopa-0,99 %
PORK
PORK+27,02 %
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /
13 июл., 03:22·
Я обнаружил, что это еще более изощренно. Я заметил, что транзакция фронтраннинга (со стороны атакующих) вызывает `initialize`, и протоколы также _успешно_ вызывают `initialize` после этого (поэтому они думают, что все в порядке). Но подождите, как это вообще возможно? Мне пришлось глубоко изучить изменения в слотах хранения, и угадайте, что я нашел: они _сбрасывают_ значение слота хранения `_initialized` в конце транзакции фронтраннинга (после того, как они переключились на контракт злонамеренной реализации). Это означает, что хранилище прокси теперь выглядит так, как будто оно никогда не было инициализировано. Соответствующий слот хранения, на который стоит обратить внимание, это `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` Это зло на следующем уровне.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /10 июл., 22:13
Ситуация становится еще более интересной: способ, которым Etherscan был обманут, показывая неправильный контракт реализации, основан на установке 2 различных прокси-слотов в одной транзакции фронтраннинга. Таким образом, Etherscan использует определенную эвристику, которая включает различные слоты хранения для получения контракта реализации. Существует старый прокси от OpenZeppelin, который использовал следующий слот: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Теперь у нас также есть стандартный слот EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Таким образом, что произошло: старый слот прокси OpenZeppelin был записан с доброкачественным адресом реализации _и_ стандартный слот EIP-1967 также был записан с вредоносным адресом реализации. Поскольку Etherscan сначала запрашивает старый слот прокси, он сначала извлекает доброкачественный, и, таким образом, отображает его.
21,52K