The Protection Racket
Sean McManus explains how to protect your Basic from prying eyes
Having sculpted your first original program from reams of Basic, glued together with blood and sweat, you might feel like installing some security to protect your work from prying eyes and plagiarising hackers. Enquiries in the computer press have shown that a fascination with protection exists, even though very few methods cannot be relatively easily defeated. It's true that this feeling contradicts the public domain ethos of sharing knowledge and code. However, whilst this section shows means of preventing trespass, it also provides all you need to know to bring the fortress crashing down.
The simplest way to protect your program is to put a password on it. The program Password on the disc is an example of a password system. Valid$ holds characters which are valid for input and the correct password here is "comedy". The program is case sensitive (i. e. "COMEDY" is wrong - lower case must be used). It could be standardised to accept upper or lower case by using lower$ to convert whatever you type into its lower case version before any comparisons are drawn. Line 110 detects if the password is incorrect and you will need to force action here to prevent access to the program. For example, CALL 0 would reset the machine. The rest of the program can be appended from line 120 onwards. The INPUT command is generally inadequate for inputting passwords because the user can just tap the escape key and the INPUT command could be relatively easily intercepted. This method also helps to keep the display tidy and you might wish to look at the possibility of not displaying the password as it is entered. Careful thought should be exercised in choosing passwords- don't make it something blindingly obvious like your friend's name, your favourite singer or your hobby. Something obscure is best, especially if it isn't even a real word. Be careful not to forget it. It's a statement of the obvious, but these things happen.
Pressing [ESC] twice would soon bypass all this, revealing the listing (and the redundant password) in its full glory. There are three ways to disable the escape key. It can be effectively disabled by using the command:
KEY DEF 66,0,0,0,0
Much more effective though, is the poke:
This will even render [CTRL]+[SHIFT]+[ESC] useless. Machine code programmers might like to consider the possibility of writing a routine for if [ESC] is pressed and patching it in through &bdee.
ON BREAK GOSUB line number allows you to intercept break when it occurs and jump to a special routine to handle it. Such a routine might ask whether the user wants to reset the machine or resume play or could simply act as a pause function for a game. Later versions of Basic also have the command ON BREAK CONT (see the Downgrading chapter) which will keep things running even if someone tries to use escape to break in.
Basic has its own protection system built in: SAVE "filename",P. Basic will not let you list a program saved in such a way. It may not be loaded nor merged (only run) and is automatically deleted upon ending or breaking. It works by changing the filetype in the header from $ to %. This protection, having been around since the very beginning, was cracked long ago. There are public domain programs to load protected listings and most backup utilities automatically remove such protection.
Far more useful would be if we could stop people listing our programs. I have two methods of protecting programs against the LIST command.
Basic programs are stored in a tokenised form. For example, the command REM is represented in memory by the single number 197 which is called its token. It is possible to make listing and execution of a program impossible by placing an illegal token in it (one which cannot be reconverted into a command upon listing/execution). Try the following; Type in:
10 REM Illegal Token
20 MODE 2: PRINT"Okay"
The program is unlistable. Or, to be more precise, line 10 is unlistable. The REM has been replaced with 255, an illegal token. Line twenty remains valid. LIST 20 and RUN 20 prove this fact. However, RUNning line 10 will crash the machine. Such illegal lines need to be jumped over (e. g. insert line "1 GOTO 20"). The memory address 372 is the address of the first token in the program. So, unless the 372 is altered, only the first line may be protected in this way. It is possible to insert lines before the first one afterwards and the illegal line will be shifted along to a new address automatically. You might like to insert several illegal tokens, scanning the program for REMs (code 197). Bear in mind that not all 197s are REMs and that the apostrophe abbreviation for REM has a different token.
The second method completely scrambles your Basic listing. Make sure that you have an unprotected version saved before you experiment with it. The first command in the program should be:
This entered, PRINT PEEK(368) in direct mode. Now replace the 255 in the first command with the value produced. It should be clear that as it stands, this has no effect; it will now be poking into 368 what is already there when the program is run. But, try poking 368 with values between 1 and 255 in direct mode and then LISTing. You may wish to experiment to find the most suitable value for each program scrambled. Upon running, the program should be restored to full working health as long as the first command still works. From here, the protection racket can take over.
You may be concerned about scrambling data, for example in an adventure game. Reading an adventure game listing lays all its secrets bare. XOR is a logic function of BASIC. It's a bit like a maths operation, except it breaks a number down into its binary form and works on its constituent zeroes and ones. The same two numbers XORed together twice give you what you started with. XOR them once and you have a coded version which is decoded by XORing it with the number you started with. This book returns to XOR and related logic functions later on, but for now the Encrypt program (on the disc) demonstrates this application. Line 40 contains a scrambled message, Line 50 is the password that was used in scrambling it and will be subsequently used for decoding. Lines 60-80 decode the message and place the new version in c$. Each character in the message string is XORed with each character in the password string. With the password "BEWILDERED", the first character is XORed with "B", the second with "E" and so on. The password string starts from the beginning again when it's finished. It is difficult to decode the text without the password, since the character "E", for example, will have several different encrypted versions, depending on which character of the password it was XORed with. Try changing the password in a$. Programs I and II could be combined so that the password is entered by the user and then used to decode the data. If the password is wrong, the data will become re-scrambled.
It is possible to make the first line of a basic program have the line number zero by issuing POKE 370,0. Line zero is run as a part of the program when RUN is issued, but cannot be LISTed or jumped to. Nobody need ever know it's there: ideal for tucking away protection commands.
The final program protects basic listings from a multiface. It works by checking under interrupt for the presence of a device and if it finds one, it freezes the computer. This means that if a multiface is switched on at any time during the program's execution, everything will stop. This protects against multifaces with invisibility switches but will only offer hit and miss protection against those with automatic switches. Excessive? Certainly. Funny? Moderately.
However much protection a program is enshrined in, it can and will be cracked (if it's worth cracking).
Basic programs are a doddle compared to machine code.
Be careful, though: Sad as it seems, people lock themselves out of their own programs.
If it happens, it could teach you a new computer language altogether: a language characterised by spoken four letter and three letter words.
Chapter Four: A character building experience