# X86 Disassembly/Disassemblers and Decompilers

## What is a Disassembler?

In essence, a **disassembler** is the exact opposite of an assembler.
Where an assembler converts code written in an assembly language into
binary machine code, a disassembler reverses the process and attempts to
recreate the assembly code from the binary machine code.

Since most assembly languages have a one-to-one correspondence with
underlying machine instructions, the process of disassembly is
relatively straight-forward, and a basic disassembler can often be
implemented simply by reading in bytes, and performing a table lookup.
Of course, disassembly has its own problems and pitfalls, and they are
covered later in this chapter.

Many disassemblers have the option to output assembly language
instructions in Intel, AT&T, or (occasionally) HLA syntax. Examples in
this book will use Intel and AT&T syntax interchangeably. We will
typically not use HLA syntax for code examples, but that may change in
the future.

## x86 Disassemblers

Here we are going to list some commonly available disassembler tools.
Notice that there are professional disassemblers (which cost money for a
license) and there are freeware/shareware disassemblers. Each
disassembler will have different features, so it is up to you as the
reader to determine which tools you prefer to use.

### Online Disassemblers

ODA: is a free, web-based disassembler for a wide variety of architectures. You can use \"Live View\" to see how code is disassembled in real time, one byte at a time, or upload a file. The site is currently in beta release but will hopefully only get better with time.
:   <http://www.onlinedisassembler.com>

### Commercial Windows Disassemblers

IDA Pro: is a professional disassembler that is expensive, extremely powerful, and has a whole slew of features. The downside to IDA Pro is that it costs \$515 US for the standard single-user edition. As such this wikibook will not consider IDA Pro specifically because the price tag is exclusionary. Freeware versions do exist; see below.

-   (version 6.x) <http://www.hex-rays.com/idapro/>

Relyze Desktop: is an interactive software reverse engineering tool that lets you disassemble, decompile and diff x86, x64, ARM32 and ARM64 software.
:   <https://www.relyze.com/overview.html>

```{=html}
<!-- -->
```

Hopper Disassembler: is a reverse engineering tool for the Mac, that lets you disassemble, decompile and debug 32/64bits Intel Mac executables. It can also disassemble and decompile Windows executables.
:   <http://www.hopperapp.com>

```{=html}
<!-- -->
```

OBJ2ASM: is an object file disassembler for 16 and 32 bit x86 object files in Intel OMF, Microsoft COFF format, Linux ELF or Mac OS X Mach-O format.
:   <http://www.digitalmars.com/ctg/obj2asm.html>

```{=html}
<!-- -->
```

PE Explorer: is a disassembler that \"focuses on ease of use, clarity and navigation.\" It isn\'t as feature-filled as IDA Pro and carries a smaller price tag to offset the missing functionality: \$130
:   <http://www.heaventools.com/PE_Explorer_disassembler.htm>

```{=html}
<!-- -->
```

W32DASM (Win32dasm): W32DASM was an excellent 16/32 bit disassembler for Windows, it seems it is no longer developed. the latest version available is from 2003. the website went down and no replacement went up.
:   <http://www.softpedia.com/get/Programming/Debuggers-Decompilers-Dissasemblers/WDASM.shtml>

```{=html}
<!-- -->
```

Binary Ninja: Binary Ninja is a commercial, cross-platform (Linux, OS X, Windows) reverse engineering platform with aims to offer a similar feature set to IDA at a much cheaper price point. A precursor written in python is open source and available at <https://github.com/Vector35/deprecated-binaryninja-python>. Introductory pricing is \$99 for student/non-commercial use, and \$399 for commercial use.
:   <https://binary.ninja/>

```{=html}
<!-- -->
```

Hiew: x86-64 disassembler & assembler. Single license pricing is \$19, and \$199 with lifetime updates.
:   hiew.ru

### Commercial Freeware/Shareware Windows Disassemblers

OllyDbg: OllyDbg is one of the most popular disassemblers recently. It has a large community and a wide variety of plugins available. It emphasizes binary code analysis. Supports x86 instructions only (no x86_64 support for now, although it is on the way).
:   <http://www.ollydbg.de/> (official website)
:   <http://www.openrce.org/downloads/browse/OllyDbg_Plugins> (plugins)
:   <http://www.ollydbg.de/odbg64.html> (64 bit version)

### Free Windows Disassemblers

Capstone: Capstone is an open source disassembly framework for multi-arch (including support for x86, x86_64) & multi-platform with advanced features.
:   <http://www.capstone-engine.org/>

```{=html}
<!-- -->
```

Zydis: Fast and lightweight x86/x86-64 decoder library. It does not offer disassembler features such as linear sweep or recursive disassembling.
:   <https://github.com/zyantific/zydis>

```{=html}
<!-- -->
```

Objconv: A command line disassembler supporting 16, 32, and 64 bit x86 code. Latest instruction set (SSE4, AVX, XOP, FMA, etc.), several object file formats, several assembly syntax dialects. Windows, Linux, BSD, Mac. Intelligent analysis.

-   <http://www.agner.org/optimize/#objconv>

IDA 3.7: A DOS GUI tool that behaves very much like IDA Pro, but is considerably more limited. It can disassemble code for the Z80, 6502, Intel 8051, Intel i860, and PDP-11 processors, as well as x86 instructions up to the 486.

-   <http://www.simtel.net/product.php> (search for **ida37fw**)

IDA Pro Freeware: Behaves almost exactly like IDA Pro, but disassembles only Intel x86 opcodes and is Windows-only. It can disassemble instructions for those processors available as of 2003. Free for non-commercial use.

-   (version 4.1) <http://www.themel.com/idafree.zip>
-   (version 4.3) <http://www.datarescue.be/idafreeware/freeida43.exe>
-   (version 5.0) <https://www.scummvm.org/frs/extras/IDA/idafree50.exe>
-   (version 7.0)
    <https://www.hex-rays.com/products/ida/support/download_freeware.shtml>

BORG Disassembler: BORG is an excellent Win32 Disassembler with GUI.
:   <http://www.caesum.com/>

```{=html}
<!-- -->
```

HT Editor: An analyzing disassembler for Intel x86 instructions. The latest version runs as a console GUI program on Windows, but there are versions compiled for Linux as well.
:   <http://hte.sourceforge.net/>

```{=html}
<!-- -->
```

diStorm64: diStorm is an open source highly optimized stream disassembler library for 80x86 and AMD64.
:   <http://ragestorm.net/distorm/>

```{=html}
<!-- -->
```

crudasm: crudasm is an open source disassembler with a variety of options. It is a work in progress and is bundled with a partial decompiler.
:   <http://sourceforge.net/projects/crudasm9/>

```{=html}
<!-- -->
```

BeaEngine: BeaEngine is a complete disassembler library for IA-32 and intel64 architectures (coded in C and usable in various languages : C, Python, Delphi, PureBasic, WinDev, masm, fasm, nasm, GoAsm).
:   <https://github.com/BeaEngine/beaengine>

```{=html}
<!-- -->
```

Visual DuxDebugger: is a 64-bit debugger disassembler for Windows.
:   <http://www.duxcore.com/products.html>

```{=html}
<!-- -->
```

BugDbg: is a 64-bit user-land debugger designed to debug native 64-bit applications on Windows.
:   <http://www.pespin.com/>

```{=html}
<!-- -->
```

DSMHELP: Disassemble Help Library is a disassembler library with single line Epimorphic assembler. Supported instruction sets - Basic,System,SSE,SSE2,SSE3,SSSE3,SSE4,SSE4A,MMX,FPU,3DNOW,VMX,SVM,AVX,AVX2,BMI1,BMI2,F16C,FMA3,FMA4,XOP.
:   <http://dsmhelp.narod.ru/> (in Russian)

```{=html}
<!-- -->
```

ArkDasm: is a 64-bit interactive disassembler and debugger for Windows. Supported processor: x64 architecture (Intel x64 and AMD64)
:   <http://www.arkdasm.com/>

```{=html}
<!-- -->
```

SharpDisam: is a C# port of the udis86 x86 / x86-64 disassembler
:   <http://sharpdisasm.codeplex.com/>

```{=html}
<!-- -->
```

CFF Explorer: Special fields description and modification (.NET supported), utilities, rebuilder, hex editor, import adder, signature scanner, signature manager, extension support, scripting, disassembler, dependency walker etc.
:   ntcore.com

```{=html}
<!-- -->
```

bddisasm: fast, lightweight, x86/x64 instruction decoding library.
:   github.com/bitdefender/bddisasm

### Unix Disassemblers

