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.