How to write a disassembler

I'm interested in writing an x86 dissembler as an educational project.

The only real resource I have found is Spiral Space's, "How to write a disassembler". While this gives a nice high level description of the various components of a disassembler, I'm interested in some more detailed resources. I've also taken a quick look at NASM's source code but this is somewhat of a heavyweight to learn from.

I realize one of the major challenges of this project is the rather large x86 instruction set I'm going to have to handle. I'm also interested in basic structure, basic disassembler links, etc.

Can anyone point me to any detailed resources on writing a x86 disassembler?
 ===
 Not an answer but the answer in stackoverflow.com/questions/82432/… is also a good read for those who are starting. 
===

Start with some small program that has been assembled, and which gives you both the generated code and the instructions. Get yourself a reference with the instruction architecture, and work through some of the generated code with the architecture reference, by hand. You'll find that the instructions have a very stereotypical structure of inst op op op with varying number of operands. All you need to do is translate the hex or octal representation of the code to match the instructions; a little playing around will reveal it.

That process, automated, is the core of a disassembler. Ideally, you're probably going to want to construct a n array of instruction structures internally (or externally, if the program is really large). You can then translate that array into the instructions in assembler format.
===

You need a table of opcodes to load from.

The fundamental lookup datastructure is a trie, however a table will do well enough if you don't care much about speed.

To get the base opcode type, beginswith match on the table.

There are a few stock ways of decoding register arguments; however, there are enough special cases to require implementing most of them individually.
Since this is educational, have a look at ndisasm.
===

I would recommend checking out some open source disassemblers, preferably distorm and especially "disOps (Instructions Sets DataBase)" (ctrl+find it on the page).
The documentation itself is full of juicy information about opcodes and instructions.
Quote from https://code.google.com/p/distorm/wiki/x86_x64_Machine_Code

80x86 Instruction:
A 80x86 instruction is divided to a number of elements:

1. Instruction prefixes, affects the behaviour of the instruction's operation.
2. Mandatory prefix used as an opcode byte for SSE instructions.
3. Opcode bytes, could be one or more bytes (up to 3 whole bytes).
4. ModR/M byte is optional and sometimes could contain a part of the opcode itself.
5. SIB byte is optional and represents complex memory indirection forms.
6. Displacement is optional and it is a value of a varying size of bytes(byte, word, long) and used as an offset.
7. Immediate is optional and it is used as a general number value built from a varying size of bytes(byte, word, long).

The format looks as follows:

/-------------------------------------------------------------------------------------------------------------------------------------------\
|*Prefixes | *Mandatory Prefix | *REX Prefix | Opcode Bytes | *ModR/M | *SIB | *Displacement (1,2 or 4 bytes) | *Immediate (1,2 or 4 bytes) |
\-------------------------------------------------------------------------------------------------------------------------------------------/
* means the element is optional.

The data structures and decoding phases are explained in https://code.google.com/p/distorm/wiki/diStorm_Internals
Quote:

Decoding Phases

1. [Prefixes]
2. [Fetch Opcode]
3. [Filter Opcode]
4. [Extract Operand(s)]
5. [Text Formatting]
6. [Hex Dump]
7. [Decoded Instruction]

Each step is explained also.

---

The original (dead) links are kept for historical reasons:
http://ragestorm.net/distorm/vol1.html and http://ragestorm.net/distorm/vol2.html
===

Take a look at section 17.2 of the 80386 Programmer's Reference Manual. A disassembler is really just a glorified finite-state machine. The steps in disassembly are:

1. Check if the current byte is an instruction prefix byte (F3, F2, or F0); if so, then you've got a REP/REPE/REPNE/LOCK prefix. Advance to the next byte.
2. Check to see if the current byte is an address size byte (67). If so, decode addresses in the rest of the instruction in 16-bit mode if currently in 32-bit mode, or decode addresses in 32-bit mode if currently in 16-bit mode
3. Check to see if the current byte is an operand size byte (66). If so, decode immediate operands in 16-bit mode if currently in 32-bit mode, or decode immediate operands in 32-bit mode if currently in 16-bit mode
4. Check to see if the current byte is a segment override byte (2E, 36, 3E, 26, 64, or 65). If so, use the corresponding segment register for decoding addresses instead of the default segment register.
5. The next byte is the opcode. If the opcode is 0F, then it is an extended opcode, and read the next byte as the extended opcode.
6. Depending on the particular opcode, read in and decode a Mod R/M byte, a Scale Index Base (SIB) byte, a displacement (0, 1, 2, or 4 bytes), and/or an immediate value (0, 1, 2, or 4 bytes). The sizes of these fields depend on the opcode , address size override, and operand size overrides previously decoded.

