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.