"Rescue that Protected Basic Program!"

By Mike Steiner, Sierra Vista, AZ., MacTutor Contributing Editor

In my diggings into Microsoft BASIC, I found some interesting things about how a program is stored on disk. My ultimate aim is to be able to “crack” a protected BASIC program; I once lost a program because I had saved it as protected and did not have an unprotected back-up copy.

The information in this column is valid only for BASIC Version 2.0; the discussion and program are not valid for Version 2.1. Most of the data presented in ‘MS BASIC Tokens Explained’ in the July 1985 Mactutor do not apply to Version 2.1. Also, the program is for a 512K Macintosh. Change the starting memory location (Peekloc) for a 128K or 1024K Macintosh as described in ‘MS BASIC Tokens Explained.’

Each version of BASIC (Binary and Decimal) is coded so that the finder treats them as two different creators. This, I assume, is because of the incompatabilities between the two versions. See last month's discussion of how numbers are stored in the two versions.

Fig. 1 How Rescuit Works

Table 1 shows the creators, file types, and ID bytes of the various files used by Microsoft BASIC version 2.0. (See sidebar for a brief explanation of creators and file-tpes.) The four-letter codes in parentheses on the top line of the table are the identification of the creators of the files. The four-letter codes in the table show the file types. The hexadecimal numbers in parentheses show the first byte (ID byte) of the files. TEXT files do not have an ID byte.

Once a file is loaded, the ID byte tells BASIC whether the file is protected. TEXT files do not need an ID byte because BASIC knows it is a text file and loads it in as is, translating reserved words into their hexadecimal tokens. BASIC can load any text file and treat it as a program listing (sometimes with curious results if the file is not a program). Each version (binary or decimal) can load compressed and protected files that were created only by itself. However, you can use SetFile to change the creator ID to load a file from the ‘other’ BASIC. If you do this, I recommend changing the ID byte with a disk zap program such as fEdit. Keep in mind that if there are any non-integer numbers defined in the program listing, their format will not be proper for the ‘new’ creator.

Protected programs, in addition to being having a unique TYPE and ID byte, are encyphered. It appears that this encyphering in only in the Macintosh version of Microsoft BASIC; friends with CP/M and MS DOS versions have not encrypted files with their versions of Microsoft BASIC. I have not yet been able to decypher these files; I have however, devised an interesting solution!

Following is a discussion of how you can prevent losing access to protected programs. The method discussed will not work on programs already protected; it will, however, give you a ‘back door’ into future programs. It works because when a protected program is loaded, it is decyphered and resides in memory as if it had been loaded from a text or compressed file. However, LIST, PEEK, and a slew of other commands are disabled in the command window. These commands have not been disabled from running from within the program, and that is what allows us to recover the file.

Listing 1 is a subprogram called "rescueit" which may be appended to any program prior to saving it as protected. Save rescueit as a TEXT file and MERGE it to your program. To use it, type the name of the subprogram in the command window, answer one question, and wait until it says that it is finished. (The name of the subprogram is in effect a password, so I strongly recommend that you change it to a name that only you know; otherwise anyone who knows it can recover your program.) Your program will be saved as a file called “Ressurected.”

Rescueit asks whether you are using Binary or Decimal BASIC. It then opens a file called “res” for output and then PRINTs one byte (the ID byte for a compressed program in the version of BASIC you are using) to the file. It then PEEKs the program in memory and PRINTs it to res, one byte at a time. It then PRINTs five zeroes at the end of the file. Read ‘MS BASIC Tokens Explained’ to see why this is necessary. After closing res, rescueit renames “res” as “Ressurected” and changes the filetype from TEXT to MSBC or MSBB, as appropriate. Then it prints “finished..” on the screen and exits to the desktop. Calling a sub-program from the command window sometimes scrambles pointers and causes memory problems. By exiting to the finder, these problems are avoided. The next step is to re-enter BASIC, load “Ressurected” using the Standard File and save the program. The program is now saved in compressed mode, ready to run or be edited. This last step sets the creator. If this step is omitted, the program will still load and run, but only from within BASIC; the finder will not recongnize an application to run the program if it is double-clicked, and the file will have the generic document icon. The only difference between ressurected and the original program is that ressurected has an extra blank line at the end of the listing. If you understand how BASIC stores programs in memory, you should be able to figure out why this is so. The reason is printed in a question / answer session at the end of this article.

