Chapter I How to Crack
-------------------------------------------------------------
Let's start with a simple introduction to patching a program
using the DOS DEBUG program. The following article will in-
troduce you to the basic ideas and concepts of looking for a
certain area of a program and making a patch to it.
-------------------------------------------------------------
By: Charles Petzold / Specular Vision
Title: Case Study: A Colorful CLS
This article originally appeared in the Oct. 14,1986 Issue
of PC Magazine (Vol 15. Num 17.). Written by Charles Petzold.
The hardest part of patching existing programs is determin-
ing where the patch should go. You really have to make an
intelligent guess about the functioning of the program.
As an example, let's attempt to modify COMMAND.COM so that
is colors the screen on a CLS command. As with any type of
patch try it out on a copy and NOT the original.
First, think about what we should look for. CLS is differ-
ent from all the other DOS internal Commands, It is the only
internal command that does something to the screen other than
just write to it with simple teletype output. CLS blanks the
screen and homes the cursor. Since it can't do this through
DOS Calls (unless ANSI.SYS is loaded), it is probably calling
the BIOS Directly. The BIOS Interrupt 10h call controls the
video, and so the CLS command probably uses several INT 10h
instructions. The machine code for INT 10h is CD 10.
(While this same method will work under any version of
PC-DOS, Version 2.0 and later, the addresses I'll be using
are from PC-DOS 3.1. Other versions of PC-DOS(or MS-DOS) will
have different addresses; you should be absolutely certain
that you're using the correct addresses.)
Load COMMAND.COM into DEBUG:
DEBUG COMMAND.COM
and do an R (Registers) command. The size of COMMAND.COM is
in register CX. For DOS 3.1's COMMAND.COM, this value is
5AAA.
Now do Search command to look for the CD 10 bytes:
S 100 L 5AAA CD 10
You'll get a list of six addresses, all clustered close to-
4
gether. The first one is 261D. You can now pick an address a
little before that (to see what the first call is doing) and
start disassembling:
U 261B
The first INT 10 has AH set to 0F which is a Current Video
State call. The code checks if the returned value of AL
(Which is the video mode) is less than 3 or equal to 7.
These are the text modes. If so, it branches to 262C. If
not, it just resets the video mode with another INT 10 at ad-
dress 2629.
At 262C, the code first sets the border black (the INT 10
at 2630), then does another Current Video State call (at
2634) to get the screen width in register AH. It uses infor-
mation from this call to set DX equal to the bottom right row
and column. It then clears the screen by scrolling the en-
tire screen up with another INT 10 (at 2645), and then sets
the cursor to the zeroth row and zeroth column with the final
INT 10 (at 264D).
When it scrolls the whole screen, the zero value in AL ac-
tually means blank the screen, the value of BH is the at-
tribute to be used on the blanked area. In an unmodified
COMMAND.COM, BH is set to 7 (Which is white on black) by the
following statement at address 2640:
MOV BX,0700
If you prefer a yellow-on-blue attribute (1E), you can
change this line by going into Assemble mode by entering:
A
then entering
MOV BX,1E00
and exiting Assemble mode by entering a blank line.
Now you can save the modified file:
W
and quit DEBUG:
Q
When you load the new version of COMMAND.COM (and you can
do so without rebooting by just entering:
COMMAND
5
on the DOS command level), a CLS will turn the screen blue
and display characters as yellow.
If it doesn't or if anything you type shows up as white on
black, that probably means you have ANSI.SYS loaded. If you
use ANSI.SYS, you don't have to make this patch but can in-
stead use the prompt command for coloring the screen.
END.
6
-------------------------------------------------------------
That was just one section of a very large article that helped
me to get started. Next we'll look at two other articles,
both written by Buckaroo Banzi. These two articles CRACK-1
and CRACK-2 give you an introduction to the different copy
protection schemes used on IBM PC's, and how to find and by-
pass them.
-------------------------------------------------------------
By: Buckaroo Banzai
Title: Cracking On the IBM PC Part I
Introduction
------------
For years, I have seen cracking tutorials for the APPLE
computers, but never have I seen one for the PC. I have de-
cided to try to write this series to help that pirate move up
a level to a crackest.
In this part, I will cover what happens with INT 13 and how
most copy protection schemes will use it. I strongly suggest
a knowledge of Assembler (M/L) and how to use DEBUG. These
will be an important figure in cracking anything.
INT-13 - An overview
--------------------
Many copy protection schemes use the disk interrupt
(INT-13). INT-13 is often use to either try to read in a il-
legally formatted track/sector or to write/format a
track/sector that has been damaged in some way.
INT-13 is called like any normal interrupt with the assem-
bler command INT 13 (CD 13). [AH] is used to select which
command to be used, with most of the other registers used for
data.
INT-13 Cracking College
-----------------------
Although, INT-13 is used in almost all protection schemes,
the easiest to crack is the DOS file. Now the protected pro-
gram might use INT-13 to load some other data from a normal
track/sector on a disk, so it is important to determine which
tracks/sectors are important to the protection scheme. I
have found the best way to do this is to use LOCKSMITH/pc
(what, you don't have LS. Contact your local pirate for it.)
Use LS to analyze the diskette. Write down any track/sector
that seems abnormal. These track are must likely are part of
the protection routine. Now, we must enter debug. Load in
7
the file execute a search for CD 13. Record any address
show.
If no address are picked up, this mean 1 or 2 things, the
program is not copy protected (right...) or that the check is
in an other part of the program not yet loaded. The latter
being a real hassle to find, so I'll cover it in part II.
There is another choice. The CD 13 might be hidden in self
changing code. Here is what a sector of hidden code might
look like
-U CS:0000
1B00:0000 31DB XOR BX,BX
1B00:0002 8EDB MOV DS,BX
1B00:0004 BB0D00 MOV BX,000D
1B00:0007 8A07 MOV AL,[BX]
1B00:0009 3412 XOR AL,12
1B00:000B 8807 MOV [BX],AL
1B00:000D DF13 FIST WORD...
In this section of code, [AL] is set to DF at location
1B00:0007. When you XOR DF and 12, you would get a CD(hex)
for the INT opcode which is placed right next to a 13 ie,
giving you CD13 or INT-13. This type of code can't and will
not be found using debug's [S]earch command.
Finding Hidden INT-13s
----------------------
The way I find best to find hidden INT-13s, is to use a
program called PC-WATCH (TRAP13 works well also). This pro-
gram traps the interrupts and will print where they were
called from. Once running this, you can just disassemble
around the address until you find code that look like it is
setting up the disk interrupt.
An other way to decode the INT-13 is to use debug's [G]o
command. Just set a breakpoint at the address give by
PC-WATCH (both programs give the return address). Ie, -G
CS:000F (see code above). When debug stops, you will have
encoded not only the INT-13 but anything else leading up to
it.
What to do once you find INT-13
-------------------------------
Once you find the INT-13, the hard part for the most part
is over. All that is left to do is to fool the computer in
to thinking the protection has been found. To find out what
the computer is looking for, examine the code right after the
INT-13. Look for any branches having to do with the
8
CARRYFLAG or any CMP to the AH register. If a JNE or JC
(etc) occurs, then [U]nassembe the address listed with the
jump. If it is a CMP then just read on.
Here you must decide if the program was looking for a pro-
tected track or just a normal track. If it has a CMP AH,0
and it has read in a protected track, it can be assumed that
it was looking to see if the program had successfully com-
plete the READ/FORMAT of that track and that the disk had
been copied thus JMPing back to DOS (usually). If this is
the case, Just NOP the bytes for the CMP and the correspond-
ing JMP.
If the program just checked for the carry flag to be set,
and it isn't, then the program usually assumes that the disk
has been copied. Examine the following code
INT 13 <-- Read in the Sector
JC 1B00 <-- Protection found
INT 19 <-- Reboot
1B00 (rest of program)
The program carries out the INT and find an error (the il-
legally formatted sector) so the carry flag is set. The com-
puter, at the next instruction, see that the carry flag is
set and know that the protection has not been breached. In
this case, to fool the computer, just change the "JC 1B00" to
a "JMP 1B00" thus defeating the protection scheme.
NOTE: the PROTECTION ROUTINE might be found in more than just
1 part of the program
Handling EXE files
------------------
As we all know, Debug can read .EXE files but cannot write
them. To get around this, load and go about cracking the
program as usual. When the protection scheme has been found
and tested, record (use the debug [D]ump command) to save + &
- 10 bytes of the code around the INT 13. Exit back to dos
and rename the file to a .ZAP (any extension but .EXE will
do) and reloading with debug. Search the program for the 20+
bytes surrounding the code and record the address found.
Then just load this section and edit it like normal. Save
the file and exit back to dos. Rename it back to the .EXE
file and it should be cracked.
***NOTE: Sometimes you have to play around with it for a
while to make it work.
9
DISK I/O (INT-13)
-----------------
This interrupt uses the AH resister to select the function
to be used. Here is a chart describing the interrupt.
AH=0 Reset Disk
AH=1 Read the Status of the Disk
system in to AL
AL Error
----------------------------
00 - Successful
01 - Bad command given to INT
*02 - Address mark not found
03 - write attempted on write protected disk
*04 - request sector not found
08 - DMA overrun
09 - attempt to cross DMA boundary
*10 - bad CRC on disk read
20 - controller has failed
40 - seek operation failed
80 - attachment failed
(* denotes most used in copy protection)
AH=2 Read Sectors
input
DL = Drive number (0-3)
DH = Head number (0or1)
CH = Track number
CL = Sector number
AL = # of sectors to read
ES:BX = load address
output
AH =error number (see above)
[Carry Flag Set]
AL = # of sectors read
AH=3 Write (params. as above)
AH=4 Verify (params. as above -ES:BX)
AH=5 Format (params. as above -CL,AL
ES:BX points to format
Table)
------------------------------------------------------------
For more information on INT-13 refer to appendix A.
------------------------------------------------------------
END.
10
-------------------------------------------------------------
In part II, Buck cover's Calls to INT-13 and INT-13 that are
located in different overlays of the program. This is a
method that is used often.
-------------------------------------------------------------
Cracking Tutorial II.
By: Buckaroo Banzai
Title: Cracking On the IBM PC Part II
Introduction
------------
OK guys, you now passed out of Copy Class 101 (dos files)
and have this great new game with overlays. How do I crack
this one. You scanned the entire .EXE file for the CD 13 and
it's nowhere. Where can it be you ask yourself.
In part II, I'll cover cracking Overlays and the use of
locksmith in cracking. If you haven't read part I, then I
suggest you do so. The 2 files go together.
Looking for Overlays
--------------------
So, you cant find CD 13 in the .EXE file, well, it can mean
4 things.
1: The .EXE (though it is mostly .COM) file is just a
loader for the main file.
2: The .EXE file loads in an overlay.
3: The CD 13 is encrypted &/or hidden in the .EXE file.
4: Your looking at the WRONG file.
I won't discuss case 1 (or at least no here) because so
many UNP files are devoted to PROLOCK a