 |
 |
| Method |
|
| 4M1 |
|
Found on the 80T DFS version of Worlds Without Words by 4Mation.
Track 19 had a data CRC error and tracks 40-79 were unformatted. This prevented *BACKUP. Track 19 sector 9 had its length set as 512 bytes and was over-read such that locations &100 to &1FF in this sector contained data, which was checked by the boot program and, if not found, loading was aborted.
The disc was also a dual catalogue disk and a program called X swapped the catalogues as needed.
DEFEATING All files from the main directory were copied to side 0 of a newly formatted 80T disc and all files from the hidden, second directory were copied to side 2 of this disc. A program a.devices which loaded at &A00 in the loading chain decrypted itself by EORing all the bytes from the program with the encrypted portion. A second program was written to decrypt a.devices and a JSR call was changed to a JMP call at &A2D. This had the effect of returning to BASIC cleanly. The file was saved on the new disk.
The BASIC programs were all examined and all references to the second directory were removed and file names had ":2." added as a prefix. The title now ran as a double-sided disc.
|
|
| 4M2 |
|
A 4Mation protection method found on the Stretch title.
Track 39 has a sector with a data CRC error and from track 55 onwards the tracks are unformatted.
!BOOT issues a number of control codes to blank the screen. It sets PAGE to &2700 and CHAINs a file called "Loader".
The file, Loader, has a machine code component at &274E which is called first of all. This issues *FX114,1, *TV0,1, *FX4,1, *FX5,1, MODE1, performs some VDU19 commands, sets locations between &39F and &3A6 then issues a *RUN LOADER2, which loads and runs at &2800.
Loader2 EORs code from &281E to &28FF using bytes from &2800 to &281D. This code cannot be modified without destroying the encryption. A second program was written to perform the decryption. The decrypted code looked for the error on track 39 and halted if it were not found.
DEFEATING All files were individually copied to a newly formatted disc. The decrypted file "loader2" was modified to skip checking track 39 and the decryption code was bypassed. The title now works normally.
|
|
| 4M3 |
|
This 4Mation protection method was found on the Jacaranda edition, 3.5" disk version of Dinosaur Discovery.
The 3.5" disk was formatted to 320K on side 1, M format, but the disk size was wrongly reported as being 640K, L format. A check was made on side 2 for unformatted tracks.
There were a number of files missing from the catalogue and these were loaded by direct disk access by a machine code program, "L", which resided at &900 to &AFF.
"L" expected the X-register to contain a pointer in the range 0 - 18 to determine which file to load and run. All the files loaded were normal BASIC programs. PAGE was set as &1200.
DEFEATING "L" was modified so that instead of RUNning the BASIC pogram it LISTed it instead. Each BASIC program was loaded by *LOADing the modified "L", setting X% to the right value (0 - 18 but not 17) and CALLing &0946. The BASIC programs were saved to a freshly formatted disk as L0 - L18.
Each BASIC program, L0 - L18, was edited to change the X%=:CALL&946 statements to the appropriate CHAIN"L" instead. !BOOT was now simply CHAIN"L1".
All the files fitted on a single side of a DFS formatted floppy disk and would now run under any filing system on the BBC micro and all variants of the BBC.
|
|
| 4M4 |
|
This was found on the Telebook package. The system disk was 40T and had a protected catalogue. There were two dummy files in the directory which contained VDU21 codes to disable screen output. The disk size was also set to zero on T1 S1. Together these factors prevented *BACKUP and *COPY.
DEFEATING A disk sector editor was used to discover the file names on the disc. These were then individually copied onto a newly formatted blank disc. The correct title was added and the boot option set.
The copy now worked perfectly and could be copied as needed.
|
|
| ABEuropean 1 |
|
The floppy disk was formatted to 40 tracks but only the first 20 tracks were formatted. Additionally tracks from 13 onwards had +128 added to their sector numbers. The disk would not verify nor would it backup.
The catalogue showed only three files in the directory, !BOOT, BOOT and t.set1. !BOOT was machine code which loaded at &7000 and BOOT was also machine code which loaded at &900.
!BOOT checked for a correctly formatted disc and loaded a BASIC menu loader program. The loader program used code at &900 to load the component BASIC programs and machine code directly from the disk surface, taking into account the odd sector numbers.
DEFEATING !BOOT and BOOT were hacked so that, instead of running the respective programs, they loaded the code and exited cleanly to BASIC thus allowing the code to be saved onto a newly formatted disk. There were five such files hidden on the disk.
!BOOT and BOOT were no longer needed as the necessary files could be loaded via the catalogue. A new !BOOT was added which simply CHAINed the main loader program. The other programs were also modified to CHAIN the respective BASIC programs rather than calling code at &900 to load and run them.
The program now runs properly on all variants of the BBC micro and filing systems.
|
|
| Ampalsoft 1 |
|
The tapes themselves were unprotected. However, the BASIC programs were un-listable due to having the &FF byte after the last &0D in the program replaced with &00. The tapes would run correctly due to RUN[CR] being placed into the keyboard buffer after the programs had loaded.
In addition the file names of the main programs of the title contained obscure control codes, which would make copying difficult.
DEFEATING This was quite easy but tedious. Each BASIC program was loaded and the &FF byte inserted. The programs whose names contained control codes were simply saved with alphabetic names.
Each program in the suite had its own loader, which set the user defined characters and placed some data values in zero page.
|
|
| ASK1 |
|
This was a 40/80T disk. Side 0 was formatted to 40 tracks and side 2 was formatted to 80 tracks. The disk was write protected, having no write enable cut out.
The disk catalogue showed all the files used by the title. When copying the files all the files in directory O and two files in directory $ would not copy, reporting a 'disc error' when using a 8271 DFS and showing as 'execute only' with a 1770 DFS on a Master.
Scanning the disc showed that track 2 was formatted to 11 sectors of 128 bytes each. Tracks used by the files reporting errors were found to contain a mixture of normal data sectors and deleted data sectors. A file PROC was used to cover track 2. This file was a dummy entry in the catalogue.
A file BOOT controlled the checking for a copied disc and controlled the loading of the files having deleted data sections. BOOT also checked the sector IDs in track 4 to determine whether to run from side 0 (40T) or side 2 (80T). Most of BOOT was encrypted and ran at &0400 onwards.
DEFEATING Firstly BOOT was decrypted. This was accomplished by loading the code to &1400. Several bytes were changed so that the decryption code referred to page &1400 rather than &400. In addition a RTS code was placed at &13FF and a branch altered to point to this address after the decryption was finished.
On examining the decrypted code it was noted that the BOOT code loaded directly and ran the protected files using the track and sector details given in the disk catalogue.
A custom copier was written to load the protected files directly from the disk surface and then to write them back to a newly formatted disk. A short BASIC program was written to load the splash screen and action the menu, running the different sub-programs as required. This meant that BOOT was no longer needed.
The end result was a disk containing all the programs which would run on any BBC Micro variant. The software would also run from any filing system on a Master. The software expects PAGE to be able to go as low as &1500 on a Model B/B+ so that if NFS+DFS or ADFS are used on the B/B+ a routine to move the code down to the required PAGE will be needed./p>
|
|
| AVP 1 |
|
The catalogue was hidden by placing a VDU21 control code in the last character of the title string. This effectively disables VDU output. In addition the first file name was ![12][3]AVP[21]. The control codes cleared the screen, switched off printer output and disabled the VDU.
Additionally the disk had only the first 20 tracks formatted, thus preventing *BACKUP.
*COPY *.* was prevented by the control codes in the first file.
DEFEATING A new 40T disk was formatted. The file names were read from track 0 sector 0 of the original disk using ADI. Using *COPY 01 B* copied the files beginning with B and this method was used for all the files on the original disk. !BOOT was also copied using *COPY 01 !BOOT. The boot option was set to RUN using *OPT 4 2 and the disc worked and could be archived.
|
|
| AVP 1a |
|
As AVP1 but with additions.
The disc title had CHR$(12) as the first character which would clear the screen. All file names except !BOOT were three random characters. Several of these files were repeated but with CHR$(21) and CHR$(12) added as part of their file names. This would make casual copying very difficult.
|
|
| AVP1b |
|
As AVP1 but with additions.
The disc title had CHR$(12) as the first character which would clear the screen. All file names except !BOOT were three random characters. Several of these files were repeated but with CHR$(21) and CHR$(12) added as part of their file names. This would make casual copying very difficult.
In addition the disc included a file, often called !XX or !!, which would not copy as its sector address occupied an unusually formatted area of the disk. This would prevent *BACKUP.
|
|
| Bad size |
|
The disk has the size parameter wrongly set in sector 1 of track 0.
DEFEATING The files were simply copied to another correctly formatted disc. The disc title was copied and the boot option correctly set. This new disk worked perfectly and would archive correctly.
Another method used was to clone the disk and then use a disk sector editor to set the correct disk size for the clone.
|
|
| BBC Picture Craft |
|
This was supplied on a 40T floppy disk. !BOOT was a short machine code file which seeks track 0 and then *EXECs the file !B. !B sets several resident integer variables, loads the splash screen and then CHAINs the menu program.
The menu has a machine code routine appended above TOP. This routine is moved down to &900 and executed. The routine reads a single sector from the disc, track 27, sector 9 and places this at &A00. The code at &A00 is then compared to the code at &900. If the code matches all is well and the routine returns to BASIC. If the two sections of code do not match the program outputs the message Disc badly copied and hangs.
In addition the disc size and number of files available are wrongly set. This effectively prevents *BACKUP from working. *COPY *.* also will not work due to the data hidden on track 27.
DEFEATING All files were copied across to a new, formatted disc using *COPY *.* . Using the new disc, !BOOT was deleted and !B renamed as !BOOT. The disc boot option was changed using *OPT 4 3.
The only purpose of the code above TOP in the menu program was to check if track 27 sector 9 contained the correct data. The call to this routine was removed from the menu program and this was saved over the old program. Lastly the title of the new disc was set to match the original disc as the program checks the disc title.
|
|
| BES1 |
|
This method was discovered when attempting to archive Happy Letters from a
cassette tape. The tape was unprotected in that the two files on the tape could
be read and copied to another tape or to a disc.
The first file on the tape was a loader for the main program file. This file
contained a short BASIC program that CALLed a machine code routine residing at
TOP. This machine code routine checked if PAGE were &6000. If not the code
relocated the file to &6000, set BASIC's pointers to point to the BASIC program
at PAGE=&6000 and exited back to BASIC.
This caused the short BASIC program to execute a second time. This time,
however, PAGE was at &6000 and so the relocation code was skipped.
The machine code at &607A was executed and performed several functions;
- Output text on the loading screen,
- Re-directed WRCHV to some of its own code,
- Moved code into page &A00,
- Moved some BASIC program code down to page &E00 (this code was
incomplete),
- Set a buffer to contain the string LOAD [&A0]HLETTERS 1D00[CR],
- Displayed the string on the loading screen,
- If the character &A0 were missing from the start of the filename the
code would hang in an endless loop,
- Placed a * character at the beginning of the buffer and executed the
buffer as an OSCLI command (part of the re-directed WRCHV code),
- Moved the contents of the file just loaded to reconstitute the full
BASIC program,
- Restored WRCHV,
- Set the BASIC pointers to the program now residing at PAGE=&E00 and
exited back to BASIC, causing the main program to execute.
The protection was, therefore, several fold. Firstly copying the files from
the tape was prevented by the &A0 character at the start of the HLETTERS file.
Next the BASIC program was jumbled so that it could not be read until it had
been re-assembled in the correct order. Lastly a *FX200,3 command was issued to
stop anyone using [Break] to retrieve the working program.
DEFEATING
As the cassette was unprotected the files were copied onto an ADFS format
disc using ADT. The initial idea was to convert the code to run from disc.
The &A0 character at the start of HLETTERS was not copied and was replaced by
a ? character. This file would not be loaded correctly by the loader program.
Two changes were made to the loader program and these involved replacing the
byte &A0 with &3F, the ASCII for a ?, in the OSCLI buffer.
The files recovered were copied to an SSD image, ?HLETTERS being shortened to
?HL
Using the excellent DiscImage Manager from Gerald Holdsworth, a UEF image was
created and the files HL (modified) and ?HL were imported. ?HL was renamed as ?HLETTERS
and then the image was saved.
The title now runs perfectly from the tape UEF image and also runs on a
Master from an ADFS disc.
|
|
| CMS2 |
|
This method was found when preserving Tessellations from Cambridge Micro Software. The package contained two 40T disks. One, a library disk, was not protected. The other, the system disk, was also 40T and had the catalogue hidden by use of a VDU21 code as the disk title.
All tracks of the disk were formatted but the head number for each sector was set as 171 (&AB), effectively preventing *BACKUP and *COPY from working since the head number would be 0 for the copy and the software would not load.
!BOOT was a short machine code program which loaded and ran at &3000. It firstly read the sector IDs for Track 0, Sector 0, checked that the head number was &AB and placed it in &81. If the head number was not &AB the code entered an endless loop and nothing else would load.
After calling miscellaneous OSByte routines to disable access to the running program and outputting various VDU codes to disable the screen, !BOOT then EORed the value in &81 with part of itself from &30D1 to &30F9 to decrypt a function key definition.
The function key definition was;
*KEY0M%=?&81:F%=1:W%=0: PA.=6400:CH."P"|M
Following this definition the command *FX138,0,128 was issued and !BOOT returned to BASIC.
DEFEATING All files were copied individually from the original disk to a newly formatted 40T disk.
Method 1:!BOOT was replaced by a short text file;
M%=171:F%=1:W%=0
PAGE=&1900:CHAIN"P"
and the disc boot option was set to EXEC
Method 2:!BOOT was modified to remove the code reading the head number and instead directly placing 171 into location &81.
The unprotected title will run properly only from DFS. It will run from RAMFS on a Datacentre with the exception of the set up program, SYSTEM. It will run from ADFS but cannot load library examples or run SYSTEM.
|
|
| CMS3 |
|
The disk was a 40T variant and the catalogue was hidden by adding a VDU21 code to the disk title.
The file !BOOT loaded BASIC files from the disk surface.
The disk catalogue sectors (T0S0 and T0S1) contained messages to the potential hacker;

