atarpara

If solady has a million fans then I am one of them If solady has ten fans then I am one of them If solady has only one fan then that is me If solady has no fans then that means I am no longer on earth If the world is against solady then I am against the world

🧵How memory works under the hood in the EVM and how this knowledge led me to recently discover a ✨critical vulnerability✨ Oh and if you're new to assembly, don't worry, it's simpler than you think Memory Layout Starting with the basics, Solidity reserves the following 4 32-byte memory slots: 0x00-0x3f (64 bytes): Scratch space for hashing methods We can use this area for temporary memory usage as long as we don't need more than 64 bytes 0x40-0x5f (32 bytes): Free memory pointer This slot keeps a pointer to free memory, i.e. the point beyond which it's safe to write to memory. When we use additional memory, this slot gets updated to point beyond that used memory. It's important that we never overwrite this value or else high level solidity logic may overwrite existing memory unexpectedly 0x60-0x7f (32 bytes): Zero slot This slot is reserved as the initial value for dynamic memory arrays, as such it must always be zero Memory Management Opcodes There are several opcodes that manipulate memory, but for simplicity, we'll focus on the two most common ones: mstore and mload mstore and mload write (store) and read (load) 32 byte values to and from memory, respectively In assembly (yul), mstore takes two inputs, an offset and a (32 byte) value. The value is then placed at the provided offset in memory. Simple, right? mload works about the same, taking just an offset and returning the (32 byte) value at that offset Example Taking what we've learned so far, we can safely write and read to and from memory as follows: The Critical Bug During a recent audit, I came across a simple, yet easy to miss, assembly memory management bug The code worked by manually deriving a storage slot from the hash of a set of parameters, including the caller As commented in the snippet, we expect memory from 0x1c to 0x40 to contain the selector, followed by the caller, followed by a However, even though a is only 96 bits (12 bytes), it overwrites the last 20 bytes of the caller. Since addresses are only 20 bytes long, this overwrites the entire value. This occurs because mstore always writes a full 32 bytes to the provided offset. If a smaller value is provided, the upper bytes will be zeroed such that the full 32 bytes are overwritten (Try testing this out in chisel with !memdump to get a feel for it) As a result of this bug, the storage slot is not derived from the calller, and thus anyone calling this function will write to the same storage slot, bypassing intended authorization logic Fin Let me know if you're feeling ready for an advanced memory management writeup (😈solady style😈)

We’ve been quietly testing advanced miners with high-performance hardware and a high voltage facility. The Blackwell Miner (with Nvidia's latest chips) and the Watercooled Miner, live today alongside the new facility. With the emergence of mining pools, the Bigcoin ecosystem is evolving. Bigcoin is for everyone. These powerful miners are a necessary step to help democratize Bigcoin's distribution and levels the playing field as mining and hashrate scales. The future of Bigcoin should be shaped by strategy, coordination, and upgrades; not just who showed up first. Lastly, while I find mining pools interesting and progressive, I am not responsible for any of them, be responsible and evaluate the team and the risk.