Your Spectrum
Issue 10, December 1984 - Codebusters
Home Contents KwikPik
Everything you always wanted to know about the art of hacking... but were afraid to ask! The facts up-front from Terry Bulfib.
Let me state, right from the very beginning, this magazine does not condone pirate copying. It's both illegal and immoral, and it discourages the development of quality software. However, there's no legal or moral objection to breaking the protection on a program in order to examine the programming methods, make alterations, or even just for the hell of it! Under the copyright laws (as you may read in the notice taped to the photocopier in any library) it's perfectly legal to make a copy of a work for the purposes of private study; the only stipulation is you must not use such a copy for other purposes, or pass it on to others. Private study is what we are proposing here.
'Conditions of sale' that claim to prohibit the purchaser from copying a particular package are unlikely to be enforceable except under business contracts. The law in Britain does now allow
firms to make 'unreasonable' conditions when selling to the general public, and these are plainly unreasonable. Even with signed licences on business software, one has always been permitted (indeed advised) to make several backup and working copies. What you mustn't do is then distribute copies to other people. I am, of course, assuming that the copyright laws will be held to apply to software, when and if a test case ever actually goes to a decision.
Keeping these points firmly in mind, we'll now go on to explore a few general approaches to ways of cracking the locks. I won't be telling you the names of the specific programs that use particular methods of protection ... there's no point in making it too easy!


It's just another piece of social misdirection, that old saying about "cheaters
never prospering". Probably it was put about by a lot of prosperous old cheats who were anxious to minimise competition. In fact, the practise is not at all deleterious to one's well-being, provided one indulges the vice in private and publicly inveighs against such depravity in horrified tones.
The letters columns of various computer mags are occasionally scorched by very upset arcade players complaining that the POKEing of JSW or similar destroys all credibility in the top scores they have virtuously and arduously attained. What these purists do not wish to acknowledge is that cheating is a skill no less difficult to master than their own cherished ability to press a button at precisely the right moment. It must be admitted that the rewards for deviousness are somewhat greater than those for virtue, but that's merely the way the world works. Confucius he say "You have to turn the handle the way it goes, not the way it ought to go".


But how do you get started? Spectrum programs are often protected by ingenious methods designed to help stop piracy (rather than cheating) to the extent that one even begins to suspect that 'protection' is the favourite game of the programmer! These measures are of little use in preventing piracy, in any case.
At a recent press launch, Melbourne House (of Penetrator, The Hobbit, Mugsy, et al) admitted that its cassette protection routines apparently had no effect on the level of piracy and sales on games so protected - as compared to games published without protection.
The latest vogue is for fast loading routines which, while purporting to save loading time, usually appear designed to make tape-to-tape copying less reliable. Inevitably, they also make legitimate loading of the tape you paid for trickier, with the faster speed offset by the need to try several LOADs before one actually works! This can only be counter-productive from the publisher's point of view.


The first point to make is that you'll not get far with most programs unless you learn at least a little machine code. Luckily, cracking protection is both an ideal way to learn and an excellent motivation. You may not get into every tape you try to chisel open, but when you strike gold, it'll make up for any amount of failure.
There are a number of books around which will help you to learn machine code, but when it comes to breaking Spectrum protection there are just two which I consider indispensable. These
are Understanding Your Spectrum and The Complete Spectrum ROM Disassembly from Melbourne House. The first, by Dr Ian Logan, will get you started on machine code and at the same time give you a lot of information on how the Spectrum ROM routines can be used by your own programs. The second book, though not for the beginner, is invaluable once you know enough about machine code to be able to follow it.


Besides knowledge (just a little to start with) you'll need a few handy tools - the software equivalent of prybar, celluloid ruler ... and nitro!
Nothing is so helpful as a nice compact little Hex handling utility, written in Basic so that you can add things as you need them and carve them out again when space gets tight. The one I use came from the book mentioned above. It's tiny and simple and worth more to me for this kind of work than the full feature disassembler on my disk-based computer. This is little more than the sort of Hex loader that gets published with machine code games so you can type them in, but the utility allows you to list code as well as enter it. Mine gives me both decimal and Hex simultaneously, and calculates the two-byte addresses in decimal as well. A quick scrabble through back issues of YS should reveal something suitable for conversion.
The next essential is a 'header reader' that'll tell you what length of screech is Basic or bytes, what the start LINE is (if any), where the CODE LOADs are going to go and how long they are. There was a nice header reader in issue four - shame on you if you missed it! Send for a back number (and a subscription too, to
make sure it doesn't happen again).
Of course, some LOADs have no header - but that just puts the smile on the coconut.