Many of the Unix disassemblers, especially the open source ones, have
been ported to other platforms, like Windows (mostly using MinGW or
Cygwin). Some Disassemblers like otool (\[OS X) are distro-specific.

Capstone: Capstone is an open source disassembly framework for multi-arch (including support for x86, x86_64) & multi-platform (including Mac OSX, Linux, \*BSD, Android, iOS, Solaris) with advanced features.
:   <http://www.capstone-engine.org/>

```{=html}
<!-- -->
```

Bastard Disassembler: The Bastard disassembler is a powerful, scriptable disassembler for Linux and FreeBSD.
:   <http://bastard.sourceforge.net/>

```{=html}
<!-- -->
```

ndisasm: NASM\'s disassembler for x86 and x86-64. Works on DOS, Windows, Linux, Mac OS X and various other systems.

```{=html}
<!-- -->
```

udis86: Disassembler Library for x86 and x86-64
:   <http://udis86.sourceforge.net/>

```{=html}
<!-- -->
```

Zydis: Fast and lightweight x86/x86-64 disassembler library.
:   <https://github.com/zyantific/zydis>

```{=html}
<!-- -->
```

Objconv: See above.

```{=html}
<!-- -->
```

ciasdis: The official name of ciasdis is *computer_intelligence_assembler_disassembler*. This Forth-based tool allows to incrementally and interactively build knowledge about a code body. It is unique that all disassembled code can be re-assembled to the exact same code. Processors are 8080, 6809, 8086, 80386, Pentium I en DEC Alpha. A scripting facility aids in analyzing Elf and MSDOS headers and makes this tool extendable. The Pentium I ciasdis is available as a binary image, others are in source form, loadable onto lina Forth, available from the same site.
:   <http://home.hccnet.nl/a.w.m.van.der.horst/ciasdis.html>

```{=html}
<!-- -->
```

objdump : comes standard, and is typically used for general inspection of binaries. Pay attention to the relocation option and the dynamic symbol table option.

```{=html}
<!-- -->
```

gdb : comes standard, as a debugger, but is very often used for disassembly. If you have loose hex dump data that you wish to disassemble, simply enter it (interactively) over top of something else or compile it into a program as a string like so: char foo\[\] = {0x90, 0xcd, 0x80, 0x90, 0xcc, 0xf1, 0x90};

```{=html}
<!-- -->
```

lida linux interactive disassembler: an interactive disassembler with some special functions like a crypto analyzer. Displays string data references, does code flow analysis, and does not rely on objdump. Utilizes the Bastard disassembly library for decoding single opcodes. The project was started in 2004 and remains dormant to this day.
:   <http://lida.sourceforge.net>

```{=html}
<!-- -->
```

dissy : This program is a interactive disassembler that uses objdump.
:   <http://code.google.com/p/dissy/>

```{=html}
<!-- -->
```

EmilPRO : replacement for the deprecated dissy disassembler.
:   <http://github.com/SimonKagstrom/emilpro>

```{=html}
<!-- -->
```

x86dis : This program can be used to display binary streams such as the boot sector or other unstructured binary files.

```{=html}
<!-- -->
```

ldasm: LDasm (Linux Disassembler) is a Perl/Tk-based GUI for objdump/binutils that tries to imitate the \'look and feel\' of W32Dasm. It searches for cross-references (e.g. strings), converts the code from GAS to a MASM-like style, traces programs and much more. Comes along with PTrace, a process-flow-logger. Last updated in 2002, available from Tucows.
:   <http://www.tucows.com/preview/59983/LDasm>

```{=html}
<!-- -->
```

llvm: LLVM has two interfaces to its disassembler:

:   ```{=html}
    <dl>
    ```
    ```{=html}
    <dt>
    ```
    `llvm-objdump`

    ```{=html}
    </dt>
    ```
    ```{=html}
    <dd>
    ```
    Mimics GNU objdump.

    ```{=html}
    </dd>
    ```
    ```{=html}
    <dt>
    ```
    `llvm-mc`

    ```{=html}
    </dt>
    ```
    ```{=html}
    <dd>
    ```
    See the LLVM
    blog. Example
    usage:

    ```{=html}
    <div class="mw-code">
    ```
    \$ echo \'1 2\' \| llvm-mc -disassemble
    -triple=x86_64-apple-darwin9\
    addl %eax, (%rdx)\
    \$ echo \'0x0f 0x1 0x9\' \| llvm-mc -disassemble
    -triple=x86_64-apple-darwin9\
    sidt (%rcx)\
    \$ echo \'0x0f 0xa2\' \| llvm-mc -disassemble
    -triple=x86_64-apple-darwin9\
    cpuid\
    \$ echo \'0xd9 0xff\' \| llvm-mc -disassemble
    -triple=i386-apple-darwin9\
    fcos\

    ```{=html}
    </div>
    ```
    ```{=html}
    </dd>
    ```
    ```{=html}
    </dl>
    ```

```{=html}
<!-- -->
```

otool: OS X\'s object file displaying tool.

```{=html}
<!-- -->
```

edb: A cross platform x86/x86-64 debugger.
:   <https://github.com/eteran/edb-debugger>

```{=html}
<!-- -->
```

bddisasm: fast, lightweight, x86/x64 instruction decoding library.
:   github.com/bitdefender/bddisasm

```{=html}
<!-- -->
```

rasm2: radare2 disassembler and assembler tool. Includes x86.nz library with support for x86/x86-64.

## Disassembler Issues

As we have alluded to before, there are a number of issues and
difficulties associated with the disassembly process. The two most
important difficulties are the division between code and data, and the
loss of text information.

### Separating Code from Data

Since data and instructions are all stored in an executable as binary
data, the obvious question arises: how can a disassembler tell code from
data? Is any given byte a variable, or part of an instruction?

The problem wouldn\'t be as difficult if data were limited to the .data
section (segment) of an executable (explained in a later chapter) and if
executable code were limited to the .code section of an executable, but
this is often not the case. Data may be inserted directly into the code
section (e.g. jump address tables, constant strings), and executable
code may be stored in the data section (although new systems are working
to prevent this for security reasons). AI programs, LISP or Forth
compilers may not contain .text and .data sections to help decide, and
have code and data interspersed in a single section that is readable,
writable and executable, Boot code may even require substantial effort
to identify sections. A technique that is often used is to identify the
entry point of an executable, and find all code reachable from there,
recursively. This is known as \"code crawling\".

Many interactive disassemblers will give the user the option to render
segments of code as either code or data, but non-interactive
disassemblers will make the separation automatically. Disassemblers
often will provide the instruction AND the corresponding hex data on the
same line, shifting the burden for decisions about the nature of the
code to the user. Some disassemblers (e.g. ciasdis) will allow you to
specify rules about whether to disassemble as data or code and invent
label names, based on the content of the object under scrutiny.
Scripting your own \"crawler\" in this way is more efficient; for large
programs interactive disassembling may be impractical to the point of
being unfeasible.

The general problem of separating code from data in arbitrary executable
programs is equivalent to the halting problem. As a consequence, it is
not possible to write a disassembler that will correctly separate code
and data for all possible input programs. Reverse engineering is full of
such theoretical limitations, although by Rice\'s theorem all
interesting questions about program properties are undecidable (so
compilers and many other tools that deal with programs in any form run
into such limits as well). In practice a combination of interactive and
automatic analysis and perseverance can handle all but programs
specifically designed to thwart reverse engineering, like using
encryption and decrypting code just prior to use, and moving code around
in memory.

### Lost Information

User defined textual identifiers, such as variable names, label names,
and macros are removed by the assembly process. They may still be
present in generated object files, for use by tools like debuggers and
relocating linkers, but the direct connection is lost and
re-establishing that connection requires more than a mere disassembler.
Especially small constants may have more than one possible name.
Operating system calls (like DLLs in MS-Windows, or syscalls in Unices)
may be reconstructed, as their names appear in a separate segment or are
known beforehand. Many disassemblers allow the user to attach a name to
a label or constant based on his understanding of the code. These
identifiers, in addition to comments in the source file, help to make
the code more readable to a human, and can also shed some clues on the
purpose of the code. Without these comments and identifiers, it is
harder to understand the purpose of the source code, and it can be
difficult to determine the algorithm being used by that code. When you
combine this problem with the possibility that the code you are trying
to read may, in reality, be data (as outlined above), then it can be
even harder to determine what is going on. Another challenge is posed by
modern optimising compilers; they inline small subroutines, then combine
instructions over call and return boundaries. This loses valuable
information about the way the program is structured.

## Decompilers

Akin to Disassembly, **Decompilers** take the process a step further and
actually try to reproduce the code in a high level language. Frequently,
this high level language is C, because C is simple and primitive enough
to facilitate the decompilation process. Decompilation does have its
drawbacks, because lots of data and readability constructs are lost
during the original compilation process, and they cannot be reproduced.
Since the science of decompilation is still young, and results are
\"good\" but not \"great\", this page will limit itself to a listing of
decompilers, and a general (but brief) discussion of the possibilities
of decompilation. Compared to disassemblers a decompiler generates code
that doesnot require that one is familiar at the processor at hand. It
may even be that the decompiled code can be compiled on a different
processor, or give a reasonable starting point to reproduce the program
on a different processor.

### Decompilation: Is It Possible?

In the face of optimizing compilers, it is not uncommon to be asked \"Is
decompilation even possible?\" To some degree, it usually is. Make no
mistake, however: an optimizing compiler results in the irretrievable
loss of information. An example is in-lining, as explained above, where
code called is combined with its surroundings, such that the places
where the original subroutine is called cannot even be identified. An
optimizer that reverses that process is comparable to an artificial
intelligence program that recreates a poem in a different language. So
perfectly operational decompilers are a long way off. At most, current
Decompilers can be used as simply an aid for the reverse engineering
process leaving lots of arduous work.

### Common Decompilers

Hex-Rays Decompiler: Hex-Rays is a commercial decompiler. It is made as an extension to popular IDA-Pro disassembler. It is currently the only viable commercially available decompiler which produces usable results. It supports both x86 and ARM architecture.
:   <http://www.hex-rays.com/products/decompiler/index.shtml>

```{=html}
<!-- -->
```

ILSpy: ILSpy is an open source .NET assembly browser and decompiler.
:   <https://github.com/icsharpcode/ILSpy>

```{=html}
<!-- -->
```

DCC: DCC is likely one of the oldest decompilers in existence, dating back over 20 years. It serves as a good historical and theoretical frame of reference for the decompilation process in general (Mirrors: 12). As of 2015, DCC is an active project. Some of the latest changes include fixes for longstanding memory leaks and a more modern Qt5-based front-end.

```{=html}
<!-- -->
```

RetDec: The Retargetable Decompiler is a freeware web decompiler that takes in ELF/PE/COFF binaries in Intel x86, ARM, MIPS, PIC32, and PowerPC architectures and outputs C or Python-like code, plus flow charts and control flow graphs. It puts a running time limit on each decompilation. It produces nice results in most cases.
:   <https://github.com/avast/retdec>

```{=html}
<!-- -->
```

Reko: a modular open-source decompiler supporting both an interactive GUI and a command-line interface. Its pluggable design supports decompilation of a variety of executable formats and processor architectures (8- , 16- , 32- and 64-bit architectures as of 2015). It also supports running unpacking scripts before actual decompilation. It performs global data and type analyses of the binary and yields its results in a subset of C++.
:   <http://sourceforge.net/projects/decompiler>
:   <https://github.com/uxmal/reko>

```{=html}
<!-- -->
```

C4Decompiler: C4Decompiler is an interactive, static decompiler under development (Alpha in 2013). It performs global analysis of the binary and presents the resulting C source in a Windows GUI. Context menus support navigation, properties, cross references, C/Asm mixed view and manipulation of the decompile context (function ABI).
:   <http://www.c4decompiler.com>

```{=html}
<!-- -->
```

Boomerang Decompiler Project: Boomerang Decompiler is an attempt to make a powerful, retargetable decompiler. So far, it only decompiles into C with moderate success.
:   <http://boomerang.sourceforge.net/>

```{=html}
<!-- -->
```

Reverse Engineering Compiler (REC): REC is a powerful \"decompiler\" that decompiles native assembly code into a *C-like* code representation. The code is half-way between assembly and C, but it is much more readable than the pure assembly is. Unfortunately the program appears to be rather unstable.
:   <http://www.backerstreet.com/rec/rec.htm>

```{=html}
<!-- -->
```

ExeToC: ExeToC decompiler is an interactive decompiler that boasted pretty good results in the past.
:   <http://sourceforge.net/projects/exetoc>

```{=html}
<!-- -->
```

snowman: Snowman is an open source native code to C/C++ decompiler. Supports ARM, x86, and x86-64 architectures. Reads ELF, Mach-O, and PE file formats. Reconstructs functions, their names and arguments, local and global variables, expressions, integer, pointer and structural types, all types of control-flow structures, including switch. Has a nice graphical user interface with one-click navigation between the assembler code and the reconstructed program. Has a command-line interface for batch processing.
:   <https://derevenets.com>

```{=html}
<!-- -->
```

Ghidra: Ghidra is a reverse engineering package that includes a decompiler. It was written by the NSA for internal work, and apparently released because they didn\'t want to have to re-train every new person they hired. It is written in Java.

## A General view of Disassembling

### 8 bit CPU code

Most embedded CPUs are 8-bit CPUs.[^1]

Normally when a subroutine is finished, it returns to executing the next
address immediately following the `call` instruction.

However, assembly-language programmers occasionally use several
different techniques that adjust the return address, making disassembly
more difficult:

-   jump tables,
-   calculated jumps, and
-   a parameter after the call instruction.

#### jump tables and other calculated jumps

On 8-bit CPUs, calculated jumps are often implemented by pushing a
calculated \"return\" address to the stack, then jumping to that address
using the \"return\" instruction. For example, the RTS
Trick uses this technique
to implement jump tables (branch table).

#### parameters after the call instruction

Instead of picking up their parameters off the stack or out of some
fixed global address, some subroutines provide parameters in the
addresses of memory that follow the instruction that called that
subroutine. Subroutines that use this technique adjust the return
address to skip over all the constant parameter data, then return to an
address many bytes after the \"call\" instruction. One of the more
famous programs that used this technique is the \"Sweet 16\" virtual
machine.

The technique may make disassembly more difficult.

A simple example of this is the `write()` procedure implemented as
follows:

``` asm
; assume ds = cs, e.g like in boot sector code
start:
        call write       ; push message's address on top of stack
        db   "Hello, world",0dh,0ah,00h
; return point
        ret              ; back to DOS

write proc near
        pop  si          ; get string address
        mov  ah,0eh      ; BIOS: write teletype
w_loop:
        lodsb            ; read char at [ds:si] and increment si
        or   al,al       ; is it 00h?
        jz   short w_exit
        int  10h         ; write the character
        jmp  w_loop      ; continue writing
w_exit:
        jmp  si
write   endp
        end start
```

A macro-assembler like TASM will then use a macro like this one:

``` asm
_write macro message
       call write
       db message
       db 0
_write endm
```

From a human disassembler\'s point of view, this is a nightmare,
although this is straightforward to read in the original Assembly source
code, as there is no way to decide if the db should be interpreted or
not from the binary form, and this may contain various jumps to real
executable code area, triggering analysis of code that should never be
analysed, and interfering with the analysis of the real code (e.g.
disassembling the above code from 0000h or 0001h won\'t give the same
results at all).

However a half-decent tool with possibilities to specifiy rules, and
heuristic means to identify texts will have little trouble.

### 32 bit CPU code

Most 32-bit CPUs use the ARM instruction set.[^2][^3][^4]

Typical ARM assembly code is a series of subroutines, with literal
constants scattered between subroutines. The  standard prolog and
epilog
for subroutines is pretty easy to recognize.

### A brief list of disassemblers

-   ciasdis
    \"an assembler where the elements opcode, operands and modifiers are
    all objects, that are reusable for disassembly.\" For 8080 8086
    80386 Alpha 6809 and should be usable for Pentium 68000 6502 8051.

-   radare, the reverse engineering framework
    includes open-source tools to disassemble code for many processors
    including x86, ARM, PowerPC, m68k, etc. several virtual machines
    including java, msil, etc., and for many platforms including Linux,
    BSD, OSX, Windows, iPhoneOS, etc.

-   IDA, the Interactive Disassembler ( IDA
    Pro ) can disassemble code for a
    huge number of processors, including ARM Architecture (including
    Thumb and Thumb-2), ATMEL AVR, INTEL 8051, INTEL 80x86, MOS
    Technologies 6502, MC6809, MC6811, M68H12C, MSP430, PIC 12XX, PIC
    14XX, PIC 18XX, PIC 16XXX, Zilog Z80, etc.

-   objdump, part of the GNU binutils, can disassemble code for several
    processors and platforms. binutils is an important part of the
    toolchain as it provides the linker, assembler and other utilties
    (like objdump) to manipulate executables on the target platform, and
    is available for most popular platforms.
    -   For OS X/BSD systems, there is a rough equivalent called otool
        in the XCode kit.

-       lists a huge number of disassemblers

-   Program transformation wiki:
    disassembly
    lists many highly recommended disassemblers

-   search for \"disassemble\" at
    SourceForge shows
    many disassemblers for a variety of CPUs.

-   Hopper is a disassembler that runs on OS-X
    and disassembles 32/64-bit OS-X and windows binaries.

-   The University of Queensland Binary Translator
    (UQBT)
    is a reusable, component-based binary-translation framework that
    supports CISC, RISC, and stack-based processors.

## Further reading

-   <http://www.crackmes.de/> : reverse engineering challenges
-   \"A Challengers Handbook\" by Caesum
    3 has some tips on
    reverse engineering programs in JavaScript, Flash Actionscript
    (SWF), Java, etc.
-   the Open Source Institute occasionally has reverse engineering
    challenges among its other brainteasers.4
-   The Program Transformation wiki has a Reverse engineering and
    Re-engineering
    Roadmap,
    and discusses disassemblers, decompilers, and tools for translating
    programs from one high-level language to another high-level
    language.
-   Other disassemblers with multi-platform
    support

[^1]: Jim Turley. \"The Two Percent
    Solution\".
    2002.

[^2]:

[^3]: Mark Hachman. \"ARM Cores Climb Into 3G
    Territory\".
    2002. \"Although Intel and AMD receive the bulk of attention in the
    computing world, ARM's embedded 32-bit architecture, \... has
    outsold all others.\"

[^4]: Tom Krazit. \"ARMed for the living
    room\".
    \"ARM licensed 1.6 billion cores \[in 2005\]\". 2006.


# X86 Disassembly/Analysis Tools

## Debuggers

**Debuggers** are programs that allow the user to execute a compiled
program one step at a time. You can see what instructions are executed
in which order, and which sections of the program are treated as code
and which are treated as data. Debuggers allow you to analyze the
program while it is running, to help you get a better picture of what it
is doing.

Advanced debuggers often contain at least a rudimentary disassembler,
often times hex editing and reassembly features. Debuggers often allow
the user to set *breakpoints* on instructions, function calls, and even
memory locations.

A breakpoint is an instruction to the debugger that allows program
execution to be halted when a certain condition is met. For instance,
when a program accesses a certain variable, or calls a certain API
function, the debugger can pause program execution.

### Windows Debuggers

SoftICE : A *de facto* standard for Windows debugging. SoftICE can be used for *local kernel debugging*, which is a feature that is very rare, and very valuable. SoftICE was taken off the market in April 2006.

WinDbg : WinDbg is a free piece of software from Microsoft that can be used for local user-mode debugging, or even remote kernel-mode debugging. WinDbg is not the same as the better-known Visual Studio Debugger, but comes with a nifty GUI nonetheless. Available in 32 and 64-bit versions.
:   <https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools>

```{=html}
<!-- -->
```

IDA Pro : The multi-processor, multi-OS, interactive disassembler by DataRescue.
:   <http://www.hex-rays.com/idapro/>

```{=html}
<!-- -->
```

OllyDbg : OllyDbg is a free and powerful Windows debugger with a built-in disassembly and assembly engine. Very useful for patching, disassembling, and debugging.
:   <http://www.ollydbg.de/>

```{=html}
<!-- -->
```

x64dbg : A set of 32 and 64 bit x86 debuggers. x64dbg is the spiritual successor to the discontinued OllyDbg.

```{=html}
<!-- -->
```

Immunity Debugger : Immunity Debugger is a branch of OllyDbg v1.10, with built-in support for Python scripting and much more.
:   <http://immunityinc.com/products/debugger/index.html>

### Linux Debuggers

Many of the open source debuggers on Linux, again, are cross-platform.
They may be available on some other Unix(-like) systems, or even
Windows. Some of the debuggers may give you better experience than the
old and native ones on your system.

gdb : The GNU debugger, comes with any normal Linux install. It is quite powerful and even somewhat programmable, though the raw user interface is harsh.

```{=html}
<!-- -->
```

lldb: LLVM\'s debugger.

```{=html}
<!-- -->
```

emacs : The GNU editor, can be used as a front-end to gdb. This provides a powerful hex editor and allows full scripting in a LISP-like language.

```{=html}
<!-- -->
```

ddd : The Data Display Debugger. It\'s another front-end to gdb. This provides graphical representations of data structures. For example, a linked list will look just like a textbook illustration.

```{=html}
<!-- -->
```

strace, ltrace, and xtrace : Lets you run a program while watching the actions it performs. With strace, you get a log of all the system calls being made. With ltrace, you get a log of all the library calls being made. With xtrace, you get a log of some of the funtion calls being made.

```{=html}
<!-- -->
```

valgrind : Executes a program under emulation, performing analysis according to one of the many plug-in modules as desired. You can write your own plug-in module as desired. Newer versions of valgrind also support OS X.

```{=html}
<!-- -->
```

NLKD : A kernel debugger.
:   <http://forge.novell.com/modules/xfmod/project/?nlkd>

```{=html}
<!-- -->
```

edb : A fully featured plugin-based debugger inspired by the famous OllyDbg. Project page

```{=html}
<!-- -->
```

KDbg : A gdb front-end for KDE. <http://kdbg.org>

```{=html}
<!-- -->
```

RR0D : A Ring-0 Debugger for Linux. RR0D Project Page

```{=html}
<!-- -->
```

Radare2
:   A debugger and reversing framework.

```{=html}
<!-- -->
```

Winedbg: Wine "wikilink")\'s debugger. Debugs Windows executables using wine.