The opcode tells you the operation being performed. The arguments of the opcode can be decoded form the values of the Mod R/M, SIB, displacement, and immediate value. There are a lot of possibilities and a lot of special cases, due to the complex nature of x86. See the links above for a more thorough explanation.
 

Intel manual says Groups 1 through 4 may be placed in any order relative to each other, so steps 1-4 may be not in that order

===

Checkout objdump sources - it's a great tool, it contains many opcode tables and it's sources can provide a nice base for making your own disassembler.

 

Reference: 

http://stackoverflow.com/questions/924303/how-to-write-a-disassembler?rq=1 

Windows serial number key finder

Belarc Advisor is the standard when it comes to system information software. I've been using this program for many, many years. One small aspect of Belarc Advisor is its ability to extract product keys for many software programs, including the one for Windows.

Advantages include display of information in your browser window, no adware/toolbars to worry about, and an extensive list of other important computer data.

Finds Keys for Operating Systems: Windows 8, Windows 7, Windows Vista, Windows Server 2012/2008/2003, Windows XP, Windows 2000, Windows NT, Windows ME, Windows 98, and Windows 95.

Finds Keys for Other Software: Microsoft Office 2013, 2010, (plus all previous versions), Microsoft enterprise products, most programs from Adobe, Nero, Corel, and more, as well as keys for popular video games.

Please try Belarc Advisor for your software and Windows key finding needs before any other program. It's likely to provide you with the best results.

http://www.belarc.com/free_download.html

How can I see the Assembly code for a C++ Program?

Approach 1

If you are building the program yourself, you can ask your compiler to emit assembly source. For most UNIX compilers use the -S switch.

If you are using the GNU assembler, compiling with -g -Wa,-alh will give intermixed source and assembly on stdout (-Wa asks compiler driver to pass options to assembler, -al turns on assembly listing, and -ah adds "high-level source" listing):

g++ -g -c -Wa,-alh foo.cc

For Visual Studio, use /FAsc.

If you have compiled binary, use objdump -d a.out on UNIX (also works for cygwin), dumpbin /DISASM foo.exe on Windows.

Debuggers could also show disassebly. Use disas command in GDB, or the disassembly window of Visual Studio on Windows.

Approach 2

Whatever debugger you're using should have an assembly view (VS, Borland IDE, gdb, etc). If you are not using a debugger and you merely want to see what assembly is in a program you can use a disassembler or alternatively, run the program and attach to it with a debugger and do the dump from there. See references to disassemblers for info on options.

Approach 3

As someone else mentioned, your platform's debugger is a good starting point. For the jackhammer of all debuggers and disassemblers, take a look at IDA Pro.

On Unix/Linux platforms (including Cygwin) you can use objdump --disassemble .

If there is an option to have the compiler generate the assembler (like gcc -S, or the VS /FA option below), that is preferable over disassembly. It is more symbolic.

Sure, if you have the source.

By the way, you'd be surprised how much symbol information can be deduced by IDA Pro.

Approach 4

In Visual Studio; 

1. set a breakpoint
2. run the program until it stops at the breakpoint
3. rightclick on the sourcecode and pick "show dissasembly"

Approach 5

In GCC/G++, compile with -S. That will output a something.s file with the assembly code.

Edit: If you want the output to be in Intel syntax (which is IMO, much more readable, and most assembly tutorials use it), compile with -masm=intel.

add also -fverbose-asm option

Approach 6

Most compilers have an option to output an assembly listing. E.g. with VisualStudio you can use something like:

cl.exe /FAfile.asm file.c

For best readability though, most debuggers will offer a view that interleaves the disassembly with the original source, so you can compare your code with the compiler's output line by line.

Approach 7

Lots of people already told how to emit assembly code with a given compiler. Another solution is to compile an object file and dump it with a tool such objdump, readelf (on Unix) or DUMPBIN(link) (on Windows). You can also dump an executable, but it will be more difficult to read the output.

This has the advantage of working the same way with any compiler.

Approach 8

PE Explorer Disassembler for 32-bit PE files. IDA for others.

Approach 9

For gcc/g++

gcc -save-temps -fverbose-asm prog.c

This will generate prog.s with some comments on variables used in every asm line:

    movl    $42, -24(%ebp)  #, readme
    movl    -16(%ebp), %eax # pid, pid
    movl    %eax, 4(%esp)   # pid,
    movl    $.LC0, (%esp)   #,
    call    printf  #

Reference:
http://stackoverflow.com/questions/840321/how-can-i-see-the-assembly-code-for-a-c-program

NASM is pure assembly, but MASM is high level Assembly?

My recommendation purely from a "reverse engineering" perspective is to understand how a compiler translates high-level concepts into assembly language instructions in the first place. The understanding of how register allocation is done in various compilers and how various optimizations will obscure the high-level representation of nested loops (et.al.) is more important than being able to write one particular dialect of assembly input.