As with any new endeavour, start with something easy and work up. Protection was a lot easier to get through a year ago, so try your hand at an older program before tackling a fast loader.
Once a program is running it's too late to do any clever hacking tricks. Occasionally the writer will leave in a 'magic word' for his own convenience (like 'WRITETYPER' in Jet Set Willy) but even if this is the case, you'll only unearth it by breaking into the program. You won't find it by guessing, not in a million (no exaggeration!) years.
'Once it is running' includes the short loading program preceding most games. These usually disable or 'bomb' the Break key to stop you from interrupting a LOAD to get a look at part of the program.
The classic method of sussing out the lock on a program is to use MERGE instead of LOAD to get the Basic loader program aboard. Once in the Spectrum, without having been auto-run, the loader can be investigated for clues about the main program (which is usually a block of machine code). The loader will often tell you the USR address of the start of the M/C program, and in the case of headerless LOADs, there will be a bit of code somewhere (possibly POKEd into a REM Statement) to load the machine registers with the address and length of the LOAD and call the appropriate ROM routine.
Naturally, the protection artist (PA for short) knows that this is the classic approach and takes measures against it.

There are three general methods of foiling an investigation by MERGE.
One of the most popular ways is to have a loader of just one line, that is something like '10 LOAD "" CODE'. This gives you no information beyond the fact that all the protection is in the CODE LOAD to follow. This is often used with a block of code which includes a Basic program and the system variables as well as the M/C game itself. That Basic program might start like this:

10 SAVE "TEEHEE" CODE 23552,40000
20 POKE 23659,0: REM bomb the break key, then continue with the rest of the program

The programmer SAVEs this program with GO TO 10, and when this block of code is loaded, the Spectrum thinks it has just finished doing line 10 (because that's what the system variables just loaded tell it) and it starts working on line 20. This method gives you a CODE LOAD which has an auto-run, and is less easy to crack than a Basic LOAD with auto-run. It also makes a game written in Basic load as if it were machine code. The code may start at 16384 to LOAD a title page in the same block.
Of course, the loader could be packed with false information. Because of the way the Spectrum Basic stores numbers, the visible part of the listing can be POKEd with spurious and misleading figures without affecting the invisible five-byte floating point notation which follows each visible number in the listing.
The Spectrum only uses the invisible part itself, so protection artists can put whatever they think will be most misleading into the visible part. The careful hacker will not take the figures on trust, but PEEK out all the invisible notations, just to make sure.
Last, but not least, MERGE won't work! The copyright message rides again! The PA has POKEd a line number to be bigger than about 32,512. 'POKE (address of first byte of line number), 128' will do the trick for him. this confuses the MERGE routine in ROM, which doesn't know how to deal with illegal line numbers. You just need to POKE the same address with zero - once you've got in, that is. You can't use MERGE, so you get in by using LOAD, but with the header from another program - one that doesn't auto-run and is as long or preferably longer than the loader program. LOAD the 'tame' header, then switch tapes and play the protected program (just the part after the header) as if it were the rest of the 'tame' program. 'Et Viola!', as the starving cellist said.
Using a 'tame' header is useful in other situations too, such as with headerless LOADs. Once you've LOADed it, you won't be able to see the line with the impossible line number. This won't matter if the PA has put in a line at the end of the program, just to have the impossible line number and stop MERGE from working. If the PA's POKEd the number of a line that actually
has some program in it, then it'll have to be un-POKEd before the line will run.
There is, of course, nothing to stop the keen and/or dedicated protection artist from using all three of the above, or even from disguising one approach as another. Dodges such as setting the INK to the same colour as the PAPER (which won't fool a printer) may be added for nuisance value. POKEing in impossible INVERSE numbers will make a listing unLLISTable as well as unLISTable. POKE them out again. It's better not to use EDIT, because editing a line with falsified numbers will cause the invisible notation to be changed to agree with the visible figures - which is not what you're after! Nothing the PA can arrange is proof against what you can do, but they'll try to wear you out before you unravel the last knot.


Next month, I'll be looking into 'headerless' loaders with a number of hints and tips on what to do with them. There'll also be some other interesting titbits for you to play around with ... so be there!
On a very important note, it must be stressed that in no way am I or this magazine condoning software piracy - it's illegal! If you're looking for a quick way to provide free copies of software for a few of your mates then you've just read the wrong article ... but if you want to find out more about that little black box of tricks, then I applaud you and look forward to your company next issue.
Home Contents KwikPik