
100x faster EVM traces with Python
An introduction to evm-trace, a fast and correct Python library to work with Ethereum Virtual Machine traces. There are two common trace formats, which we’ll refer to as Geth-style and Parity-style traces. Geth traces provide opcode-level resolution, while the most commonly used Parity trace format provides a call tree. Our goal today would be to make opcode-resolution traces 100x faster, making them from a little-known Parity trace format. We’ll also make them compatible with Geth traces so ...
EIP-4626 Compatibility Study
SummaryThere are currently 566 contracts implementing EIP-4626 Tokenized Vaults standard on Ethereum mainnet. Of them, 69 contracts, including some notable ones like Savings DAI and Staked Yearn Ether, don't emit a Transfer event on mint/deposit/burn/redeem. This could affect tokens being picked up by explorers and wallets, as well as require changes to data analytics pipelines to correctly account for all balance changes. The results can be found here (.csv).How it happenedThe EIP-4626 ...
the bunny talisman of yearn

100x faster EVM traces with Python
An introduction to evm-trace, a fast and correct Python library to work with Ethereum Virtual Machine traces. There are two common trace formats, which we’ll refer to as Geth-style and Parity-style traces. Geth traces provide opcode-level resolution, while the most commonly used Parity trace format provides a call tree. Our goal today would be to make opcode-resolution traces 100x faster, making them from a little-known Parity trace format. We’ll also make them compatible with Geth traces so ...
EIP-4626 Compatibility Study
SummaryThere are currently 566 contracts implementing EIP-4626 Tokenized Vaults standard on Ethereum mainnet. Of them, 69 contracts, including some notable ones like Savings DAI and Staked Yearn Ether, don't emit a Transfer event on mint/deposit/burn/redeem. This could affect tokens being picked up by explorers and wallets, as well as require changes to data analytics pipelines to correctly account for all balance changes. The results can be found here (.csv).How it happenedThe EIP-4626 ...
the bunny talisman of yearn
Share Dialog
Share Dialog

Subscribe to banteg

Subscribe to banteg
<100 subscribers
<100 subscribers
Wintermute had their mainnet safe deployed from a Proxy Factory 1.1.1, which is older than the earliest official Optimism deployment of 1.3.0.
Luckily for our hacker, Safe deliberately utilizes non-EIP-155-compliant deployment transactions, which can be replayed on any network which doesn’t enforce EIP-155.
They did exactly that, replaying the deployment of Proxy Factory 1.1.1 on Optimism.
Similar to externally owned accounts, contracts on Ethereum maintain a nonce, which is increased when they spawn new contracts with either CREATE or CREATE2. Both addresses can be predicted from either (address, nonce) or (address, salt, initcode).
This safe was created using createProxy(masterCopy, data) which uses CREATE that only depends on the Factory address and its nonce value. The attacker can manipulate both the master copy and data parameters, assigning themselves as the owner. This is not possible for safes created with CREATE2 since they use the initializer (which includes the owner set) as a salt which affects the resulting address.
We can calculate that Wintermute’s safe was created at nonce 8884, and since it’s a fresh Factory, the attacker had to create all the preceding safes first. To pull this off, they created a contract which initializes 162 safes at a time, which they called 62 times, increasing the Factory’s nonce to 10,054.
This has allowed them to grab Optimism addresses for a lot of safes existing on mainnet, including a safe matching Wintermute’s address.
Wintermute had their mainnet safe deployed from a Proxy Factory 1.1.1, which is older than the earliest official Optimism deployment of 1.3.0.
Luckily for our hacker, Safe deliberately utilizes non-EIP-155-compliant deployment transactions, which can be replayed on any network which doesn’t enforce EIP-155.
They did exactly that, replaying the deployment of Proxy Factory 1.1.1 on Optimism.
Similar to externally owned accounts, contracts on Ethereum maintain a nonce, which is increased when they spawn new contracts with either CREATE or CREATE2. Both addresses can be predicted from either (address, nonce) or (address, salt, initcode).
This safe was created using createProxy(masterCopy, data) which uses CREATE that only depends on the Factory address and its nonce value. The attacker can manipulate both the master copy and data parameters, assigning themselves as the owner. This is not possible for safes created with CREATE2 since they use the initializer (which includes the owner set) as a salt which affects the resulting address.
We can calculate that Wintermute’s safe was created at nonce 8884, and since it’s a fresh Factory, the attacker had to create all the preceding safes first. To pull this off, they created a contract which initializes 162 safes at a time, which they called 62 times, increasing the Factory’s nonce to 10,054.
This has allowed them to grab Optimism addresses for a lot of safes existing on mainnet, including a safe matching Wintermute’s address.
No activity yet