2.5 Game IDs and loaders by Lance Ewing, with additions/modifications by Peter Kelly and Anders M Olsson Last updated: 3 March 1998 Since the data formats for the different AGI interpreter versions are mostly identical or easily convertible to each other, we should expect to be able to run one games data with anothers interpreter. This sounds like a reasonable assumption but when you try it, the interpreter rejects the new data. The reason behind this is GAME ID'S. Every interpreter has got a game ID coded into it and it expects to be given data for that game. Somewhere in the initialization code for each game is a set.game.id. When this command is encountered, the interpreter checks the given game ID and compares it with it's own. If they are not the same, it quits immediately. Presumably the reason for this was to stop people running games with the wrong interpter version, which can cause problems (unless you know what you're doing). HOW DO WE GET AROUND IT? Method 1: The hard way Well, basically we have to find the game ID signature in the AGI interpreter file and change it to the ID of the game whose data we wish to be executed. Here are a few examples of some game ID's and the data following them: Police Quest: "P" "Q" 00h "e" "I" "D" "X" Mother Goose: "M" "G" 00h "e" "I" "D" "X" Manhunter 2: "M" "H" "2" 00h "I" "D" "X" XMAS Demo "X" "M" "A" "S" 00h "D" "X" Leisure Suit Larry: "L" "L" "L" "L" "L" 00h "X" The game ID itself is the null terminated string that ends at the 00h. The text that follows it is of no significance, it is simply to fill in the gap although it is useful when searching for the game ID because, as you can see, this text is always "eIDX" or a suffix of it (ie. "IDX", "DX", or "X"). For most games, the game ID is two or three characters which means that you will be able to rely on the "IDX" string being there for these games. Method 2: The easy way Using the above method will allow you to run a different game with an interpreter, but you will still only be able to run the game that has the specified game ID. There is another way around this, which involves finding where the set.game.id command is used by the game. This is quiteeasy now that we have programs to edit the logics (such as AGI Studio). What you can usually do is look at the top part of logic 0 and find out what the initialization logic is (usually around 90-100 - you might have to look at a few logics before you find it). Then simply go to that logic, find the set.game.id command, remove it, and recompile the logic. Since the command is not used, the interpreter will not try and compare it with it's own ID, and it won't quit. The only drawback to using this method is that the saved games no longer have the game ID in their name (so, for example, a savegame would be called SG.1 instead of KQ2SG.1), but this is not a major hassle. WHY CAN'T I FIND THE GAME ID? This is because a lot of the AGI files themselves are encrypted. This was probably to give some protection to their product which was quite unique at the time. You can tell the difference between an encrypted AGI file and a non-encrypted AGI file by the first two characters. If they are "MZ" (the EXE file header), then it not encrypted. The AGI file is decrypted by the loader program. This is usually called SIERRA.COM but can also be named after the game (eg. KQ1.COM). In AGI version 1, the loader was called LOAD. If an AGI game doesn't have a loader, then it shouldn't be encrypted. If an AGI game does have a loader, it does not necessarily mean that the AGI file is encrypted. The decryption key was not originally embedded in the loader file. If you find a game where the key is embedded in the loader, it is because that game has had copy protection removed. There are several utilities to do that. Anders M Olsson's "SUP" is one of them. The CD re-releases have been unprotected by Sierra in exactly the same fashion. The loader would read the decryption key from track 6 of the disk, load the executable file, decrypt and run it. Track 6 had a special format that was supposedly impossible to exactly reproduce by a standard PC floppy disk controller. An interesting note is that when a copy-protected Sierra game asked for the original disk one, you could insert disk one from *any* protected Sierra game. The contents of track 6 were always the same. But even though track 6 was the same, all games didn't use exactly the same encryption key. The two bytes in the loader, immediately following the string "keyOfs", gave an offset on track 6 from where the key would be loaded. So, if the decryption string consists of 128 "k" characters, it can actually mean one of two things: Either the AGI file is not encrypted, or the game is still copy-protected. HOW DOES THE ENCRYPTION WORK? The LOADER contains a 128 byte string called the decryption key. Here's the process of decryption: The carry bit is zeroed. The first 128 bytes of the AGI file are XORed with the decryption key. The whole key string is rotated one bit to the right, including the carry-bit. (Bit 7 of the first byte is loaded from the carry. Bit 0 of the last byte is placed in the carry, where it will remain until the next rotation.) The bit that was bit 0 of the last byte (now in carry) is ORed into bit 7 of the first byte. The next 128 bytes of the AGI file are XORed with the new key. If the end of the AGI file has not been reached, then go back to 3. WHERE IN THE LOADER IS THE DECRYPTION KEY? The start of a loader will look something like this: LOADER v3.0 (c) Copyright Sierra On-Line, Inc. 1987 keyOfs There are two bytes in between the "keyOfs" string and the start of the description string. If the decryption key consists of 128 "k" characters, then the AGI file is not encrypted (or the game is still copy-protected). If it consists of a whole lot of random looking characters, then it is encrypted. As an aside, the decryption string is followed immediately by the stack and is usually marked with a whole string of "s" characters. Thus we have "k" for key and "s" for stack. The stack is usually 256 bytes long. DECRYPTING THE AGI FILE Decrypting the AGI file is simply a matter of writing a program to read the loader to get the decryption string, and then applying the process mentioned above to the AGI file. Once this has been done, the game ID can be located. POSSIBILITIES What this means is that with a few useful AGI utility programs, it is possible to run any set of game data with a compatible AGI interpreter. For example, games that use AGI versions 2.915, 2.917, and 2.936 should be able to be converted into AGIv3 format and run with an AGIv3 interpreter. 'Compatible' as it is used above refers not only to the data differences but also to some AGI command descrepencies. There are about four AGI commands that have changed the number of arguments passed to them as the interpreter developed. This sort of thing is the only real obstacle to running data on another interpreter.