kernal routine FFC3 has been accessed by a JUMP and not a JSR,
         it forces an RTS in the code flow.  This RTS returns the
         protection check to the main program.
         
      4) Defeating this protection scheme is simple. We can place a RTS
         at the beginning of the routine. This will short circuit the
         protection check completely by sending the program flow back to
         the code that called for it originally. Before changing code,
         let's find out which file contains the protection check. Looking
         over the disk log, we find that the file P99 is the only likely
         candidate. The starting address is $6000 and the ending address
         is $6FF4. Remove your utility disk from the drive and again
         insert the backup in it's place. Double check the file by
         loading P99 directly from the backup <> L "P99",08 <>. Again
         disassemble code around $6F7A (D 6F7A) and make sure this file
         is the correct one that has the protection check. When
         satisfied, use the MEMORY command to change the byte at the
         address $6F7A (M 6F7A) to a 60. Now scratch and save this file
         to your backup. Remember to add one byte to the ending address.
         <> S "@0:P99",08,6000,6FF5 <>.
      
      Your backup is now completely broken. It can be fast copied and,
      because we have forced the program to not use the protection 
      check, it can even be file copied. Remember, the Block Execute
      (which now is not used) accesses a specific spot on the disk, and
      is not picked up by directory files. Finally, note the name placed
      on the diskette directory. You'll find it on many programs. Now you
      know the secret of XEMAG 2.0 protection.


      Four examples using this scheme have been discussed above. We
      must assume that you have mastered the techniques used to defeat
      those titles. Many titles have been released using Fat Tracks. 
      Some were relatively simple to break and others were quite
      difficult. Some protection programmers have been checking not only
      for the Fat Track but also to see if either their computer OR drive
      code had been tampered with. This was done by checksumming. If any
      sign of tampering was evident, the program refused to run - even if
      the break code was technically sound. If you have applied the
      methods in Kracker Jax Vol I to a similar protection, and it
      refused to work, you can assume they caught you in their code. We
      are going to give you examples of how to defeat the drive code,
      computer code, and the checksumming. Be advised, these examples
      show tricks and techniques that can be used again on other schemes.
      Breaking protection involves thought and ingenuity.

            K.J. REVEALED TRILOGY    PAGE [31]     (C)1990 K.J.P.B.

<<previous page - next page>>