Interphase is badly cracked

Because of my earlier patch for Omnicron Conspiracy that froze at the title screen, being unable to read keystrokes when run in DOSBox, it wasn't surprising to see a similar problem arrive in my mailbox. This time, the game was "Interphase" and it also got stuck in a loop at the intro screen and rolling demo, not acknowledging any input from keyboard or mouse.

I asked the person who reported the problem to provide me with a copy of the game, which he did. Running the game in DOSBox, I could see the problem was as described. A quick test in conjunction with my earlier patch showed no change. Obviously, the problem had a different root cause. Running the game outside DOSBox yielded the same results, so it could not be a problem in the emulator.

There is only a finite number of ways by which to get keyboard input under DOS. The most common way is to hook the keyboard signalling interrupt, IRQ 1 (aka INT 9). The excellent debugger in DOSBox provides ways of quickly checking for this. Strangely enough, the game never touched the keyboard handler, leaving it at the default. It also didn't use any of the other common methods:

• DOS input functions in INT 21
• the keyboard interrupt INT 16
• reading directly from the keyboard buffer
• polling port 60
• the keyboard intercept function INT 15/AH=4F

I don't know of any other ways to get input from the keyboard so it was time to resort to more drastic measures. Running the program through a disassembler resulted in a large chunk of ASM code. A quick search revealed that there was a chunk of code to hook the keyboard handler that I looked for initially. That bit of code was just never getting executed. The plot thickens!

By tracing the code back up, it is possible to find the entry point of the function. These can often be identified by a bunch of "PUSH" instructions following a "RET"-like instruction, commonly with some NUL bytes (00) or NOPs (90) in between. Elsewhere in the code, there was a CALL to this function, so the next step was to trace the code in that function back up. Not far into that, there was some very strange code: an unconditional JMP over the call to the keyboard initialisation routine, followed by some highly suspect and probably invalid opcodes. XOR DX,DX; OUTSB would write to hardware port 0, which is used by DMA channel 0, assigned to the system board. Not something a game (or any program, for that matter) should be touching.

Something fishy was going on there. Disabling the JMP and the garbage following it made the program refuse to start with a clear error message: "Please insert your key disk in drive A or B and retry." A typical 1980s and early '90s copy protection scheme if ever I saw one. The crack to bypass the keydisk protection also bypassed important parts of the game's initialisation code. There is no way the cracked version could ever have worked. The cracker never properly tested it.

Some web searching revealed that this particular crack is widespread on the internet, even earning rave reviews on some "abandonware" websites. I wonder how they managed to praise a game so highly when it was impossible to even start.

It was easy enough to correct the crack and confirm my theory, but this is a good example of why the nice people at VOGONS refuse to support or help out with the so-called abandonware.