### Debuggers for Other Systems

dbx : The standard Unix debugger on systems derived from AT&T Unix. It is often part of an optional development toolkit package which comes at an extra price. It uses an interactive command line interface.

```{=html}
<!-- -->
```

ladebug : An enhanced debugger on Tru64 Unix systems from HP (originally Digital Equipment Corporation) that handles advanced functionality like threads better than dbx.

```{=html}
<!-- -->
```

DTrace : An advanced tool on Solaris that provides functions like profiling and many others on the entire system, including the kernel.

```{=html}
<!-- -->
```

mdb : The Modular Debugger (MDB) is a new general purpose debugging tool for the Solaris Operating Environment. Its primary feature is its extensibility. The Solaris Modular Debugger Guide describes how to use MDB to debug complex software systems, with a particular emphasis on the facilities available for debugging the Solaris kernel and associated device drivers and modules. It also includes a complete reference for and discussion of the MDB language syntax, debugger features, and MDB Module Programming API.

### Debugger Techniques

#### Setting Breakpoints

As previously mentioned in the section on disassemblers, a 6-line C
program doing something as simple as outputting \"Hello, World!\" turns
into massive amounts of assembly code. Most people don\'t want to sift
through the entire mess to find out the information they want. It can be
time consuming just to find the information one desires by just looking
through the code. As an alternative, one can choose to set breakpoints
to halt the program once it has reached a given point within the
program\'s code.

