CRACKS: Problems with Pirated Copies

CRACKS: Problems with Pirated Copies

by Jaxon Hollis

Pirated copies are no longer a taboo subject. Sometimes it is the only way to still get hold of a certain program. On the Internet, you can already find many Spectrum programs that were once sold commercially and are now freely available to everyone. In the following, Jaxon Hollis vents about why a game should be properly "cracked" rather than snapped. I would like to point out that while the article frequently mentions the Multiface, that device is actually the least affected since it has its own RAM. Rather, the author refers to ANY hack interface here instead of just Multiface.

You have probably all been disappointed at some point by the state in which you received a good game. The title picture is corrupted, the selection menu is missing, or other things are broken. 128K users in particular had a hard time dealing with a guy named "CARGADOR", who snapped 128k programs in 48k mode.

I think it is very stupid to snap (or Multiface) programs just to get them onto disk more easily (My words exactly!!! L.C.D.). Quick perhaps, but not clever. In the following, I will try to explain why:

Take BETADISK for example. When pressing the snap button, all registers are PUSHed below SP. That is not good, because the game might be using several CALLs, and the PUSHed registers can corrupt data. One could build protection into the program against pressing an NMI button (any SNAPSHOT button) by constantly polling the processor's frequency.

With disk systems that have built-in RAM, this method is easier, since SNAP might store the registers in that RAM. The same applies to the Multiface 128.

In other cases, pressing the Multiface button saves PC (Program Counter, the address where the program currently is) and the AF register below SP. But relying on the Multiface or snapshots every time is a mistake.

Many games also use the stack pointer to store a return address after a CALL. Even then it is not yet catastrophic; it only becomes problematic when the program uses SP for even more things, e.g., storing variables.

An example: If you only have 4 bytes of room for SP because the program code sits directly below it, you can only store 2 addresses there. If you press the Multiface button now, one address will be overwritten.

Another example: The stack pointer is used for something else entirely:

   LD SP, TABLE
   POP HL
   JP (HL)
   ...

If the Multiface button is pressed during this routine, the jump table (JP) will be corrupted, and upon resuming, the program will produce errors and eventually crash.

Yet another example: SP is used for graphics:

   LD SP,GFX
   POP HL
   POP DE
   POP BC
   POP AF
   LD SP,20480
   PUSH AF
   PUSH DE
   ...

Here too, the contents of SP would be altered, thereby corrupting the graphics. Although this method does not occur very often, when it does, the graphics are permanently destroyed.

These were a few examples intended to point out the problems with the Multiface. In such cases, you cannot use Multiface or snapshot. I have been a hacker for 11 years now and have seen many games that crash immediately after loading. As an example, I can name "IRON LORD 128". Whoever uses Multiface in the final part destroys the graphics. You should really only use Multiface or snapshot to examine LOADERs or COPY PROTECTION, strictly speaking BEFORE the complete game resides in memory. Especially if you don't know whether your Multiface (or whatever you are using) has its own RAM, you cannot guarantee that the data throughout the entire program remains intact. I repeat... If the disk system or hack interface has its own RAM, then in 80% of cases the registers are stored inside it. Then there are no problems, and you can use the interface to analyze LOADERs or COPY PROTECTION. An interface without RAM is better off not being used at all.

But how to "crack" a program then? It is best to use the appropriate software (disassemblers, monitors that run in SCREEN$, i.e., stored directly in screen memory). There is no copy protection good enough that it cannot be removed with the right software. That is a hacker's law. Multiface can be a substantial help in tracking down and investigating things; there are no issues with it on "SPEEDLOCK" or "RAT FLASH" copy protection, for example. But all of this can also be done entirely with software—and far more reliably than with hardware. The Multiface is fast, but there is no data safety (remember the 4 bytes in SP; on Betadisk, for instance, it pushes 24! registers). Many games have already been damaged by this kind of thing. Another example is "GRELL & FALLA 128". Someone snapped it and converted it into a normal file afterwards. When I got it, I noticed the missing music. I analyzed the program and found the error, which had been triggered by the SNAPSHOT. Now everything runs perfectly.

