A disassembler is a computer program that translates machine language into assembly language—the inverse operation to that of an assembler. Disassembly, the output of a disassembler, is often formatted for human-readability rather than suitability for input to an assembler, making it principally a reverse-engineering tool. Common uses of disassemblers include analyzing high-level programing language compilers output and their optimizations, recovering source code of a program whose original source was lost, malware analysis, modifying software (such as ROM hacking), and software cracking.
A disassembler differs from a decompiler, which targets a high-level language rather than an assembly language.
Assembly language source code generally permits the use of constants and programmer comments. These are usually removed from the assembled machine code by the assembler. If so, a disassembler operating on the machine code would produce disassembly lacking these constants and comments; the disassembled output becomes more difficult for a human to interpret than the original annotated source code. Some disassemblers provide a built-in code commenting feature where the generated output gets enriched with comments regarding called API functions or parameters of called functions. Some disassemblers make use of the symbolic debugging information present in object files such as ELF. For example, IDA allows the human user to make up mnemonic symbols for values or regions of code in an interactive session: human insight applied to the disassembly process often parallels human creativity in the code writing process.
Writing a disassembler which produces code which, when assembled, produces exactly the original binary is possible; however, there are often differences. This poses demands on the expressivity of the assembler. For example, an x86 assembler takes an arbitrary choice between two binary codes for something as simple as MOV AX,BX. If the original code uses the other choice, the original code simply cannot be reproduced at any given point in time. However, even when a fully correct disassembly is produced, problems remain if the program requires modification. For example, the same machine language jump instruction can be generated by assembly code to jump to a specified location (for example, to execute specific code), or to jump a specified number of bytes (for example, to skip over an unwanted branch). A disassembler cannot know what is intended, and may use either syntax to generate a disassembly which reproduces the original binary. However, if a programmer wants to add instructions between the jump instruction and its destination, it is necessary to understand the program's operation to determine whether the jump should be absolute or relative, i.e., whether its destination should remain at a fixed location, or be moved so as to skip both the original and added instructions.
Another challenge is that it is not always possible to identify which parts of the binary correspond to executable code, and which correspond to data. While common executable formats like ELF and PE divide the binary into executable and data sections, other formats such as flat binaries do not, so any given location in the binary may contain either executable instructions or non-executable data, making it difficult to decide whether it should be disassembled as instructions or left as data. Since CPUs generally allow dynamic jumps computed at runtime, it is not always possible to identify all possible locations in the binary that may be jumped to and therefore contain instructions.
On computer architectures with variable-width instructions, such as in many complex instruction set computer (CISC) architectures, more than one disassembly may be valid.
Disassemblers do not handle code that varies during execution.
Encryption may be used on some computer programs, particularly as part of Digital Rights Management to thwart reverse engineering and cracking. This poses an additional challenge to disassembly as the code must be decrypted before being disassembled.
A disassembler may be stand-alone or interactive. A stand-alone disassembler, when executed, generates an assembly language file which can be examined; an interactive one shows the effect of any change the user makes immediately. For example, the disassembler may initially not know that a section of the program is actually code, and treat it as data; if the user specifies that it is code, the resulting disassembled code is shown immediately, allowing the user to examine it and take further action during the same run.
Any interactive debugger will include some way of viewing the disassembly of the program being debugged. Often, the same disassembly tool will be packaged as a standalone disassembler distributed along with the debugger. For example, objdump, part of GNU Binutils, is related to the interactive debugger gdb.[1]
A dynamic disassembler can be incorporated into the output of an emulator or hypervisor to 'trace out', line-by-line, the real time execution of any executed machine instructions. In this case, as well as lines containing the disassembled machine code, the register(s) and/or data change(s) (or any other changes of "state", such as condition codes) that each individual instruction causes can be shown alongside or beneath the disassembled instruction. This provides extremely powerful debugging information for ultimate problem resolution, although the size of the resultant output can sometimes be quite large, especially if active for an entire program's execution. OLIVER provided these features from the early 1970s as part of its CICS debugging product offering and is now to be found incorporated into the XPEDITER product from Compuware.
A length disassembler, also known as length disassembler engine (LDE), is a tool that, given a sequence of bytes (instructions), outputs the number of bytes taken by the parsed instruction. Notable open source projects for the x86 architecture include ldisasm,[8] Tiny x86 Length Disassembler[9] and Extended Length Disassembler Engine for x86-64.[10]
