Tech Juice

Introduction

The x86 processor chips have gone through many changes in the last 20 years. The transitions between 16, 32 and 64 bits versions immediately come to mind–and they are very notable indeed–but x86 assembly programmers have had to deal with many other changes. Another big change was the introduction of a new operating mode in the 286 and 386 CPU models: protected mode. Protected mode replaced the older operating mode called real mode, and it allowed software to utilize features such as virtual memory and paging. These features are now used in virtually all modern operating systems which run on the x86 architecture, such as Microsoft Windows, Linux, and many others.

In this article we give an overview of the available registers and operating modes of the various x86 architectures, and we describe the basic register semantics in different operating modes.

x86 CPU Registers

Processors have small amounts of high-speed storage, called registers, located in the heart of the CPU. All data must be represented in a register before it can be processed, so they play a central role: the first step of learning a new platform is usually learning the register set. The advantage…

Introduction

If learning assembler with the NASM.exe assembler peaks your interest, you might be interested in this extensive tutorial by Paul Carter. Annoyingly, finding a linker on Windows that plays nice with NASM took me a while. The tutorial by P. Carter is not very clear on this matter. I wanted to use the linker link.exe that comes with Visual Studio 2010, because the free DJGPP linker that is mentioned by Mr Carter generates badly formatted .exe files. In this post I will show how to compile and link a Hello World assembler program with nasm.exe and link.exe.

Compiling Assembly Code

Let’s compile and link this Hello World program (courtesy of Ray Toal) in a file named helloworld.asm.

; This is a Win32 console program that writes "Hello, World" on one line and
; then exits.  It needs to be linked with a C library.
 
global  _main
extern  _printf
 
section .text
_main:
push    message
call    _printf
add     esp, 4
ret
message:
db      'Hello, World', 10, 0

As you can see we use the printf() function to print the text “Hello, World”. This function is marked as extern, because it is an imported function (it resides in the C Runtime Library).

The tutorial …

Introduction

Most fields in a Portable Executable (.exe) file that refer to a location in memory use a so-called Relative Virtual Address (RVA). This is useful because it allows the Windows loader to load the executable in any virtual memory location, without having to change every pointer in the executable. The RVA is relative to the Load Base Address, which is the location where the first byte of the executable is loaded into memory. A virtual address refers to a location in memory, whereas a file offset refers to a location in an executable file on physical storage.

The goal is to convert between these values:

• (Relative) Virtual Address: a location in virtual memory
• File offset: a location in a file on physical storage

How it Works

When an executable is loaded into memory it is not copied byte for byte from disk. What happens is a process called aligning: the sections in a PE file are spaced so they all start on the first byte of a memory page (usually 4096 bytes on x86 systems). This can introduce padding at the end of sections. Because of this effect, among other things, we cannot translate directly between RVA and file offset.

When looking at the hexadecimal code of a 32 bits Portable Executable file (files with the well known extension .EXE) I ran into some questions. According to the specification every PE file starts with a DOS header. This element contains the DOS stub, the part that usually prints “This program cannot be run in DOS mode”. Next we find the PE header, which contains many important fields of information about the executable file.

When viewing calc.exe (Windows Calculator) in a hex editor, I found some extra paragraphs (16 bytes) in the DOS stub that I could not explain. The contents of calc.exe are displayed below:

We can identify elements at these offsets:

• 0x00 - 0x3F: 64 bytes of DOS header
• 0x40 - 0x7F: 64 bytes of DOS stub
• 0x80 - 0xD7: Unknown code
• 0xD8:  The characters ‘PE’ (pointed to by 0x3C in the DOS header) denoting the start of the PE header.

How Do We Know the DOS Stub Code Is Only 64 Bytes?

According to the specification, the DOS stub field starts at 0x40 and ends right before the start of the PE header at 0xD8. However, if you disassemble the code you will see it does not reference anything beyond the ‘$’ character at 0x78. The rest of the DOS stub …

This is a quick post about the Ildasm tool, which is interesting for those who are interested in the internals of .NET. The .NET framework is similar to the Java Virtual Machine in the sense that it provides a layer of abstraction on top of the operating system. Applications are compiled to an intermediate language, which is then interpreted by the framework when the application is executed.

Several languages can be compiled to .NET, two examples being C# and VB.NET. Now let’s say you have a compiled .exe or .dll file for .NET, and you want to see exactly what’s going on in there. With the Ildasm.exe tool you can easily look at the guts of a compiled .NET application. From the Microsoft website:

This tutorial offers an introduction to the MSIL Disassembler (Ildasm.exe) that is included with the .NET Framework SDK. The Ildasm.exe parses any .NET Framework .exe or .dll assembly, and shows the information in human-readable format. Ildasm.exe shows more than just the Microsoft intermediate language (MSIL) code — it also displays namespaces and types, including their interfaces. You can use Ildasm.exe to examine native .NET Framework assemblies, such as Mscorlib.dll,

…

The dumpbin.exe tool is included with Visual Studio, and its a great way to get details on the structure of a Windows Portable Executable or COFF file. For those of you who don’t know: the Portable Executable format is used by Windows for .exe files, and it is based on COFF. You can run it from the Visual Studio Command Prompt.

Now if you want all information you would use dumpbin /all bla.exe. This gives you all the information on the structure of the file, but it also print all the ‘raw’ content: the CPU instructions. This will leave you with a dump that is very hard to read. To omit the raw content use the following command:

dumpbin /all /rawdata:none bla.exe

This will print ALL the information about the file, except the raw data. You can also save the output to a file.

dumpbin /all /rawdata:none bla.exe > bla.exe.txt

This will save the dump to bla.exe.txt in the same directory. Running this command on C:\Windows\notepad.exe generates this output:

Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.
 
Dump of file notepad.exe
 
PE signature found
 
File Type: EXECUTABLE IMAGE
 
FILE