Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC830713); site snow.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!mhuxj!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!mcvax!ukc!qtlon!flame!ubu!snow!dpa From: dpa@snow.UUCP (David Angier) Newsgroups: net.micro.cbm Subject: Re: Copy protected disks Message-ID: <420@snow.UUCP> Date: Wed, 27-Feb-85 19:34:43 EST Article-I.D.: snow.420 Posted: Wed Feb 27 19:34:43 1985 Date-Received: Mon, 4-Mar-85 04:50:18 EST References: <414@bonnie.UUCP> <136@tektools.UUCP> Organization: Computer Science Department, Warwick University, UK Lines: 34 I've just discovered a NEW form of protection (I was looking at a game called Fighter Pilot). I am intrigued at how it protects itself, there are no Disk Errors and yet it still won't get past the loader when copied (I've got the original, it's just a hobby trying to find out how things work). A lot of hard work (and looking at the dis-assembly of the DOS) has lead to the re-discovery of a DOS command '&', when sent to the disk controller it crashes, except on the original of Fighter Pilot where the default drive number becomes 8!!! (Not the device no. the DRIVE no. :-) Much later I found that this causes a file called '&,USR' to be loaded into the DOS RAM directly and then executes (seems like B-E to me), but has a strange file format:- Low address (load and execute) Hi address Byte count data . . Checksum. This was deduced from the DOS dis-assembly, but the file on the Fighter Pilot disk (&,USR) points to track 18 sector 1, the directory track and the check-sum would be wrong etc.. Looking around I found the directory header block (Trk 18 sct 0) was set up in this format!! The original loads the header block into the DOS RAM, all copies load the directory, is there any one out there who knows what the '&' command really does, has it a bug? Dave.