Protection Schemes

ON ERR…..

The ON ERR… command on the TS 2068 can be used to make your programs essentially “unbreakable”. If the first line of your program, for example, is:

1 ON ERR GOTO 9000

and there is a line 9000 of this sort;

9000 CONTINUE

any time a “break” error occurs the program will “CONTINUE”

Slightly nastier, and certainly terminal, is this line,

1 ON ERR GOTO 9000

Followed by:

9000 NEW

The meaning of this should be obvious.

For Password protection try:

1 ON ERR GOTO PASS

Where “PASS” is a line # containing a new ON ERR command and a password routine. E.g.,

Line #          CODE
PASS            ON ERR CONTINUE
PASS + 10       INPUT "PASSWORD",P$
PASS + 20       IF P$ = "PSWD" THEN STOP
PASS + 30       GO TO PASS

ACCIDENTLY ON PURPOSE

In addition to “disabling” the BREAK key, the use of ON ERR can also prevent hackers from stopping a program through the use of wrong data. As you may know, if you respond to an INPUT statement, after moving outside the quotes, with the keyword STOP, you create the error message: STOP IN INPUT, which halts the BASIC program.

Entering a character or string of characters when asked to input a number (INPUT without the “”), will have a similar effect. Good error trapping can help you avoid most such situations (e.g., always accept a string and translate it to numeric data, or better yet, use INKEY$), but ON ERR… is good in these situations, too.

It is virtually impossible for a hacker to break into a program on his 2068 if it is properly protected using ON ERR. Notice I said, “2068”. One easy and obvious way of defeating this protection is to load the program into a Spectrum. The ON ERR means nothing to that machine and the program will stop. The hacker then has only to remove the offending statement (or better yet, replace it with one of precisely the same length, using REM, perhaps) and re-SAVE the now-unprotected version of the program. ON ERR looks like this on the Spectrum ({).

THE DOUBLE BOGEY

ON ERR works fine once the program is loaded, but even on a 2068, can be defected by the hacker who writes his own “false” header and removes the autostart (more later or see back issues of LIST). Another trick to add to the arsenal for first line defense is the use of a dummy CODE load. Here, you save a program in parts, which looks much like a conventional LOAD (see last month) i.e., BASIC loader, screen, machine code section. However, the end of the screen load on the “code” section can actually be more BASIC. You might even fool the uninitiated into thinking you were using machine code, when, in fact, your program is completely in BASIC. Your BASIC loader had to be created seperately from the “real” program. It will load the real program as if it were CODE and then execute it. This is accomplished by first finding out where your variables and program start (the system variable) and end (for all intents and purposes, the variable E line). Subtracting these to get the program length, you will enter:

SAVE "SECRET" CODE PROG, LENGTH

First, of course, we need to “fix up” certain system variables (PROG, NXTLIN & VARS) in order to configure the system the way we want it. This can be accomplished by POKEing the correct values on better yet, by executing an LDIR just prior to SAVING the program.

Now, the BASIC loader tells the hacker practically nothing, as all it appears to do is load some “Code”. That “CODE”, of course, is the real BASIC program, which takes over as soon as it is loaded. To break into this kind of program, the hacker must use a header reader. Any start address below the normal address of PROG (e.g., like 26710) tells him that the “CODE” block actually contains BASIC. (See also, last years article “Breaking into Transylvania Tower”).

This same technique, and a little machine code should allow you to set up “real” and “phoney” BASIC areas. The “Phoney” BASIC program could be a non-functional simulacrum of your real program with just one little USR call which makes the jump and resets the start of BASIC.

Here’s a very simple example, all in BASIC. For your “real” program enter:

10 PRINT "GOTCHA"

We could check E Line now to see how long the program is, but let’s just assume 200 bytes. Now:

PRINT PEEK 23635+256*PEEK 23636

The number which appears on your screen is the start of basic. Let’s suppose it was 26710 (“norma” in a 2068). Enter:

SAVE "GOTCHA" CODE 26710,200 and SAVE this short BASIC program
CODE. Now:

New ("GOTCHA" is gone)
10 PRINT "LOADING CODE"
20 LOAD "" CODE 26810
30 POKE 23635,186:POKE 23636,104:RUN and SAVE this one with

SAVE "LOADER" LINE 10

Now New your machine again and enter:

LOAD ""

Rewind your tape and let “loader” play in. It will come up running. Now rewind again and play in “gotcha”. What happened?

Loader seems to have disappeared and gotcha which we saved as CODE is now, apparently, the only BASIC program resident. How did we do it? See those POKE’s in line 30. They tell the system that the Basic Program starts at 26810 (104*256+186). The 2068 then bythely follows orders and resets BASIC TO start at 26810.

RIDING the BREAKERS

If the ROM’s LOAD routine is actually LOADing a program(not some psuedo load routine within the code), most users know that they can BREAK into the program by using the break key during the loading sequence. Unlike the old ZX81 this does not cause a NEW. One way to partially break a program then, is to ride the break key. This is done by first timing the load using a stopwatch. The end of the header is often used as a starting place and the final beep of the load as the end. The hacker, knowing that the program takes, say, 32 seconds to LOAD, will then start the LOAD, but will hit the break key after 31+ seconds. If (s)he’s fast enough, he or she will get to see perhaps 99% of your program.

However, do you remember what comes at the end of a LOAD, after the BASIC program? That’s right, the variables area. By using specially assigned variables, you can make your would-be pirate want to jump ship. While it is standard practice to define variables within your program, this is not necessary with Sinclair BASIC. Try this in immediate mode:

LET a=10

Now enter this little program:

 10 GOTO 20
 12 REM define vars (phoney)
 15 LET a=100
 20 PRINT "The value of a is ";a
 25 GOTO a
 29 STOP
100 PRINT "Can't get here!"

A hasty look at the program would lead one to believe that ‘a’ was 100. It is not, you defined it as equal to 10 and it will remain that way unless someone GOes TO line 15 or RUNs the program.

This technique can be used to define all your key variables & even line numbers for jumps. If you put in enough of them, the pirate will probably get very discouraged, very soon. Unless, of course, he has a variables listing program, and an editor utility with search and replace commands, in addition to some other way to break your program from the outside. With these tools it would be child’s play to stop the program, list all the variables and their values. Substitution can also be done almost automatically. If you’ve protected your program with ON ERR first, the hacker will still have a tough time with 2068 programs. He’d have to read the header, and then either generate a false header, without autostart, or(simpler to write,harder to interpret) Load the program as CODE and search thru it for the variables area.