Let’s Write An Ethereum Virtual Machine Disassembler
home // page // Let’s Write An Ethereum Virtual Machine Disassembler

Let’s Write An Ethereum Virtual Machine Disassembler

In this article we’ll discuss writing a disassembler for the Ethereum Virtual Machine (EVM). While writing disassemblers doesn’t necessarily require much knowledge of the machine the instructions are for, it’s actually quite a fun way to get your feet wet.

During this tutorial we’ll be using the D programming language. Why D? Honestly there’s no great reason. It’s mostly because I think it’s clearer and simpler than the alternatives for this kind of low-level code. Let’s get started.


When writing a disassembler, the first place I like to start is with a high-level description of the machine. This helps me to get my bearings and hopefully answers any major architectural questions I might have during development. So let’s elaborate the EVM a bit.

EVM Basics

Machine Word and Stack

The EVM is a big-endian, stack-based machine architecture. The machine uses 256-bit words in order to facilitate SHA3-256 hash values and elliptic curve computations.

The machine stack has a maximum depth of 1024 items (each item is a 256-bit word).

Memory Model

Memory for the EVM is word rather than byte addressable. This means that each sequential address stores a whole 256-bit value. Machines that are byte-addressable would use 32 sequential addresses to store the same 256-bit value as each address only contains 8-bits (1 byte) of the total value. All storage and memory in the EVM is initialized to zero.

Programs are not stored in memory, but instead can be considered to be stored in a separate virtual read-only memory (ROM) that is accessible only through a special instruction – CODECOPY – which copies the program into main memory.

Compiled Contracts

When Ethereum contracts are compiled down to byte-code the convention is not to represent them as binary, but instead to represent them as a single long hex string like the following:

This is the compiled byte-code for the following solidity contract:

There could literally not be less going on here, but it provides us a good place to start. To see what that byte-code is doing let’s use Etherscan’s disassembler to decompile the hex string into the 25 opcodes that compose it:


Hex Strings To Binary

This is actually more information than we probably need, but it’s interesting and provides a nice high-level summary. To begin using our disassembler let’s first write a program to convert the hexadecimal string of a compiled contract into binary. The binary format is a useful first step as it allows us to do numeric comparisons and operations, which will come in handy later.

After playing around with it for a little bit we can come up with some D code to do the conversion for us.

Collecting The Opcodes

Now that we’ve got our data in the format we want, it’s time to approach writing the disassembler. The next step is assembling a list of all the possible opcodes and their binary values. Once we have this list we can then recognize and handle the opcodes on a case-by-base basis. The easiest place to get this list of opcodes is from the original Ethereum Yellow Paper, namely you can find the hex values in the appendix.

Completing The Disassembler

Now it’s time to complete our disassembler. One simple way to write a disassembler is simply to check for every single opcode one-by-one and then display its name. At 129 opcodes, this is still doable for the EVM but tedious.

In addition to thinking about displaying the opcode names, we also need to display any arguments they take. For some architectures this is a very complicated affair involving various argument encoding schemes. Luckily for us, Ethereum is stack based, so the only arguments to opcodes are provided to the PUSH opcodes, all 32 of ’em.

This means if we can match names to opcodes, the only thing we have to deal with on a case-by-case basis are the PUSH opcodes. The parameters to these opcodes are values between 8 and 256-bits, and these values are encoded in big-endian format. Most modern CPUs are little endian, and most modern programming languages do not natively support 256-bit integer values. This means we have to do a bit of work to construct our 256-bit integer values. Specifically, we consolidate them into a big integer byte-by-byte as we encounter them. With this information we can writing a disassembler routine as follows, where EvmOpcodes is our enumeration of all possible opcodes:

Testing It Out

Now we can test it out, let’s use it on our original example:

The output is slightly different, but everything seems to match, and with that we’ve completed our EVM disassembler.


Thanks for following along. You can find the link to the project in GitHub below. For extra points you might consider trying the following:

  • Format the output to match the output from etherscan’s opcode tool.
  • Write an assembler that takes this code as input and outputs bytecode.