Use of the program is fairly straightforward. Assuming that you already have rescuit on your disk (Remember to save it as a text file, not as a compressed program.), write your program and save it as a text or compressed file. (Don't forget to always keep a backup file!) In the command window, type “Merge "rescueit".” This will cause rescueit to be appended to the end of your program. Then choose “Save As ” from the File menu. Save your program (with rescueit appended) as a protected program. Now, if you ever lose your backup and need to recover the protected file, load BASIC and open the protected file. Within the command window, type resuceit (or the name to which you renamed the sub-program). The routine will execute, and when it ends will tell you that it is finished and return to the desktop. Next, set the creator as described above. Whenever you use rescueit, start with the Macintosh turned off. As discussed in ‘MS BASIC Tokens Explained,’ if another application has been run before BASIC, sometimes BASIC programs do not load at the same memory location. Rescueit always assumes that the program loads at the same point. Illustration 1 is a brief schematic of the rescueit process.

File Types and Creator Bytes

File-type and creator (also called file-type and creator flags) are four-letter abbreviations that show the file type and which application generated the file. An application (i.e. a program that can be run by double-clicking it's icon on the desktop) is a file that always has the file-type APPL. All other files are known as ‘Documents’ and may have any file-type that the programmer chooses.

Applications without a defined icon use the generic application icon (the diamond-shaped paper with a hand writing on it). Documents without a defined icon use the generic document icon (a piece of blank paper with the upper right corner folded down).

The finder uses the file type and creator flags to know which document files can be loaded by a given application. A document is linked to it's creator by the creator flag. When a document and a program have the same creator, the finder knows to launch that program when you double click on the document icon; once the program is launched, the finder tells it to open the document. The file type flag has a number of purposes. The most common is to assign an icon to the file. All the desk-top icons used by a program are stored in it's ICN# resource. The finder uses the type and creator flags to assign the correct icon to the file. (However, for ducument files, a bit in the application called the bundle bit must be set to 1; otherwise, the link is not established.) Also, the Standard File (which contains the list of documents that you can open when you choose Open from the File menu within a program) uses the file type to determine which files may be opened. These files are not restricted to those created by the application; for example, Microsoft Word can open files created by Apple's Macwrite. However, you cannot open a Macwrite document with Word by double-clicking the document icon; you can only do it from within Word via the Standard File.

Two interesting features of Microsoft BASIC are that you can specify file types when loading a file from within a program by use of the FILE$(1) function; by using the NAME command, you can change the file-type of a file on the disk. Rescueit makes use of this latter feature to change the rescued program from a TEXT file to a BASIC compressed file; this step is necessary because the file is generated in the compressed format, but saved as a TEXT file.

So far as I have been able to determine, there is no way for a Microsoft BASIC program to determine which version of BASIC it is using. The prefix byte exists only on the disk, and is not stored in memory; FILES$(1) can read the file type, but not the creator; NAME likewise can change only the file type and name. Does anyone know how to read or set the creator of a file from within MS BASIC? MacTutor will pay $50 to the first submission that shows how to do it.

Table 1

Microsoft BASIC 2.0 Creator and File Type Codes

Mode Binary (MSBB) Decimal (MSBA)

Text TEXT TEXT

Compressed MSBC (F9) MSBB (FB)

Protected MSBD (F8) MSBP (FA)

Listing 1 - Rescueit

REM }|{ Marker for end of main program - don't change!!
SUB rescueit STATIC: REM Change the name “rescueit” of sub-program for 
password protection

prefixbyte(1) = &HF9:prefixbyte(2) = &HFB
filetype$(1) = "MSBC":filetype$(2) = "MSBB"
Peekloc(1) = 66999!: Peekloc(2) = 77001!

WINDOW 1,,(100,100)-(400,200),2
TEXTFONT 0
PRINT "  Which version of BASIC are you using?"
TEXTFONT 1
BUTTON 1,1,"Binary",(35,40)-(95,65)
BUTTON 2,1,"Decimal",(170,40)-(240,65)
WHILE DIALOG (0)<>1:WEND
buttonpressed = DIALOG (1)
Peekloc = Peekloc(buttonpressed)

WINDOW 1,"rescuit",(2,39)-(508,338),1
OPEN "res" FOR OUTPUT AS #1
PRINT#1,CHR$(prefixbyte(buttonpressed));

rescue1:
peekloc = peekloc +1
IF PEEK (peekloc) = &HAF THEN IF PEEK  (peekloc+1) = &H20 AND PEEK (peekloc+2) 
 = ASC ("}") AND PEEK (peekloc+3) = ASC      ("|") AND PEEK (peekloc+4 
) = ASC ("{")  THEN rescue2: REM Find marker
PRINT #1, CHR$ (PEEK (peekloc));
GOTO rescue1

rescue2:
FOR j = 1 TO 4
 PRINT #1,CHR$(&H0);
NEXT j
CLOSE #1
NAME "res" AS "Resurrected", filetype$(buttonpressed)

CALL TEXTSIZE (127)
PRINT: PRINT "Finished..";
SYSTEM
END SUB

Q: "Why does rescuit add a line feed to the end of a file?"

A: When rescueit (or any other file) is merged to a program, it is appended to the end of the program, starting on a new line. This generates a carriage return after the last line of the program. Then when rescueit runs, it looks for the REM line that starts the rescueit routine, and saves the program up to the last byte before the REM. This last byte is the carriage return that was inserted when rescueit was merged. A carriage return at the end of a program is treated by BASIC as a blank line.

For What It's Worth Dept.

Peter Wollschlaeger of Hildeseim, West Germany, sent in this little gem. Try it, you'll like it! Peter says "...the most information I ever got for a Mac programmer like me in Macworld was an ad to subscribe to MacTutor!" Peter also reports that trying to run the MDS Editor under Finder version 3.3 bombs. Update to 4.1 Peter. Then your only problem will be missing icons occasionally! (See top column right.)

program Bugged;
var
 r :  rect;
 left, top, right, bottom : integer;
 icon1, icon2, width :  integer;
begin
 left := 10;
 top := 10;
 right := 40;
 bottom := 40;
 width := right - left + 10;
 icon1 := 1;
 icon2 := 257;

 showdrawing;
 setrect(r, left, top, right, bottom);
 ploticon(r, geticon(icon1));
 setrect(r, left + width, top, right + width, bottom);
 ploticon(r, geticon(icon2));
end.