Simply put, diffing is the practice of comparing two things for differences, especially after some change has been made. The two things in question could be files, Registry entries, memory contents, packets, e-mails—almost anything. The general principle is that you take some sort of snapshot of the item in question (for example, if it’s a file, save a copy of the file), perform the action you think will cause a change, and then compare the snapshot with the cur- rent item, and see what changed.
Any number of objects could be compared for differences. For the purposes of this chapter, we’ll limit our discussion to files (including special files, such as the Windows Registry) and memory.
Why is it useful to be able to see the differences in a file or memory before and after a particular action? One reason is to determine the portion of the file or the memory location of the item of interest. For example, if you have a file that you think contains a form of the password to an application, but the file appears to be in a binary format, you’d like to know what part of the file repre- sents the password. To make this determination, you’d save a copy of the file for comparison, change the password, and then compare the two files. One of the differences between the two files (as there may be several) represents the password. This information is useful when you want to make changes to the file directly without going through the application. We’ll look at an example of this in this chapter. For cases like this, the goal is to be able to make changes to the storage directly.
In other cases, we may be interested largely in decoding information rather than changing it. The steps are the same, causing actions while monitoring for changes. The difference is that rather than trying to gain the ability to make changes directly, we want to be able to determine when a change occurs, and possibly infer the action that caused it.
The differences between the two cases are minor, and the problems are very interrelated. The technique is basically the same in both cases.
To examine the rough equivalent of diffing concerning information that crosses a network, check out the “Sniffing” (Chapter 9) and “Session Hijacking” (Chapter 10) chapters of this book.
Files
I first ran across the idea of directly manipulating data files in order to affect an application when I was about 13 years old. At the time, I had an Apple ][+ computer, and enjoyed games quite a bit. By that point, I had completed some- where between one and two years of junior high programming classes. One of my favorite games was Ultima 2. Ultima is a fantasy role-playing game that put you in the typical role of hero, with a variety of weapons, monsters to kill, and gold to be had. As is typical of games of this genre, the goal is to gain experience and gold, and solve the occasional quest. The more experience you have, the better you can kill monsters; and the more gold you have, the better weapons and armor you can buy.
I wanted to cheat. I was tired of getting killed by daemons, and at that age, I had little concept of cheating spoiling my game. The obvious cheat would be to give my character a lot more gold. I knew the information was written to a diskette each time I saved my game, and it occurred to me that if I could find where on the disk the amount of gold I had was stored, I might be able to change it.
The technique I used at that time is a little different from what we’ll pre- sent in this chapter, largely because the tools I had at my disposal were much more primitive. What I did was to note how much gold I had, save my game, and exit. I had available to me some sort of sector editor, which is a program used to edit individual disk sectors straight on the disk, usually in hexadec- imal. The sector editor had a search feature, so I had it search the disk for the name of my character to give me an approximate location on the disk to
examine in detail. In short order, I found a pair of numbers that corresponded to the amount of gold I had when I saved my game. I made an increase and saved the changes to the sector. When I loaded my game back up, I had much more gold. Eureka! My first hack. Little did I know at the time that I had stumbled onto a technique that would serve me for many years to come.
I was able to expand my small bit of research, and built myself an Ultima 2 character editor that would allow me to modify most of the character
attributes, such as strength, intelligence, number of each type of weapons, armor, etc.
Of course, that was more years ago than I care to admit. (To give you an idea, Ultima IX was recently released, and they only make one every couple of years on average.) Today, I play different games, such as Heroes of Might and Magic II. This is a fantasy role-playing game in which you play a character who tries to gather gold and experience through killing monsters… you get the idea. Figure 5.1 shows the start of a typical game.
In particular, notice the amount of gold I have, 7500 pieces. First thing I do is save the game, calling it hack1. Next, I make a change to the amount of gold I have. The easiest way is to buy something; in my case, I went to the castle
and bought one skeleton, one of the lowest-priced things to buy. It’s important to have the change(s) be as small as possible, which we’ll discuss shortly. After the purchase of the skeleton, I now have 7425 gold pieces. I save the game again, calling it hack2.
I drop to a DOS prompt and run the file compare (fc) command as shown in the following example:
C:\Program Files\Heroes2\GAMES>dir hack* Volume in drive C has no label
Volume Serial Number is 3C3B-11E3
Directory of C:\Program Files\Heroes2\GAMES
HACK1 GM1 108,635 06-03-00 11:32p hack1.GM1 HACK2 GM1 108,635 06-03-00 11:39p hack2.GM1
2 file(s) 217,270 bytes 0 dir(s) 10,801.64 MB free
C:\Program Files\Heroes2\GAMES>fc /b hack1.gm1 hack2.gm1 Comparing files hack1.GM1 and hack2.gm1
000002A2: 31 32 000002C3: 32 FF 00000306: FF 03 00000368: 4C 01 00003ACE: FF 2F 00003AD3: 00 01 00003AE4: 08 07 C:\Program Files\Heroes2\GAMES>
The fc command will compare two files, byte for byte if you give it the /b switch, and report the differences in hex. So, my next stop is the Windows cal- culator to see what 7500 and 7425 are in hex. If you pick “scientific” under the View menu in the calculator, you will then have some conversion options, including decimal to hex, which is what we want. With “Dec” selected, punch in 7500, and then click on “Hex.” You’ll get back 1D4C. Repeat the process for 7425, and you’ll get 1D01.
Now, looking at the results of the fc command above, the difference at address 368 (hex) looks promising. It was 4C and is now 01, which matches our calculations exactly. We can also probably infer what some of the other numbers mean as well. There were eight skeletons available in our castle, and we bought one, leaving seven. That would seem to indicate the byte at 3AE4. The byte at 3AD3 might indicate one skeleton in our garrison at the castle, where there were none before.
For now, though, we’re just interested in the gold amount. So, I fire up a hex editor (similar to a sector editor, but intended to be used on files rather than a raw disk) and load up hack2.gm1. I go to offset 368, and there are our values 1D 01. Notice that they appear to be reversed, as we Latin-language based humans see it. That’s most likely because Intel processors store the least significant byte first (in the lower memory location). There’s only one way to find out if we have the right byte: change it. I change the 1D (the most sig- nificant byte, because I want the biggest effect) to FF (the biggest value that fits in one byte, expressed in hex.) Figure 5.2 shows the result of loading hack2.gm1 into the game.
Take a look at the amount of gold, which is now 65281. A quick check with calc confirms that 65281 in decimal is FF01 in hex. We now have a significant advantage in the game, and can crush our simulated enemies with ease. Should we have wanted even more gold, which is entirely possible to have in this game, then we could have tried increasing the next byte to the right of the 1D as well, which was 0 when I looked at it. At worst, a couple tries at the adjacent bytes in the file with the hex editor will reveal which byte is needed to hand yourself millions of gold pieces.
Of course, the purpose of this book isn’t really to teach you how to cheat at games; there are more efficient means to do so. For this game in particular, there is a saved-game editor someone has written, likely starting with the exact
same technique we’ve outlined here. There are also a few cheat codes you can just punch in to the game directly, keeping you from having to exit at all. A quick Web search will reveal either if you’re really interested.
If you’re familiar with this game, then you may be wondering why our example wasn’t done in Heroes of Might and Magic III, which is the current version. The reason is discussed later in the chapter.
Tools
Before we move on to other more interesting examples, let’s take a moment to discuss some of the tools you will need to perform this sort of work. We’ve mentioned the fc utility. We’ve talked about hex editors and sector editors. We even used calc.