For instance, let\'s say that in your program you consistantly
experience crashes after one particular event: immediately after closing
a message box. You set breakpoints on all calls to *MessageBoxA*. You
run your program with the breakpoints set, and it stops, ready to call
*MessageBoxA*. Executing each line one-by-one thereafter (referred to as
*stepping*) through the code, and watching the program stack, you see
that a buffer overflow occurs soon after the call.

## Hex Editors

**Hex editors** are able to directly view and edit the binary of a
source file, and are very useful for investigating the structure of
proprietary closed-format data files. There are many hex editors in
existence. This section will attempt to list some of the best, some of
the most popular, or some of the most powerful.

HxD (Freeware): For Windows. A fast and powerful free hex, disk and RAM editor
:   <http://mh-nexus.de/hxd/>

```{=html}
<!-- -->
```

Freeware Hex Editor XVI32 : For Windows. A freeware hex editor.
:   <http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm>

```{=html}
<!-- -->
```

wxHexEditor (Beta, For Windows and Linux, Free & Open Source): A fast hex editor specially for HUGE files and disk devices, allows up to hexabyte, allow size changes (inject and deletes) without creating temp file, could view files with multiple panes, has built-in disassembler, supports tags for (reverse) engineering big binaries or file systems, could view files thrug XOR encryption.
:   <http://wxhexeditor.sourceforge.net/>

```{=html}
<!-- -->
```

HHD Software Hex Editor Neo : For Windows. A fast file, disk, and memory editor with built-in disassembler and file structure viewer.
:   <http://www.hhdsoftware.com/Family/hex-editor.html>

```{=html}
<!-- -->
```

Catch22 HexEdit : For Windows. his is a powerful hex editor with a slew of features. Has an excellent data structure viewer.
:   <http://www.catch22.net/software/hexedit.asp>

```{=html}
<!-- -->
```

BreakPoint Hex Workshop : For Windows. An excellent and powerful hex-editor, its usefulness is restricted by the fact that it is not free like some of the other options.
:   <http://www.bpsoft.com/>

```{=html}
<!-- -->
```

Tiny Hexer : Free and does statistics. For Windows.
:   <http://www.mirkes.de/files/>

```{=html}
<!-- -->
```

frhed - free hex editor : For Windows. Free and opensource.
:   <http://www.kibria.de/frhed.html>

```{=html}
<!-- -->
```

Cygnus Hex Editor: For Windows. A very fast and easy-to-use hex editor, available in a \'Free Edition\'.
:   <http://www.softcircuits.com/cygnus/fe/>

```{=html}
<!-- -->
```

Hexprobe Hex Editor : For Windows. A professional hex editor designed to include all the power to deal with hex data, particularly helpful in the areas of hex-byte editing and byte-pattern analysis.
:   <http://www.hexprobe.com/hexprobe/index.htm>

```{=html}
<!-- -->
```

UltraEdit32 : For Windows. A hex editor/text editor, won \"Application of the Year\" at 2005 Shareware Industry Awards Conference.
:   <http://www.ultraedit.com/>

```{=html}
<!-- -->
```

Hexinator (For Windows and Linux): lets you edit files of unlimited size (overwrite, insert, delete), displays text with dozens of text encodings, shows variables in little and big endian byte order.
:   <https://hexinator.com>

```{=html}
<!-- -->
```

ICY Hexplorer : For Windows. A lightweight free and open source hex file editor with some nifty features, such as pixel view, structures, and disassembling.
:   <http://hexplorer.sourceforge.net/>

```{=html}
<!-- -->
```

WinHex : For Windows. A powerful hex file and disk editor with advanced abilities for computer forensics and data recovery (used by governments and military).
:   <http://www.x-ways.net/index-m.html>

```{=html}
<!-- -->
```

010 Editor : For Windows. A very powerful and fast hex editor with extensive support for data structures and scripting. Can be used to edit drives and processes.
:   <http://www.sweetscape.com/010editor/>

!A view of a small binary file in a 1Fh hex
editor.{width="250"}

1Fh : For Windows. A free binary/hex editor which is very fast, even while working with large files. It\'s the only Windows hex editor that allows you to view files in byte code (all 256-characters).
:   <http://www.4neurons.com/1Fh/>

```{=html}
<!-- -->
```

HexEdit : For Windows (Open source) and shareware versions. Powerful and easy to use binary file and disk editor.
:   <http://www.hexedit.com/>

```{=html}
<!-- -->
```

HexToolkit : For Windows. A free hex viewer specifically designed for reverse engineering file formats. Allows data to be viewed in various formats and includes an expression evaluator as well as a binary file comparison tool.
:   <http://www.binaryearth.net/HexToolkit>

```{=html}
<!-- -->
```

FlexHex : For Windows. It Provides full support for NTFS files which are based on a more complex model than FAT32 files. Specifically, FlexHex supports Sparse files and Alternate data streams "wikilink") of files on any NTFS volume. Can be used to edit OLE compound files, flash cards, and other types of physical drives.
:   <http://www.heaventools.com/flexhex-hex-editor.htm>

```{=html}
<!-- -->
```

HT Editor : For Windows. A file editor/viewer/analyzer for executables. Its goal is to combine the low-level functionality of a debugger and the usability of IDEs.
:   <http://hte.sourceforge.net/>

```{=html}
<!-- -->
```

HexEdit : For MacOS. A simple but reliable hex editor wher you to change highlight colours. There is also a port for Apple Classic users.
:   <http://hexedit.sourceforge.net/>

```{=html}
<!-- -->
```

Hex Fiend : For MacOS. A very simple hex editor, but incredibly powerful nonetheless. It\'s only 346 KB to download and takes files as big as 116 GB.
:   <http://ridiculousfish.com/hexfiend/>

```{=html}
<!-- -->
```

ImHex : For Windows, MacOS and Linux. Displays, decodes and analyzes binary data (+ printable ASCII chars) and allow edition of bytes. Includes data inspector with various decoding (integers, floats, char/wchar, Unicode, dates, RGBA/RGB565 color\...), search by hex bytes and string, hex diff, pattern matching, yara rules (for malware pattern detection), hash computations, graphical data statistics, disassemblers, and various extra tools from a \"content store\". Free and open-source, licensed under GPLv2.
:   <https://imhex.werwolv.net/>

### Linux Hex Editors only

bvi: A typical three-pane hex editor, with a vi-like interface.

```{=html}
<!-- -->
```

emacs : Along with everything else, emacs also includes a hex editor.

```{=html}
<!-- -->
```

joe : Joe\'s own editor now also supports hex editing.

```{=html}
<!-- -->
```

bless : A very capable gtk based hex editor.

```{=html}
<!-- -->
```

xxd and any text editor : Produce a hex dump with xxd, freely edit it in your favorite text editor, and then convert it back to a binary file with your changes included.

```{=html}
<!-- -->
```

GHex : Hex editor for GNOME.
:   <http://directory.fsf.org/All_Packages_in_Directory/ghex.html>

```{=html}
<!-- -->
```

Okteta : The well-integrated hexeditor from KDE since 4.1. Offers the traditional two-columns layout, one with numeric values (binary, octal, decicmal, hexdecimal) and one with characters (lots of charsets supported). Editing can be done in both columns, with unlimited undo/redo. Small set of tools (searching/replacing, strings, binary filter, and more).
:   <http://utils.kde.org/projects/okteta>

```{=html}
<!-- -->
```

