Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utcsrgv.UUCP Path: utzoo!utcsrgv!dudek From: dudek@utcsrgv.UUCP (Gregory Dudek) Newsgroups: net.micro.apple Subject: Re: Disk Protection (problems)# Message-ID: <3511@utcsrgv.UUCP> Date: Mon, 12-Mar-84 17:08:07 EST Article-I.D.: utcsrgv.3511 Posted: Mon Mar 12 17:08:07 1984 Date-Received: Mon, 12-Mar-84 17:26:51 EST References: <575@ihuxn.UUCP> Organization: CSRG, University of Toronto Lines: 31 It looks to me like your disk "backup" method will only work on the simper protection schemes. For those of you who missed the lead-in article, it outlined saving a memory image of a "locked" program by using the built-in tape read/write code. The method for getting control of the Apple was to re-route the RESET vector via the language card so that you could use the monitor to capture the program. At least, this was my understanding. The problem seems to be that: a) most well protected software uses a multi-stage boot (I would still call this "single disk access" loading), and the first stage often disables the language card. b) Some protected software keeps code "behind" the keyboard buffer so that typing things destroys it. (i.e. when you trys to type in the tape save command.) One method the "crackers" use to deal with software that does these "neat" things is called "boot trace cracking". This involves copying the bootstrap ROM code (at c600) and making it branch back to the monitor after the first phase of boot, instead of to the loaded code (at 0x0800). This procedure is then repeated for each phase of the boot. To make this difficult for them, intermediate sections of the code can be loaded at the monitors keyboard in buffer, or into the screen buffer so then then control returns to the monitor, it automatically erases the offending code. Gregory Dudek {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!dudek -- Gregory Dudek {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!dudek