K R A C K I N G by the Disk Jockey C o n t e n t s Chapter 1: Intro to Kracking Chapter 2: Where to Begin. A discussion on the first steps to kraking protected programs Chapter 3: Minimal Hardware Necessary for Kraking Protected Programs Chapter 4: Deprotecting Single Load programs Chapter 5: Modified DOS Protection Chapter 6: Modified RWTS Protection Chapter 7: Using Second Stage DOS for your own programs Chapter 8: The Art of Memory Packing Chapter 9: Introduction to the Non-Maskable Interrupt (NMI) Chapter 10: Protected Applesoft Basic Programs APPENDIX A- KRAKING MODIFIED DOS'S WITH COPYB APPENDIX B- MAKING A F8 KRAK ROM APPENDIX C- MAKING YOUR OWN NMI BOARD APPENDIX D- PRACTICAL USES FOR THE NMI/MODIFIED ROM HARDWARE APPENDIX E- THE ROM CARD APPENDIX F- MEMORY MOVE WRITER DOCUMENTATION APPENDIX G- DISABLING MINOR DISK ACCESS FROM SINGLE LOAD PROGRAMS ______________________________ Chapter 1: Intro to Kracking by the Disk Jockey Anyone interested in the Apple seems to be intrigued by the "art of kraking", for a variety of reasons. Probably the foremost is this opens the way for worry free and ample software, that anyone can use and trade. Besides these immediate uses, kraking a program seems to impress all but the author of the program. I will be discussing the methods used in kraking protected Apple programs. After reading (and understanding!) all the files on this disk, you should be able to deprotect most any commercially protected Apple program. Of course, these files will not make you an instant expert on Apple copy protection, and there are many things to learn that I can not cover. But this will be an excellent starting point to grow from. The key to your success will be keeping an open mind, understanding all concepts mentioned, ingenuity, and above all, practice. Kraking protected programs requires several things that you should try your best to possess. The first is a good basic understanding of the Apple Computer and its architecture. Read your DOS manual and the Apple II reference manual for informative discussions of your computer. Even better, pick up a copy of Don Worth's "Beneath Apple DOS" and study it carefully. After you have done these basic things, you can probably impress everyone but Steve "The Woz", and turn the salesmen at Computer Land to shame. I can not stress the importance of reading these well written manuals, and doing the best to understand their implications. After you have achieved the knowledge granted by these books, you are well beyond 99% of the Apple users that claim they know anything about anything. Of particular importance is the "Apple II Reference Manual". The most important part of this manual is chapter 3, "The System Monitor" (page 40). STUDY THIS CHAPTER CAREFULLY. This chapter will describe many of the monitor commands you will need to krak protected programs. These commands include examining and changing memory locations, moving memory and comparing ranges of memory, and executing code. Also discussed is the Mini-Assembler and how to enter your own machine language programs. For the ultimate understanding of the Apple, and to make your job as a "krakist" easiest, the last step is to learn the forbidden language, 6502 ASSEMBLY language. Although this is not necessary for a great number of kraking chores, any program that is the least bit tricky will require you to understand ASSEMBLER. The reason is simple: most everything sold today is written in ASSEMBLER. Look at Softalk's top ten list and I bet you 95% of the programs are written in ASSEMBLY language. The obvious reason for this is because ASSEMBLER is fast, and this is VERY important for graphic games. Also, because protecting a disk on the Apple is done at the Operating System level, the protection really has to be written in ASSEMBLER. For learning ASSEMBLER, I would suggest either Roger Wagner's "Assembly Lines", or Randy Hyde's "Using 6502 ASSEMBLY Language". Both of these books are excellent and are easy to understand for the beginning programmer. Beyond this, the next best thing to do is to use your new found knowledge. Write some ASSEMBLY language programs to get familiar with the language. Instead of writing that "hello" program in BASIC, do it in ASSEMBLER. Get use to it, and keep good notes of what you learn! Now your ready for the big time.... kraking programs. I assume you have a good understanding of the monitor commands (list, move, verify, execute) from reading the Apple II reference manual. Of most importance is the "L" command to disassmble and list code presently in memory. Get use to looking at these disassemblies since you will never have "source" code from protected programs to examine. Therefore be fluent in Apple disassembly. The best way to achieve this is practice, and nothing else will substitute. Also, be aware of the existing documentation on kraking. Now just about anyone can read "cookbooks" on how to deprotect a particular program that they down loaded from Pirate's Harbor. So you want to take a step further. Don't discard or casually glance through these "cookbooks", but go through them and understand the protection and see how the author choose to krak the particular program. This will prove invaluable by opening your mind to previously used techniques that you can learn from. Try and understand every step the experienced krakist took to deprotect the program, and make careful notes (both mental and on paper) to guide you in your own efforts. After you have a good understanding of the basic techniques, the next step is to make some small hardware modifications used in kraking tricky programs. These will make your job infinitely easier. So read on and be prepared to learn. ______________________________ Chapter 2: Where to Begin. A discussion on the first steps to kraking protected programs Before we really start digging into discussions on copy protection, I think we should first define a few things and state the objective of this series. The object to this series is to make the average user more informed about copy protection and how to defeat them. Copy protection is what a publisher/author does to prevent you, the user, from making "unauthorized copies". The problem with copy protection is obvious: what do you do if: 1) Your original disk fails? 2) You need to modify the protected program for your particular application? Copy protection makes copies with "FID" or "COPYA" impossible. So many users save turned to programs such as "Locksmith" to make back-ups. This is not defeating the copy protection, but merely makes a clone of the entire disk and its protection. The disk is still un-modifiable, and consistent copies are a problem and time consuming. I consider this unacceptable. I will be discussing "kraking" methods, as opposed to copying methods using Locksmith or Nibbles Away. Kraking is defined as the techniques used to capture a protected program onto a normal DOS 3.3 disk that can be copied in a convenient manner, such as with COPYA. The primary objective of this series is to provide you with the knowledge to krak programs for your own use. Of course, using this information for illegal and otherwise perverted uses is frowned upon by myself and this series is written only for your amusement and education (com'on, this is serious, don't laugh...). Now that the objectives are clear, lets begin... The subject of deprotecting programs is truly a humongous one. There are probably thousands of ways to make a disk "uncopyable". This provides us with a mental puzzle that can (and probably will) consume much of your time and effort. But of course, the rewards are worth it not only in the obvious returns, but also in the gain in knowledge of programming and your Apple in general. If you enjoy puzzles and treasure hunts, you will enjoy kraking programs. Part of any puzzle is to find the first piece or starting point. This is no exception in the puzzle of protection either, and is probably the hardest step for the novice krakist. There is no substitute for experience, but there are some general guidelines to follow and some real dead giveaway clues to look for. In addition to finding the starting point, you will have to have some basic tools to krak most programs. Please refer to the chapter entitled "Basic Kraking Tools" for a complete description of what is absolutely minimal in attempting to krak protected programs. Protection generally falls into one of three categories. The first is protecting a single program in memory and/or on disk (called the "single load" protection). The second is protecting a set of programs by using a modified DOS (called the "modified DOS" protection). The third is using a loader or a modified RWTS (read-write-track-sector) for protection (called "Modified RWTS protection"). Since there are so many ways to protect programs in the above three manners, I will be mentioning general techniques that you may apply to just about any protected program. Now that we have categorized copy protection into three main categories, you must be able to recognize which category a particular program fits into. The remainder of this chapter will discuss this. After determining the type of protection used, you may refer to the particular chapters on kraking that protection type. THE SINGLE LOAD PROTECTION. This type of program is probably the easiest type of protection to deal with, but unfortunately is being seen less and less everyday. Single load programs are loaded in from disk only once, and then run from memory with no or very little disk access. Several years ago just about all games on the Apple fell into this category, and kraking these programs was not that difficult. The identification of these programs is simple: When the program boots and loads into memory and starts running, there is no additional disk access. (Disk access is when a program turns the disk drive on and read some data from disk. Usually this is for loading additional game levels, etc.). Programs that first load a title page, turn off the drive, and then wait for you to press a key and load the program are also single load if no other disk access is encountered. An example of this is Penguin Software's arcade games. Even though the drive turns off and then on after showing a title page, this is a single load program (title pages just don't count!). In addition, programs that save high scores to disk or do only some other minimal disk access are also single load. Many times they are not actually loading any data but are checking to see if the original disk in still in the drive. An example of this is most Penguin arcade games and many of the Electronic Arts games (One on One, Axis Assassin, etc.). This small disk accesses can almost always be defeated in some manner. Usually, the kraking of single load programs is finalized into a single (or small number of) files. Then from normal DOS this file can be BRUN. I am sure most of you have seen this type of program. MODIFIED DOS PROTECTION. Probably the most popular protection scheme is the Modified DOS Protection. These programs load much like a disk that you create (with the command INIT HELLO) do. The difference is that the publisher/author have modified DOS slightly to read and write to their copy protected disk. Publishers like to use this protection scheme because it is easy to incorporate, easy (and cheap) to make multiple copies for retail sales, and does a good job at discouraging the nibble copier owners. fortunately, kraking modified DOS disks is generally more systematic and sure-fire than the other types of protection. Also, there are many programs already developed to aide you in kraking modified DOS programs. There are some real dead giveaways to identifying whether a protected program is using a modified DOS. The foremost is the appearance of a BASIC prompt on the screen during the boot (either the "]" or "<" prompts). Some protectors have started to bypass the routine that prints the prompt, but you can still guess there is a modified DOS present from the sound of the boot. The sound of the boot is very important. Initialize a normal DOS 3.3 disk and boot it a couple of times. Listen to your disk drive as the disk boots. You will first here the drive chatter (this is making sure that the drive is ready to read track zero of the booted disk). Right after the chatter, the disk drive head will swing out to track two and read to track one (most drives click each time the head swings to another track. Listen for the click.). This is the process of loading DOS into memory. This process takes about 3 seconds at the most. Next you will here the drive head swing out to the catalog track to locate the "hello" program and load and run it. Now upon booting a protected disk you here the above sounds, there is a 99 percent change the program uses a modified DOS. If a BASIC prompt appears, it is a 100 percent chance a modified DOS is present. I have devoted a chapter and some examples to this type of protection. MODIFIED RWTS PROTECTION. The use of a modified RWTS is really just an off-shoot of the Modified DOS protection scheme. RWTS is a portion of DOS that does the actual reading and writing of particular sectors of a disk. Modified RWTS (or "loaders" if they only read and do not write to disk) are popular for multilevel games that must read from disk. Since RWTS only occupies a portion of DOS, the actual program that is being protected can be larger that if an entire DOS is being used. (NOTE: many single load programs use a modified RWTS to do the initial loading of the program. But if there is no more disk access after the initial load, the program falls into the "Single Load Protection" category, not "Modified RWTS Protection.). The method to deprotecting these disk is quite similar to deprotecting modified DOS disks. This is because RWTS is merely a portion of DOS. To identify a disk as using a modified RWTS is fairly simple. If the boot does not sound like a modified DOS boot (as described in the Modified DOS protection above) and a BASIC prompt does not appear, and there is additional disk access during the program, the protection is using a modified RWTS. Basically, if the program does not fit into the other two categories, it is probably a modified RWTS protection. (The only other real alternative is that the disk uses a modified PASCAL operating system, like the PFS and Wizardry series do). Examples of programs using this kind of protection are games like Zaxxon, Miner 2049'er, Donkey Kong and Jungle Hunt. I have devoted a chapter to this type of protection along with some practical examples. Now that you can identified what type of protection is being used, refer to the chapter that discusses it. This will outline the methods used to krak that particular type of program. ______________________________ Chapter 3 - Minimal Hardware Necessary for Kraking Protected Programs IMPORTANT NOTE: The first thing I should mention is that for doing any serious kraking you will need an Apple II or II+. Apple //e's are fine computers, but for the hardcore krakist, they will simply not do. The reason being is that the //e, Apple uses many "proprietary" chips that are not easily available, thus making any hardware modifications difficult. I'm not saying it can not be done, just its more difficult. For example, changing the Apple's monitor ROM is a considerably most difficult job on the //e than on the II+. Also, since slot zero is unusable by anything other than the built-in RAM card, we can not put a ROM card in its place. The II+ is just easier to modify on the hardware level, so I will be expecting you to have one. In order to krak most protected program you will have to have some way to break out of the program. The standard way of doing this has been to hit the reset key. But depending on the program on hand, this may not enable you to break out of the program without disturbing a minimal amount of memory. I am sure you have noticed that after hitting reset (assuming a normal Apple II+) that many things can happen. Usually, the program clears memory and reboots. This is evident by the screen filling up with some single character (the most popular is the inverse "@" character, representing a hex $00) and the disk drive starts up just like you hit "PR#6". This is rather inconvenient since our objective in kraking is to break out of a program, save memory to a normal DOS disk, and then reload and restart the program. This is very difficult if the program clears memory in the process of breaking out of it. This is where we need some help from the god of hardware. What we need is the infamous "old style F8 monitior ROM". This F8 monitor ROM is one of those big fat chips that lives inside your Apple, just in front and to the left of the peripheral slots. It should be labeled "ROM-F8". The old style F8 monitor was the monitor ROM that came with the Apple II. It enables you to enter the monitor whenever reset is pushed. (NOTE: If you have a RAM card in slot zero, a program can fool the Apple into looking at the memory in it instead of the F8 monitor ROM, and do funny things accordingly when reset is pushed. For a full discussion of this protection technique, read the chapter on "Kraking Flip-Out".) Now days, the Apple II+ (and //e) have the new style F8 monitor ROM, called the "Autostart" monitor ROM. This ROM allows the reset key to be programable, or do what ever you want when reset is pushed. For example, with the autostart ROM you can program it to jump to a routine that clears memory and reboots when the reset key is pushed. All that is involved is to change three locations in memory to point to your reset routine, and there is no way for you to stop it from executing when the reset key is pushed, unless you have an old style monitor ROM (or you do some tricks with your RAM card. See the chapter entitled "Kraking with a RAM card"). So to conclude this chapter, I am saying you will need, at minimum: 1) An Apple II or II+. 2) An old style F8 monitor ROM (available at most good Apple repair stores). But before you run out with your wallet in hand, I suggest you finish reading all chapters in this series for alternative and cheaper ideas. But I am for warning you that you will need this hardware, at the minimum. ______________________________ Chapter 4- Deprotecting Single Load programs At this point I must assume that you have read the introductory chapters and that you have obtained the minimal hardware necessary for kraking, as described in chapter three (since the hardware reset is an absolute necessity to begin kraking). Now the path divides and I will have to assume that you have determined that the program at hand fits into the "single load protection" category, as described in chapter two. But for review, remember that single load protection encompasses those programs that are loaded in only once, and then run strictly from memory with no disk access. Some minimal disk access is allowed, for example, to save high scores or to check for the original disk, but ultimately, these will be defeated or altered to allow us to save our program into a normal DOS binary file. Unfortunately (or fortunately,depending how you look at it) you will have to have some knowledge of ASSEMBLY language and some good working knowledge of the Apple's monitor commands. In addition, the ability to decipher the monitor's "disassembly" will prove invaluable. These tools will help a great deal since by the nature of the crimes we are committing, the rules are written in deceiving and uncommented 6502 machine language. There is no substitute for experience, but the only way to gain experience is to practice, so let's begin. First let's outline the steps we want to follow in deprotecting a single load program: 1) Find the starting address. This is the address that will always restart the program. 2) Figure out what parts of memory should be saved (we can not save >>all<< of memory, so we must figure out what is really needed and what is not). 3) Save the program as a normal DOS binary file that includes all of the needed memory. STEP 1: FINDING THE STARTING ADDRESS ------------------------------------ To further explain what a starting address is, remember when you are using "FID" from your DOS 3.3 System Master and you mistakenly reset from the program? Well many people get their system master disk back out and BRUN FID again to run the program. This is really unnecessary since all one must do is to enter the monitor and type the starting address with a "G" at the end (the "G" is the monitor's go or execute command): ]CALL -151 *803G The starting address of *803 will always restart FID, and this is what we want to find in our protected program. (Now some of you may be asking how I knew *803 was FID's starting address. A normal DOS file's starting address is kept at *AA72 and *AA73, in backassward order of course. After BRUNing or BLOADing FID, type: *AA60.AA73 The first two bytes listed are the length of the file, and the last two bytes are the starting address. Remember they are listed backwards, so *0803 will be listed as 03 08.) In the old days starting address were even numbers like $800, $900, or $6000. It is definitely still worth checking these address as many people find it more convenient to program with these starting addresses. So usually the first key you will want to press after the program is loaded is the reset key to reset into the monitor (giving us the "*" prompt). Now we can test our starting address by typing the address we think it is followed by a "G" to start execution at that address. Usually, you will be disappointed by your first attempts at guessing the starting address. Therefore, we need a more structured method for finding the programs's starting address. Since many programs first display a hi-res title page before starting the program, a good place to start looking is the series of instructions that turn on the graphic pages. The graphic pages are turned on and off by a series of "soft switches" in the $C050 range. It doesn't matter what you do to these locations as long as you access them in some way: C050: DISPLAY GRAPHIC MODE C051: DISPLAY TEXT MODE C052: DISPLAY ALL TEXT OR GRAPHICS C053: MIX TEXT WITH GRAPHICS C054: DISPLAY PRIMARY PAGE (PAGE 1) C055: DISPLAY SECONDARY PAGE (PAGE 2) C056: DISPLAY LO-RES GRAPHICS MODE C057: DISPLAY HI-RES GRAPHICS MODE This means that the following commands will have the same effect of turning on the graphics mode: LDA $C050 STA $C050 EOR $C050 BIT $C050 CMP $C050 ROL $C050 and if you understand the indexing from ASSEMBLY language: LDY #$71 AND $BFAF,Y However, most reasonable people have established the chore by writing: LDA $C050 LDA $C057 LDA $C054 LDA $C052 to turn on the graphics page. Now to find these instruction you can page through memory with the monitor's "L" command or you can use the Inspector's Find command and search for "50 C0" (refer to the appendix concerning the ROM card for a further explanation of the Inspector). After you find the code, trace backwards looking at the code just before it. Try and find an absolute end for the previous code before such as an RTS or a JMP. Your starting address should be immediately after the absolute end of the previous code. In addition, the code that turns on the hi-res page may just be a small subroutine, so you may have to search for a JSR to that location and trace backwards to find the starting location. When you think you have found the starting address, test it with the "G" command (i.e. *9000G). If you fail, reload the program and reset and start over. It is a good idea to always reload the program since the code you executed might have disturbed some other memory locations. It is always best to start fresh. Also keep in mind that that the hi-res routine may have been accessed by a "branch" instruction. These are conditional jumps that can reach $7F locations away in either direction. So search about 60 instruction before and after your the possible start. If you fine a BEQ or a BNE to your starting address, trace that routine back to its beginning and try it. In addition, try looking for a JMP to your starting location with the Inspector. This may produce another routine to trace back and find the starting address. Keep in mind if you have to trace back more than two steps, you are probably in the wrong area of memory and on the wrong trail. In addition, many programs wait for a key press before starting the program. You may also search for the code that accesses the keyboard. Usually the code looks like this: LDA $C010 THIS CLEARS THE KEYBOARD LDA $C000 THIS GETS A KEYSTROKE BPL $XXXX IF NO KEY, GOTO $XXXX JMP $START KEYSTROKE FOUND JMP START This is very common code and often produces a starting address. Another very good way of finding a starting address is to find the key that re-starts the program. Many times games use CTRL R to end the current game and to start a new one. This almost always produces a good starting address. Usually the code looks like this: LDA $C000 CHECK FOR KEYSTROKE BPL $XXXX NO KEY, JMP TO NEXT STAGE CMP #$93 COMPARE TO CTRL S (SOUND) BNE NEXT1 NOT EQUAL, TRY ANOTHER JMP SOUND IF EQUAL, GOTO SOUND CMP #$92 COMPARE TO RE-START BNE NEXT2 COMPARE TO CTRL R JMP START IF EQUAL, GOTO START CMP #$9B COMPARE TO ESCAPE BNE NEXT3 NOT EQUAL, TRY ANOTHER JMP HALT IF EQUAL, HALT PROGRAM CMP ..... Notice after the CMP #$92 (compare to CTRL R) the jump to a location. This is most likely your starting address. This address could have also be jumped to by means of a BEQ too, so keep that in mind. So to test your new found starting address, turn on the hi-res page manually (the game might not do it for you), and type the starting address followed by a "G": *C050 (you will be blind, so type carefully) *C057 (turn on hi-res graphics) *C055 (if using page 2 graphics) *START ADDRESS G If these two described processes do not provide you with a starting address, there are a couple of other things to look for. The first is a "jump table", which more experienced programmer generally use. This looks like this: JMP $4050 JMP $4000 JMP $900 JMP $931A . . . Try any of these as starting locations, but you are kinda poking in the dark with this one. In addition, the above JMP's could also be JSR's too. Just try executing the beginning of the jump table in that case. Lastly, a lot of programs start by setting up a bunch of zero page locations with parameters and so forth. This generally looks like this: LDA #$00 STA $03 STA $05 STA $07 LDA #$01 STA $7F LDA #$80 STA $FE STA $FF . . . Try starting the program with a starting address as the beginning of the zero page set-up routine. As you can see, finding the starting address can be a time consuming endeavor, and may not even produce any results. But do not be discouraged, and practice will make it easier. If you can not find the starting address, it may be because the program uses some "volatile" memory location that get distroyed when you hit reset. When you try and re-start the program, it sees these location do not contain what they should, and refuses to run. These locations include the text page ($400 to $7FF) and pages $01 and $02, and some zero page locations. This requires a different approach and will also call for some additional hardware. Refer to the chapter on NMI's when you have tried everything and can still not find the starting location. STEP 2: WHAT PORTION OF MEMORY TO SAVE -------------------------------------- Now that you have found the starting address of the protected program, we must determine what portions of memory we should save in our final product. We cannot save all of the 48K memory since we must use DOS to load the program back in. Basically, we have $8E pages of memory to play with and save as a maximum, out of the available $C0 pages that exist. NOTE: There are ways of saving more that $8E pages of memory in a standard bfile, and I address these methods in the chapters entitled "Using Second Stage DOS" and "Memory Packing". With our memory limitations in mind and the starting address at hand, we can find what portions of memory we need to run our program. The best way to start out is to turn your Apple on, and get into the monitor and clear memory to zeros. This way, after the program is loaded, we can examine memory and see what is loaded in by the program. The best way to do this is to type: ]CALL -151 *800:0 *801<800.BFFFM This takes whatever we put in location $800 and copies it to $801 to $BFFF. NOTE: if after doing this your Apple hangs, just hit reset to recover. Now boot your protected program by typing: *C600G or *6 (assumes disk controller card in slot 6). After the program is loaded, reset into the monitor and get the inspector up and search through memory for blank pages. Write down on paper any blank memory areas you find (don't try and remember them, just write them down). Alternatively, you can flip through memory using the monitor "L" command, but this will take an incredible amount of time. Also be aware of "garbage memory" and shape tables". Garbage memory is unused junk that does not disassemble. Shape tables look like garbage memory but actually contain graphic shapes and the such. Write down these suspect garbage memory areas on paper. Also check how the program starts. Does is turn on the hi-res page and use what is already there, or does it re-drawn the hi-res page. If it re-draws, you do not have to save that hi-res page (either $2000-3FFF or $4000-5FFF). Write that down too. The best way to check to see if a memory area is used is to load the program and reset, zero the suspect memory area, and restart the program. Run the program for a while and if it works OK, then that memory area is not needed. IMPORTANT: BE SURE TO CHECK ALL FACETS AND LEVELS BEFORE DISCARDING A MEMORY RANGE. The best way to zero a memory portion is to use the monitor's move command. For example, say you want to test to see if hi-res page 1 is re-drawn ($2000-3FFF). Type: *2000:0 *2001<2000.3FFDM This will zero out $2000 to $3FFF. Now restart the program and check it out. Make sure you keep careful notes of what is needed and what is not. WRITE DOWN EVERYTHING ON PAPER. AFTER YOU HAVE FOUND ALL NEEDED MEMORY AREAS, ZERO ALL UN-NEEDED AREAS AND RUN THE PROGRAM FOR A WHILE TO VERIFY. STEP 3: SAVING THE PROGRAM AS A BFILE ------------------------------------- Now that you have found the starting address and what portions of memory the protected program encompass, you have to get the memory portions to a standard DOS 3.3 disk. The best way to do this is to use a 48K slave disk (I will ignore anything you say about a tape recorder!). A 48K slave disk does not disturb memory from $900 to $95FF when it is booted. The best way to make a 48K slave disk is to boot any normal DOS 3.3 disk (fast DOS preferred), and type: ]FP ]INIT HELLO The disk created will be a 48K slave disk. A slave disk will give us a total of $8D pages of memory undisturbed when booted (a page of memory is $100 hex locations or 256 decmal locations). If a program is bigger than $8D pages of memory, you will have to save the memory portions in steps, or use some additional hardware as described in the chapter about NMI's. The best way to explain this is to use an example. Say you have found the starting address of a program and have found it lives from $800 to $2000 and $6000 to $BFFF. This means that you must relocate $800 to $8FF and $9600 to $BFFF, to clear the way for a slave disk boot. Since $2000 to $5FFF is unused, we can use that memory portion to temporarily store $800-8FF and $9600-BFFF. We can let the Apple do some of the work to determine if we have enough room. type: *C0-96 and the Apple will return a $2A. Now subtract $60-20 by typing: *60-20 and $40 will be returned. We obviously have enough room since we only need $2B pages ($2A+01). Now use the monitor move commands to move memory around: *2000<9600.BFFFM *4A00<800.8FFM Now boot your 48K slave disk and save the memory portions to disk: ]BSAVE ^09-20,A$900,L$1700 ]BSAVE ^96-C0,A$2000,L$2A00 ]BSAVE ^08,A$4A00,L$100 ]BSAVE ^60-96,A$6000,L$3600 Once again, use the monitor's addition and subtraction capabilities to figure out the lengths of the files if you are not good at hex math. Congratulations, you now have all of your protected program saved on a normal DOS 3.3 disk. But you are not finished, since you can not simply run any of these files. Now you must put them all into one file and move the pieces of memory back to where they belong. You can not simply re-load all the parts of memory since some will overwrite DOS, so we must load the memory portions in between $800 and $95FF and move the $9600 to $BFFF region back up to where is belongs, then jump to the beginning of the program. This is accomplished through the use of memory moves. A short program will move portions of memory from one part of memory to another. We can use the program MEMORY MOVE WRITER to do this work for us (there is additional doc on this program in one of the appendices). Remember that the unused portion of memory from $2000 to $5FFF is partially taken up from $2000 to $4A00 (we can move $4A00-$4AFF back to $800-8FF). So we can put our memory move program at $4A00. To do this, BRUN the file called MEMORY MOVE WRITER and choose a running location of $4A00. We want 1 move which will move $2000 to $4A00 to $9600. Now we select the viewing pages we want (hi-res, or text) and then enter the starting location of the program. A file will be saved to disk containing our memory move program. Now to put it all together. Bload the files into the appropriate place by typing: ]BLOAD ^08,A$800 ]BLOAD ^09-20,A$900 ]BLOAD ^96-C0,A$2000 ]BLOAD MEMORY MOVE$4A00,A$4A00 ]BLOAD ^60-96,A$6000 Now enter the monitor and make a couple changes so the file will run when BRUN: ]CALL -151 *7FD:4C 00 4A (this jumps to $4A00 when the file is BRUN) *A964:FF (enables us to save big files) Note that we enter a JMP to the memory move routine at $4A00 three bytes before $800. This is because the jump instruction takes three bytes (4C 00 4A). Now you can save the file to your disk by typing: *BSAVE FILE,A$7FD,L$8E03 You can determine the length parameter by typing: *96-08 and $8E will be returned. Since we want those three extra bytes for the initial jump to the memory move routine, we need to add three to that. Hence we arrive at a length of $8E03. Brunning this file should restart the program and all should be fine. Note that we have saved some unnecessary memory in the file, memory from $4B00 to $5FFF. We could pack the file move and use more memory moves to make the file smaller, but I will leave that to you. FINAL NOTES: If your program has some additional minimal disk access for saving high score and the such, refer to the appendix entitled "Removing Disk Access" for help with that. Also, if your program requires saving "volatile" memory locations (text page, etc.), refer to the chapter entitled NMI's for help with that subject. ______________________________ Chapter 5: Modified DOS Protection By far the most popular protection scheme ever used is the modified DOS protection. This scheme bases its protection upon normal DOS 3.3, but makes some vital changes to the DOS to read a perverted disk structure. Before being able to krak disks using this protection, it is best to understand a normal DOS disks' structure. Then we can evaluate how the normal structure is modified. Each normal DOS disk has 35 tracks (labeled 0 thru 34) and 16 sectors (labeled 0 thru 15), where each sector represents one page (256 bytes) of data. Each sector consists of two separate parts: an address field and a data field. First let's discuss the address field. If you read a disk with a "nibble read" routine (found in The Inspector, Nibbles Away and Locksmith), you will see a disk's data in the raw form. Scanning through the data you should see something like this: ....FF FF FF FF D5 AA 96 FF FE AA AA ! (1) ! (2) ! (3) ! (4) ! AA AA FF FE DE AA EB FF FF FF FF... ! (5) ! (6) ! (7) ! (8) D5 AA AD -342 bytes- XX DE AA EB ! (9) ! (10) !(11)! (12) The first few FF's (1) are known as syncbytes, and are used as separators, or borders. The next three bytes (2) are called the prologue address bytes, and are very important. This sequence of three bytes will not be found anywhere else on a disk except the address field. These bytes serve as unique identifiers to DOS so it can find what track and sector it is reading (hence "soft sectoring"). The data following the address markers are therefore, address identifiers. This includes the disk's volume number (3), track number (4), sector number (5), and checksum (6). The format is a little strange, and is called 4+4 nibblizing. This format stores data in which the even bits of a byte are stored in one 8-bit sequence and the odd bits are stored in a second 8-bit sequence. In other words, it takes two bytes to store one byte. This was done because of limitations imposed by disk drive hardware. The address identifiers are all pretty obvious, except for the checksum. The checksum tells DOS that everything checks out OK when reading the disk. The next set of bytes are the address field epilogue bytes (7). These are used to mark the end of the address field. A total of three bytes are used (DE AA EB), but only the first two are checked when the field is read. The epilogue bytes are really not needed, but provide added assurance that the drive is still in sync with the bytes on the disk. The next set of bytes (8) are more syncbytes which separate the address field from the data field. The second part of a sector is the data field. The first three bytes are the data prologue bytes (9) and they tell DOS that the data follows. In raw form, 256 bytes of memory data is represented in 342 bytes of disk data (10). Each disk byte represents 6 bits of a memory byte (remember there are 8 bits to a byte). Therefore it takes 342 disk bytes to represent 256 memory bytes. Once again, this is used because of disk drive hardware limitations. At the end of the data is a single checksum byte (11). The checksum is a number which when exclusive ORed with the rest of the data in a sector equals zero. If this number does not equal zero, DOS thinks thinks something is wrong and gives you an "I/O ERROR". Also, there are data field epilogue bytes (12) which also make sure the drive is in sync with with the disk. Now this brings us to our first and most popular protection trick. This involves changing the epilogue bytes of either the data and/or address fields from the standard. This is really not a very good protection scheme. If the prologue bytes are not changed, normal DOS can still find the address and data fields (and knows how long each should be), and can still read the data. An I/O ERROR will occur though because the epilogue bytes can not be found to correctly mark the end of the data. To read a disk in which the epilogue bytes have been played with is very easy. Just enter the monitor and change byte $B942 from $38 to $18. What this does is to "clear the carry" instead of "setting the carry" when a disk error is encountered (DOS used the carry bit as a flag for errors). Just type: ]CALL-151 *B942:18 *9DBFG THIS IS PROBABLY THE MOST IMPORTANT MODIFICATION YOU CAN LEARN TO MAKE WHEN TRYING TO DEPROTECT A MODIFIED DOS PROGRAM! A program that uses this protection exclusively is "Money Street" from Bullseye Software. But more traditionally, this mild protection is combined with other modifications. Also very common is to change the address or data field prologue bytes. This will immediately choke up any normal DOS copy program and even confuses Nibbles Away and Locksmith on occasion. This is because normal DOS can not find where the address identifiers are, so it can not figure out what sector it is reading. Also, if the data field prologue bytes are changed, it can not find where the data starts. The way to find out if these bytes have been changed is to do a nibble read (using the Inspector, Nibbles Away or Locksmith) of the protected disk and to examine the data. Look for the landmarks as described above. It is usually best to read a series of non-DOS tracks like track 3, 17 and 20 when doing a nibble read of a disk to make sure you get the same results (but of course, some protectors have even used different address and data markers for each track!). Alternatively, you can load the program, reset into the monitor and examine the DOS locations that hold the address and data field bytes. Compare them to what they should be and note any differences. Once you have determined what address or data field bytes have been changed, it is a breeze to copy the disk with COPYA. All you have to do is to add three lines to COPYA. First here is a table of locations that are to be changed and their original values in regards to the address and data field bytes: ADDRESS PROLOGUE BYTES: ----------------------- 47445 ($B955):213 ($D5) 47455 ($B95F):170 ($AA) 47466 ($B96A):150 ($EB ADDRESS EPILOGUE BYTES: ----------------------- 47505 ($B991):222 ($DE) 47515 ($B99B):170 ($AA) DATA PROLOGUE BYTES: -------------------- 47335 ($B8E7):213 ($D5) 47345 ($B8F1):170 ($AA) 47356 ($B8FC):173 ($AD) DATA EPILOGUE BYTES: -------------------- 47413 ($B935):222 ($DE) 47423 ($B93F):170 ($AA) The change we want to make to COPYA is to swap the address or data field bytes that are different on the read and the writes. So we just poke the modified bytes before the read, and poke the normal bytes before the write. This is best illustrated with an example. Suppose a disk has modified address epilogue bytes of D5 AA AD (instead of the normal D5 AA 96) and modified data prologue bytes of D5 AA DA (instead of the normal D5 AA AD). So we would need to add these three lines to COPYA by typing: ]RUN COPYA (after program is loaded and waiting for you to select drives and slots): CTRL C ]198 POKE 47446,173: POKE 47356,218 ]248 POKE 47466,150: POKE 47356,173 ]258 POKE 47466,150: POKE 47356,173 ]70 ]RUN The first added line changes the address and data prologue bytes to the modified format just before reading the original disk. The last two lines added change them back to normal DOS 3.3 just before initializing and writing to the destination disk (respectively). Of course I converted the hex values of the bytes to decimal and only poked the different ones. Instead of doing the poking by hand, I have written a program called "ADVANCED COPYA" that allows you to input any changes to the address or data markers (in hex or decimal), along with other parameters you may find handy. Now that you have converted a disk to a normal DOS 3.3 format, that does not guarantee that it will work! You may have to find other routines that expect certain address and data markers to be different than normal and modify or defeat them. If it is a BASIC program, look for peeks and poke above 47000 and track them down. Probably the most common "fix" is to change track 0, sector 3, byte $42 from $38 to $18. This is actually changing location $B942 in the DOS tracks, and is doing so right to the disk so it is permanent. It should be noted that some programs change the address and/or data marker bytes as the program runs. Examples of this is adventure games and business programs that run from a protected disk but save the game or other data to a normal DOS 3.3 disk. In this case you must find these "byte swap" routines and defeat them. An easier and more general method of converting protected DOS disks to a normal format is COPYB. COPYB simply uses the RWTS (read - write - track - sector) portion of the protected DOS to read the original disk, and uses normal DOS RWTS to write to a normal DOS disk. This is a much easier and more general method of deprotection than using "ADVANCED COPYA", but is also not as flexible. It is best to become familiar with both programs and how to use them. I have devoted a appendix and several examples to the subject of using COPYB in deprotecting programs. Please refer to those for more information on COPYB. To summarize this chapter, we had discussed the most popular methods of protecting a disk using a modified DOS. This usually means modification of the address and/or data field epilogue and/or prologue bytes. At this point, I would suggest going through the example kraks of programs. They will provide some real-life situations that are very typical. ______________________________ Chapter 6: Modified RWTS Protection The modified RWTS protection is an offshoot of the modified DOS protection, but instead of using an entire DOS, just the RWTS portion of DOS is used. RWTS is roughly the upper third of DOS $B700-BFFF) and does the actual loading and writing of separate sectors. Many programs use only RWTS, or a portion of RWTS because of memory limitation, better protection, or pure finesse. It is also very easy to control disk drive access from ASSEMBLER, so it is a natural to use RWTS calls from ASSEMBLY language programs and to ignore the rest of DOS altogether. Sometimes mere portions of RWTS are used in the form of a loader. A short program (around $300 bytes) can be written to just read from a disk, thus saving memory and also making the disk access harder to find. This is typical is many of the older Sirius games, along with some others. Because a loader or RWTS tends to be a short program, much of the normal DOS error checking is defeated and forms of protection are included. For example, perhaps a nibble count is added to the loader to check if the disk is an original. Also very common is the address and/or data prologue or epilogue bytes are changed from the norm. To deprotect a program which is using a loader or RWTS can be difficult or very easy, much like any of the other kinds of protection. Generally, you have to do three things: By-pass the nibble count or checksum routine, modify the loader to read normal DOS address/data headers, and copy the modified disk to a normal DOS format and make the changes to that disk. So the first thing you will have to do is to get the data from the protected disk to a normal DOS 3.3 format. The first thing I ALWAYS try is to defeat the DOS error checking routine at $B942 and try and copy the disk with COPYA. This routine sets the carry flag when ever DOS thinks it can not read a sector. DOS monitors the carry bit, and if set, bomb out with some dumb error message. Usually an error can be prevented if modified epilogue bytes are used. To defeat the DOS error checking, type: ]CALL-151 *B942:18 *RUN COPYA Many times you will only have to read a portion of the protected disk, because it does not use all tracks. Use ADVANCED COPYA or COPYB to transfer the data to a normal DOS disk in this case, or where the above mod to DOS did not allow you to copy the disk (ADVANCED COPYA and COPYB are discussed in the previous chapter, and in appendix A). Also, it would help if you knew what the address/data markers are, if different than normal DOS. Beyond this, the protection is more involved and you will have to dig for the answer.... After making a normal DOS copy of the protected program, it probably won't run, so you will have to change the modified RWTS so it can read a normal DOS format. To do this, reset from the protected program and check these locations for anything funny (remember that RWTS normally lives from $B700 to $BFFF): NORMAL ADDRESS VALUE USE ------- ---- ------------------------- $B853 D5 DATA PROLOGUE BYTE1-WRITE $B858 AA DATA PROLOGUE BYTE2-WRITE $B85D AD DATA PROLOGUE BYTE3-WRITE $B89E DE DATA EPILOGUE BYTE 1-READ $B8A3 AA DATA EPILOGUE BYTE 2-READ $B8A8 EB DATA EPILOGYE BYTE 1-WRITE $B8AC FF DATA EPILOGUE BYTE 2-WRITE $B8E7 D5 DATA PROLOGUE BYTE 1-READ $B8F1 AA DATA PROLOGUE BYTE 2-READ $B8FC AD DATA PROLOGUE BYTE 3-READ $B92A D9 00 LOCATION CHECKSUM COMPARE $B935 DE DATA EPILOGUE BYTE 1-READ $B93F AA DATA EPILOGUE BYTE 2-READ $B942 38 SET CARRY FOR I/O ERROR $B955 D5 ADDR PROLOGUE BYTE 1-READ $B95F AA ADDR PROLOGUE BYTE 2-READ $B96A 96 ADDR PROLOGUE BYTE 3-READ $B991 DE ADDR EPILOGUE BYTE 1 $B99B AA ADDR EPILOGYE BYTE 2 $BC7A D5 ADDR PROLOGUE BYTE1-WRITE $BC7F AA ADDR PROLOGUE BYTE2-WRITE $BC84 96 ADDR PROLOGUE BYTE3-WRITE $BCAE DE ADDR EPILOGUE BYTE1-WRITE $BCB3 AA ADDR EPILOGUE BYTE2-WRITE $BCB8 EB ADDR EPILOGUE BYTE3-WRITE If any are different, locate the different byte sequence on the COPYA version of the disk using a good disk scanning program (the Inspector, CIA, etc.) and change the locations back to normal with a sector editor. Many times, this is all that is necessary, but not always. Maybe there was a nibble count that will prevent the COPYA copy from running. Finding this could be the trickiest part. Search through the program looking for any JMP's or JRS's to the DOS area. Beyond this I can not give much help. But after you find it, locate the routine on the disk and defeat it. You can do this by putting a $60 at the beginning of the nibble count subroutine (Return from subroutine), or by "noping" the call (no operation) to the subroutine with three "$EA"s. For some real life examples, refer to the files "Zaxxon" and "Oil's Well". These give good examples of modified address/data markers and defeating nibble counts in modified RWTS protection. In addition, the program may be using a loader that doesn't live in the $B700 to $BFFF range. These can be tricky to find, and even tricker to make work in a modified DOS environment. I would first do a nibble read of the disk and find out what the address and data prologue and epilogue bytes are. Then look for code like this: 0350- B9 9E C0 LDA $C09E,Y 0353- C9 D5 CMP #$D5 0355- D0 F8 BNE $0350 0357- B9 9E C0 LDA $C09E,Y 035A- C9 AA CMP #$AD 035C- D0 F8 BNE $0357 . . This type of code accesses the drive and compare some data header to make sure it is the protected format. All you need to do is to find this routine on the disk, and change the headers to normal DOS. Easy, huh? Also be familiar with direct calls to RWTS. If you can recognize these you can usually find from where the data is being loaded from. Here the parameter list for using DOS from ASSEMBLY language: $B7EA: DRIVE NUMBER TO USE $B7EB: VOLUME NUMBER ($00=ANYTHING) $B7EC: TRACK NUMBER TO READ $B7ED: SECTOR NUMBER TO READ $B7F0: LO-BYTE OF BUFFER TO READ/WRITE $B7F1: HI-BYTE OF BUFFER TO READ/WRITE $B7F3: PARTIAL SECTOR READ(0=WHOLE SCT) $B7F4: COMMAND CODE(0=SEEK,1=RD,2=WRT) $B7F5: ERROR CODE (VALID IF CARRY SET) $B7B5: SUBROUTINE FOR ACTUAL READ/WRT. $BD00: ALSO SUBROUTINE FOR READ/WRITE Here is a sample program that uses these parameters: 9000- A9 04 LDA #$04 ;track 4 9002- 8D EC B7 STA $B7EC; 9005- A9 0F LDA #$0F ;sct F 9007- 8D ED B7 STA $B7ED; 900A- A9 00 LDA #$00 ; 900C- 8D EB B7 STA $B7EB;vol # 900F- 8D F0 B7 STA $B7F0;page 9012- A9 4F LDA #$4F ;hi-page 9014- 8D F1 B7 STA $B7F1; 9017- A9 01 LDA #$01 ;read 9019- 8D F4 B7 STA $B7F4; 901C- A0 E8 LDY #$E8 ;ready 901E- A9 B7 LDA #$B7 ;to rd 9020- 20 B5 B7 JSR $B7B5;read 9023- CE ED B7 DEC $B7ED;dec sct 9026- CE F1 B7 DEC $B7F1;dec pg. 9029- AD ED B7 LDA $B7ED;compare 902C- C9 FF CMP #$FF ;sct. 902E- D0 EC BNE $901C;go back 9030- A9 0F LDA #$0F ;else 9032- 8D ED B7 STA $B7ED;sct $0F 9035- CE EC B7 DEC $B7EC;dec trk 9038- AD EC B7 LDA $B7EC;compare 903B- C9 01 CMP #$01 ;track 903D- D0 DD BNE $901C;go back 903F- 60 RTS ;return Try and figure out what this does...This reads track 4, sector F down to track 2, sector 0 into $4F00 to $2000. This would be a perfect example for reading a hi-res picture in using RWTS. Be able to recognize these routines. The dead giveaway is the JSR $B7B5. All the parameters could have been loaded through other location, such as zero page location, then re-loaded into RWTS. But the JSR $B7B5 gives it all away. Also notice how the routine read "backwards", or down. This is done for speed reasons, and none other. If we incremented the sectors instead of decrementing them, this routine would take 4 times longer to load. It does not matter if we increment the tracks or memory pages though...just the sectors (this has to do with "sector skewing"). I hope this has provided some useful information in deprotecting modified RWTS programs. For further information on RWTS, refer to the chapter on using second stage DOS (RWTS). This provides information on how to use RWTS from your own programs. ______________________________ Chapter 7: Using Second Stage DOS for your own programs Sometimes you will find your self with a single load program that is too big for a file under normal DOS. This usually means the program uses more that $8E pages of memory. In cases like these, you can often load in the file using second stage DOS, or otherwise know as RWTS. Another application for using second stage DOS is when you have a multi-disk access program that uses a fairly standard disk structure. Lets say you know the program loads in, and then runs for a while. Then a new level is loaded in from track $01. You could krak the program into a file, transfer track $01 to a normal format disk, and put the file on some other tracks than track $01. But DOS uses tracks $0 to $02, so how do you load the file?.. You can use second stage DOS (that lives on track $0, sectors 0 to $09 only) to load the file from track 2 and up, and this could read the levels from track1. Being able to use second stage DOS is certainly handy, and if you write your own programs, a great way to make them load "professionally", without the dumb BASIC prompt appearing during the boot. First let's see why it's called "second stage DOS". DOS loads in from a disk in three parts, labeled stage (or boot) 0 through 2. The first stage of DOS boot (stage 0) is loaded from track 0, sector 0, by the code in your disk controller card. This one page of memory gets loaded into $800-$8FF. The second stage of the DOS boot (stage 1) is loaded in from track 0, sector 0 to sector 9 into $B600-$BFFF. This is loaded by the code at $800-$8FF. The code loaded into $B600 and up is RWTS. The third stage of the DOS boot (stage 2) is loaded from track 0, sector C to track 2, sector 4, and is the rest of DOS ($9D00 to $B5FF). This is loaded by the code at $B600-$BFFF. But we can fool DOS into loading our program instead of loading in the rest of DOS! To summarize, here are the steps: boot 0: loads trk 0, sct 0 into $800 boot 1: loads trk 0, sct 0-9 into $B600 Boot 2: loads our program into ??? Here is how we do it: 1) Boot your DOS 3.3 System Master (you CAN NOT use a fast DOS disk here, but that won't matter cuz it will load real fast anyway). 2) Initialize a blank disk by typing: ]INIT HELLO 3) Run a sector editor on this initialized disk and change track 0, sector 0, byte $4A to $4C 80 08. Don't forget to write the sector back out. 4) Read track 0, sector 0 into $800 and write this program at $880: 0880- A9 XX LDA #$XX :# of scts 0882- 8D E0 B7 STA $B7E0: 0885- A9 XX LDA #$XX :starting trk 0887- 8D 15 B7 STA $B715 088A- A9 XX LDA #$XX :starting sct 088C- 8D 1A B7 STA $B71A 088F- A9 XX LDA #$XX :start pg+1 0891- 8D E7 B7 STA $B7E7 0894- 4C 00 B7 JMP $B700 NOTES: ------ $881: enter the number of pages (or sectors, they're the same, remember?) you want to read in. $886: enter the starting track to read from. This will read in descending order, so enter the HI-TRACK. $88B: enter the starting sector to read from. This will read in descending order, so enter the HI-SECTOR. $890: enter the HI-PAGE PLUS 1 you want to load into. This will be the first page read into, and it will descend from there. I.E. If you want to start loading at $AFFF, the start page is $B0. 5) Write the sector back out. 6) Read in track 0, sector 1 and change byte $47 to $4C XX YY where XX YY is the address you want to jump to after the program is loaded, in lo-hi order (just like normal). Don't forget to write the sector back out. Now you're all done! You can use track 0, sector A through track 22, sector F for any data. Transfer your program or other data using the Inspector or some other means onto the tracks and sectors you specified above. REMEMBER, SECOND STAGE DOS WILL READ YOU PROGRAM FROM THE HIGH TRACK AND SECTOR DOWN, AND FROM THE HIGH PAGE DOWN (I.E. TRACK 9, SECTOR F INTO $8F00-$8FFF, TRACK 9, SECTOR E INTO $8E00-$8EFF, ETC.). It should be noted that many protection schemes use this exact format to load in their programs. They just modify RWTS for their protection, as described in chapter six, modified RWTS protection. An example of this is many of Datamost's programs, including "Roundabout". ______________________________ Chapter 8: The Art of Memory Packing Many times when kraking a single load protection scheme and finding the starting address and what memory the program occupies, the program is just too big to fit into a normal DOS file. After examining memory, you find a large section of memory that all the bytes are the same, but is necessary for the program to run. You could use second stage DOS to read the file in, but it just seems to be a waste to have all that repetitive data on a disk. Or maybe you have just kraked a great new game, and you have just put the finishing touches on the file, complete with a hi-res banner displaying your name and the program's name (don't break your arm patting yourself on the back). Just for reassurance, you want to make that hi-res picture so some idiot can't erase or change it (at least not easily). Both of these cases warrant using a memory packer. Memory packing is taking some repetitive bytes and storing them into some smaller format in a file. Then, when the program is reloaded, expanding them back out to their normal size and positions. Hi-res pages and shape tables tend to have a great deal of repetitive bytes, and can sometimes be reduced to a quarter of their original size using a memory packer. The way memory packing works is simple. Typically, a memory packer finds a byte that repeats 4 or more times (3 times is the break-even point) and stores the repetition as 3 bytes: the first byte is a "flag" byte, signifying the next 2 bytes are a packed sequence. The second byte is the number of times the byte repeats itself, and the third byte is the actual byte that is repeated. Of course, doing this by hand would be stupid at best, so we can write a program that searches a specified range of memory for repeating bytes, and packs the range (many "picture packers" do this, but only for one of the two hi-res pages). It would be optimal to pack over the original memory, as a convenience to us (the programmer) to avoid moving surrounding memory around too much. But before we can pack any memory, we must have a flag byte. A flag byte is a byte that signifies the next 2 bytes are a packed sequence. OF COURSE, THIS FLAG BYTE CAN NOT OCCUR ANY WHERE ELSE IN THE MEMORY RANGE YOU ARE PACKING. So to pack a range of memory, we need to be able to do 3 things: 1) Find a Flag byte. 2) Pack the memory using a Flag byte. 3) Unpack the memory. Of course, I have provided you with some short routines to do these three things. (NOTE: all these routines are written by "KRAKOWICZ", and are public domain). The first program is called "SHOWBIN", and finds our flag byte. To use SHOWBIN: 1) load the memory range you want to pack (any range from $800 to $95FF). 2) Put the low page in location $00, the high page in $01. 3) BRUN SHOWBIN. The first display will be the bytes that are never used in that memory range. Now hit RETURN, and the bytes used once are displayed. Hit RETURN again, and the bytes used twice are displayed, and so on. To exit, hit ESCAPE. Make a note of one of the bytes that are never used in that memory range (if there is NO bytes that are never used, you will have to make the memory range you are packing smaller, sorry). Now its time to run PACKER. To PACK the memory range, do the following: 1) Load location $05 with the flag byte, location $06 with the low page, and $07 with the hi page. 2) BRUN PACKER After a second, you will get your prompt back. So now type: *00.01 The returned two bytes are the address that the packed data starts at (in backassward order, of course). It ends at the last location of the hi-page specified. An example is needed to clarify: Suppose you want to pack memory from $4000 to $95FF. To do this, here are the steps: 1) BLOAD the memory you want packed ($4000 to $95FF). 2) type: ]CALL-151 *00:40 95 (remember, $40 is the lo page, $95 is the hi-page). 3) type: *BRUN SHOWBIN 4) Write down one of the unused bytes and hit ESCAPE to exit (let's say $91 is the unused byte that will be our flag byte). 5) type: *05:91 40 95 *BRUN PACKER *00.01 6) Write down the two bytes returned from locations $00 and $01 (Let's say they are $B3 and $71, respectively. This means we have packed $4000-$95FF into $71B3 to $95FF). Now to reconstruct $4000-$95FF from $71B3-$95FF, we need to load locations $00 and $01 with $B3 and $71 (just like PACKER gave them to us), and call the UNPACKER routine. UNPACKER is less than $50 bytes long and is relocatable (can run in any memory range). UNPACKER will unpack memory over itself, saving us a lot of work and programming. So to unpack the $71B3 to $95FF: 1) type: *00:B3 71 *BRUN UNPACKER That's it! Under program control, it would look like this: LDA #$B3 STA $00 LDA #$71 STA $01 JSR UNPACKER For more explanations on memory packing, refer to the file "SINGLE FILE ROUNDABOUT", where I show how I krak and pack a single load protection game from Datamost called "Roundabout". ______________________________ CHAPTER 9 -INTRODUCTION TO THE NON- MASKABLE INTERRUPT (NMI) INTRODUCTION: Assuming that you have read the first several chapters of this series, you now should possess some basic information regarding the architecture of the Apple computer. Using this basic information you will go quite far down "memory lane" in your kraking efforts, but it doesn't stop there. Now we need to talk about some basic hardware you will need to make your job easier. What we will be discussing is the use of resets and "NMIs" in the art of kraking. INTRODUCING THE NMI: NMI is an acronym for NON MASKABLE INTERRUPT, and as the name implies, it can not be prevented (or masked) on the Apple. The NMI is the basis behind most of the "copy cards" on the market, such as the Wildcard or Replay cards. The NMI allows us to interrupt a program, and to restart it with minimal effort. Obviously this is of extreme importance to the krakist, who wants to interrupt a programs, save memory to a normal DOS disk, and restart the program upon BRUNing the file. To use an NMI you can simply crossed pin 26 (ground) and pin 29 (NMI) of any one of the peripheral slots. You can do this with a 100 ohm resistor. This will execute an NMI. Unfortunately, this is less than ideal since when you try to do this, you will probably execute 20 or so NMI's. This is because it happens so fast, that an NMI will interrupt an NMI, and so on for many, many times. This will put much garbage onto the stack (page one). Using a switch for this chore doesn't help since the switch actually slams (or bounces) against itself many times causing the same problem. To solve this we need to make a "de-bounced" NMI switch. This will constitute about $8 to $20 of capital resources (depending on your parts supplier), and a soldering iron. This is considerably less expensive than a store bought NMI board, but will lack some of the features the commercial ones have. A full discussion of how to make an NMI board is in the appendix "Making a NMI Board". Assuming you have made your NMI card, I will now tell you more about how it works and its uses. If you don't fully understand the workings of the NMI, don't worry about it. Just try and follow along. When you push the NMI switch, the 6502 processor will push the present value of the program counter on the stack along with the processor status word. Then it will jump to what ever locations are pointed to by $FFFA and $FFFB. So to restart an interrupted program, we only need to restore the registers (x, y, accum), the lower pages of memory, and the stack pointer, and do a "RTI" (return for interrupt) instruction. I have written a small program which does this all for you and works in conjunction with the NMI board and a modified F8 ROM, which I am about to describe. Now remember our old F8 monitor ROM? Well these two locations live in the monitor ROM. It would be nice if we could change these location and after an NMI is executed, run a small program to that will save the registers, the stack pointer, and the lower pages of memory. Now this leads us back to our old friend, the F8 monitor ROM. This is indeed what we need to do. The best thing would be to execute an NMI, and then jump to a routine that moves the lower 16K of memory into a RAM card. Then we could boot a 16K slave disk (which would only disturb the lower 16K of memory), and save all of memory to a disk. After we have saved all of memory, we could reconstruct our program and re-start, or do a "return from interrupt". Of course to do this we need to change some of the code in the F8 monitor ROM. We can not do this directly to the F8 chip that comes with your Apple since it is Read Only Memory. But we can move the code in the ROM down to RAM, put our routines in, and burn a new "2716 EPROM". The 2716 EPROM will replace the ROM, and will have our new kraking routines in it. Now you ask, "how do I burn a 2716 EPROM?". Well, if you don't have access to an EPROM programmer, you can take your modified F8 code (saved to a disk) to a local computer store and they should be able to burn you one for a nominal fee. Refer to the appendix entitled "Making a F8 Krak ROM" for an explanation of how to create the code for the new EPROM and how to plug it in after it is burnt. Lastly, we need to make a 16K slave disk and to use the program to save all of memory to a disk. To get the program type it in or download it from someone. To create a 16K slave disk, do the following: (NOTE: this only applies to the Apple II or II+) 1) Turn off your computer. 2) Open the lid, and look for the 3 rows of chips that have a white line boarder around them. These are the 48K of RAM in your Apple II+. 3) Remove any one chip from each of the two rows of RAM furthest away from the keyboard. 4) Turn the computer on and boot your DOS 3.3 System Master. 5) Put a blank disk in the drive and type: ]INIT RAM 48K SAVER 6) When this is complete, turn the computer off and replace the two chips. 7) Run a sector editor and change the following sectors of the 16K slave disk: TRK SECTOR BYTE FROM TO ------------------------------ $00 $01 $48 $03 $00 $00 $0D $42 $06 $34 8) Write the sector back out to your 16K slave disk. 9) Delete the Hello program on the disk by typing: ]DELETE RAM 48K SAVER Now download the "RAM 48K SAVER" file and save it to your 16K slave disk. Also down load the file "MEMORY MOVE WRITER". Save these to your 16K slave disk also, and then write protect it. The program "RAM 48K SAVER" will save all 48k of memory to a disk and also create a restart program that will do the "return from interrupt". The "MEMORY MOVE WRITER" program will enable you to reconstruct memory back to where it belongs after you load it from your normal DOS 3.3 disk. In the appendix "Using your NMI board", I will discuss how to use this hardware and software in a real-life application. ______________________________ Chapter 10: Protected Applesoft Basic Programs Many protected programs are written in APPLESOFT. Of course, most publishers are sly enough to protect against breaking out of their program with CTRL C or reset. Also, most protect against re-entering BASIC from the monitor by changing the typical BASIC re-entry point (at $3D0) so that it points to disaster. And lastly, many change the RUN flag vector at $D6 so if you manage to get out of their program and into BASIC, anything you type will RUN their BASIC program. I will describe how to beat all these protection schemes, assuming you have an old style F8 monitor ROM. First, we must determine if the protected program is written in APPLESOFT. If after you boot the program a BASIC prompt appears, this is a good indicator that at least some of the program is written in BASIC. Further more, if the program prints a lot of text on the screen, or requires a good deal of user inputs, it is a good guess that the program is written in BASIC. The reason for this is that printing text on the screen and inputing data from the keyboard is easily accomplished from BASIC using PRINT and INPUT statements. To do this from ASSEMBLY language requires a great deal more work. Also, we should realize why a programmer uses ASSEMBLY language. The only real advantage to ASSEMBLER is speed. If speed is not critical, most (non-sadist) programmers will use BASIC. With this in mind, look at how the program runs and prints on the screen. If it runs at about the same speed as the BASIC programs you have written run, it is a good guess that it is in BASIC. Remember, ASSEMBLY language is considerably faster than BASIC in every respect. Finally, read the package the program came in. It usually says what it was written it. If it doesn't, a dead give away is in the hardware requirements. If the program requires APPLESOFT in ROM, then at least part of the program is probably written in APPLESOFT. Now that you have figured out your protected program is written in BASIC, it is time to LIST their code. The first step is to reset into the monitor when the program is running. Now you can try to enter the immediate BASIC mode by typing: *3D0G This is the normal BASIC re-entry point. But if the protection is worth anything, this will not work. Assuming that didn't work, reload the program and reset into the monitor again. The next thing is to try typing 9D84G or 9DBFG. These are the DOS cold and warm start routines, respectively. If you are lucky enough to get a BASIC prompt, you have done well. Most of the time, you won't. If in either case you succeed in getting a BASIC prompt, try LISTing the program or CATALOGing the disk. If anything you type starts the program running again, the protection has changed the RUN flag at $D6. So reset into the monitor again. The RUN flag is a zero page location (at $D6) which will run the BASIC program in memory if $D6 contains $80 or greater (128 or greater in decimal). This is easy to defeat after you have reset into the monitor by typing: *D6:00 This resets the RUN flag to normal. Now if 3D0G, 9D84G or 9DBFG previously rewarded you with a BASIC prompt, this will solve the problem of the program re-running when you type a command. For debugging efforts, the RUN flag can get changed from within a BASIC program by issuing the code: 10 POKE 214,255 or by poking location 214 with anything greater than 127. From ASSEMBLY language, the code would most likely look like this: 800- A9 FF LDA #$FF 802- 85 D6 STA $D6 or by loading a register with $80 or greater and storing it at $D6. Now if 3D0G, 9D84G or 9DBFG did not produce a BASIC prompt, then the DOS being used is more elaborate. So re-load the program and reset into the monitor after it is running. Now comes the final steps in trying to examine a BASIC program. If you are using a ROM card in slot zero with an old style F8 monitor ROM to reset into the monitor, turn on the mother board ROMs and turn off the ROM card INTEGER ROMs by typing: *C081 Now reset the RUN flag to normal, just to be sure. Type: *D6:00 Finally, enter APPLESOFT the sure fire way by typing: * You should see an APPLESOFT prompt. Now type: ]LIST and your APPLESOFT program should now appear. Applying this to a real world example, try this method with one of Strategic Simulations releases (SSI). SSI uses a highly modified DOS called RDOS for their protection. SSI uses all the tricks mentioned to prevent you from LISTing their programs. But using the above procedure, you can LIST their BASIC programs. In addition, the DOS used by SSI (RDOS) uses the ampersand in all of its DOS commands. So if you see any ampersands from within their BASIC program, you know it is a DOS command. For example, to catalog a SSI disk, after you follow the above procedure and you are in BASIC, type: ]&CAT This will display SSI's catalog. Very different, eh! Well, back at the ranch, if you want to save your APPLESOFT program to a normal DOS disk, do these steps: 1) Reset into the monitor after the program is running. 2) If you are using a ROM card in slot zero, Type: *C081 3) Now type: *D6:00 *9500<800.8FFM 3) Check where the APPLESOFT program ends by typing: *AF.B0 4) Write down the two bytes listed somewhere. 5) Boot a 48K normal DOS 3.3 slave disk with no HELLO program. 6) Enter the monitor by typing: ]CALL-151 7) Restore the APPLESOFT program by typing: *800<9500.95FFM *AF: enter the two bytes you wrote down here, separated by spaces. 8) Enter BASIC and save the program by typing: *3D0G ]SAVE PROGNAME What you have done is to move $800 to $8FF out of the way so you can boot a slave disk. After normal DOS is up, you restore $800 to $8FF from $9500 to $95FF, and then restore the end of APPLESOFT program pointers so DOS knows how big your BASIC program is. Next you just save it to your disk! Of course there are other more automated ways of getting programs to a normal DOS 3.3 disk (such as Demuffin Plus or CopyB), but this is a quick and dirty method that will always work. Keep in mind that the program may not run from normal DOS because of more secondary protection from within the BASIC program itself. Any curious CALLs, POKEs or PEEKs to memory above 40192 (this is memory where DOS resides) or below 256 (zero page memory) should be examined closely. I hope this will help you learn more about the protected programs you own that are written in APPLESOFT. ______________________________ APPENDIX A-KRAKING MODIFIED DOS'S WITH COPYB INTRODUCTION: There are probably hundreds of ways to protect a program from being copied. But generally speaking, protection falls under two categories: protect the actual program (by various means), or protect a disk full of programs with some sort of DOS modification. DOS modifications are the most common since they are the easiest to deal with (from the publisher's point of view). DOS modifications are also the least successful of protection, since someone always seems to find a way to copy all the files onto a normal DOS disk, eluding all the protection. The classic program for dealing with modified DOS's is DEMUFFIN PLUS. It works much the same way as Apple's MUFFIN program works. MUFFIN was written to read files from a DOS 3.2 disk and then write them to a DOS 3.3 disk. DEMUFFIN was a variation of MUFFIN, allowing the hardcore 3.2 user to copy files from DOS 3.3 to DOS 3.2. DEMUFFIN PLUS operates on the same principle, but uses whatever DOS is in memory to read the disk, and then writes out to an initialized DOS 3.3 disk. While this is a powerful utility, it only works with programs that are based on DOS file structures and that have a catalog track. INTRODUCING COPYB: COPYB (originally written by "Krakowicz") is a highly modified version of COPYA which converts a protected disk that uses a modified DOS and/or RWTS to normal DOS 3.3 format. The protected disk may have a normal DOS file structure, or it may not. Since COPYB copies on a track by track basis, this does not matter. This makes COPYB a far more flexible tool than DEMUFFIN PLUS. COPYB uses the protected disk's RWTS to read in the tracks and then uses normal DOS 3.3 to write them back out to an initialized disk. Unless otherwise instructed, COPYB copies track $03 to track $22, sector $0F to sector $00 of each track. Here are the parameters for COPYB: LOCATION NORMALLY HEX DEC DESCRIPTION HEX DEC NT --------------------------------------- 22E 558 FIRST TRACK TO READ 03 03 (1) 236 556 FIRST SECTOR TO READ 0F 15 (2) 365 869 RESET SECTOR NUMBER 0F 15 (2) 3A1 929 STOP ON ERROR($18=NO) 38 56 (3) 302 770 TRK TO STOP READING+1 23 35 (4) 35F 863 TRK TO STOP READING+1 23 35 (4) NOTES (denoted above as "NT"): 1) This is the first track that COPYB starts reading at. This is normally set at track 3, so not to copy the protected DOS which normally resides on track 0 through track 2. 2) These two parameters are normally set to $0F for 16 sector disks. Change these two parameters to $0C for 13 sector disks. Most of today's protection schemes are based on 16 sectors. Yet there are still a few using 13 sectors (such as Muse). Interestingly enough, there is a handful of authors that also us sectoring other than 13 or 16 sectors per track. An example of this is "Thief" from Datamost. This program uses 11 sectors per track. COPYB can also accommodate these programs. 3) This parameter is normally set so that upon reading a 'bad sector' COPYB will stop and display an error. To let COPYB keep going after a read error, change this byte to $18 (24 in decimal). The equivalent sector on the copied disk will be written blank. 4) These two parameter determine where COPYB will stop reading the protected disk. Normally, this is set to the last track, $22 (34 in decimal) , plus one. To change this, add one to the last track you want to copy and change these two parameters. USING COPYB: To use COPYB, you must capture the foreign RWTS and put it at locations $8000 through $88FF. You can do this one of two ways: 1) Boot the protected disk and after the foreign DOS is loaded, reset into the monitor. The foreign DOS will usually be loaded a few seconds after the boot starts. You can tell this because many times a BASIC prompt will appear at the bottom of the text screen. Use the monitor move command to move RWTS down to $8000 as so: *8000! ! -! ! ! ! . . . . . . . . . . . . ! !/ / / / / / / / / / / / ! !12 11 10 9 8 7 6 5 4 3 2 1 ! --------------------------------------- Now your soldering skills come in handy! Using some short, hi-gauge wire (wire-wrap is preferable, but anything in the 26-30 gauge will work), solder a piece between pins 21 and 24, and solder a piece between pins 12 and 18. Be extremely careful not to short out the wire or to cross solder any pins! Also, try and solder as close to the base of the socket as possible, since you have to cut off pins 18 and 21 after you have finished soldering them. Now cut of pins 18 and 21 as close to the base of the socket without cutting the freshly soldered wires! Remember, pins 18 and 21 should be short enough so that they will not touch the socket you will be plugging this one into. The socket should now look like this: --------------------------------------- ! 13 14 15 16 17 18 19 20 21 22 23 24! ! ./ ./ ./ ./ ./ ./ ./ ./ ./ ./ ./ ./ ! ! x x / ! ! / / / ! ! / /--------/ - ! /--------/ ! ! / -! ! / ! ! / . . . . . . . . . . . ! !/ / / / / / / / / / / / ! !12 11 10 9 8 7 6 5 4 3 2 1 ! --------------------------------------- Double check your soldering and the connections (and notice that pin 18 and 21 are cut off!). Now carefully remove the ROM labelled F8 (it is the socket farthest on the left that has 24 pins as you face the keyboard) and plug this jumper socket into the motherboard. Now plug your modified 2716 EPROM into this jumper socket and your all done! Make sure you have the notch pointing in the same direction as the other ROMs (towards the keyboard). When you turn on the Apple you should see a screen full of garbage with the monitor prompt at the bottom of the screen. To boot your Apple, just type "6 ctrlP", and your computer will act just as usual. ------- APPENDIX C-MAKING YOUR OWN NMI BOARD In this article I will describe how to make your own NMI board that will work in conjunction with the modified F8 monitor EPROM you have (or will) create. Here is the parts lists for the NMI board: (1) 7400 or 74LS00 chip. Radio Shack part #276-1801. $0.59 (1) SPDT momentary push switch. Radio Shack part #275-1549. $2.19 (1) 14 pin low profile or wire wrap socket. Radio Shack part #276-1999 or #276-1993. $0.89 (2) 3.3k ohm resisters, 1/4 watt. Radio Shack part #271-1328. $0.39 (1) Dual plug-in interface board. Radio Shack part #276-164. $4.95 NOTE: This part has been discontinued by Radio Shack, but you can sometimes still find them in the junk bin. Cut the board so it will fit inside your Apple. ALTERNATIVELY: (1) Apple bare board number PAPGBP5001. $13.95 from Priority Electronics, 9161 Deering Ave., Chatsworth, CA 91311. After you have obtained all the parts above, you should solder the 14 pin socket and the two resistors somewhere convenient on the bare board. Next get some hi-gauge wire and make the following connections: 1) Connect pin 25 of the bare board to one leg of each of the two resistors. 2) Connect each of the other legs of the resistors to the two outside contacts of the switch. (one resistor goes to one contact, the other resistor goes to the other contact). Use some good wire. 3) Connect pin 25 of the bare board to pin 14 of the 14 pin socket. 4) Connect the middle contact of the switch to pin 7 of the 14 pin socket. 5) Connect pin 26 of the bare board to pin 7 of the 14 pin socket. 6) Connect pin 2 of the 14 pin socket to pin 6 of the 14 pin socket. 7) Connect pin 3 of the 14 pin socket to pin 4 of the 14 pin socket. 8) Connect pin 4 of the 14 pin socket to pin 29 of the bare board. 9) Connect the leg of one of the resistors that is connected to the switch to pin 5 of the 14 pin socket. 10) Connect the other leg of the resistor that is connected to the switch to pin 1 of the 14 pin socket. 11) Check all connections twice, and don't get confused on what pin is what on the bare board and the 14 pin socket. You have now completed building your own NMI board. This board may be plugged into any one of the peripheral slots. ------- APPENDIX D-PRACTICAL USES FOR THE NMI/MODIFIED ROM HARDWARE Now that you have burned your own F8 monitor ROM, constructed your own NMI board and created a 16K slave disk with the previously mentioned files, its time to put it all together and use it (also make sure you have a RAM card in slot 0). The primary use for these hardware devices is for the single load program. As a practical example, we will be putting the Locksmith 5.0 fastcopy program into a file. This program is a really fast normal DOS copy program that is worth having in a file. First turn off your computer and install your new F8 monitor EPROM into the motherboard, and put your NMI board in any slot. Now boot your Locksmith 5.0 (an original or a copy will do) and select the "16 sctr utilities" option. Next select the "16 sector fast disk backup". Now just after the drive stops spinning, and before you see the prompt "drive- original:1", hit the NMI switch on your NMI card. You should then be in the monitor. Now boot your 16K slave disk. The "RAM 48K SAVER" program will run and will initialize a disk and save all 48K of memory to your disk. Finally, run the "MEMORY MOVE WRITER" program and select the number of moves as one. Next select the running address as $8000. Use a forward memory move, and enter the start page as $40, and the hi page as $80. Next select the starting page to move to as $00. Finally, select the text page, page one, and full text. Now enter $8024 as the address to jump to and save the memory move program to disk. Now its time to put all these files together as the final product. Boot a normal 48K disk and Bload the following files by typing: ]BLOAD ^00-3FFF,A$4000 ]BLOAD MEMORY MOVE $8000,A$8000 ]BLOAD RERUN,A$8024 Now make the file run when you brun it by typing: ]CALL -151 *3FFD:4C 00 80 Now we can save the final product by typing: *BSAVE LS 5.0 FASTCOPY,A$3FFD,L$4040 Congratulations! You now have deprotected the Locksmith fast copy program into a file that you may brun anytime! This technique will work well for deprotection other single load programs too! The main advantage to this technique is that you don't have to find the starting address of the program to restart it. The program will just start up from the point where you interrupted it. The only other thing you really must do is determine what parts of memory you must save so the program will run. REMEMBER, YOU MUST ALWAYS SAVE MEMORY FROM $00 TO $2FF FOR THIS PROCESS TO WORK CORRECTLY! Use the Memory Move Writer to rearrange memory so you can save it in a normal DOS binary file. If you want further practice in using your NMI/F8 EPROM hardware, write a program in APPLESOFT that some some screen displaying and interrupt the program. Then try and reconstruct it using the same technique as described above and restart the program. You can save the BASIC program in a Bfile by saving $00 to $7FF and from $800 to the end of the program, where ever that might be (zero page locations $AF and $B0 will give you the ending location of a APPLESOFT program, in backassward order). You might also have to save some of the variable storage for your BASIC program, which lives from $95FF down (depending on size). The best thing to do is to experiment, and practice makes perfect. ------- APPENDIX E- THE ROM CARD INTRODUCING THE ROM CARD: The foremost of important tools for easily snooping through memory is the ROM card. The ROM card was originally developed for those with programs written in both INTEGER and APPLESOFT BASIC. Remember that your motherboard (the big green printed circuit board inside your computer case) can house only one of the BASIC languages, either INTEGER or APPLESOFT. When the Apple was originally released, it was only available with INTEGER BASIC. So many programs were written in INTEGER, and would not run on the Apple II+ (with APPLESOFT on board) when it was introduced. Before RAM memory was very cheap, many people bought ROM cards for their Apple II+ that could be put in slot zero (as you would a RAM card), to enable them to run programs that were written in either BASIC language. It was just as though you had loaded INTEGER BASIC into you RAM card, like the DOS 3.3 System Master's HELLO program does. When RAM cards became available at a reasonable cost, everyone started buying them because they are so much more versatile for the average folk. That is why you don't see ROM cards for sale too much any more. But for deprotecting Apple programs, the ROM card is indespensible. Also, for the Apple II owner who wanted to run the newer APPLESOFT programs, the ROM card was available with APPLESOFT ROMs. The INTEGER and the APPLESOFT versions of the ROM card are identical, except for the actual ROMS on the card. In other words, one had INTEGER ROMs and the other had APPLESOFT ROMs, and there is no other differences. THE REASONS WHY: Their are several reasons the ROM card is so important. The least of the reasons is the need for INTEGER BASIC or the Programmer's Aid chip. If you can get a ROM card cheaply without INTEGER or the Programmer's Aid ROMs, do so. From a cost outlook, it is to your advantage. Besides, INTEGER is a dead dinosaur, and who really cares if it's faster than APPLESOFT? The reason we want a ROM card is so we can put an old style F8 monitor ROM and THE INSPECTOR ROM (from Omega Microware) on it. These two ROM chips are really essential for learning more about protected programs. Ultimately, we would like WATSON in conjunction with THE INSPECTOR, but to do so you will also need INTEGER BASIC ROMs, since WATSON uses some routines from the INTEGER BASIC ROMs. Watson enhances the Inspector by adding even more commands and flexibility. The combination of Watson and the Inspector provides you with great power for not only snooping, but also for general purpose utility chores. The reason we want the old style F8 ROM should be obvious by now. After reading several kraking articles and from your own experiences, you have noticed that it is impossible to break out of many programs with just an autostart F8 monitor ROM. The reason we should have the old style F8 ROM on the ROM card and not on the mother board is for convenience. The ROM card has a switch which determines which F8 monitor ROM is active when you hit reset. So you can have the convenience of the Autostart F8 monitor ROM, and when you need it, hit the switch and be able to break out of any program you want with the old style F8 monitor ROM. OBTAINING YOUR OWN ROM CARD: ROM cards are available used at very cheap prices. Check your local Apple users' group. Alternatively, you can get blank cards and stuff it yourself. I would suggest stuff your own since the parts are easy to get, and it is usually the least expensive route! I have also seen Japanese clone cards for sale at a very reasonable price. The best place to check for these is in The Computer Shopper, a bi-monthly newspaper of Apple and other computer bargains. OBTAINING YOUR OWN ROMs: You can either buy an old style F8 monitor ROM, or you can make one by changing your autostart F8 code slightly. After making the change, you can save the file to disk and have a friend or your local computer store burn the image into a 2716 EPROM. Here is the instructions for creating your own: 1) Boot a normal DOS 3.3 disk. 2) Enter the monitor by typing: ]CALL-151 3) Move the autostart F8 ROM image into RAM by typing: *4800