BEYE : A viewer of binary files with built-in editor in binary, hexadecimal and disassembler modes. It uses native Intel syntax for disassembly. Highlight AVR/Java/Athlon64/Pentium 4/K7-Athlon disassembler, Russian codepages converter, full preview of formats - MZ, NE, PE, NLM, coff32, elf partial - a.out, LE, LX, PharLap; code navigator and more over. (
:   <http://beye.sourceforge.net/en/beye.html>

```{=html}
<!-- -->
```

BIEW : A viewer of binary files with built-in editor in binary, hexadecimal and disassembler modes. It uses native Intel syntax for disassembly. Highlight AVR/Java/Athlon64/Pentium 4/K7-Athlon disassembler, Russian codepages converter, full preview of formats - MZ, NE, PE, NLM, coff32, elf partial - a.out, LE, LX, PharLap; code navigator and more over. (PROJECT RENAMED, see BEYE)
:   <http://biew.sourceforge.net/en/biew.html>

```{=html}
<!-- -->
```

hview : A curses based hex editor designed to work with large (600+MB) files with as quickly, and with little overhead, as possible.
:   <http://web.archive.org/web/20010306001713/http://tdistortion.esmartdesign.com/Zips/hview.tgz>

```{=html}
<!-- -->
```

HexCurse : An ncurses-based hex editor written in C that currently supports hex and decimal address output, jumping to specified file locations, searching, ASCII and EBCDIC output, bolded modifications, an undo command, quick keyboard shortcuts, etc.
:   <http://www.jewfish.net/description.php?title=HexCurse>

```{=html}
<!-- -->
```

hexedit : View and edit files in hexadecimal or in ASCII.
:   <http://rigaux.org/hexedit.html>

```{=html}
<!-- -->
```

Data Workshop : An editor to view and modify binary data; provides different views which can be used to edit, analyze and export the binary data.
:   <http://www.dataworkshop.de/>

```{=html}
<!-- -->
```

VCHE: A hex editor which lets you see all 256 characters as found in video ROM, even control and extended ASCII, it uses the /dev/vcsa\* devices to do it. It also could edit non-regular files, like hard disks, floppies, CDROMs, ZIPs, RAM, and almost any device. It comes with a ncurses and a raw version for people who work under X or remotely.
:   <http://www.grigna.com/diego/linux/vche/>

```{=html}
<!-- -->
```

DHEX: DHEX is just another Hexeditor with a Diff-mode for ncurses. It makes heavy use of colors and is themeable.
:   <http://www.dettus.net/dhex/>

{{-}}

## Other Tools for Windows

### Resource Monitors

SysInternals Freeware : This page has a large number of excellent utilities, many of which are very useful to security experts, network administrators, and (most importantly to us) reversers. Specifically, check out **Process Monitor**, **FileMon**, **RegMon**, **TCPView**, and **Process Explorer**.
:   <https://docs.microsoft.com/en-us/sysinternals/>

### API Monitors

SpyStudio Freeware : The Spy Studio software is a tool to hook into windows processes, log windows API call to DLLs, insert breakpoints and change parameters.
:   <http://www.nektra.com/products/spystudio/>

```{=html}
<!-- -->
```

rohitab.com API Monitor : API Monitor is a free software that lets you monitor and control API calls made by applications and services. Features include detailed parameter information, structures, unions, enumerated/flag data types, call stack, call tree, breakpoints, custom DLLs, memory editor, call filtering, COM monitoring, 64-bit. Includes definitions for over 13,000 APIs and 1,300+ COM interfaces.
:   <http://www.rohitab.com/apimonitor>

### PE File Header dumpers

Dumpbin : Dumpbin is a program that previously used to be shipped with MS Visual Studio, but recently the functionality of Dumpbin has been incorporated into the Microsoft Linker, link.exe. to access dumpbin, pass /dump as the first parameter to link.exe:

`link.exe /dump [options]`

:   It is frequently useful to simply create a batch file that handles
    this conversion:

`::dumpbin.bat`\
`link.exe /dump %*`

**All examples in this wikibook that use dumpbin will call it in this
manner.**

:   Here is a list of useful features of dumpbin
    1:

`dumpbin /EXPORTS         displays a list of functions exported from a library`\
`dumpbin /IMPORTS         displays a list of functions imported from other libraries`\
`dumpbin /HEADERS         displays PE header information for the executable`

:   <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_dumpbin_reference.asp>

```{=html}
<!-- -->
```

Depends : Dependency Walker is a GUI tool which will allow you to see exports and imports of binaries. It ships with many Microsoft tools including MS Visual Studio.

## GNU Tools

The GNU packages have been ported to many platforms including Windows.

GNU BinUtils : The GNU BinUtils package contains several small utilities that are very useful in dealing with binary files. The most important programs in the list are the GNU objdump, readelf, GAS assembler, and the GNU linker, although the reverser might find more use in addr2line, c++filt, nm, and readelf.
:   <http://www.gnu.org/software/binutils/>

```{=html}
<!-- -->
```

objdump : Dumps out information about an executable including symbols and assembly. It comes standard. It can be made to support non-native binary formats.

`objdump -p               displays a list of functions imported from other libraries, exported to and miscellaneous file header information`

It\'s useful to check dll dependencies from command line

readelf : Like *objdump* but more specialized for ELF executables.

```{=html}
<!-- -->
```

size : Lists the sizes of the segments.

```{=html}
<!-- -->
```

nm : Lists the symbols in an ELF file.

```{=html}
<!-- -->
```

strings : Prints the strings from a file.

```{=html}
<!-- -->
```

file : Tells you what type of file it is.

```{=html}
<!-- -->
```

fold : Folds the results of *strings* into something pageable.

```{=html}
<!-- -->
```

kill : Can be used to halt a program with the sig_stop signal.

```{=html}
<!-- -->
```

strace : Trace system calls and signals.

## Other Tools for Linux

oprofile : Can be used the find out what functions and data segments are used

```{=html}
<!-- -->
```

subterfugue : A tool for playing odd tricks on an executable as it runs. The tool is scriptable in python. The user can write scripts to take action on events that occur, such as changing the arguments to system calls.
:   <http://subterfugue.org/>

```{=html}
<!-- -->
```

lizard : Lets you run a program *backwards*.
:   <http://lizard.sourceforge.net/>

```{=html}
<!-- -->
```

dprobes : Lets you work with both kernel and user code.

```{=html}
<!-- -->
```

biew : Both a hex editor and a disassembler.

```{=html}
<!-- -->
```

ltrace : Displays runtime library call information for dynamically linked executables.

```{=html}
<!-- -->
```

asmDIFF : Searches for functions, instructions and memory pointers in different versions of same binary by using code metrics. Supports x86, x86_64 code in PE and ELF files.
:   <http://duschkumpane.org/index.php/asmdiff>

## XCode Tools

XCode contains some extra tools to be used under
OS X with the Mach-O format. You can see more of them under
`/Applications/Xcode.app/Contents/Developer/usr/bin/`.

lipo: Manages fat binaries with multiple architectures.

```{=html}
<!-- -->
```

otool: *Object file displaying tool*, works somehow like objdump and readelf.

XCode also packs a lot of Unix tools, with many of them sharing the
names (and functions) of the GNU tools. Other tools like nasm/ndisasm,
lldb and GNU as can also be found.


# X86 Disassembly/Microsoft Windows

## Microsoft Windows

The **Windows operating system** is a popular reverse engineering target
for one simple reason: the OS itself (market share, known weaknesses),
and most applications for it, are not Open Source or free. Most software
on a Windows machine doesn\'t come bundled with its source code, and
most pieces have inadequate, or non-existent documentation.
Occasionally, the only way to know precisely what a piece of software
does (or for that matter, to determine whether a given piece of software
is malicious or legitimate) is to reverse it, and examine the results.

## Windows Versions

Windows operating systems can be easily divided into 2 categories:
Windows9x, and WindowsNT.

### Windows 9x

The Windows9x kernel was originally written to span the 16bit - 32bit
divide. Operating Systems based on the 9x kernel are Windows 95, Windows
96, Windows 98, and Windows Me. Windows9x Series operating systems are
known to be prone to bugs and system instability. The actual OS itself
was a 32 bit extension of MS-DOS, its predecessor. An important issue
with the 9x line is that they were all based around using the ANSI
format for storing strings, rather than Unicode.

Development on the Windows9x kernel ended with the release of Windows
Me.

### Windows NT

The WindowsNT kernel series was originally written as enterprise-level
server and network software. WindowsNT stresses stability and security
far more than Windows9x kernels did (although it can be debated whether
that stress was good enough). It also handles all string operations
internally in Unicode, giving more flexibility when using different
languages. Operating systems based on the WindowsNT kernel are: Windows
NT (versions 3.1, 3.11, 3.2, 3.5, 3.51 and 4.0), Windows 2000 (NT 5.0),
Windows XP (NT 5.1), Windows Server 2003 (NT 5.2), Windows Vista (NT
6.0), Windows 7 (NT 6.1), Windows 7.1 (NT 6.11), Windows 8 (NT 6.2),
Windows 8.1 (NT 6.3), and Windows 10 (NT 10.0).

The Microsoft Xbox and Xbox 360 also run a variant of NT, forked from
Windows 2000. Most future Microsoft operating system products are based
on NT in some shape or form.

## Virtual Memory

Memory is organized into \"pages\" that are 4096 bytes by default. Pages
not in current use by the system or any of the applications may be
written to a special section on the hard disk known as the \"paging
file.\" Use of the paging file may increase performance on some systems,
although high latency for I/O to the HDD can actually reduce performance
in some instances.

32-bit Windows NT allows for a maximum of 4 GiB of virtual memory
address space per process. This is divided into 2 GiB user memory and 2
GiB kernel memory by default.

In some 32-bit versions and editions, the operating system can be
started with the /3GB switch which divides this into 3 GiB user memory
and 1 GiB kernel memory. Only 32-bit applications that are compiled with
the large memory flag can use up to 3 GiB in this mode. The /3GB switch
is not supported in 64-bit Windows, but 32-bit applications with the
large memory flag can access up to 4 GiB on 64-bit Windows. 64-bit
applications are not restricted in this way.

Starting with the Pentium Pro CPU some 32-bit versions and editions can
use Physical Address Extensions (the /PAE switch) to access memory above
4 GiB up to 64 GiB. This memory can be accessed by 32-bit applications
that support PAE (i.e. some versions of 32-bit Microsoft SQL Server and
32-bit Microsoft Exchange Server). Special configuration is required,
however.

## System Architecture

The Windows architecture is heavily layered. Function calls that a
programmer makes may be redirected 3 times or more before any action is
actually performed. There is an unignorable penalty for calling Win32
functions from a user-mode application. However, the upside is equally
unignorable: code written in higher levels of the windows system is much
easier to write. Complex operations that involve initializing multiple
data structures and calling multiple sub-functions can be performed by
calling only a single higher-level function.

The Win32 API comprises 3 modules: KERNEL32, USER32, and GDI32. KERNEL32
is layered on top of NTDLL, and most calls to KERNEL32 functions are
simply redirected into NTDLL function calls. USER32 and GDI32 are both
based on WIN32K (a kernel-mode module, responsible for the Windows
\"look and feel\"), although USER32 also makes many calls to the
more-primitive functions in GDI32. This and NTDLL both provide an
interface to the Windows NT kernel, NTOSKRNL (see further below).

NTOSKRNL is also partially layered on HAL (Hardware Abstraction Layer),
but this interaction will not be considered much in this book. The
purpose of this layering is to allow processor variant issues (such as
location of resources) to be made separate from the actual kernel
itself. A slightly different system configuration thus requires just a
different HAL module, rather than a completely different kernel module.

## System calls and interrupts

After filtering through different layers of subroutines, most API calls
require interaction with part of the operating system. Services are
provided via \'software interrupts\', traditionally through the \"int
0x2e\" instruction. This switches control of execution to the NT
executive / kernel, where the request is handled. It should be pointed
out here that the stack used in kernel mode is different from the user
mode stack. This provides an added layer of protection between kernel
and user. Once the function completes, control is returned back to the
user application.

Both Intel and AMD provide an extra set of instructions to allow faster
system calls, the \"SYSENTER\" instruction from Intel and the SYSCALL
instruction from AMD.

## Win32 API

Both WinNT and Win9x systems utilize the Win32 API. However, the WinNT
version of the API has more functionality and security constructs, as
well as Unicode support. Most of the Win32 API can be broken down into 3
separate components, each performing a separate task.

### kernel32.dll

Kernel32.dll, home of the KERNEL subsystem, is where non-graphical
functions are implemented. Some of the APIs located in KERNEL are: The
Heap API, the Virtual Memory API, File I/O API, the Thread API, the
System Object Manager, and other similar system services. Most of the
functionality of kernel32.dll is implemented in ntdll.dll, but in
undocumented functions. Microsoft prefers to publish documentation for
kernel32 and guarantee that these APIs will remain unchanged, and then
put most of the work in other libraries, which are then not documented.

### gdi32.dll

gdi32.dll is the library that implements the GDI subsystem, where
primitive graphical operations are performed. GDI diverts most of its
calls into WIN32K, but it does contain a manager for GDI objects, such
as pens, brushes and device contexts. The GDI object manager and the
KERNEL object manager are completely separate.

### user32.dll

The USER subsystem is located in the user32.dll library file. This
subsystem controls the creation and manipulation of USER objects, which
are common screen items such as windows, menus, cursors, etc\... USER
will set up the objects to be drawn, but will perform the actual drawing
by calling on GDI (which in turn will make many calls to WIN32K) or
sometimes even calling WIN32K directly. USER utilizes the GDI Object
Manager.

## Native API

The native API, hereby referred to as the NTDLL subsystem, is a series
of undocumented API function calls that handle most of the work
performed by KERNEL32. Microsoft also does not guarantee that the native
API will remain the same between different versions, as Windows
developers modify the software. This gives the risk of native API calls
being removed or changed without warning, breaking software that
utilizes it.

### ntdll.dll

The NTDLL subsystem is located in ntdll.dll. This library contains many
API function calls, that all follow a particular naming scheme. Each
function has a prefix: Ldr, Nt, Zw, Csr, Dbg, etc\... and all the
functions that have a particular prefix all follow particular rules.

The \"official\" native API is usually limited only to functions whose
prefix is Nt or Zw. These calls are in fact the same in user-mode: the
relevant Export
entries map to the same
address in memory. However, in kernel-mode, the Zw\* system call stubs
set the *previous mode* to kernel-mode, ensuring that certain parameter
validation routines are *not* performed. The origin of the prefix \"Zw\"
is unknown; this prefix was chosen due to its having no significance at
all[^1].

In actual implementation, the system call stubs merely load two
registers with values required to describe a native API call, and then
execute a software interrupt (or the `sysenter` instruction).

Most of the other prefixes are obscure, but the known ones are:

-   Rtl stands for \"Run Time Library\", calls which help functionality
    at runtime (such as RtlAllocateHeap)
-   Csr is for \"Client Server Runtime\", which represents the interface
    to the win32 subsystem located in csrss.exe
-   Dbg functions are present to enable debugging routines and
    operations
-   Ldr provides the ability to load, manipulate and retrieve data from
    DLLs and other module resources

### User Mode Versus Kernel Mode

Many functions, especially Run-time Library routines, are shared between
ntdll.dll and ntoskrnl.exe. Most Native API functions, as well as other
kernel-mode only functions exported from the kernel are useful for
driver writers. As such, Microsoft provides documentation on many of the
native API functions with the Microsoft Server 2003 Platform DDK. The
DDK (Driver Development Kit) is available as a free download.

## ntoskrnl.exe

This module is the Windows NT \"\'Executive\'\", providing all the
functionality required by the native API, as well as the kernel itself,
which is responsible for maintaining the machine state. By default, all
interrupts and kernel calls are channeled through ntoskrnl in some way,
making it the single most important program in Windows itself. Many of
its functions are exported (all of which with various prefixes, a la
NTDLL) for use by device drivers.

## Win32K.sys

This module is the \"Win32 Kernel\" that sits on top of the lower-level,
more primitive NTOSKRNL. WIN32K is responsible for the \"look and feel\"
of windows, and many portions of this code have remained largely
unchanged since the Win9x versions. This module provides many of the
specific instructions that cause USER and GDI to act the way they do.
It\'s responsible for translating the API calls from the USER and GDI
libraries into the pictures you see on the monitor.

## Win64 API

With the advent of 64-bit processors, 64-bit software is a necessity. As
a result, the Win64 API was created to utilize the new hardware. It is
important to note that the format of many of the function calls are
identical in Win32 and Win64, except for the size of pointers, and other
data types that are specific to 64-bit address space.

## Windows Vista

Microsoft has released a new version of its Windows operation system,
named \"Windows Vista.\" Windows Vista may be better known by its
development code-name \"Longhorn.\" Microsoft claims that Vista has been
written largely from the ground up, and therefore it can be assumed that
there are fundamental differences between the Vista API and system
architecture, and the APIs and architectures of previous Windows
versions. Windows Vista was released January 30th, 2007.

## Windows CE/Mobile, and other versions

Windows CE is the Microsoft offering on small devices. It largely uses
the same Win32 API as the desktop systems, although it has a slightly
different architecture. Some examples in this book may consider
WindowsCE.

## \"Non-Executable Memory\"

Recent windows service packs have attempted to implement a system known
as \"Non-executable memory\" where certain pages can be marked as being
\"non-executable\". The purpose of this system is to prevent some of the
most common security holes by not allowing control to pass to code
inserted into a memory buffer by an attacker. For instance, a shellcode
loaded into an overflowed text buffer cannot be executed, stopping the
attack in its tracks. The effectiveness of this mechanism is yet to be
seen, however.

## COM and Related Technologies

COM, and a whole slew of technologies that are either related to COM or
are actually COM with a fancy name, is another factor to consider when
reversing Windows binaries. COM, DCOM, COM+, ActiveX, OLE, MTS, and
Windows DNA are all names for the same subject, or subjects, so similar
that they may all be considered under the same heading. In short, COM is
a method to export Object-Oriented Classes in a uniform,
*cross-platform* and *cross-language* manner. In essence, COM is .NET,
version 0 beta. Using COM, components written in many languages can
export, import, instantiate, modify, and destroy objects defined in
another file, most often a DLL. Although COM provides cross-platform (to
some extent) and cross-language facilities, each COM object is compiled
to a native binary, rather than an intermediate format such as Java or
.NET. As a result, COM does not require a virtual machine to execute
such objects.

Due to the way that COM works, a lot of the methods and data structures
exported by a COM component are difficult to perceive by simply
inspecting the executable file. Matters are made worse if the creating
programmer has used a library such as
ATL to simplify
their programming experience. Unfortunately for a reverse engineer, this
reduces the contents of an executable into a \"Sea of bits\", with
pointers and data structures everywhere.

## Remote Procedure Calls (RPC)

RPC is a generic term referring to techniques that allow a program
running on one machine to make calls that actually execute on another
machine. Typically, this is done by *marshalling* all of the data needed
for the procedure including any state information stored on the first
machine, and building it into a single data structure, which is then
transmitted over some communications method to a second machine. This
second machine then performs the requested action, and returns a data
packet containing any results and potentially changed state information
to the originating machine.

In Windows NT, RPC is typically handled by having two libraries that are
similarly named, one which generates RPC requests and accepts RPC
returns, as requested by a user-mode program, and one which responds to
RPC requests and returns results via RPC. A classic example is the print
spooler, which consists of two pieces: the RPC stub spoolss.dll, and the
spooler proper and RPC service provider, spoolsv.exe. In most machines,
which are stand-alone, it would seem that the use of two modules
communicating by means of RPC is overkill; why not simply roll them into
a single routine? In networked printing, though, this makes sense, as
the RPC service provider can be resident physically on a distant
machine, with the remote printer, and the local machine can control the
printer on the remote machine in exactly the same way that it controls
printers on the local machine.

[^1]: <https://msdn.microsoft.com/en-us/library/windows/hardware/ff565646(v=vs.85>).aspx


# X86 Disassembly/Linux

## GNU/Linux

The **GNU/Linux operating system** is open source, but at the same time
there is so much that constitutes \"GNU/Linux\" that it can be difficult
to stay on top of all aspects of the system. Here we will attempt to
boil down some of the most important concepts of the GNU/Linux Operating
System, especially from a reverser\'s standpoint

## System Architecture

The concept of \"GNU/Linux\" is mostly a collection of a large number of
software components that are based on the GNU tools and the Linux
kernel. GNU/Linux is itself broken into a number of variants called
\"distros\" which share some similarities, but may also have distinct
peculiarities. In a general sense, all GNU/Linux distros are based on a
variant of the Linux kernel. However, since each user may edit and
recompile their own kernel at will, and since some distros may make
certain edits to their kernels, it is hard to proclaim any one version
of any one kernel as \"the standard\". Linux kernels are generally based
on the philosophy that system configuration details should be stored in
aptly-named, human-readable (and therefore human-editable) configuration
files.

The Linux kernel implements much of the core API, but certainly not all
of it. Much API code is stored in external modules (although users have
the option of compiling all these modules together into a \"Monolithic
Kernel\").

On top of the kernel generally runs one or more **shells**. Bash is one
of the more popular shells, but many users prefer other shells,
especially for different tasks.

Beyond the shell, Linux distros frequently offer a GUI (although many
distros do not have a GUI at all, usually for performance reasons).

Since each GUI often supplies its own underlying framework and API,
certain graphical applications may run on only one GUI. Some
applications may need to be recompiled (and a few completely rewritten)
to run on another GUI.

## Configuration Files

## Shells

Here are some popular shells:

Bash : An acronym for \"Bourne Again SHell.\"

```{=html}
<!-- -->
```

Bourne : A precursor to Bash.

```{=html}
<!-- -->
```

Csh : C Shell

```{=html}
<!-- -->
```

Ksh : Korn Shell

```{=html}
<!-- -->
```

TCsh : A Terminal oriented Csh.

```{=html}
<!-- -->
```

Zsh : Z Shell

## Desktop Environments

Some of the more popular desktop environments:

GNOME : GNU Network Object Modeling Environment

```{=html}
<!-- -->
```

KDE : K Desktop Environment

## Debuggers

gdb : The  GNU Debugger. It is available on most Linux distributions, and is primarily used to debug ELF executables. manpage

```{=html}
<!-- -->
```

winedbg : A debugger for Wine "wikilink"), used to debug Windows executables under Linux. manpage

```{=html}
<!-- -->
```

edb : A fully featured plugin-based debugger inspired by the famous OllyDbg. Project page

## File Analyzers

strings : Finds printable strings in a file. When, for example, a password is stored in the binary itself (defined statically in the source), the string can then be extracted from the binary without ever needing to execute it. manpage)

```{=html}
<!-- -->
```

file : Determines a file type, useful for determining whether an executable has been stripped and whether it\'s been dynamically (or statically) linked. manpage)

```{=html}
<!-- -->
```

objdump : Disassembles object files, executables and libraries. Can list internal file structure and disassemble specific sections. Supports both Intel and AT&T syntax

```{=html}
<!-- -->
```

nm : Lists symbols from executable files. Doesn\'t work on stripped binaries. Used mostly on debugging version of executables.


# X86 Disassembly/Linux Executable Files

## ELF Files

The **ELF file format** (short for Executable and Linking Format) was
developed by Unix System Laboratories to be a successor to previous file
formats such as COFF and a.out. In many respects, the ELF format is more
powerful and versatile than previous formats, and has widely become the
standard on Linux, Solaris, IRIX, and FreeBSD (although the
FreeBSD-derived Mac OS X uses the Mach-O format instead). ELF has also
been adopted by OpenVMS for Itanium and BeOS for x86.

Historically, Linux has not always used ELF; Red Hat Linux 4 was the
first time that distribution used ELF; previous versions had used the
a.out format.

ELF Objects are broken down into different segments and/or sections.
These can be located by using the ELF header found at the first byte of
the object. The ELF header provides the location for both the program
header and the section header. Using these data structures the rest of
the ELF objects contents can be found, this includes .text and .data
segments which contain code and data respectively.

The GNU readelf utility, from the binutils package, is a common tool for
parsing ELF objects.

### File Format

!An ELF file has two views: the program header shows the *segments*
used at run-time, while the section header lists the set of *sections*
of the
binary.{width="200"}

Each ELF file is made up of one ELF header, followed by file data. The
file data can include:

-   Program header table, describing zero or more segments
-   Section header table, describing zero or more sections
-   Data referred to by entries in the program or section header table

The segments contain information that is necessary for runtime execution
of the file, while sections contain important data for linking and
relocation. Each byte in the entire file is taken by no more than one
section at a time, but there can be orphan bytes, which are not covered
by a section. In the normal case of a Unix executable one or more
sections are enclosed in one segment.

{{-}}

## Relocatable ELF Files

Relocatable ELF files are created by compilers. They need to be linked
before running.

Those files are often found in `.a` archives, with a `.o` extension.

## a.out Files

a.out is a very simple format consisting of a
header (at offset 0) which contains the size of 3 executable sections
(code, data, bss), plus pointers to additional information such as
relocations (for .o files), symbols and symbols\' strings. The actual
sections contents follows the header. Offsets of different sections are
computed from the size of the previous section.

The a.out format is now rarely used.

### File Format


# X86 Disassembly/Mac OS X

## Mach-O format overview

MacOS (Previously OS X) uses the Mach-O file format to encode
executables, object files, and shared libraries (.dylib files). Here, we
will be looking at the 64-bit version of the Mach-O format. The majority
of data in Mach-O files are \'segments\' and \'sections\', where
Segments are containers for Sections, and store information about each
Section. The Sections themselves are containers for data. Mach-O files
have five primary structures:

  **Structure**   Description
  --------------- ----------------------------------------------------------------------------
  Header          Contains information about the purpose, and size of the file\'s structures
  Load Commands   Declaration of all Segments and Sections
  Data            The actual contents of the file (e.g. Data section, Text section).
  Symbol table    Says where each symbol is located in the file
  String table    Contains the name of each symbol

Note that when each Structure is gone over, they are all an unbroken
sequence of bytes, and there is no empty space between them.

## Header

### Information

The header is the very first thing in the file, and it has 8 unsigned
32-bit integers:

  Name                      Purpose                                                            Endianness      Typical Value
  ------------------------- ------------------------------------------------------------------ --------------- -------------------------------------------------------
  Magic Number              The File\'s magic number                                           Big-Endian      0xFEEDFACF for 64-bit architecture
  CPU Type                  The Intended CPU type for the executable                           Little-Endian   0x01000007 for x86_64
  CPU subtype               The specific kind of CPU used                                      Little-Endian   0x00000003 for all x64 CPUs
  File type                 The purpose of the file                                            Little-Endian   0x00000001 for object file, 0x00000002 for executable
  Number of Load Commands   The quantity of Load commands (does not include section headers)   Little-Endian   Variable
  Size of Load Commands     The number of bytes occupied by the Load Commands                  Little-Endian   Variable
  Flags                     Extra file information                                             Little-Endian   0x00000000
  Reserved                  No practical use                                                   Little-Endian   0x00000000


# X86 Disassembly/The Stack

## The Stack

![](Data_stack.svg "Data_stack.svg") Generally speaking, a **stack** is
a data structure that stores data values contiguously in memory. Unlike
an array, however, you access (read or write) data only at the \"top\"
of the stack. To read from the stack is said \"**to pop**\" and to write
to the stack is said \"**to push**\". A stack is also known as a LIFO
queue (Last In First Out) since values are popped from the stack in *the
reverse order* that they are pushed onto it (think of how you pile up
plates on a table). Popped data disappears from the stack.

All x86 architectures use a stack as a temporary storage area in RAM
that allows the processor to quickly store and retrieve data in memory.
The current top of the stack is pointed to by the **esp** register. The
stack \"grows\" downward, from high to low memory addresses, so values
recently pushed onto the stack are located in memory addresses *above*
the esp pointer. No register specifically points to the bottom of the
stack, although most operating systems monitor the stack bounds to
detect both \"underflow\" (popping an empty stack) and \"overflow\"
(pushing too much information on the stack) conditions.

When a value is popped off the stack, the value remains sitting in
memory until overwritten. However, you should never rely on the content
of memory addresses below esp, because other functions may overwrite
these values without your knowledge.

Users of Windows ME, 98, 95, 3.1 (and earlier) may fondly remember the
infamous \"Blue Screen of Death\" \-- that was sometimes caused by a
stack overflow exception. This occurs when too much data is written to
the stack, and the stack \"grows\" beyond its limits. Modern operating
systems use better bounds-checking and error recovery to reduce the
occurrence of stack overflows, and to maintain system stability after
one has occurred.

## Push and Pop

The following lines of ASM code are basically equivalent:

```{=html}
<center>
```
+----------+-----------------------------+
| ``` asm  | ``` asm                     |
| push eax | sub esp, 4                  |
| ```      | mov DWORD PTR SS:[esp], eax |
|          | ```                         |
+----------+-----------------------------+
| ``` asm  | ``` asm                     |
| pop eax  | mov eax, DWORD PTR SS:[esp] |
| ```      | add esp, 4                  |
|          | ```                         |
+----------+-----------------------------+

```{=html}
</center>
```
but the single command actually performs much faster than the
alternative. It can be visualized that the stack grows from right to
left, and esp decreases as the stack grows in size.

```{=html}
<center>
```
  Push                                                           Pop
  -------------------------------------------------------------- ------------------------------------------------------------
  ![](ReverseEngineeringPush.JPG "ReverseEngineeringPush.JPG")   ![](ReverseEngineeringPop.JPG "ReverseEngineeringPop.JPG")

```{=html}
</center>
```
## ESP In Action

Let\'s say we want to quickly discard 3 items we pushed earlier onto the
stack, without saving the values (in other words \"clean\" the stack).
The following works (note that it overwrites the **eax** register):
{{-}}

``` asm
pop eax
pop eax
pop eax
```

However there is a faster method, that also does not affect any register
but the stack pointer. We can simply perform some basic arithmetic on
esp to make the pointer go \"above\" the data items, so they cannot be
read anymore, and can be overwritten with the next round of **push**
commands.

``` asm
add esp, 12  ; 12 is 3 DWORDs (4 bytes * 3)
```

Likewise, if we want to reserve room on the stack for an item bigger
than a DWORD, we can use a subtraction to artificially move esp forward.
We can then access our reserved memory directly as a memory pointer, or
we can access it indirectly as an offset value from esp itself.

Say we wanted to create an array of byte values on the stack, 100 items
long. We want to store the pointer to the base of this array in **edi**.
How do we do it? Here is an example:

``` asm
sub esp, 100  ; num of bytes in our array
mov edi, esp  ; copy address of 100 bytes area to edi
```

To destroy that array, we simply write the instruction

``` asm
add esp, 100
```

## Reading Without Popping

To read values on the stack without popping them off the stack, **esp**
can be used with an offset. For instance, to read the 3 DWORD values
from the top of the stack into eax (but without using a pop
instruction), we would use the instructions:

``` asm
mov eax, DWORD PTR SS:[esp]
mov eax, DWORD PTR SS:[esp + 4]
mov eax, DWORD PTR SS:[esp + 8]
```

Remember, since esp moves downward as the stack grows, data on the stack
can be accessed with a positive offset. A negative offset should never
be used because data \"above\" the stack cannot be counted on to stay
the way you left it. The operation of reading from the stack without
popping is often referred to as \"peeking\", but since this isn\'t the
official term for it this wikibook won\'t use it.

## Data Allocation

There are two areas in the computer memory where a program can store
data. The first, the one that we have been talking about, is the stack.
It is a linear LIFO buffer that allows fast allocations and
deallocations, but has a limited size. The **heap** is typically a
non-linear data storage area, typically implemented using linked lists,
binary trees, or other more exotic methods. Heaps are slightly more
difficult to interface with and to maintain than a stack, and
allocations/deallocations are performed more slowly. However, heaps can
grow as the data grows, and new heaps can be allocated when data
quantities become too large.

As we shall see, explicitly declared variables are allocated on the
stack. Stack variables are finite in number, and have a definite size.
Heap variables can be variable in number and in size. We will discuss
these topics in more detail later.


# X86 Disassembly/Functions and Stack Frames

## Functions and Stack Frames

In the execution environment, functions are frequently set up with a
\"**stack frame**\" to allow access to both function parameters, and
automatic local function variables. The idea behind a stack frame is
that each subroutine can act independently of its location on the stack,
and each subroutine can act as if it is the top of the stack.

When a function is called, a new stack frame is created at the current
**esp** location. A stack frame acts like a partition on the stack. All
items from previous functions are higher up on the stack, and should not
be modified. Each current function has access to the remainder of the
stack, from the stack frame until the end of the stack page. The current
function always has access to the \"top\" of the stack, and so functions
do not need to take account of the memory usage of other functions or
programs.

## Standard Entry Sequence

For many compilers, the standard function entry sequence is the
following piece of code (*X* is the total size, in bytes, of all
*automatic* local variables used in the function):

``` asm
push ebp
mov ebp, esp
sub esp, X
```

For example, here is a C function code fragment and the resulting
assembly instructions (the code generated with ABI standards won\'t have
\"sub esp, 12\" instruction due to red zones):

``` C
void MyFunction()
{
  int a, b, c;
  ...
```

``` asm
_MyFunction:
  push ebp     ; save the value of ebp
  mov ebp, esp ; ebp now points to the top of the stack
  sub esp, 12  ; space allocated on the stack for the local variables
```

This means local variables can be accessed by referencing ebp. Consider
the following C code fragment and corresponding assembly code:

``` C
a = 10;
b = 5;
c = 2;
```

``` asm
mov [ebp -  4], 10  ; location of variable a
mov [ebp -  8], 5   ; location of b
mov [ebp - 12], 2   ; location of c
```

This all seems well and good, but what is the purpose of **ebp** in this
setup? Why save the old value of ebp and then point ebp to the top of
the stack, only to change the value of esp with the next instruction?
The answer is *function parameters*.

Consider the following C function declaration:

``` C
void MyFunction2(int x, int y, int z)
{
  ...
}
```

It produces the following assembly code:

``` asm
_MyFunction2:
  push ebp
  mov ebp, esp
  sub esp, 0     ; no local variables, most compilers will omit this line
```

Which is exactly as one would expect. So, what exactly does **ebp** do,
and where are the function parameters stored? The answer is found when
we call the function.

Consider the following C function call:

``` C
MyFunction2(10, 5, 2);
```

This will create the following assembly code (using a Right-to-Left
calling convention called CDECL, explained later):

``` asm
push 2
push 5
push 10
call _MyFunction2
```

**Note:** Remember that the **call** x86 instruction is basically
equivalent to

``` asm
push eip + 2 ; return address is current address + size of two instructions
jmp _MyFunction2
```

It turns out that the function arguments are all passed on the stack!
Therefore, when we move the current value of the stack pointer (**esp**)
into **ebp**, we are pointing ebp directly at the function arguments. As
the function code pushes and pops values, ebp is not affected by esp.
Remember that pushing basically does this:

``` asm
sub esp, 4   ; "allocate" space for the new stack item
mov [esp], X ; put new stack item value X in
```

This means that first the return address and then the old value of
**ebp** are put on the stack. Therefore \[ebp\] points to the location
of the old value of ebp, \[ebp + 4\] points to the return address, and
\[ebp + 8\] points to the first function argument. Here is a (crude)
representation of the stack at this point:

`:    : `\
`|  2 | [ebp + 16] (3rd function argument)`\
`|  5 | [ebp + 12] (2nd argument)`\
`| 10 | [ebp + 8]  (1st argument)`\
`| RA | [ebp + 4]  (return address)`\
`| FP | [ebp]      (old ebp value)`\
`|    | [ebp - 4]  (1st local variable)`\
`:    :`\
`:    :`\
`|    | [ebp - X]  (esp - the current stack pointer. The use of push / pop is valid now)`

The stack pointer value may change during the execution of the current
function. In particular this happens when:

-   parameters are passed to another function;
-   the pseudo-function \"alloca()\" is used.

\[FIXME: When parameters are passed into another function the esp
changing is not an issue. When that function returns the esp will be
back to its old value. So why does ebp help there. This needs better
explanation. (The real explanation is here, ESP is not really needed:
<https://learn.microsoft.com/en-us/archive/blogs/larryosterman/fpo>)\]
This means that the value of **esp** cannot be reliably used to
determine (using the appropriate offset) the memory location of a
specific local variable. To solve this problem, many compilers access
local variables using negative offsets from the **ebp** registers. This
allows us to assume that the same offset is always used to access the
same variable (or parameter). For this reason, the ebp register is
called the **frame pointer**, or FP.

## Standard Exit Sequence

The Standard Exit Sequence must undo the things that the Standard Entry
Sequence does. To this effect, the Standard Exit Sequence must perform
the following tasks, in the following order:

1.  Remove space for local variables, by reverting **esp** to its old
    value.
2.  Restore the old value of **ebp** to its old value, which is on top
    of the stack.
3.  Return to the calling function with a *ret* command.

As an example, the following C code:

``` C
void MyFunction3(int x, int y, int z)
{
  int a, b, c;
  ...
  return;
}
```

Will create the following assembly code:

``` asm
_MyFunction3:
  push ebp
  mov ebp, esp
  sub esp, 12 ; sizeof(a) + sizeof(b) + sizeof(c)
  ;x = [ebp + 8], y = [ebp + 12], z = [ebp + 16]
  ;a = [ebp - 4] = [esp + 8], b = [ebp - 8] = [esp + 4], c = [ebp - 12] = [esp]
  mov esp, ebp
  pop ebp
  ret 12 ; sizeof(x) + sizeof(y) + sizeof(z)
```

## Non-Standard Stack Frames

Frequently, reversers will come across a subroutine that doesn\'t set up
a standard stack frame. Here are some things to consider when looking at
a subroutine that does not start with a standard sequence:

### Using Uninitialized Registers

When a subroutine starts using data in an *uninitialized* register, that
means that the subroutine expects external functions to put data into
that register before it gets called. Some calling conventions pass
arguments in registers, but sometimes a compiler will not use a standard
calling convention.

### \"static\" Functions

In C, functions may optionally be declared with the **static** keyword,
as such:

``` C
static void MyFunction4();
```

The **static** keyword causes a function to have only local scope,
meaning it may not be accessed by any external functions (it is strictly
internal to the given code file). When an optimizing compiler sees a
static function that is only referenced by calls (no references through
function pointers), it \"knows\" that external functions cannot possibly
interface with the static function (the compiler controls all access to
the function), so the compiler doesn\'t bother making it standard.

### Hot Patch Prologue

Some Windows functions set up a regular stack frame as explained above,
but start out with the apparently non-sensical line

``` asm
mov edi, edi;
```

This instruction is assembled into 2 bytes which serve as a placeholder
for future function patches. Taken as a whole such a function might look
like this:

``` asm
nop               ; each nop is 1 byte long
nop
nop
nop
nop

FUNCTION:         ; <-- This is the function entry point as used by call instructions
mov edi, edi      ; mov edi,edi is 2 bytes long
push ebp          ; regular stack frame setup
mov ebp, esp
```

If such a function needs to be replaced without reloading the
application (or restarting the machine in case of kernel patches) it can
be achieved by inserting a jump to the replacement function. A short
jump instruction (which can jump +/- 127 bytes) requires 2 bytes of
storage space - just the amount that the \"mov edi,edi\" placeholder
provides. A jump to any memory location, in this case to our replacement
function, requires 5 bytes. These are provided by the 5 no-operation
bytes just preceding the function. If a function thus patched gets
called it will first jump back by 5 bytes and then do a long jump to the
replacement function. After the patch the memory might look like this

``` asm
LABEL:
jmp REPLACEMENT_FUNCTION ; <-- 5 NOPs replaced by jmp

FUNCTION:
jmp short LABEL          ; <-- mov edi has been replaced by short jump backwards
push ebp
mov ebp, esp             ; <-- regular stack frame setup as before
```

The reason for using a 2-byte mov instruction at the beginning instead
of putting 5 nops there directly, is to prevent corruption during the
patching process. There would be a risk with replacing 5 individual
instructions if the instruction pointer is currently pointing at any one
of them. Using a single mov instruction as placeholder on the other hand
guarantees that the patching can be completed as an atomic transaction.

## Local Static Variables

Local static variables cannot be created on the stack, since the value
of the variable is preserved across function calls. We\'ll discuss local
static variables and other types of variables in a later chapter.


# X86 Disassembly/Functions and Stack Frame Examples

## Example: Number of Parameters

``` asm
_Question1:
  push ebp
  mov ebp, esp
  sub esp, 4
  mov eax, [ebp + 8]
  mov ecx, 2
  mul ecx
  mov [esp + 0], eax
  mov eax, [ebp + 12]
  mov edx, [esp + 0]
  add eax, edx
  mov esp, ebp
  pop ebp
  ret
```

The function above takes 2 4-byte parameters, accessed by offsets +8 and
+12 from ebp. The function also has 1 variable created on the stack,
accessed by offset +0 from esp. The function is nearly identical to this
C code:

``` C
 int Question1(int x, int y)
 {
    int z;
    z = x * 2;
    return y + z;
 }
```

}}

## Example: Standard Entry Sequences

``` asm
_Question2:
  call _SubQuestion2
  mov ecx, 2
  mul ecx
  ret
```

The function does not follow the standard entry sequence, because it
doesn\'t set up a proper stack frame with ebp and esp. The function
basically performs the following C instructions:

``` C
 int Question2()
 {
    return SubQuestion2() * 2;
 }
```

Although an optimizing compiler has chosen to take a few shortcuts. }}