This week, I post some remarks following up on the just-concluded disassembler tutorial; there are always a few loose ends to tie up, and I wanted to clarify or expand on:
- The opcode map
- Addressing
- Demo code
- Hardening
This week, I post some remarks following up on the just-concluded disassembler tutorial; there are always a few loose ends to tie up, and I wanted to clarify or expand on:
Editorial Note: Over the last two weeks, we’ve done the groundwork for building a disassembler: We’ve seen how to find documentation for a machine’s instruction format, how to read machine code by hand, and how to build up a machine-readable opcode map. Now it’s time to build the disassembler itself.
This article will walk through the process of building a disassembler for 8086 integer instructions in Python. It takes a “bottom-up” approach, beginning with low-level data structures, and ending with a method that disassembles an arbitrary sequence of bytes.
Editorial Note: This article is the second in a three part series on writing an 8086 disassembler. Today we’ll cover the practical issues involved in finding an opcode map; we saw last week that such a map is central to the process of disassembly. Next week, we’ll use this map (and Python!) to build a disassembler for 8086 integer instructions.
At first, it seems pretty easy to find an opcode map for an 8086 processor: just consult Intel’s documentation. Unfortunately, there are two problems with this approach. First, and most importantly, the quality of the published maps is somewhat poor. The second problem is that the 8086 is a very old (c. 1978) chip, and documentation dedicated to it (as opposed to later members of its family) is not easy to come by. Both problems can be overcome by consulting multiple resources.
Editorial Note: This article is the first in a three part series on writing a disassembler. Today we’ll cover the high-level concepts involved in disassembly and see how to read machine code “by hand”. Next week, we’ll look at the issues involved in finding and/or constructing an opcode map. Finally, in week 3, we’ll build a disassembler for 8086 integer instructions, using Python.
Over the last few weeks, we’ve seen how to use a debugger (such as DOS DEBUG) to find and examine interesting portions of an executable’s machine code. Now it’s time to begin considering how the debugger performs some of its tricks. I don’t want to launch into a full discussion of debugger programming (yet!), but I do want to talk a little about how to produce an assembly-language view of an executable’s instructions.
Since it’s a holiday week, I’m just going to do a quick followup to a loose end from last week. In that post, I hypothesized that the function located at CS:3A30
in my run-time copy of the Neuromancer executable existed solely to create a delay for the user. Today, I’d like to test that hypothesis by examining some more assembly code.
Editorial note: This is the second of a two-part tutorial on reverse engineering executables. Today, we’ll walk through the process of analyzing a series of assembly instructions. These instructions implement the codewheel verification check from the 1989 game “Neuromancer”. We covered the process of finding these instructions last week.
Editorial note: This is the first of a two-part tutorial on reverse engineering executables. Today, we’ll walk through the process of finding the section of an executable responsible for performing a certain task, and next week we’ll analyze the assembly instructions which comprise that section.
The game “Neuromancer”, from 1989, uses a “Pax Verification Code Wheel” as a form of copy protection. I wanted to dig into the codewheel’s implementation because I was curious whether the codes were generated algorithmically, or pulled from a look-up table. The aim of this project, therefore, is to find and analyze the portion of Neuromancer’s machine code that is concerned with codewheel checks.
A recent project required me to handle a large-ish number of symbolic constants, and I found it useful to develop a little utility class to help me manage them. Weighing in at only 8 lines, it made my life a lot easier.
I’ve been working on a longer, reverse-engineering piece about Neuromancer, but couldn’t get it finished in time to post this week. In it’s place, a simple javascript implementation of the game’s code wheel.
As I’ve mentioned before, I like to use the DOS DEBUG command to investigate older 16-bit programs. Today, I present a brief guide to using that tool to take snapshots of running programs.