Game Killer/Game_Killer.bin/1003.INT13.DOC

Text File | 1986-08-10 | 9KB | 187 lines

P                               INT13 DOCUMENTATION

P     The file INT13.ARC contains the following:

P                       INT13.ASM - Source file for INT13.COM
P                       INT13.COM - Resident interrupt 13h handler
P                       INT13.DOC - This documentation file


P         I. Function of INT13.COM

P         INT13.COM is a resident "front-end" program which intercepts ROM
P     BIOS interrupt 13h calls to perform disk functions on specific sectors.
P     INT13.COM prints out the requested disk drive, side, track, sector,
P     number of sectors, and operation type contained in the registers.  After
P     the interrupt processing is completed, INT13.COM prints the status code
P     returned (which indicates whether an error has occured), and the address
P     in the calling program to which control will be returned.


P         II. Purpose of INT13.COM

P         INT13.COM was written as a tool to help unravel copy protection
P     schemes, virtually all of which use interrupt 13h to look for weirdly-
P     formatted tracks on the original "key" diskette.  This utility allows
P     you to find out - without searching through a disassembly of the program
P     - what the copy protection scheme is looking for on the key diskette.
P     The return address printed shows where (or, more accurately, the point
P     immediately after) the call to interrupt 13h was made.  This can be
P     especially useful where the copy protection scheme trys - as many do -
P     to disguise the interrupt call so as to thwart casual attempts to defeat
P     the protection.

P         I will not attempt to provide information on the various codes
P     associated with interrupt 13h processing since this information is
P     available in any book on IBM Assembly Language or in the IBM Technical
P     Reference manuals.  In general, however, a few things to look for in a
P     protection scheme are:

P            a.  Sector numbers greater than 9.

P            b.  Sectors deliberately formatted with CRC errors.  The pro-
P                tection scheme either "reads" (operation code 02) or "veri-
P                fies" (operation code 04) the sectors.  The program then
P                expects to get a return code of 10, indicating the sectors do
P                indeed contain CRC errors.

P            c.  Multiple calls for the same sector.  Some schemes format a
P                track with two sectors with the same number.


P         III. Using INT13.COM

P         Before executing the program to be examined, simply run INT13.  A
P     short message will be displayed indicating that the program has been
P     installed.  Be sure to reboot your computer after finishing your work
P     with INT13.  Also take care not to install INT13 more than once (between
P     reboots).  I haven't written in any safeguards against multiple in-
P     stalls, although a future version may have this feature.



P         If you are not using DEBUG, then simply execute your program.  A log
P     of the disk activity will then be printed.  Program loading and execu-
P     tion will be slowed due to the time required for printing.

P         If you are using DEBUG, then proceed as you would normally.  The
P     addresses reported on the disk activity log will correspond to the
P     locations in the program being debugged so you may immediately see where
P     the calls are being made.

P         It is advisable to run INT13 with your program more than one time
P     since some protection schemes select different tracks for checking on a
P     random basis.

P         Note: Since copy protection schemes rarely, if ever, check other
P     than the "A" diskette drive, INT13 is set up to log only calls to that
P     drive.  If you wish disk activity on all drives to be logged, remove the
P     instructions listed in the source code and reassemble the program.


P         IV.  Interpreting the results

P         This is the hardest part.  If you are going to become an accom-
P     plished "unprotector" you will have to have at least a passing knowledge
P     of assembly language.  INT13 will point you to the part(s) of the pro-
P     gram doing the protection verification and will show you what the pro-
P     gram expects to find.  It's up to you to figure out how to bypass the
P     protection.  This can be quite easy, sometimes only requiring a branch
P     around the code doing the protection verification, or it can involve
P     hours of single-stepping through the program for really devious
P     protection schemes.  Either way, INT13 should speed up things.


P         V.  Caveats

P         Since INT13 functions under DOS's control, this utility will not
P     always function with some game programs which have their own operating
P     system on the disk.

P         INT13 also doesn't work with PROLOK-protected diskettes.  Apparently
P     PROLOK assigns interrupt 13h to some other interrupt number (at least
P     this is my guess).


P         VI.  How INT13 works

P         When you run INT13, the vector in low memory which normally points
P     to the ROM BIOS routine for interrupt 13h is changed to point to the
P     front-end processing contained in INT13.  When your program issues an
P     interrupt 13h call, control goes first to INT13 and the required
P     information is stored for later printout.  Control is then passed to the
P     normal interrupt 13h routine.  When the I/O processing is finished,
P     INT13 regains control and prints the log data, including the return code
P     passed back.  Finally, control returns to the calling program.  If you
P     are interested in further details, examine the source code.








P         VII.  How some protection schemes attempt to disguise interrupt 13h
P               calls

P         If you are attempting to unprotect a program, the usual course of
P     action is to search for occurences of "CD13", which is machine language
P     for interrupt 13h.  One way or another, the protection scheme will have
P     to use this interrupt to check for the special sectors on the disk.  If
P     you examine a cross section of programs, however, you will find programs
P     which do not have "CD13" in their machine code, but which clearly are
P     checking the key diskette for weird sectors.  How is this being done?

P         There are several techniques which can be used to camouflage the
P     protection scheme from prying eyes.  I'll describe below two such
P     techniques I have come across:

P         a.  The following section of code is equivalent to issuing a INT 13
P             command to read one sector from: drive A, side 0, track 28h,
P             sector ffh, and then checking for a status code of 10h:

P             XXXX:1000 MOV AH,02                  ;read operation
P             XXXX:1002 MOV AL,01                  ;1 sector to read
P             XXXX:1004 MOV CH,28                  ;track 28h (40d)
P             XXXX:1006 MOV CL,FF                  ;sector ffh (255d)
P             XXXX:1008 MOV DX,0000                ;side 0, drive A
P             XXXX:100B XOR BX,BX                  ;move 0
P             XXXX:100D MOV DS,BX                  ;       to DS register
P             XXXX:100F PUSHF                      ;push the flags onto stack
P             XXXX:1010 PUSH CS                    ;push the CS register
P             XXXX:1011 CALL 1100                  ;push addr. of next instr.
P                                                  ; onto stack and branch
P             XXXX:1014 CMP AH,10                  ;check for CRC error
P             XXXX:1017 rest of verification code
P                  .
P                  .
P                  .
P             XXXX:1100 PUSHF                      ;push the flags onto stack
P             XXXX:1101 MOV BX,004C                ;addr. of int 13h vector
P             XXXX:1104 PUSH [BX+02]               ;push CS of int13h routine
P             XXXX:1107 PUSH [BX]                  ;push IP of int13h routine
P             XXXX:1109 IRET                       ;pop IP,CS and flags

P             Notice that there is no "INT 13" command in the source code, so
P             if you had simply used DEBUG to search for "CD13" in the machine
P             code, you would never have found the protection routine.


P         b.  Another technique is to put in a substitute interrupt instruc-
P             tion (such as INT 10, which looks harmless enough), and have the
P             program change the "10" to "13".  A search for "CD13" would turn
P             up nothing.