Structure of this Series
The aim of this series is to walk you through various different assembly concepts using the Ethernaut wargame as a base. Ethernaut was developed by OpenZeppelin and is a series of challenges that we will solve by seeing what vulnerabilities exist in each contract. The ethernaut github contains the list of contracts we will be using.
Some of these challenges should be fairly straightforward for anyone with some experience with solidity, some of them genuinely do require some thought.
The aim of each article is to introduce a couple of new concepts at a time - so as not to become overwhelming. I will try and keep the articles self contained but may reference techniques from previous articles for brevity.
We will be using Foundry to run all our tests, as opposed to OpenZeppelin’s deployed challenge. Reasons for this are as follows:
- Foundry has excellent debugging tools that let us inspect the stack and memory line by line.
- Testing our contracts is fast and easy to do, and we have a number of utilities built in to help us manipulate the state.
If you’re experienced with foundry, awesome, if not - here’s a quick primer
I assume because you are looking at an assembly course, you’ve got a basic idea about how smart contracts work, how the Ethereum blockchain works, and how to write solidity. We will not cover any solidity syntax here unless we use some advanced features or utilities specific to foundry.
We will be pulling the OZ ethernaut contracts directly from their repo, but if you want a ready-to-go setup (with solutions), you can pull my repo with everything setup.
Everything will be using the solidity ^0.8.0 pragma. Not all the OZ contracts are written in v8, but with some small amendments to the contracts, we can replicate older behaviours.
Some pre-reading
Ultimately what I hope you takeaway from these posts is not the ability to shoehorn yul/inline assembly into every contract, instead it’s a foundational and hands-on knowledge of how the EVM is processing your solidity code under the hood.
Saying all that, a lot of what we will be doing relies on you having at least a basic knowledge of what the EVM is, and the basics of Memory, Storage, Calldata and the EVM Stack Machine. I will try my best to cover things as they come up, but I suggest that you prepare yourself with some learning.
In the appendix section of this series you’ll see a basic primer on reading from memory and setting up a dev environment, but there’s a couple of posts I wanted to share with you as well.
EVM Deep Dives
You may already have seen the absolutely excellent series from @noxx on the EVM, if you have, and you’ve digested it thoroughly, feel free to carry on, if not READ THESE ARTICLES:
And by read, I mean take your time. It might be useful to get a pen and paper out and take formal notes. Going fast is secondary to getting a thorough underderstanding of the basics.
This stuff is not hard but, if you are new to a lot of low-level computer science concepts, it can be confusing.
Let me repeat: take your time. If it takes you a week or two to go through all of the posts properly - good. You will have a proper solid foundation that will make the rest of this much, much easier.
If you need some additional pre-prepared notes, I’ve prepared some here.
When you’re ready, let’s get started.