As we're in the midst of preparing an "introduction to reverse engineering and assembly" workshop (to be officially announced soon), we've asked ourselves the obvious question: which of the hundreds of x86-64 assembly instructions one should start with.

Typically you would learn assembly instructions in groups. First the basic data moves, arithmetics, and bit operations. Then the unconditional jumps followed by tests and comparisons paired with conditional jumps. Then probably stack instructions, followed by CALL/RET. And then it gets a bit vague. But is this the right order? Is it really more urgent to know what JS is than what CALL is, especially when learning assembly with reverse code engineering as the final goal?

These questions should be considered from a couple of angles, but one thing that might help with the answer is always data!

Given the above, Dan wrote a Python script for Ghidra and counted how many times each specific instruction appeared in common binaries found both on Windows and Ubuntu Linux. To be a bit more precise, by instruction we specifically mean a unique mnemonic as shown by Ghidra.

Here are the results:

See full top 100 at the bottom of this post...

Based on this data, if you just learn the top 10 assembly instructions on the list, you will understand over 75% of the instructions that make the code you are reverse engineering. With learning top 20 that's over 90% of actual used instruction. Of course, there's a long tail of instructions remaining—we've observed over 800 of them, and more do exist. And there's more to understanding the algorithm than just understanding the instructions, but this might be a good way for a fast start.

A few notes about this table:

• While it's interesting to consider the popularity of operations, and it can serve as a good datapoint when designing a course, many applications require a more accurate approach (e.g. when designing CPUs and trying to figure out where to spend more time on optimisation).
• The "Share" column indicates the proportion of all observed instructions that this particular instruction accounts for. There is likely some error here as described later in these notes, so don't read too much into the actual number. Also, it matters more whether a given instruction is common or not, than whether a given instruction is in place e.g. 55th or 57th.
• On the same note, please remember that this is a list of most common instructions as observed in code (deadlistings). Specifically, this is not a list of most commonly executed instructions.
• Also, any instructions which dynamically appear in memory, for example as a result of code unpacking or just-in-time compilation, would also not make it to the list.
• As the instructions were sourced from Ghidra's output, some Ghidra-specific idiosyncrasies do apply. For example, the LOCK instruction prefix in Ghidra is outputted as a suffix in the instruction name. As such, e.g. INC and INC.LOCK appear as separate entries in the table on 29th and 78th place. You could argue that this is the same instruction—in such a case it would occupy 28th place.
• Note that you might get a bit different results with other disassemblers. For example, some disassemblers might use data-length suffixes (MOVL or MOV.L). Some disassemblers might represent multi-byte no-ops as NOP or NOPn, while others might show the actual aliased instructions.
• Given the problem of distinguishing what actually is and isn't code in a program (solved usually by a bunch of heuristics), there is likely a slight error introduced on this front as well. This also includes disassembler runs that start at a wrong offset (inside the actually generated instruction)—thankfully these tend to align pretty quickly during the run.
• There are certain differences in the order and instructions that appear in the top 100 between Windows and Linux. This makes sense as different compiler suites are used to generate the majority of code on these platforms.
• Along the same lines the results would be different on Gentoo for example—especially if you use custom compilation settings in your make.conf.
• Lastly, the top 100 list of instructions in user-mode and kernel-mode code will probably be different as well. To state the obvious, privileged instructions do not appear in user-mode programs outside of errors (and local-privilege escalation exploits of course).

Top 100 Most Common x86-64 Instructions