About myself: As I already mentioned, I am a CRACKER. The best CRACKER in the Czech Republic was MATAsoft, who converted many games to Betadisk and tape. There were close to 200 programs, all PACKed and easy to convert for any disk system. This is the real reason why people CRACK and convert programs: so that anyone can easily transfer the program to their own disk system (after all, quite a few exist for the Spectrum). Furthermore, PACKed programs load faster and consume less storage space on disk. Let's assume the capacity of an empty floppy disk is 730 KB. A normal program would require roughly 40960 bytes (without a screen), meaning around 17 programs fit on the disk. If you PACK these programs, each would take around 25 KB (depending on the program and the PACKing method, of course), and 29 programs will fit on the disk. It makes a huge difference whether you need 50 or 150 disks. The difference is also massive with 128k programs. Many 128k games take around 110 KB. After PACKing, they are down to only 50–60 KB (in 2 files), and that directly affects the loading time (especially from tape). Try loading 60 KB and then 110 KB, and compare how much time you save. To give an example, take a LEVEL 9 adventure (SNOWBALL or ADVENTURE QUEST) and try PACKing the 128k pages. Sometimes 16384 bytes shrink down to a mere 400! Of course, that doesn't happen with every program, but it shows just how much is possible.

I suppose I should wrap this up. In any case, it is better to crack programs yourself than to rely on an interface. I know that some users hit the SNAPSHOT BUTTON just to get a program onto disk quickly, even when the program has already been cracked. It is truly very simple to transfer a cracked program. You only need to alter the loader in Basic (disk commands), and a copy program takes care of the rest. Cracking a program takes a lot of effort. Please don't ruin that hard work.

And do have the courage to tackle an original and crack it. After all, you are doing it for yourself too; you learn to identify and understand the copy protection. This knowledge helps you, and you help others who will then have an easier time transferring the programs. Properly CRACKing a game always takes more time than SNAPping it. But after a while, you develop a certain system; it goes faster, and it's fun too.

Everything written above comes from my own experience in CRACKing, PACKing, and converting programs. I almost exclusively use software for CRACKing and am successful in 95% of all cases. Only when I hit a complete dead end do I use an NMI button to inspect the program. Over these 11 years, I have cracked around 200 programs; in December '95 alone, I made roughly 50 conversions.

JAXON HOLLIS

---

To this, I would only add that finally someone agrees with me 100% when it comes to cracking. The last time I used an MF for copying was back in '87, and I still regret it today. Fortunately, I have since been able to repair some of the damage caused by it. Anyone who cracks with a Multiface and then merely modifies the loader is by no means a "cracker"! I have received several "cracks" where the authors even immortalized themselves in the loader. Are they actually proud of that? The same goes for snaps converted to tape. The upper part of the screen gets destroyed, and sometimes it doesn't get refreshed, making these games look pretty stupid. Take, for example, a shoot-'em-up with 3D graphics where the action takes place in the center of the screen. The upper and lower parts of the screen are reserved for instrument panels, and along comes such a "cracker"—let's just call him "Bobby"—and snaps the game right after loading. After that, he couldn't care less, because now he has the game in a copyable state on cassette.

What Bobby doesn't care about is that the upper screen area is disfigured by loader remnants, which interferes with gameplay. Had Bobby placed the loader just 2048 bytes higher instead of starting at 16384, it would have been overwritten by the game after launching, and we wouldn't have an issue. When I received the program, I was annoyed that it couldn't be transferred to disk, and by those stripes on the screen. So I grabbed Art Studio and touched up the title picture; the loader code had previously been shifted by 2048 bytes, which thankfully wasn't hard due to the relocatability of the code. Then I cracked it properly so that it can be loaded from any disk interface. In the meantime, I've learned that only this snap version is circulating in Poland, which doesn't speak well for the skills of the cracking scene there. The same applies to other programs that could have also been cracked with a bit of know-how, had anyone other than the "professional crackers" touched them. Yes, sometimes programs weren't cracked at all, but simply dumped onto cassette exactly as they were.

I've grown a bit out of practice lately, and the harder challenges are beyond me now, but I'd still bet there are many "top crackers" who, thanks to their laziness, are no better than I am.

L.C.D.

