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.
