Dec 232017
 
Trace and trap calls to interrupt 13. Great help in debugging.
File INT13NEW.ZIP from The Programmer’s Corner in
Category Miscellaneous Language Source Code
Trace and trap calls to interrupt 13. Great help in debugging.
File Name File Size Zip Size Zip Type
INT13.ASM 9744 2440 deflated
INT13.COM 605 452 deflated
INT13.DOC 8951 3108 deflated

Download File INT13NEW.ZIP Here

Contents of the INT13.DOC file




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.












 December 23, 2017  Add comments

Leave a Reply