In addition tracks 1, 7, 19, 20 and 38 were not formatted.
DEFEATING This was very simply achieved by using ADI2 to copy tracks 0, 2-6, 8 to 18, 21 to 37 and 39 to a newly formatted 40T DISC.
This protection means that the title will only work under DFS as there is direct disk surface access.
|
|
| CMS4 |
|
This method was found when preserving Image from Cambridge Micro Software. The package contained a single 80T disk which was a clone of the original. The clone, however, only contained the data for a 40T disk. The catalogue was hidden by use of a series of VDU21 codes as the disk title.
All tracks of the disk were formatted but the head number for each sector was set as 171 (&AB), effectively preventing *BACKUP and *COPY from working since the head number would be 0 for the copy and the software would not load.
!BOOT was a short machine code program which loaded and ran at &2000. It firstly read the sector IDs for Track 0, Sector 0, checked that the head number was &AB and placed it in &81. If the head number was not &AB the code entered an endless loop and nothing else would load.
After calling miscellaneous OSByte routines to disable access to the running program and outputting various VDU codes to disable the screen, !BOOT then EORed the value in &81 with part of itself from &20DB to &20FA to decrypt a function key definition.
The function key definition was;
*KEY0*BASIC|MR%=?&81|MCH."RK"|M
Following this definition the command *FX138,0,128 was issued and !BOOT returned to BASIC.
In addition one of the component programs of the suite loaded the disk catalogue into pages &900 and &A00 and checked for a byte of value &54 at &90F. This corresponded to the directory letter of the file T.S. After this the bytes at &A0E and A0F were checked to see they matched &01 and &3E. If all these bytes matched the software would run. If not the computer entered an endless loop.
DEFEATING
All files were copied individually from the original disk to a newly formatted 40T disk. However, the order of copying was important to make sure that the file T.S was in the correct position in the disk catalogue. The files had to be copied one by one in reverse order.
!BOOT was replaced by a short text file;
*BASIC
R%=171:CH."RK"
and the disc boot option was set to EXEC with *OPT 4 3
The image now works properly on a BBC model B or on a BBC Master but from disk only due to the frequent sector accesses. It will work correctly from a Datacentre RAM disk if the *DTRAP command is issued first.
|
|
| CMS5 |
|
The disk was formatted to 40 tracks with a hidden catalogue. The last byte of the disk title was a VDU21 code, which disabled output to the screen. The last file name on the catalogue ended with a VDU6 code, which enabled the VDU output. Just to make this more effective, the first file name in the catalogue was a repeat of the disk title so that even if one did a *TITLE "" command it would appear as though nothing had happened.
Physically the disk was formatted in a way that stopped copying. Track 9 was not formatted; this would stop *BACKUP. The first and last files in the catalogue were dummy files and had their length set to a size very much bigger than the size of the disk. Not only that but also their file names contained con-alphanumeric characters. Both of these factors prevented *COPY 01 *.*. On detailed investigation of the disk format it was found that tracks 10 to 14 inclusive had logical track numbers twice their physical track number; all other formatted tracks were normally formatted. Tracks 10 to 14 contained no data except for track 10 sector 0, which contained a copyright and acknowledgement message.
There was only one active file on the disk and this was !BOOT. In addition, on some titles, there were user changeable data files needed by the program. !BOOT was a machine code file &400 bytes long, which loaded at &400 and which ran from &416. The purpose of !BOOT was to load and execute the main software and to check that the disk had not been copied.
!BOOT was a program of three apparently separate parts;
Part 1 - This occupied the code from &400 to &415. It contained data and a subroutine to decrypt the code from &4AF to &7FF,
Part 2 - This was apparently the main body of the code and appeared to run from &416 to &4AF, exiting with a jump to an RTS code in the middle of part 3,
Part 3 - The main section of the code was gibberish. This was encrypted and could only be run after decryption by the code in part 1.
Part 2 of the code on inspection was a labyrinthine program obviously designed to obfuscate and hide its true purpose. Machine code instructions were used as data, the program self-modified, often several times on the same byte, zero page locations were used to pass data to part 3 of the code and new return addresses to subroutines were placed on the stack at widely differing places. The code was written in such a way that very little could be done to insert exits to BASIC to examine what was going on as the programmer had used the obvious entry points as data items and had very early on placed values on the stack to prevent a clean exit to BASIC.
Part 3 of the code, readable after decryption, checked that the disk was the original one and that !BOOT had not been edited to allow the hacker to gain access to the main program code. Track 9 was checked to see if it was unformatted and a data read was attempted from track 10 sector 0 to check that the logical track number was correct. The code also checked that *FX200,3 was still active.
These checks were scattered throughout the code so that the title would load to a different point and then stop depending on where an error was detected. When the loading process halted various error messages were displayed and even 'legal' threats to the potential hacker.
DEFEATING
The first step was to clone the original disk onto a newly formatted 40 track disk. Tracks 0 - 8 and tracks 15 - 39 only were cloned, leaving tracks 9 - 14 as empty, formatted tracks. All further actions were performed on the cloned disk.
Part 2 was the major hurdle in that it took a very long time to work out what it was doing. One could not edit any of the code in part 2 or else the code would not work properly. To get round this the code for part 2 was assembled independently and run a small part at a time to identify the return addresses written to the stack. Any data needed from the !BOOT code were entered as immediate mode operands. Where data were pushed onto the stack, these instructions were omitted. Despite its complexity, part 2 of the code did two things, namely running the decryption subroutine and then running the decrypted code.
A short BASIC program was written which performed the decryption so that the code of part 3 could be read. Since the decryption involved EORing each byte with &16, the same program could be used for encrypting part 3 as well - useful later on.
The newly decrypted code of part 3 loaded data and program code directly from the disk surface. At three points checks were made followed by a jump to a break instruction, used to display a message to the user if the code detected that the disc was not original. These checks were replaced by NOP instructions rendering the checks non-existent.
The edited code was encrypted and then used to replace the original !BOOT on the cloned disk.
Once the function of the loader program was determined defeating the protection proved to be very easy to accomplish. Only four points in the code needed to be changed (The actual addresses of these changes in !BOOT varied depending on the title protected but the changes were always the same.).
Due to the intensive sector access, titles protected by this method can only be run from DFS.
|
|
| CMS6 |
|
The catalogue was hidden by placing a VDU21 code as the last character of the title.
The disk was dual format 40/80T. Tracks 1, 3, 10 and 20 were unformatted. Tracks 11 to 19 inclusive were the 80T section. There was no other protection.
DEFEATING The disk was cloned using ADI on a BBC micro using an 8271 DFS. The VDU21 code was replaced by the code for a space in the title.
Using ADI on the disk set to 40T in a dual disk drive, tracks 0, 2, 4-9 and 21-39 were copied to a newly formatted 40T disc. The destination disk would now verify and could be easily copied and/or backed up and would work correctly.
The disk would not work with MOS 3.50 on a Master.
|
|
| COIC1 |
|
This was a protection method discovered whilst archiving "The Game's the Thing". Firstly the disc size was set to just the first track, which contained !BOOT. !BOOT, BOOT and BREAK were the only files on the disc catalogue. This simple method would prevent *BACKUP and *COPY from working.
The file !BOOT set values in locations &3AA to &3AC inclusive then ran BOOT, which loaded a program depending on the value in &3AA. All these programs were in BASIC, loaded at a set value for PAGE and executed.
DEFEATING The original disc was cloned using ADI to a newly formatted 40T disc and the size bytes reset on the clone. The clone was used to extract further data thus protecting the original disc.
!BOOT placed 0 into location &3AA. This caused BOOT to load the first program. BOOT was modified so that the RUN command was changed to LI., the abbreviation for LIST. BOOT would now set PAGE to the correct value and LIST the program. *FX3 was needed to allow the listing to be seen.
The first-loaded program was saved onto a new, formatted disc as START. It was discovered also that this program, which loaded at &1900, had some hidden graphics data running from &1C00. These data were saved to a separate file, GFX and *LOADed when needed.
Each program recovered from the disc was listed and examined and found to contain the instruction ?&3AA=n:*RUN BOOT. n was found to have values from 65 to 72 inclusive. These values were used to recover all the individual component programs of the title and these were saved as PROG1 to PROG8 on the new disc.
Each occurrence of ?&3AA=n:*RUN BOOT was edited to CHAIN"" and the programs re-saved. A new !BOOT was created which simply set PAGE to &1900 and CHAINed the START program.
|
|
| COIC2 |
|
This method was discovered when archiving RotaView from COIC. The system disc
was 80T double-sided. The disc would not verify indicating errors on Track 1 and
Track2.
Track 1 was not formatted and Track 2 was formatted to 18 sectors of 128
bytes.
A program !B read 14 sectors of data from Track 2 and loaded them at &7800.
The data overlapped screen memory in MODE7 and produced a loading splash screen,
the top line of which contained a jump address and a checksum to compare with
one generated whilst decrypting code to be moved down to page &900. These bytes
were hidden by a conceal code as the first character of the line.
The data loaded by !B contained code from &7B00. This code checked that Track
1 was unformatted. Whilst moving code down in memory to page &900 a checksum
generated was compared with a value on the top line of the screen.
In addition the database disc was not a standard BBC format, there being no
catalogue in Sectors 0 and 1 of Track 0. This disc was read using OSWORD &7F by
the system software.
DEFEATING
A new 80T double-sided disc was formatted.
A custom program was written to perform the following functions;
- Copy Track 0 from the original disc to the new disc,
- Read 14 sectors from Track 2 on the original disc to a buffer in memory
and then write that from the memory buffer to 7 sectors on Track 2 on the
new disc.
- Copy Tracks 3 to 79 inclusive from the original disc to the new disc.
Using Advanced Disc Investigator Track 2 Sector 3 was edited on the new disc
so that bytes 5, 6 and 7 read &4C, &18, and &7B (JMP &7B18). This skipped the
check to test that Track 1 was unformatted.
The program !B was edited so that &1B41 was changed fro &0E to &27. This
changed the OSWORD &7F read to work with standard 256 byte sectors on Track 2.
After these minimal changes the system disk ran perfectly and was now a
normal 80T disc. The software would only work from DFS, MMFS or RAMFS on a
Datacentre.
To create an archive of the database disc a custom program was created to
perform the following functions on a newly formatted 80T double-sided disc;
- Copy Tracks 1 to 79 inclusive from side 0 to side 1 of the new disc,
- Copy Tracks 1 to 79 inclusive from side 2 to side 3 of the new disc,
- Read Track 0 of side 0 and save as a data file of length &A00 on a
different filing system,
- Read Track 0 of side 0 and save as a data file of length &A00 on a
different filing system.
The new disc was archived to a DSD file and the Track 0 data were also
archived to a SSD file. Both files were loaded into a BBC emulator, in this case
BeebEm. A custom program was written to *LOAD the Track 0 data into a memory
buffer and write it to the respective sides of the database disc. The DSD disc
now contained a faithful copy of the RotaView database disc.
|
|
| CSH1 |
|
This protection method was encountered when archiving Archaeology from Cambridgeshire Software House Ltd.
The disc was single-sided 40 Track and protected from copying. Track 1 was formatted as 4x512 byte sectors and tracks 17-19 inclusive were not formatted.
In addition the catalogue contained two files $.INSERT and $.MAIN[09]. In both cases the directory byte had the top bit set.
!BOOT was an EXEC file which CHAINed a file called $.LOADER. This file set MODE7 and HIMEM to &7700 and then transferred two blocks of memory from above TOP to reside at &7700. Firstly a block of 128 bytes from TOP to TOP+&7F was moved to &7800 and then a block of 265 bytes from TOP+&800 to &7700. These were machine code programs used to display the program splash screens.
The code then determined the OS and filing system in use. The OS determination used!&FFFC to check if OS was .1 or 1+. Consequently only a BBC micro model B would run the program.
Finally the LOADER program CHAINED $.MAIN. The program $.MAIN loaded and ran the program INSER, which in turn loaded and de-crypted a BASIC menu program from track 1. When LISTed the MAIN program showed a single line CALL&973. This was a bogus command and [08] characters were used to erase the actual command *INSER when the program was listed.
DEFEATING The disk was cloned using ADI2 and the cloned catalogue was edited to remove the top bit set character for the directory of $.INSER. This meant that the file $.INSER could be loaded normally.
A freshly formatted 40T disk was prepared to receive the hacked files. All saves were made to this disk.
$.LOADER was loaded and the value of TOP determined. The first &400 bytes of data above TOP were saved as a file SCRN1 and the next &400 bytes as a file SCRN2. These SCRNx files were the splash screens used by the program.
$.MAIN was not needed and deleted from the final archived disk.
INSER loaded and ran from &900. It was protected from change by the expedient of using every byte in PAGE &09 to decrypt the code of the menu program after it had been loaded. PAGE=&1900, OLD and RUN were placed in the keyboard buffer and the INSER program terminated.
Code from &900 to &9FF was copied to &C00. The version at &C00 was edited so that instead of the token for RUN being placed in the keyboard buffer the token for REM was used instead. This allowed the menu program to be saved as $.MENU when the code was called from &C00.
The LOADER program was edited so that it displayed the initial splash screen and after a delay CHAINed MENU. The INSER code was no longer needed and deleted.
The other files used by the package were copied across to the final archive disk.
The package now runs on all variants of the BBC micro and on all filing systems tested.
|
|
| E-attribute |
|
This method is found only on ADFS format disks.
A file with the E attribute set can only be run or deleted. It cannot be copied nor will its details be shown with *INFO or *EX. This is a feature of the ADFS filing system to help prevent software piracy.
DEFEATING There are two methods.
- The E attribute sets the high bit of the first character of the file name. A disk editor program can be used to clear this bit. Using the original disk could be dangerous as the surface may be damaged by use. Sometimes this is the only way, however.
- Using an A5000. The A5000 ADFS in RISCOS 3.11 does not appear to be affected by the E attribute; the A5000 ignores it. Hence a protected file may be copied to another disc using the A5000. This only works for a disk formatted as 80 track, 640K.
|
|
| ED1 |
|
This method was found on Edsoft's Zap the Numbers.
The disc had a hidden catalogue and the disc size bytes were set to &4E tracks instead of &4F. This prevented *BACKUP 01 and *COPY 01 *.*
!BOOT CHAINs a program, INTRO, which checks if Track 79 is formatted by loading all sectors of track 79 into a buffer and then looking for a letter A character code at 684th position in the buffer. If the letter A is missing or the track is unformatted the program hangs in a continuous loop.
Defeating
Advanced Disc Investigator (ADI) was used to read the names in the hidden catalogue. These were individually copied to a newly formatted disc thus bypassing the hidden catalogue.
A simple GOTO statement bypassed the protection used by the INTRO program.
|
|
| EMR1 |
|
This method was found when archiving EMR Midi Track Notator 1.
The disc was dual format 40/80T. All files copied to a newly formatted disc except the file EMR2. This had an odd sector number in track 2; sector 8 is numbered 24.
The package is started by *EMR {Return]. The code checks for the odd sector number in T2S8, decrypts itself by EORing with &FF and then performs *KEY0CHAIN"COMPOSE"|M followed by *FX138,0,128[Return] and exits to BASIC.
In addition *EMR placed &1A into zero page location &95.
COMPOSE loaded and ran several small programs which set variables and loaded some machine code routines.
All the BASIC programs were made unlistable by replacing the &FF byte after the last [CR] with &00. They were *LOADed and RUN.
DEFEATING A !BOOT file was added to the new disc. This contained ?&95=&1A followed by CHAIN"COMPOSE".
All the EMR BASIC programs were made listable by replacing the &FF byte and saved to the new disc. The file EMR2 was not needed; this was just a dummy file to hide T2S8.
A new file CHARS was created to create the user-defined characters needed for the Master; this also worked for the model B and B+. The new disc now ran on all variants of the BBC micro.
|
|
| EMR2 |
|
This is a variation of the EMR1 version of protection.
The supplied disk was 40T formatted such that Track 2 Sector 0 had a non-sequential sector ID; Sector 8 had the ID 24. This simple expedient prevented *BACKUP and *COPY *.* from working.
In addition the main program files did not appear in the disk catalogue but were loaded directly from the disk surface. This prevented just copying the listed files.
DEFEATING Tracks 0-1 and Tracks 3-39 were copied to their corresponding tracks on a freshly formatted 40T disk.
The file EMR6, called from the BASIC program PERFORMER was edited to bypass the checking of Track 2 Sector 8's sector ID. EMR6 was re-saved. There were no data in Track 2 Sector 8.
The copied disk now ran correctly on all versions of the BBC micro but only from DFS.
|
|
| ESM1 |
|
!BOOT was a machine code file which was encrypted. The code firstly decrypted itself by EORing with every byte in the file. This could not be intercepted as it would change the code being EORed.
The disc was formatted to 80 tracks but runs at 40 tracks. This effectively prevents *BACKUP working.
After decryption !BOOT loaded data from hidden sectors on the disk surface to location &2000. This code ran and loaded a second disk catalogue into memory to allow the component files to be accessed normally.
Track 0 sectors 3 & 4 held the new catalogue.
DEFEATING Once the protection mechanism had been worked out unprotecting the disk was actually very simple. The second catalogue from sectors 3 and 4 from track zero was moved to replace the first catalogue in sectors 0 and 1. *COPY *.* moved all the files from the protected disk onto a newly formatted disk and the software ran happily from there.
A side effect of unprotecting the disk was that the software will now run on all filing systems.
|
|
| ESM2 |
|
The disc size parameter was changed to prevent *BACKUP working.
!BOOT was a machine code file that checked to see if Track 0 Sector 3 was present, which it would not be if *COPY had been used to copy the catalogued files from one disc to another.
Track 0 Sector 3 was loaded at &1800 and executed at &1816. This code then ran the title.
DEFEATING The file !BOOT was edited so that the jump to &1816 was changed to RTS. This returned to BASIC and allowed the code from &1800 to &18FF to be saved as !BOOT. The disk ran correctly now and could be copied using *COPY *.
|
|
| ESM3 |
|
The disc size bytes (bytes 6 and 7 of Track 0 Sector 1) were set to show a disc of zero size and the number of files on the disc byte was also incorrectly set. In addition there was one hidden file in the catalogue and several dummy files which had very large file lengths set. These factors will prevent *BACKUP and *COPY being used.
Apart from the main menu program, the other BASIC programs on the disc were encrypted. The encryption prevented the programs from being examined. When these encrypted programs were executed they immediately jumped to a subroutine at line 22000. This subroutine read two bytes from the page &F copy of the disc catalogue held in memory on a BBC model B. These bytes were at &F07 and &F0F and contained &00 and &FF respectively. The bytes were added together and used to seed the random number generator of BASIC. RND(255) was used to decrypt each byte of the main program before the program was executed. Lastly, each of these decrypted programs read data directly from the disc surface, further protecting the software from being copied.
DEFEATING
Making a disc image of this title proved to be very simple. The disc was formatted to 40T and, apart from the bad size byte, was correctly formatted with no missing tracks or faulty sectors.
Firstly the original disc was cloned using Advance Disc Investigator 2. Track 0 Sector 1 was edited to put the correct size values into bytes 6 and 7 (&31 and &90). This clone could now be imaged using a Datacentre.
The image, however, would not work as the size bytes were 'wrong' for the software. This was rectified on the image by writing a short program to read T0S1, re-set the bytes and write the sector back again.
|
|
| FS1 |
|
This was discovered on an FSoft title.
Tracks 2-4 inclusive were not formatted thus preventing *BACKUP working. There were no hidden data on the disk.*COPY *.* was prevented from producing a working copy by checking the number of times the disc had been written. If the value in byte 5 position on track 0 sector 1 were not 64 then the program would execute Break.
DEFEATING All the files were copied onto a newly formatted disk. A disk editor was used to set byte 5 on track 0 sector 1 to read 64.
The unformatted tracks were not checked - this was a purely passive protection method. The disk now runs correctly though it must not have any write accesses.
|
|
| FWS |
|
This is a method devised by Fiveways Software. It is found on several Heineman titles, for example.
The catalogue cannot be viewed due to VDU21 and VDU23 characters in the disk title. When *CAT is used the string (c)FWS appears and the computer appears to hang.
There is only one file in the catalogue, !BOOT. This is a machine code file resident at &7000 to &7FFF.
The !BOOT file handles a lot of the protection mechanisms. Amongst other things !BOOT does;
- calls various OSBYTE routines to disable possible interruption of its working,
- resets FILEV and BREAKV to point to its own code in page &700,
- Disables all ROMs except DFS and BASIC,
- Copies part of itself down to &700 to &7FF,
- Checks for memory size and working tube presence and exits if these are incorrect,
- Checks for OS1.0 or above.
The code at &700 is responsible for loading files from the disc surface and decrypting them by adding &41 and EORing with &97. The new FILEV points to this code.
The RAM-based disk catalogue at &E00 to &FFF is modified to include an entry for a BASIC file called A. This is CHAINed and uses the code at &700 to *LOAD the needed files and decrypt them on the fly. These files are then moved down in memory and RUN.
In addition tracks 1 and 2 are specially formatted. Track 2 is formatted with 1 sector of 128 or 256 bytes and numbered 147. Track 1 is formatted as 8 sectors of 256 bytes if Track 2 is formatted with one sector of 256 bytes or one sector of 2048 bytes if Track two is formatted with one sector of 128 bytes. Track 1 is deleted data.
Most of the other tracks are deleted data but even amongst those there is the odd track that is normal data.
Tracks 24 onwards are not formatted.
DEFEATING Thanks to billcarr2005 from the StarDot forum for cracking this protection and providing the working SSD files in the downloads.
|
|
| FWS V1 |
|
This is an early variant of the generic Five Ways Software (FWS) protection mechanism and was first encountered on the Scales title for Heineman Educational Software.
The disc was an 80T DFS title with the majority of the tracks unformatted and the formatted tracks used non-standard formatting. There was only one file in the catalogue, !BOOT which was a large machine code file.
Tracks 0 to 10 inclusive were formatted and tracks 11 to 79 were unformatted. Track 0 was formatted normally with 10 256 byte sectors, Track 1 had 1 sector of 2048 bytes, Track 2 had 1 sector of 128 bytes and the sector ID was 147, Track 3 had 5 sectors of 128 bytes, Tracks 4-10 had 5 sectors of 512 bytes.
!BOOT loads at &7000 and perfoms the following actions;
- disables the Escape key
- changes the Break Vector to point inside !BOOT
- disables the VDU and the printer
- switches off all ROMS except for BASIC and the DFS
- checks for either OS1.00 or OS1.2 and sets vectors accordingly and runs code directly from the OS ROM (this prevents the title running on a model B+ or on a Master)
- runs a lot of code designed to confuse the reader, in particular placing a number of return addresses on the stack so that a RTS instruction in the code jumps somewhere unexpected
- changes read and write character vectors to point to its own routines (this intercepts LOAD and CHAIN commands redirecting them to a custom DOS)
- copies a file loading routine down to page &700. This code is entered by a call to &710, which loads the custom DOS to &10E0, decrypts each byte by adding &41 and EORing with &97 and sets the load vectors to point to this routine
- finally the code writes a small BASIC program;
10 CALL&710:CHAIN"A" enters BASIC and RUNs this program
CHAIN"A" is intercepted by the custom DOS and loads the program directly from the disk. "A" is a small loader program which loads the title screen and then CHAINs the main program, "SCALES".
DEFEATINGOnce the protection method was understood, defeating it was surprisingly very simple.
A blank, 80T formatted disk was placed in drive 1. Drive 0 held the original disk.
Exmon II was activated and !BOOT loaded from the original disk. A subroutine at &71A6 was executed to move &200 bytes down to page &700. The subroutine at &710 was then executed to install and decrypt the custom DOS.
After quitting Exmon 2 into BASIC, "A" was LOADed. A *FX200,0 command was then issued (this may not be strictly necessary but was done just in case) and Break pressed followed by OLD. This enabled the program "A" to be saved onto drive 1 and LISTed to see which other files needed to be loaded.
The process of executing the subroutines and then loading the respective files, pressing Break and then SAVEing or *SAVEing as appropriate recovered the files from the disk surface.
The original !BOOT was no longer needed (this was saved in the file O.!BOOT in the archive for information purposes along with the FWS DOS). A new !BOOT was made which simply CHAINed "A".
The recovered title now will run from any filing system on any BBC micro variant. If PAGE is any higher than &1900 a simple move down routine will have to be used for the program "SCALES".
|
|
| FWS V2 |
|
This is another variant of the Five Ways Software (FWS) protection method. It is much simpler than other methods found and may be one of the earliest methods used.
The disk was 80T DFS and had non-standard formatting applied. Tracks 2 to 19 inclusive and tracks 40 to 79 inclusive were not formatted. All other tracks were formatted normally.
The catalogue contained only one entry, !BOOT. The disc size was wrongly set to be 40 tracks.
!BOOT checked that track 6 sector 3 was unformatted. If the track was formatted then the loading sequence stopped in an endless loop. This was the only check that the disk was the original one.
DEFEATING This proved to be very simple. Tracks 0 and 1 and tracks 20 to 39 were copied to a newly formatted 40T disk. Using the copied disk, !BOOT was edited to ignore the check for an unformatted track 6, sector 3. This was the minimum change needed to hack the protection.
The copied disk worked normally on all variants of the BBC Micro but only under DFS due to the direct accessing of the disk surface of drive 0.
Update On examining the !BOOT code it was possible to pause execution to extract the component files. !BOOT loaded the data from various sectors on the disk and then decrypted the data by adding &0E followed by EORing with &74. Various return addresses were put on the stack to make subroutine return difficult to follow. This section of code was skipped. The *FX200,2 call was changed to *FX200,0 to allow Break to reset all vectors and leave the code intact in memory. Exmon II was used to scan through memory to find the loaded code and this was saved to a newly formatted disk. Two files were needed - the logo/splash screen and the program code itself. The BASIC program was made unlistable by omitting the &FF marker after the last &OD in the program. This was restored and the program saved.
The hacked version now runs on all BBC micro variants and all filing systems.
|
|
| General |
|
This is a generic protection method used by many publishers. It involves hiding the catalogue, setting the disc size to be zero and, at the same time, including dummy files which are larger than the available space on the disc.
Defeating Using ADI Track 0 Sector 0 was examined. Any VDU21, VDU23 or VDU3 bytes were replaced by space characters or by zero bytes as applicable. Again for Track 0 Sector 1 any VDU21, VDU23 or VDU3 bytes were replaced by space characters or by zero bytes as applicable. The disc size was correctly set. In many cases this made the disc copyable and archiveable as a SSD file.
Where a very large dummy file was included, individual files were copied to a RAM disc of a Datacentre, the title was set correctly, the boot option was set to match the disc and the RAM disc was archived to a SSD image. This process omitted the dummy files.
|
|
| GriffTape1 |
|
The tape contained one program on each side.
There were three programs per side. The first program was a simple BASIC loader. It contained the logo above TOP and poked this directly onto the MODE 4 screen. It changed the tape speed to 300 Baud to load the second program, GS at page &700. GS was a small machine code program which set the tape speed to 1200 Baud and which read the third file, "_", the main BASIC program, one byte at a time, decrypting the byte and writing it from &E00 upwards, finally placing &00 over the end of program marker, &FF, and leaving RUN in the keyboard buffer.
DEFEATING All three programs were copied from tape to disk. The loader program was part-executed to recover the logo and this saved as a separate file, LOGO. The file GS was modified to run at &900 rather than &700, the keyboard buffer. It was also modified to restore the end of program marker, &FF, after decrypting "_". GS was executed from a point after setting the tape speed so that it would load the file "_" from disk.
The file "_" was recovered as a normal BASIC program and saved to disk.
A new menu program was written to control the loading of the required programs and all were saved to disk.
The title now worked on any BBC micro variant and on any filing system.
|
|
| GriffTape2 |
|
The tape contains a file GRIFFIN, which loads at &500 and executes from there. This provides a dedicated loader for several byte streams on the tape. The loader both reads the data and stores it at several locations in memory before exiting and starting the main BASIC program.
|
|
| GSN1 |
|
This method was found on the key disc for The Micro at Work:4 - Mail Order.
Track 10 was unformatted, which prevented *BACKUP and direct *EXPORT to the Datacentre.
!BOOT was an EXEC file but with machine code at the end. !BOOT loads and then executes itself. The machine code switches to drive 0 and *RUNs a file called S.SETUP. This file reads a new disk catalogue into &E00 to &FFF and then loads the files O.MAIN and O.INDEX, which were not present on the original catalogue. *COPY *.* would not work, of course.
DEFEATING !BOOT was copied and saved as OLDBOOT on a new, blank disk.
S.SETUP was edited to stop when it had loaded the new catalogue and the files O.MAIN, O.INDEX and S.KEY3 were copied onto the new disc. S.SETUP was also copied onto the new disc to preserve it although it was not to be used,
On the new disc !BOOT was created which contained CHAIN"HACK". The file HACK performed *FX4,1, MODE7, *LOAD S.KEY3, *LOAD O.MAIN, *LOAD O.INDEX and then CALLed the code in O.MAIN.
As a result of this hack the title now works properly on a BBC Master.
|
|
| H&H1 |
|
This method was discovered on the H&H Software Tess disc.
The disc, when catalogued, only showed two files, !BOOT and TESS. The other files on the disc were hidden. This was done by forcing MODE7 when cataloguing and making the hidden filenames all begin with character &98.
The file TESS was a short BASIC program that *LOADED the components of the main program to the correct memory locations and moved the whole lot down in memory.
Defeating Using ADI on a clone of the disc, all the &98 characters at the start of the hidden file's names were changed to "[". This made them visible. The TESS program was also edited so that the &98 character in the *LOAD commands was changed to "[".
|
|
| Hide Catalogue |
|
There are several methods for hiding the catalogue from the casual observer. These may be used in isolation or combined for a greater effect.
- One or more characters in the disc title are control codes. The usual one is to place Ctrl-U (ASCII code 21) at the start or end of the disc title.
- One or more dummy files containing ACSII code 21 in their file name(s). Such a file at the start and at the end of the files in the catalogue is commonly used.
DEFEATING As a protection method on its own this is rarely found but is quite common when used with unformatted tracks. A disk sector editor can be used to examine sector 0 of track 0. This will show what codes have been used to hide the programs and whether the top bit of characters is set.
Selective use of *COPY can assemble a working disk on a new, formatted disk and the hidden catalogue will be removed.
If the top bit is set in file names, the command *INFO can be used to find the load address, length and execution address of the file. The file can be *LOADed and then *SAVEd with its original load and execution addresses and length.
|
|
| HS1 |
|
The disc was 3.5 inch ADFS 80T M format designed for use on either a BBC Master/Master Compact or a BBC A3000.
The disc was formatted for 45 tracks. Track 2 was formatted to 10 sectors instead of 16. There was no check for unformatted or wrongly formatted tracks.
Several files needed were not in the catalogue but were loaded directly from the disk itself.
DEFEATING A new disk was formatted to 80T L format. Tracks 0 and 1 were copied from the protected disk to the new disc followed by tracks 3 - 45. The new disk works correctly and can be copied and archived. The software must run from the floppy disk or its image.
|
|
| HS2 |
|
The disc was 40 track with track IDs double the physical track number. Only 20 tracks were formatted. The catalogue was hidden due to character code 23 as the first character of the disc title and character code 21 as last character of the disc title.
Files on the catalogue were !BOOT and files C1 to C6 all in track 0 so they could be loaded normally. The files had the top bit set for the characters of the filename, which meant *COPY would not copy them. The disc size was wrongly set to show no bytes free, no files free and the disc size was 0. All these factors made the disc effectively uncopiable and not able to be archived using a Datacentre.
Advanced Disc Investigator 2 could not clone the disc on a Master. Therefore it was necessary to hack the disc in order to recover the data from the tracks.
DEFEATING !BOOT was a machine code file which loaded at 2F00. The code read data from the disc 10 sectors at a time from non-contiguous tracks. The data were EORed with &35 to give the actual code. Bytes in the !BOOT file were also EORed with &35 to give actual characters to be placed in the keyboard buffer that read PA.=&4300|MOLD|MRUN|M and the !BOOT file returned to BASIC.
The BASIC program running at PAGE &4300 was the menu program for the disc. It contained code and data below PAGE and machine code above TOP. The code above top started at &5728. This code loaded data from various tracks on the disc and the program code for the various BASIC programs chosen by the menu. The code was encrypted and was EORed with &77 to get the real code. The menu choice acted as a pointer which loaded graphics data via &5728, the file C1 to C6 respectively and then the BASIC program chosen via &5728. In addition the BASIC code was moved down in memory so that PAGE was at &E00 and *TAPE was selected. All this was hidden by a VDU21 command. Lastly the menu program placed OLD|MRUN|M into the keyboard buffer, set PAGE to &E00 and exited.
From studying !BOOT it was determined that the menu program loaded at &3F00 and the code stretched to &57FF, just below the MODE5 video screen memory. The !BOOT code was modified so that when it ran it did not place the characters in the keyboard buffer but returned cleanly to BASIC instead.
A file called MENU was saved from &3F00 to &57FF. Manually setting PAGE to &4300, typing OLD allowed the menu program to be listed. The code was altered to replace RUN with LI. the abbreviation for LIST. This modified code was saved as MENU1.
MENU1 was run from a properly formatted floppy disc in drive 1. The original disc was in drive 0. Menu choice 1 produced a listing of program 1. Executing *DISC allowed the program to be saved using *SAVE :1.PROG1 E00 2FFF. Graphics data and machine code routines were saved using *SAVE :1.AB1 A00 BFF. This process was repeated for all the programs in the menu and gave files PROG1 to PROG8 on the disc in drive 1 along with AB1 to AB8.
The files C1 to C6 were copied from the original disc to the one in drive 1 by loading and saving each file individually.
Examining the listing of the menu program showed that the variable Q% passed the value &900 to each of the separate programs called from the menu.
The menu program, therefore, performed the following steps;
- displayed the menu of programs on the disk
- accepted a choice 1 to 8 to choose the program
- asked if sound were wanted
- asked if instructions were wanted using the number choice as a pointer to the instructions
- called a routine at &3F00 using A% as a pointer to a block of data used to define the user defined graphics 224 onwards using VDU23
- used the menu choice as a pointer to load the appropriate program code from the disc, decrypting using EOR &77 and a rotating set of bytes, which could be changed depending on the program choice
- used the menu choice as a pointer to load graphics data into &900 to &CFF
- moved the program code down from &1B00 to &E00
- set PAGE=&E00 and placed OLD and RUN in the keyboard buffer to start the loaded program
The programs on the disk all had different data and graphic requirements, which made extracting them difficult and quite a detective story.
Program 1 The file C1 was needed to provide the graphics moving routines. This loaded at &900 to &9FF. The file AB1 was then loaded at &A00 to &BFF. CHAINing PROG1 produced a running program.
Program 2 The files C2 and AB2 were needed as per program 1 except AB2 was &A00 to &CFF. PROG2 was the BASIC program plus graphics data stored above TOP. HIMEM was set by the program to protect these data.
Program 3 C3 was a dummy file. AB3 actually comprised code from &900 to &CFF. After AB3 was loaded and PROG3 CHAINed the program ran correctly.
Program 4 This was loaded in a similar manner to program 2.
Program 5 This was loaded in a similar manner to program 2.
Program 6 C6 was a dummy file. AB6 actually comprised code from &900 to &CFF, which also meant that the character definitions loaded by the menu program were over-written too. After AB6 was loaded and PROG6 CHAINed the program ran correctly.
Program 7 There was no C7 file. The file AB7 was saved from &900 to &BFF. PROG7 CHAINed and ran.
Program 8 This was loaded in a similar manner to program 7.
As it stands this set of programs will only run on a BBC Master computer as PAGE is set at &E00 already.
To allow the title to run on all BBC micro variants the menu program was modified to *LOAD the respective PROG at &1B00 and then used a BASIC loop to move the code down to &E00 then run it.
A new !BOOT file was created which contained;
*BASIC
MODE7
PAGE=&4300
CHAIN"MEN"
|
|
| INF1 |
|
This protection method was developed by the Nottinghamshire County Council Computer Centre.
The disk was normally formatted to 40T and then the number of sectors on the disc was changed so that the disc appeared to be formatted to 39T. Track 39 could not therefore be normally accessed and would not be copied by *BACKUP.
The disk title string contained a VDU23 command which disabled the VDU output so preventing the disk being catalogued. In addition several files had names composed of ACSII characters in the range &80 to &87. These file names would not appear on the catalogue if the title string were reset. *COPY was thus defeated.
!BOOT CHAINed one of these hidden file names to load the main menu program and this in turn CHAINed the appropriate system file, which also had a hidden file name.
In addition the menu program read Track 0 Sector 0 and extracted the four bytes starting at offset &F0. This was followed by a read of Track 39 Sector 1. The four bytes at offset &F0 were compared with those read from Track 0 and if they matched the menu was shown. This check was performed twice.
The system files were protected from listing by inserted control codes in REM statements. These codes cleared the screen and disabled the VDU output using VDU23 codes.
As a consequence of this protection the title will only work with DFS0.9
DEFEATING ADI2 was used clone the master disk and then to verify the protection in the catalogue. The disk title was reset. The files with names composed of high bit ASCII characters were renamed using the edit function of ADI2 and the disk size was correctly set.
The presence of control codes in REM statements was determined using EXMON2 to examine the BASIC code. The REM statements only contained obfuscatory control codes. The Menu program was loaded into the BASIC Editor and the REM statements were deleted. The two lines which checked Track 39 were deleted. The CHAIN"" commands after the menu were altered to point to the renamed files on the catalogue. The menu program was renamed IRDISC and !BOOT re-written to CHAIN this.
The disk now worked on all BBC micro variants to hand and with all filing systems. It could also be easily copied and archived.
|
|
| Io1 |
|
This is a generic protection mechanism for Fernleaf Software titles. There are minor variations between titles depending on resources needed.
The disks are 40 track with non-standard formatting to prevent *BACKUP.
!BOOT runs a file BOOT which puts a menu program at &C00 and does *RUN DP. DP is a BASIC program with machine code after TOP. The machine code element moves code down to &720 and resets FILEV to point to this code. The code at &720 EORs each byte of each file loaded with &BD to give the correct code which runs.
DEFEATING The first task was to write a piece of BASIC code which read in each file one byte at a time and EORed the byte with &BD before writing the decrypted byte to a copy of the file on a newly formatted disk. This recovered the correct code for each file. One file, DATA, was not encrypted.
The file DP was modified not to change FILEV and copied to the new disc and !BOOT and BOOT copied to the new disc.
|
|
| Io2 |
|
This variant of the Io Software disk protection method changed the 40T disk size bytes to make the disk appear to have over 600K of data!
Obviously *BACKUP would not work.
The catalogue also included two dummy files whose file names were low value control codes. This prevented *COPY *.* working.
DEFEATING This turned out to be very simple. The disc had all 40 tracks normally formatted and was easy to clone using ADI. The clone had sector 1 of track 0 edited so that the disk size bytes were changed from 33 FF to 31 90, the normal values for a 40T formatted disk with *OPT 4 3 set.
The disk would now export correctly to a USB memory stick using a Datacentre. The SSD image ran correctly in BeebEm and will work when restored to a new floppy disk.
The protection was left still intact.
|
|
| JWS |
|
The directory was hidden by using VDU21 codes and the disc was formatted only on tracks 0-19. This defeated *BACKUP and *COPY *.*.
!BOOT is a machine code file which checks for Tube presence and then executes a file BOOT. The file BOOT loads code pointed to by &3AA and loads machine code into page &B00. The code in &B00 loads code into &900-&AFF. This code loads the appropriate files to the correct PAGE and executes.
DEFEATING There were 4 possible values placed in &3AA. BOOT was modified to stop after loading the files from the disc surface for each value. Each file was then saved onto a newly formatted disc.
ADI2 was used to identify the other files on the disc and these were copied across to the new disc individually. A new !BOOT was written to CHAIN the program START.
|
|
| Ladybird |
|
This is a generic protection method (with minor variations) for Ladybird -
Longman titles.
The disk was 40T with Track 1 either unformatted or formatted with a single
sector where all the IDs were set to 229. The last file in the catalogue was
named "S.", which would stop *COPY *.*, and *BACKUP would be stopped by Track 1.
The file "$." was in place to protect Track 1 from being read or written to.
Other files also contained VDU21 codes to stop the full catalogue from being
displayed.
The protection was checked by a file !MAIN or P.MAIN. This file was *RUN and
checked whether Track 1 Sector 0 was bad or not. If the sector was good, ie. a
copied disk, the code output the message "Bad Copy" and entered an endless loop.
If the sector was bad then the code copied a BASIC program to the
appropriate page (&1200 or &1300), set the BASIC page pointers and RAN the code.
DEFEATING
The disk catalogue was viewed using ADI2. All wanted files were copied
across to a newly formatted disk. !MAIN was edited to ignore the protection and
to stop after the BASIC program had been moved to the correct page. PAGE was set
appropriately and the BASIC program saved as BCODE1. !MAIN was no longer needed.
A file O.BEGIN (or O.START) was used to boot the program. This file was
edited to CHAIN "BCODE1" rather than *RUN !MAIN (or P.MAIN) and saved as
O.BEGIN1 (or O.START1). !BOOT was changed to CHAIN"O.BEGIN1" (or O.START1) and
the original !BOOT saved as OLDBOOT.
The title now ran correctly after Shift-Break on all variants of BBC micro
and all filing systems.
|
|
| Logotron1 |
|
The disk was formatted to 40T. The disk size low byte in Track 0 Sector 1 was set to &40 rather than the normal &90. This meant that the disk appeared to be 32 tracks rather than 40. *BACKUP was therefore prevented as the last 8 tracks would not be copied.
The package needed a ROM to be present, either a physical ROM or a ROM image loaded into sideways RAM. The ROM image was present on the disk in tracks 32 to 39 inclusive sectors 1 to 8 on each track. *BACKUP would copy the disk minus the ROM code. *COPY *.* would copy all the files but omit the ROM code in tracks 32 to 39. This was an effective method of preventing casual copying.
The disk protection was checked by the program INSTALL, which ran at &7800. INSTALL also extracted the ROM code from the disc and assembled the image in a buffer starting at &3800.
INSTALL firstly checked that the ROM was not already installed. If the ROM was present INSTALL terminated and returned to BASIC. INSTALL went on to check that there was a free sideways RAM slot available; if not the program reported an error and terminated. Next the disk size bytes were checked in Track 0 Sector 1. If they were not as expected (&31 and &40) INSTALL reported an error message and halted. Assuming the disk size was correct, INSTALL then copied the ROM image into the buffer in 2K chunks starting at Track 39 and ending at Track 32. The ROM code was moved from the buffer to the identified sideways RAM. Lastly code was run to initialise the ROM without needing Ctrl-Break to be pressed and control passed back to BASIC.
DEFEATING Once the protection method was understood, removing the protection was quite easy. Firstly the original disk was cloned using ADI2. Using the cloned disk the disk size was set to the expected values for a normally formatted 40T disk.
The INSTALL program was edited to remove the subroutine call to check the disk size bytes and re-saved onto the disk.
This edited disk now worked properly. The disk could be backed up and an SSD image created.
|
|
| Longman 1 |
|
This was a 40T disc with track 1 not formatted. The catalogue showed only files in the $ (root) directory; other files were hidden by two files with filenames comprising character &15 and &06 respectively. These prevented the rest of the catalogue being displayed on VDU or printer.
There were two necessary files in the P directory. Both these files were machine code files that checked for the presence of the unformatted track by trying to load sector 0 of track 1. If there was an error the program continued and loaded normally; if not then a 'bad copy' error was returned.
DEFEATING The minimal change needed was to edit both files in the P directory to skip the check for the unformatted track. A normally formatted disk could now be used.
All files in the $ and P directories were copied to a newly formatted disk and the boot option and title set correctly.
|
|
| Longman Ecce |
|
This was discovered on the Longman title Ecce Romani.
The disk was formatted to 40T. Track 2, however, was wrongly formatted to have five 512 byte sectors instead of the normal 10 256 byte sectors. This effectively prevented the use of *BACKUP to copy the disk and also prevented the Datacentre from archiving the disk.
!BOOT *RUNs the file MENU, which loaded at &1B00. This was a mixed format machine code and BASIC program. The machine code was above TOP and was called at &1D0D.
The machine code part of MENU set zero page locations &82 to &87 to hold various data values. It then checked track 2 for 512 byte sectors and if these were not found exited with the message Bad copy.
The file !.LMSdps1 had its catalogue entry set to cover the sectors in track 2. This subterfuge prevented *COPY *.*
The BASIC program in the file MENU was disabled and gave the error Bad program when LISTed. The BASIC line lengths were the wrong values and were EORed with &D6 to give the correct values by the machine code program.
Lastly the machine code program placed the text PAGE=&1B00|M*FX2,0|MOLD|MRUN|M into the keyboard buffer and exited to BASIC, causing the BASIC program to be executed.
DEFEATING A minimal hack was used to remove the check for the bigger sectors on track 2. This involved editing &1D10 in the MENU program to be JMP &1D4B, which skipped the protection checking. All files except !.LMSdps1 were copied to a newly formatted 40T disc. This disc now ran normally.
|
|
| Longman general |
|
A 40T disc which has the size wrongly set so that *VERIFY crashes on track 28. This will also defeat *BACKUP.
In addition the catalogue contains two files in the directory (.), eg. a file called ..TRANS. These files defeat *COPY *.*.
DEFEATING The files in the (.) directory were simply dummy files to prevent casual *COPY *.* If the files were copied individually to a newly formatted disk and the correct boot option set, the programs worked normally.
|
|
| LTS |
|
This protection method was first encountered when archiving Space Adventure.
The disk size is set to 0 bytes and file name 1 is 7 zero bytes with a starting sector of &3FF which is bigger than the size of the disk. This defeats *BACKUP and *COPY 01 *.*
!BOOT runs a menu program, which set PAGE=&7000 and reloads. Inside the menu program is a subroutine which sets R=?&F07+?&F0F. This is reading values from the RAM copy of the disk catalogue, namely the low 8 bits of the number of sectors on the disk and the low 8 bits of the first file start sector. This will effectively identify the original disc (or its clone).
Next the random number generator is set to a particular place in its sequence with A=RND(-R). The program then uses EOR RND(255) to decrypt itself and the main BASIC programs. This code only works correctly on a DFS BBC micro model B. This method is repeatable due to the setting of the random number generator sequence.
DEFEATING The original disc was cloned using ADI2 on a BBC model B computer. Using the clone, the MENU program was loaded, the decryption subroutine was run to decrypt the rest of the program and the decrypted version saved as MENU1.
MENU1 was now edited to remove a *FX138,0,128, which executed the definition of key F0 when the program stopped. MENU1 was run to decrypt the programs GAME and SPECIFY. These were saved as normal files. All decryption lines were removed from MENU1 and the title now loads and runs normally on all variants of the BBC micro.
|
|
| MEG |
|
This protection method was discovered on a number of titles from MEgaCyCAL.
The disk was formatted to 40T and had the catalogue hidden by the use of a
VDU23 code in the title. In addition there were a large number of dummy
filenames which contained control characters. Track 2 was formatted to 5 sectors
of 512 bytes each. As a result of these measures the disk would not respond to
*BACKUP or *COPY.
A file on the disk, REDAEH, a BASIC program checked for the existence of the
abnormal format on Track 2 and the title crashed if it was not found. The
procedure PROCENV in this program did the checking though when listing the
procedure definition nothing out of the ordinary could be seen. The actual
listing is shown below;
790DEFPROCENV:ENVELOPE1,1,-2,-2,-2,100,100,100,127,-1,0,-127,126,0:Y$="[4x CHR$127]ENDPROC ":
CALLTOP+50:ENDPROC:REM[24xCHR$127]
The string assignment Y$= ... made it appear that ENDPROC finished the line
as the 4xCHR$127 codes deleted the Y$=" from the screen. Similarly the
24xCHR$127 codes removed the CALL to the machine code routine stored at TOP+50.
It was the machine code routine which detected if Track 2 were incorrectly
formatted and crashed the machine.
Defeating
Once the protection methods were uncovered, defeating the protection was
very simple. ADI2 was used to read the hidden file names from the catalogue.
These were then copied individually from the master disk to a newly formatted
target disk.
The file REDAEH was loaded into the BASIC Editor and line 790 edited to
remove the CALL to TOP+50 and all the delete character codes.
The title would now work correctly from the target disk and under any filing
system tried.
|
|
| MGN1 |
|
Encountered whilst archiving Count with Oliver.
The disk was 40T with Track 2 formatted logically as 18 sectors of 128 bytes but physically as 10 sectors of 128 bytes. This prevented *BACKUP working. The catalogue contained a number of dummy files whose data on sector 1 indicated that they were stored on Track 2. This prevented *COPY *.* working.
!BOOT set page to &5000 and did a *RUN BOOT. The file BOOT loaded at &1400. It firstly decrypted the latter portion of itself and then executed the decrypted code. This code firstly checked the formatting of Track 2 and hung in an endless loop displaying the message "Copied disc" if the formatting was wrong.
Next BOOT loaded a BASIC program from Track 3. The data were stored as deleted data. The data were loaded at &5000 and the code finally exited by placing *BASIC[CR], PA.=&5000[CR], OLD[CR], RUN[06][CR] into the keyboard buffer.
DEFEATING The file BOOT was edited to run the decryption component and then halt. This allowed the decrypted version to be saved to another floppy disk and to be examined.
The next step involved editing the decrypted version to LIST the file loaded from Track 3 rather than running it. The BASIC program was saved as LOADER onto a new, formatted disk.
The necessary files from the original disk were copied to the new disk and a new !BOOT written. This set PAGE=&5000 and CHAINed the LOADER program. The title now worked, could be copied and archived.
|
|
| Nidd 1 |
|
The system disc had a disc title of "Protected" plus VDU7 and VDU21
characters at the end. This prevented reading the catalogue. In addition the
first file in the catalogue had a file name made up of VDU7 and VDU21
characters. This trick prevented simple copying of of files using *COPY *.*. To
prevent *BACKUP working the disc size was set as zero bytes. The disc also
contained a file O.XXXX which had its length set to be larger than the disc
size.
Defeating
The disc was scanned using ADI to check that there were no unformatted or
weirdly formatted tracks. The disc was formatted properly and so would create a
valid SSD image. To make the image a simple track copier was written to copy
tracks 0 to 39 from the original disc to a blank SSD image on a USB stick
plugged into a GOTEK drive. The copy had all the original anti-copying
protection intact but would run in a BBC micro emulator.
|
|
| Noricc1 |
|
The disk was a single sided 40T disk with an apparently open catalogue of normal files except for a very large file named "......." in directory "."
The disk would not back up and would not verify due to a bad disk size value in byte 6 of T0 S1. All files, except for the one named "......." could be copied to a new, formatted disk but the title would not work from the copy, reporting a bad disk size.
On investigating it was discovered that a file EXCH was frequently called by several of the component programs of the title.
EXCH was a machine code program that loaded at &1100 and executed from &1300. &1100 to &12FF contained an alternate directory structure for the disk. On executing, EXCH firstly checked for a correctly set disk size byte at &F06. This was compared to &1206. These should both be &31. If the size bytes differed the program crashed, reporting a bad disk size error. Secondly the code swapped catalogues by writing its copy from &1100 to &12FF to the disk as T0 sectors 0 and 1.
This new catalogue contained the start up files for the title. It also contained a second copy of EXCH with the original disk catalogue. When this second copy of EXCH was executed it swapped the catalogues again.
!BOOT was different in each catalogue. That in the second catalogue ran its version of EXCH to swap to the original catalogue and then *EXECed the original !BOOT to load the program correctly.
DEFEATING This was accomplished by firstly cloning the original disk, track by track. This allowed the file "......." to be copied, which in both catalogues protected the other catalogue's files.
Using the copy the disk size byte on T0 S1 was changed to &20, the usual value for a 40T disk. The size byte at &1206 in EXCH was also changed to &20 to match the disk. The disk would now back up properly.
Next EXCH was executed to swap to the second catalogue and the size byte alteration above was made for the second catalogue and at &1206 in the second version of EXCH.
The disk could now be copied with *BACKUP and archived on a Datacentre using the *EXPORT command.
|
|
| OSM1 |
|
The disk was formatted to 40 Tracks but Track 0 Sector 2 had an error &14 =
data CRC error. This meant that *BACKUP would not work..
The catalogue was hidden due to VDU21 commands being placed at the end of the
disk title and into the last file title. In addition two files had filenames
comprised of control codes to switch off printer output. *COPY *.* would not
work..
!BOOT was EXECed and comprised a number of control codes to hide various integer
variable assignments and the program to be executed. This file made the
following assignments;
A%=&7F:B%=&182E:C%=&XXXX:D%=&848:E%=&D9CD:H%=0:X%=&24:Y%=&18:Z%=&FFF1
?&600=3:?&637=1:?&AA6=&36
PAGE=&1800
The file $.O was LOADed (at &1800) and RUN.
The value &XXXX varies depending on the length of the program title shown on the splash
screen.
$.O is a BASIC file which is missing the &FF byte after the last &0D. It is &500
bytes long. This program will RUN but not LIST, reporting a Bad Program error on
LOADing. The first line of the program contains a REM statement which hides the
first line and disables screen and printer output and also contains an OSWORD 7F
parameter block starting at &1824.
A%, X% and Y% are configured by !BOOT to execute an OSWORD &7F command using the
parameter block at &1824, within the BASIC program. If the original !BOOT is not used then
the OSWORD call will be meaningless and probably hang the machine. &1824 points
to a data buffer at &800 and attempts to load data from Track 0 Sector 2. This
sector gives a data CRC error code after the OSWORD call has finished and the
program tests to see if this is non-zero. A zero error would indicate a copied
disk and the code then executes a call to &D9CD, which on a BBC micro will reset
the machine. On a Master this just hangs the machine. Even though the sector has
an error, constant data loads for the first 128 bytes.
If the result of the OSWORD call is non-zero, the byte at &0848 is copied into the memory
address contained in C%. The byte at
&0848 is the ASCII code for 'M'. The byte at C% is the file name to be CHAINed by
the program $.O and this is set to 'E' by default. The file $.E does not exist
on the disk. Any careless changes to the program $.O when trying to copy the
title will probably cause the machine to
crash.
This is a generic protection mechanism for the OSMIROID titles archived.
DEFEATING
The program $.O was converted into a valid BASIC program by placing the byte &FF
at the end of line 70. This would now save as a BASIC program. Exmon 2
was used to change the CALL statement to a REM statement in the first line so that line 0 read MODE 2
and was followed by a REM statement and in line
70 "E" was changed to "M".
The files !BOOT, M, N, O, P and other relevant files depending on the title were copied to a newly formatted 40T
disk. The boot option was set to EXEC and the title changed to match the
original but minus the VDU21 code.
The copy now ran and could be archived.
|
|
| OXF1 |
|
The disks were 40T and had a hidden catalogue by virtue of a VDU21 code in the disk title.*VERIFY failed at track 2 as this track was not formatted.
This was a simple but effective way of preventing *BACKUP. It would not prevent *COPY *.*, though.
DEFEATING ADI was used to check that no files occupied track 2. *COPY *.* was used to copy all the files onto a freshly formatted disk. The boot option on the new disk was set to EXEC and the titles ran and could now be archived correctly.
|
|
| Par1 |
|
This method was discovered on the BBC Compact version of Star Chaser, a 3.5" 640K ADFS disc.
There were only six files showing on the catalogue, the rest of the software was stored on the disc surface. One file, MENU, spanned unformatted sectors and was probably used to protect these from damage. The !BOOT file loaded a BASIC/machine code program, Amen. The BASIC part called the machine code stored above it. This code was encrypted for the most part. Running the machine code decrypted this program to provide the loader for the main software suite, which was a BASIC program and which loaded the rest of the suite from the disc surface. In addition, the decryption process used self-modifying code, which made interrupting the process extremely difficult.
Defeating Decrypting the program, Amen, allowed the copy protection, checking for unformatted tracks, to be disabled. Overwriting the original Amen removed the protection and allowed the title to run successfully.
|
|
| PAVIC |
|
This seems to be a generic protection method for PAVIC Publications.
The disks were 40T or 80T. 80T titles were not formatted for tracks 40 to 79
inclusive. The protection relied on one track being formatted with less than the
normal number of sectors on a track, for example track 16 having only 4 sectors
or track 6 having a single sector formatted. This unusually formatted track
returned Data Field CRC errors for all the sectors on the track. Tracks after
the unusually formatted track all had their sector IDs with the high bit set.
The disk size bytes were adjusted so that the disk size reported only the
normally formatted tracks.
*BACKUP would only back up the normal sectors and *COPY *.* would not copy
the data hidden in the sectors where the sector IDs had their high bit set.
!BOOT was a machine code program, part of which was encrypted. When it ran it
checked that the unusually formatted track existed, crashing if it did not. The
program then decrypted itself before running the decrypted section, which loaded
two sectors into &7000, some of which was downloaded to &3100. The downloaded
code placed the value &3C into location &380 before *RUN DFS was executed.
DFS checked for the unusually formatted track, crashing if it were not found
and then loaded a proprietary catalogue from track 39 and used this catalogue to
load and/or run the required programs; BASIC programs were loaded at the right PAGE,
DFS executing *BASIC and placing OLD|MRUN|M into the keyboard buffer before returning to BASIC.
DEFEATING
Once the protection mechanism was understood, DFS could be modified. !BOOT
was not really needed. The code ?&380=&3C:*RUN DFS would execute the title just
as well. !BOOT was changed to be an EXECutable file with those contents.
DFS was modified to bypass checking for the unusually formatted track by
changing the execute address to &1138 from &110C. It was also modified so that
instances of ORA #&80, which set the high bit for sector IDs, were changed to
ORA #&00, which left the IDs unchanged.
A short BASIC program was written to clone the original disk by reading
sectors from the original disk and writing them to a newly formatted disk,
unsetting the high bit of the sector IDs where necessary and omitting the
unusually formatted track. The modified !BOOT and the modified DFS were written
to the copied disk. The boot option was set to execute using *OPT 4 3. The disc
size was adjusted to the correct value for the format
The disk would now *VERIFY and could be archived as a SSD image and worked
correctly. The image will only work under DFS emulation.
|
|
| PP1 |
|
This method of protection was discovered on the Pixel Perfect title from AVP.
This is not a standard AVP protection method and is highly likely to be a method
put onto the Pixel Perfect disks before AVP took over the distribution of the
package.
The disk will not *BACKUP because track 39 has specially formatted sector
IDs; sector 3 has an ID of 0, which would not be the case on a normally
formatted disk. The value of this ID is checked by the software to detect a
pirate copy.
Apart from the peculiar formatting on Track 39, the disk is formatted
normally and there are no files containing control codes which stop the disk
being catalogued. All files may be copied freely but the title will not work on
the copy.
The protection file, called $.BOOTER on the Master Disk and !BOOT on the Page
Disk both work in an identical way. The program does some housekeeping, setting
the CSD to $, issuing a *FX200,3 command to stop Break being used to interrupt
the loading process and the Escape key is disabled. The machine is put into MODE
0 and every byte of screen memory has the byte &AA placed in it. This has the
effect of a series of alternate black and white vertical lines. The cursor is
disabled and VDU19 is used to swap foreground and background colours.
The next section is a routine to decrypt a section of code by EORing with a
decreasing counter, starting at &2B and decreasing to 0. Immediately after this
the memory location is EORed with &FF and the resultant value placed back in
memory. The decrypted code performs a simple addition check on the preceding
code to check that it has not been changed and then places the number &2B66 onto
the stack and executes an RTS instruction. Instead of returning to BASIC, the
RTS now returns to location &2B67, which is a routine which decrypts another
block of code at &2B7A.
The decryption EORs each byte of the code, in turn, with the characters O, M,
E and N. The decrypted code seeks Track 39 and reads the first four sector IDs
of that track. It checks that sector 3 ID is 0. If it is not 0 then the routine
displays the Message "Naughty naughty ..." and hangs, having recognised a copied
disk.
If the protection check passes OK then the value &26AE is pushed on the stack
so that the following RTS jumps to the location &2A6F. This location executes an
OSCLI command equivalent to
*RUN ? START JOSHUA and returns to BASIC.
DEFEATING
Once the protection method was understood a short BASIC program was written
to decrypt the code in $.BOOTER and place the instruction JMP &2A6F at the start
of the first decryption routine. This had the effect of bypassing the
decryption, ignoring the checksum calculation and ignoring the checking of Track
39.
$.BOOTER now simply set up the computer screen and then executed the command
*RUN ? START JOSHUA.
The altered file was saved over the original to allow the title to work
correctly.
|
|
| ST1 |
|
The disk was 40T with tracks 38 and 39 formatted so that sector IDs ran from
23 to 32 inclusive. The disk would catalogue properly and report the correct
disk size. It would not verify past track 37, would not *BACKUP and would not
*EXPORT to a USB stick from a Datacentre.
All files could be copied to a new disc but the copy would not work,
reporting an error 'Muddy Rabbit?'.
!BOOT CHAINed a simple loader program, 'FLIGHT' which executed a machine code
file, 'AUTOST', from PAGE &900.
'AUTOST' reset FILEV to point to code within itself and then placed
'CH."CONDZ1"[CR]' into the keyboard buffer before exiting. The command in the
keyboard buffer now executed.
CH." CONDZ1" activated through the redirected FILEV. The code firstly checked
that the command CH." CONDZ1" was in the keyboard buffer. If the command were
not recognised the routine exited by jumping to the original FILEV address.
Once the command had been recognised a BASIC program stored on tracks 38 and
39 was loaded at PAGE &E00. The OSWORD &7F parameter blocks in the code had
misleading buffer addresses for the unwary. The BASIC program, called 'CONDX',
would execute, running the whole package. The code then returned to BASIC to run
the loaded program.
If the AUTOST code detected that tracks 38 and 39 did not have the correct
formatting it halted displaying 'Muddy Rabbit?'.
DEFEATING
Once the purpose of the AUTOST code was determined it could be seen that it was
only needed to load the CONDX program whilst checking that the disk was the
original one.
The code was edited to have an RTS instruction placed at &9AE. This had the
effect of loading the CONDX program and exiting cleanly to BASIC. A BBC Master
was used to extract the BASIC program as PAGE is already at &E00, whereas a BBC
micro would have been more difficult to use to save the code.
The BASIC program was saved as CONDX on a newly formatted disk. All the files
from the program master disk were copied to the newly formatted disk. !BOOT was
changed to simply CHAIN"CONDX".
Another file 'PIP' had to be edited. PIP was CHAINed when Break or Ctrl-Break
were pressed. PIP CHAINed the FLIGHT program so that the package started afresh.
PIP was edited to CHAIN "CONDX" instead.
The new disk would now play properly and its derived SSD file worked in
BeebEm.
|
|
| STE1 |
|
This was very simple yet very effective for its time.
The catalogue was hidden completely by placing a VDU21 code at the start of the disc title string. The disc size was wrongly set to be 401 rather than the normal 400 sectors. In addition many data files were hidden in sectors not appearing in the disc catalogue.
These practices would stop casual file copying as not all files would be copied and BACKUP would not work as the disc sizes would be different.
DEFEATING
Using a disc sector editor Track 0 Sector 1 was edited so that byte 7 was set to &90 rather than the existing &91. The edited disc could be copied with *BACKUP and could be *EXPORTed from a Datacentre to make a SSD file for archiving.
This copy would not run until byte 7 was reset to &91. This was accomplished by writing a custom piece of software to run in the BBC emulator and make the change. At the same time the disc title was set to be "COASTAL", which removed the VDU21 byte hiding the catalogue.
The copy and original will only run on a BBC model B with PAGE set to be &1900.
|
|
| Tape |
|
This is a generic description for a protected tape.
|
|
| Unconventional format |
|
The standard format of DFS discs is either 40 or 80 tracks, each track containing 10 sectors of 256 bytes each. ADFS discs are formatted with 16 sectors of 256 bytes per track.
Any departure from these parameters will render the disc unable to be copied or archived. Files may still be copied using *COPY on DFS or Dircopy on ADFS but a faithful copy may be prevented if a crucial file is on an unconventionally formatted track.
Types of unconventional formatting found include;
- changing the number of sectors per track, eg. track 2 of an ADFS disk having 10 sectors,
- changing the sector size, eg. a single 2048 byte sector on one track,
- formatting sectors marked as holding deleted data; this prevents *BACKUP and files being copied using *COPY,
- having more than 40 or 80 tracks on the disk;an extra track will be very difficult to read,
- having a mixture of 40 and 80 track formatting on the same disk; data are stored on every other track in the 80 track section,
- changing the track ID number; track 1 should have a track ID of 1, if this is changed to 129, say, the track will normally be unreadable.
DEFEATING There is no single, simple method to defeat this protection. However, the programmer has already written code to read data from such an unconventionally formatted disk. The general method involves unpicking the program that loads data from the protected tracks and stopping the program just before it runs any code.
Sometimes the programmer has thought about this and taken steps to prevent it but generally there is a back door through which one can gain access to the code to recover the data.
|
|
| Unformatted tracks |
|
This was a simple method of protection employed by some software houses.
A single, unformatted track, usually at the start of the disc was an effective deterrent to casual copying. This defeated *BACKUP but would not defeat *COPY *.* on its own.
Later examples of this technique involved only formatting those tracks needed to store the data. For example, a 40 track disk may only have the first 20 tracks formatted.
Used by itself this is an uncommon method of protection but is found used in conjunction with other methods.
DEFEATING The usual way to defeat this is to *COPY the files to a newly formatted disk. However, there may be a file on the disc which checks to see if a particular track is unformatted so that *COPY alone will not work. The checking file must be edited to miss out the check for unformatted tracks.
Sometimes this is very difficult because the program is written in a way to defeat editing. In this case a partial re-write may be necessary.
|
|
| Unknown |
|
The disc is protected from copying and from inspection. It will not verify and will not archive to an SSD image using *EXPORT on a Datacentre.
The mechanism of protection has not been investigated and the disc has not been de-protected.
The download image is in HFE format for use with the BeebJIT emulator or with a GOTEK floppy drive.
|
|
| W1S |
|
This is a method used only by Sherston Software for all their titles and relies on a file called W1S.
The original discs are all part formatted and have tracks 2 or 9 formatted with a CRC Data Error. This is enough to prevent *BACKUP and most disc cloning software from working.
Not all programs needed by the title are shown in the disc catalogue; they are hidden on the disc surface in unused tracks. Using *COPY *.* will be defeated by this method.
This method also allows more files than the 31 DFS maximum to be stored on the disc. It also works on ADFS titles.
The file, W1S, serves two purposes;
- it checks for the CRC error and crashes if it is not found, needing a Ctrl-Break to restart the computer; this also clears memory,
- it loads 'hidden' programs directly from the disc surface.
W1S loads and executes from &480 in memory. It loads a default program, usually a menu, to the correct PAGE and then this is run.
W1S is also used to load other programs as needed by the suite of programs. Its use in this way is *RUN W1S LOAD1. This command is instead of PAGE=&1800:CHAIN"LOAD1", for example.
The list of programs loaded by W1S is given at the end of the code disassembly. This list includes some dummy names.
At about mid-program W1S places OLD|MRUN|M into the keyboard buffer so that the loaded program runs.
DEFEATING
This turned out to be simplicity itself. The word RUN, as mentioned above, was changed to LI., which is an abbreviation for LIST. When W1S runs it now lists the program rather than running it.
W1S also issued a VDU21 command and set FX3 to prevent output to screen and printer. Ctrl-F undid the VDU21 command, allowing output to screen and blind typing *FX3,0 restored the output to screen as well. (Not all variants of W1S needed the *FX3,0. This seems to be a later addition.)
The program can now be saved to disc, using the name from the W1S code. PAGE can also be determined.
Each component BASIC program was examined to find calls to W1S and replaced this with setting PAGE to the right value and CHAINing the correct program.
Removing the need for W1S had a side effect of allowing most titles to run on ADFS, NFS and RAMFS. This was because W1S called disc drive 0 each time it ran.
|
|
| W1S-a |
|
This is a variant on the W1S Sherston Software protection mechanism and was
found whilst archiving Sellardore Tales, one of their later titles for the BBC
micro.
The disk was formatted to 40 tracks but had sector 9 of track 39 formatted
with a data CRC error. The load and execution addresses and the file length of
W1S were different in this version being &440, &440 and &293 respectively. The
copy protection mechanism attempted to load a sector of data from T39 S9 twice
and compared the first 8 bytes. If the bytes were different, this would indicate
an original disk and the program would continue normally. If the bytes matched,
such as would occur on a correctly formatted disk, the process of reading and
comparing T39 S9 would occur ad infinitum, causing the computer to hang.
On an original disk W1S loaded a BASIC program, LOADER5, directly from the
disc without referencing the catalogue. This program loaded at PAGE=&1900 and
ran to further load either the BBC micro version or the Master 128 version.
DEFEATING
W1S was edited so that the file LOADER5 would load and LIST rather than RUN.
Ctrl-F and *FX3 were issued and the program could be LISTed. It was then saved
on a newly formatted disk. All the files shown in the setup disk catalogue were
then copied across to the newly formatted disk.
The file MENU was edited so that the two occurrences of */W1S LOADER5 were
changed to CHAIN"LOADER5".
The copied setup disk now ran correctly. The title has been tested on a real
BBC micro and Master 128 and works correctly. Under emulation in BeebEm 4.14 the
setup disk will only work in Master 128 mode and all three versions of the
program appear to work correctly.
|
|
| W1S-b |
|
This variant of the W1S protection method relied on Track 39 Sector 9 having
the 'weak bits' protection and returning a Data CRC error. It was found when
archiving Fleet Street Phantom.
Fortunately this version of W1S was very easy to modify to remove the
protection checks. The code loaded at &0480 as usual and had a straight forward
protection check mechanism.
T39S9 was initially loaded at &1800 and the code then jumped to subroutines
at &1800 and &1803. Both of these addresses held a RTS instruction and the code
would therefore continue normally. If the sector were normally formatted with
random data it would be very unlikely that the locations would contain
meaningful subroutines and the program would crash. Lastly, if the check were
successful, &32 was placed in location &3A1.
T39S9 was read for a second time into &1800 and the first 8 bytes of the
loaded code were placed in &80 to &87 inclusive. Immediately T39S9 was read
again into &1800 and the code then checked that the 8 bytes were different. If
the bytes were the same, as they would be on a properly formatted disk, the
program hung, repeating the check ad infinitum.
Lastly the contents of &3A1 were checked. If &3A1 did not contain &32, the
program would again crash.
DEFEATING
Tracks 0 to 38 of the original disk were cloned onto a newly formatted disk.
A short BASIC program was then written to load sectors 0-8 from track 39 and
write those to the cloned disk.
W1S was edited and written over the existing version. Changes made to W1S
were minor. JMP &04AA was placed at &049D and JMP &057D was placed at &053A.
These were sufficient to remove the checks made on T39S9 and allowed the cloned
disk to run normally. As the cloned disk was now properly formatted it could be
easily copied or archived.
|
|
| X1 |
|
This method was found on a batch of disks from Xavier Educational Software. The disc is 40T DFS but with track 1 not formatted. This defeats *BACKUP.
The catalogue is hidden by using VDU21,VDU3 as the title for the disc and for a dummy file physically at the end of the catalogue. This has the effect of disabling screen and printer output so preventing *CAT, *INFO *.* and *COPY *.*.
!BOOT is a machine code file which runs at &1900 and loads 1 sector from T0 S7 into &2000 and executes it. The code at &2000 then attempts to load data from track 1. If the load is successful the screen is cleared and the text 'formatting' is output and the code hangs in an endless loop.
An unsuccessful attempt to load data from track 1 (normal for the genuine disk) *RUNs a file. The directory for this file is variable between titles as is the file name.
DEFEATING Using ADI the catalogue entries were viewed for T0 S0. These were copied to a Datacentre RAM disc using ADT2, excepting the dummy file which was only there to stop the catalogue being viewed.
!BOOT was renamed to OLDBOOT to preserve the original protection mechanism.
The code in !BOOT was edited so that a JSR &FFF1 was changed to JMP &FFF1. This had the effect of loading the code from T0S7 at &2000 and exiting to BASIC.
This code at &2000 was edited to remove the attempt to load the unformatted track 1 and check that it was unformatted. The file was saved as MC1 onto the RAM disc.
A new !BOOT was made which did *RUN MC1. The boot option was changed to EXEC using *OPT 4 3.
|
|
© 2018 - 2026 flaxcottage.com |
|