Your best bet is to start with the assembly language intermediate files from source code that you write (seethis question for more information). Then you can change the source and see how it affects the intermediate files. The other place to start is by using an interactive disassembler like IDA Pro.

Actually writing assembly language programs and learning the syntax of NASM, MASM, gas, of as is the easiest part and it does not really matter which one you learn. They are very similar because the syntax of the source language is very basic. If you are planning to learn how to disassemble and understand what a program is doing, then I would completely ignore macro assemblers since the macros completely disappear during translation and you will not see them when looking at disassembler output.

Diatribe on Learning Assembly

Learning an assembly language is different than learning a higher level programming language. There are fewer syntactical constructs if you ignore macro assemblers. The problem is that every compiler chain has a slightly different representation so you have to concentrate on the concepts such as supported address modes, register restrictions, etc. These aren't part of the language per se as they are dictated by the hardware.

The approach that I took (partially because the university forced me to), is to explore and understand the hardware itself (e.g., # of registers, size of registers, type of branch instructions supported, etc.) and slightly more academic concepts such as interrupts and using bitwise manipulation for integer match before you start to write assembly language programs. This is a much longer route but results in a rich understanding of assembly and how to write high performance programs.

The interesting thing is that in the time that I spent learning assembly and compiler construction (which is intrinsically related), I actually wrote very few assembly programs. More often, I am required to write little snippets of inline assembly here and there (e.g. setting up index registers when the runtime loader didn't). I have spent an enormous amount of time dissecting crash dumps from a memory location, loader map file, and assembler output listings. I can honestly say that the syntax of each assembler is dramatically different as well as what various compilers will do to muddle the intent into fast or small code.

Learning how to write assembly programs was the least worthwhile part of the education process. It was necessary to understand how source is translated into the bits and bytes that the computer executes, but it really was not what I really needed to reverse engineer from a raw binary (disassembler -> assembly listing -> best guess of high level intent) or a memory dump. I do more of the latter, but the requirements of the job are the same.

1. You really have to understand what the constraints of the architecture are.
2. You have to know the very basic syntax of the assembler in question - how are address modes indicated, how are registers indicated, what is the order of arguments for a move
3. What transformations a compiler does to go from if (a > 0) to mov.b r0,d0 ... bnz $L

Start by learning about computer architecture (e.g., read something from Andrew Tanenbaum), then how an OS actually loads and runs a program (Levine's Linkers & Loaders), then compile simple programs in C/C++ and look at the assembly language listings.

But for understanding the disassembly... don't I need to learn assembly?

@questions: I think the best way to learn assembly is to look at disassembled code and figure out what it does. But that's my personal opinion.

Reference:

http://stackoverflow.com/questions/9944160/nasm-is-pure-assembly-but-masm-is-high-level-assembly

use mutt command to send email with attachment

# cd /usr/ports/mail/mutt ; make install clean
or
# cd /usr/ports/mail/mutt-lite ; make install clean

# mutt -s EMAIL_SUBJECT -a ATTACHMENT < EMAIL_BODY

command to show system information on Windows

cmd> dxdiag

Dynamically add multiple buttons to wpf grid?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
using System.Diagnostics;

namespace WpfApplication2
{
    /// 

    /// Interaction logic for MainWindow.xaml
    /// 
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            for (int i = 0; i < 10; i++)
            {
              g1.RowDefinitions.Add(new RowDefinition());
              g1.ColumnDefinitions.Add(new ColumnDefinition());
            }

            Button[] MyButtonList = new Button[100];
            int count = 0;

            for (int i = 0; i < 10; i++)
            {
                for (int j = 0; j < 10; j++)
                {
                  Button b = new Button()
                  {
                      Name = "btn" + i + j,
                      Content = "gan " + i + "" + j,
                      Tag = "tagg " + i + j
                  };
                  b.Click += new RoutedEventHandler(button_Click);

                  MyButtonList[count] = b;

                  g1.Children.Add(b);
                  Grid.SetRow(b, i);
                  Grid.SetColumn(b, j);

                  count++;
                }
            }

            // remove a button
            g1.Children.Remove(MyButtonList[97]);
        }

        void button_Click(object sender, RoutedEventArgs e)
        {
            //Debug.WriteLine("you clicked {0}", (sender as Button).Name);
            Debug.WriteLine("you clicked {0}", (sender as Button).Name, null);
            Debug.WriteLine(string.Format("you clicked {0}", (sender as Button).Name));
            Debug.WriteLine("you clicked " + (sender as Button).Name);
            Debug.Print("you clicked " + (sender as Button).Name);
            Debug.WriteLine("you clicked {0}", (sender as Button).Content);
            Debug.WriteLine("you clicked {0}", (sender as Button).Tag);

            //Window1 w1 = new Window1();
            //w1.ShowDialog();
        }
    }
}