CRACKING WORKSHOP PART 4

In a letter, I was asked how to remove passwords from the games that were included on the cover tapes in SINCLAIR USER as so-called prize games. The sole purpose of these passwords was to force the user to buy the next issue just to find out the password. SU will no longer be published, and this practice was truly shameless, especially because sometimes the passwords didn't even appear in the next issue at all. Apparently, the SU editorial team cared more about making money than about the users.

I chose three games to crack: TWINZ, a type of Memory game, as well as CEASEFIRE I and II (NIGHT RUN, truly outstanding!). I easily bypassed the tedious task of cracking the loader because, as I assumed, so-called reader games usually consist of a BASIC part and a code part; the BASIC program memory is not used by the machine code, nor is the printer buffer.

The procedure was identical for all three programs: I loaded SNAPOUT, then the program, entered the password, and waited until the game was decompressed. Once the title screen appeared, I pressed Snapshot and then the "e" key, which dropped me back into BASIC. The CLEAR address might be present in the BASIC loader; if not, it can be found using:

PRINT PEEK 23730+PEEK 23731*256

If it is too high, you have to determine the start of the program manually by yourself, but once that is done, the whole thing can be saved to disk. Since the entire contents from the program start address to the end of memory are saved, a compressor should be used.

Now I started wondering: what should the execution address be? The program only ever said RANDOMIZE USR 16384, and that was by no means the wrong number. The solution to the problem lay in the original loader: part of the loader is copied into the screen area. The section to be copied (from the address specified after LD HL!) needs to be checked with a disassembler for a JP (Jump); that target address is then the actual execution address.

This method worked for these three programs, and it will work just as well with others, even if they don't have passwords. This is also how you get these programs onto disk!

I hope this answers the question sufficiently. So far, I haven't looked into where the passwords are stored in memory, which is why there are some programs for which the password is missing.

Another question was: Where can you get the mentioned packers and screen compressors?
Answer: Just like in the last issue, there is a freeware list in this issue as well—take a look!

That wraps it up for Cracking Workshop Issue 4. To keep the series going, I need your questions.

L.C.D.

MAUSTREIBER 2.0

Advanced Patience was the first Spectrum game that could be controlled with an Atari ST or Amiga mouse; by now, there are already four games of mine that offer this control method as an alternative to the previously common ones. However, the area of application is not limited to gaming; application programs can also become much easier to use with it, though so far only I have utilized these mouse drivers. In an earlier SPC Info, I listed and described one of the first versions, but now the time has come: the second, improved version is here. Instead of the four drivers previously required (ST mouse in Kempston port, ST mouse in Sinclair port, Amiga mouse in Kempston, as well as Amiga mouse in Sinclair port), the complexity has been reduced a bit. Now there is only Amiga or ST mouse in Kempston, and Amiga or ST mouse in the Sinclair joystick port. In addition, a routine was added that moves the cursor with a joystick or keyboard.

As always, the joystick port must supply +5 volts on Pin 7, just like the Kempston Plus interface I presented in the last issue.

All of these program versions must be compiled before use, and before starting, you should not forget to POKE in the maximum coordinates.

After calling the mouse driver, you can move the cursor—which consists of an attribute block—around the screen until the fire button is pressed. Because of this, all CPU time is consumed by calculating the mouse position, and the main program can only resume after the fire button is pressed. The programs, which you can find in the "EXTRAS" section, can also be modified to return to the main program automatically after a certain period of time by utilizing the FRAMES system variable. In this way, interrupts are simulated.

None of these routines work in 128K mode! They always switch on the second screen. Why this happens, I do not know, but it might be due to the compiler. I will definitely look into this problem.

One more thing: you should use HiSoft Basic for compiling, since USCHI does not get along with some BASIC functions. With some effort, the program could probably be rewritten so USCHI understands it, but that would increase its code length considerably.

If you want to see the compiled mouse driver in action, check out ULTRA REFLECT from the last issue, or PYRAMID PATIENCE from this issue. Both are programs that already work with the same mouse driver version that I have included on the disk.

Well then, I am looking forward to seeing the first mouse-controlled programs that are not written by me.

Have fun,

L.C.D.