Initial commit

This commit is contained in:
root@procul
2021-04-15 13:31:59 -05:00
commit 278a90f7ce
57951 changed files with 34606208 additions and 0 deletions
+11
View File
@@ -0,0 +1,11 @@
# MHPC
Midnight Hackers Private Club (Unknown)
## FILES
=> gemini://informis.land/textfiles/magazines/MHPC/mhpcnws1.phk [ 20193] Midnights Hackers Private Club #1
=> gemini://informis.land/textfiles/magazines/MHPC/mhpcnws2.phk [ 19997] Midnights Hackers Private Club #2
=> gemini://informis.land/textfiles/magazines/MHPC/mhpcnws5.phk [ 16027] Midnights Hackers Private Club #5
+427
View File
@@ -0,0 +1,427 @@
Midnights Hackers Private Club
Where members or hackers gourps come to exchange ideas, and show
off skills.
**** A Cracking Guide For Beginners ****
An Article By:
The Psychopath
TABLE OF CONTENTS
-------------------
I. Introduction and Overview
II. Cracking Doc Checks
A) General Info
B) A Cracking Tutorial
III. Cracking Disk Checks
IV. Cracking with Overlays
V. Closing Remarks
--------------------------------------------------------------------------------
Introduction:
This article is to provide help and give a basic understanding of cracking
for those that just plain don't understand it. A lot of you have heard about
ways of cracking and have gone of on your own into the unknown to try to crack
your first program. And undoubtedly you failed, unless you had guidance and
help from someone more experienced then yourself. Well, I know how rough it
is to learn how to crack, 'cause I've been there myself. It takes a lot of
time, work, and patience to become proficient at the art. So those wishing to
make a leap up in society to the status of a cracker, please read on.
Some of the most useful tools to a crackist are:
DOS Debug
Quaid Analyzer
Turbo Debugger
Locksmith
Step-13/Trap-13/PC-Watch
Soft Ice
Acquire any and all that you can. You'll want and need them. I'm only
going to discuss DOS Debug (Turbo Debugger is quite similar) and Step-13/Trap-13
The others you'll have to experiment with on your own.
Here's a basic list of Debug commands:
Command Function
------------------------------------------
*A [address] Assemble
C range address Compare
D [range] Dump
E address [list] Edit
F range list Fill
*G [=address [address..]] Go
H value value Hex
I value Input
L [address [drive:record record] Load
M range address Move
N filename [filename] Name
O value byte Output
*P [=address][value] Proceed
*Q Quit
*R [register-name] Register
*S range list Search
*T [=address][value] Trace
*U [range] Unassemble
*W [address [drive:record record] Write
[* Indicates the only ones you need worry about for now. They are the main
commands that you use). Basically, you will enter the letter command and then
return (<cr>). Addresses only need to be specified based on necessity. (for
example, you could just enter G<cr> and it would execute. Specifying an address
would set a break point. (run the program up to that address). For P and T,
just enter the letter name and <cr>. It's quicker.]
Further explanation of the commands is provided in your DOS users manual.
Read it for yourself.
*** Note that not all forms of copy protection, nor their ways of removal are
discussed in this news letter ****
--------------------------------------------------------------------------------
Cracking Doc Checks:
Okay, one of the most common forms of copy protection is the doc check.
This is where you are asked to input information from the documentation that
is included with the software purchased. I will discuss a few methods of
removing this protection scheme, and then will provide you with a sample
crack.
Doc checks are usually at the beginning of the software, with a few
exceptions (some being in the middle or at the end). They range in variety
from simple text questions, to having graphic and mouse interfacing. They, of
course, range in difficulty from Insulting (easy) to Mind Boggling (hard).
It's best to start with the easy ones, because you don't want to get in
over your head, and remember that experience is the best teacher.
Doc checks are executed by CALL statements, and sometimes a series of
CALL statements. When proceeding through a program in DEBUG, you will hit
a CALL statement that will execute the program. Remember what the address was
for it, 'cause you'll have to exit out of the game and go back to where it
took control from you. If the CALL statement runs the doc check then takes
you back to DEBUG, then you're allright, and can start changing it
there. If not, then you will have to trace (T<cr> option) through the CALL
statement down to the next layer of program. Now you will proceed again, until
you get to a call statement that executes the copy protection then returns
you to DEBUG.
There are three basic ways to remove the Doc check:
1) Remove the CALL statement.
a) By the NOP command.
b) By jumping from the first byte to the last.
2) By changing the comparisons.
a) By changing the CMPs to compare registers to themselves.
b) By changing the jump statements that follow.
3) By Jumping around the Doc check to get to the part of the program
that loads in the rest of the game.
The first option deals with the above mentioned CALL statements. When you
get to the one you want, you will assemlbe at that address (A Address<cr>) and
enter either NOP (being sure to NOP all the bytes of the call statement--NOP
represents NO Option) or jumping from the address of the first byte to the
address of the second byte. Either will do. Removing the CALL statement will
not always work. Sometimes it will do a wide variety of things to the program.
If this happends, then try one of the other options listed.
The second option involved leaving the doc check entact, but making it so
that any text entered will be accepted by the computer, thus allowing you to
continue with your utility/game. You will usually find a CMP statement (i.e.
CMP AX,[BP-20]) after it calls for the text to be entered. What it's doing
is comparing the value you entered to the value it wants. You can fix this
by either changing the compare statement to compare the register to itself
(i.e. CMP AX,AX), or by changing the jump statements that follow. You might
get a jump statement like JNZ 0345 which will only jump to CS:0345 if the
value is not zero. So just change it to read JMP 0345, which will always
jump to CS:0345.
The third option involves jumping past the doc check (or CALL statement
more appropriately put). Often times you'll execute the copy protection, and
then it will take you to a new part of the program, where it will make it's
comparison, and then decide wether it will run the rest of the program (if you
answered the question correctly) or kick you out to DOS (or re ask the question
depending on the software). If you know what one of the answers is (and you
should if you have the originals), then enter the correct answer and follow
the program through until it executes the rest of the game. (Make note of where
it executes the rest of the game). Then, you exit out of the game, get back
into DEBUG, and then go back before the doc check is called. Now, jump from
the doc check over to where it executes the rest of the game. This will remove
the doc check completely.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Sample Crack-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Software Name: Fiendish Freddy's Big Top of Fun
Software Company: Mindscape
Here is a walk through for cracking a simple text doc check in the above
mentioned game. I will present you with two ways of cracking it.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Method #1:
The most preferred way amoung pirates for having a copy protection removed
is for the crackist to take it out completely. There two most common ways of
doing that are:
1) Remove the call statement that executes the protection.
2) Jump around the protection.
I'm going to teach you method 1 (removing the call statement). Find a
copy of Fiendish Freddy, and type the following:
DEBUG FREDDY.EXE
After typing this, you will be in the program itself, and you will see
the "-" to the left of the screen. To see where you are in the program,
press R<cr>, and you will see something like this:
AX=000 BX=0003 CX=4A40 DX=0000 SP=34BC BP=0000 SI=0000 DI=0000
DS=11EB ES=11EB SS=44B2 CS=11FB IP=3E93 NV UP EI PL NZ NA PO NC
-11FB:3E93 9A00005341 CALL 415E:0000
---------------------------Special Note----------------------------
The value of CS is "11FB". That is the hexadecimal segment address
for the beginning of the program code in your computer's memory. It
is highly possible that the value you see for CS is different from
mine.
-------------------------------------------------------------------
Now then, press P<cr> to proceed through the program until you come to
the call statement located at CS:3EF8. Type U 3EF2<cr> to unassemble around
the call statement. You will see the following:
.
.
11FB:3EF2 55 PUSH BP
11FB:3EF3 89E5 MOV BP,SP
11FB:3EF5 83EC02 SUB SP,+02
11FB:3EF8 9A9C01291A CALL 1A29:019C
11FB:3EFD A2CA02 MOV [02CA],AC
.
.
Okay, write down the HEX values before, including, and after the call
statement. Now in order to change it, you will type A 3EF8<cr> and you'll
see this:
CS:3EF8
Where the cursor is located, you will type NOP (No Option) 5 times, in
order to wipe out the 5 bytes of the call statement, and then press <cr>.
NOP is like erasing data. (i.e. 11FB:3EF8 NOP NOP NOP NOP NOP<cr>). Now press
G<cr> to execute the game. The actual program should load up without executing
the doc check at all. If not, then you screwed up and need to re-check your
alterations to the program.
-----------------------Saving the Changes-----------------------
Remember now, that DEBUG can only write to .COM and files
other then .EXE (with the W<cr> command). One way to save the
changes (the more unreliable way) is to rename the .EXE file to
Something like .HEY or whatever, and then going in and searching
for the data to be changed (with the S command). Now edit the
data as normal, and save with the W<cr> command. Exit out
(Q<cr>) and rename the .HEY file back to .EXE
*** This will not always work ***
Another way to save changes is with a sector editor (The two most
widely used are Norton Utilities and PCTools). Search for the
HEX values (the values I told you to write down) of the data in
front of, including, and after the statement. When you find
The statement, edit it. (In the above case, you'd change the
HEX values of the CALL statement to read 90 90 90 90 90 --90 is
the HEX value for NOP).
------------------------------------------------------------------
Method #2:
Another way to remove copy protection is to leave the doc check entact,
but change it so that it accepts the values that you enter 100% of the time,
regardless of what it is. The ways you can do this are:
1) Change the CMP (compare) of what you entered to what it's supposed
to be, so that it compares what you entered to what you entered
(i.e. CMP AX,[BX-23] would be changed to CMP AX,AX).
2) Change the Jump statements (JNZ, JZ, JB, JA, JG, JL, etc.)
We will use Option #2 this time, and again using Fiendish Freddy. Type
the following to get started:
DEBUG FREDDY.EXE
Now then, proceed back up to where we saw the CALL statement that executes
the protection. (CS:3EF8) And this time, trace through it (T<cr>). Now then,
your CS will change to something else, because you've moved down one level in
the program. Start proceeding through. You'll come upon several CALL
statements that load in the text for the doc check. Ignore them, they cause
no harm. (Just for your info, they exist at CS:022A, CS:0246, CS:025C, CS:0271,
CS:028D, CS:02A3, CS:02B8, CS:02D4). Now then, at CS:02F2 CALL 415E:0C73
appears. What this does call for the user to enter some text from the keyboard.
Proceed through the CALL statement, and the screen will wait for a key to be
pressed. Enter something like "kskdksdk<cr>" and then it will take you back
to the program.
Proceed on until you come to the following:
CS:030E 3B86DFFE CMP AX,[BP+FEDF]
CS:0312 7F25 JG 0339
CS:0314 8946FD MOV [BP-03],AX
Now, what is happening is the program is making a comparison of what was
entered. If that value is greater then what it wants, then it jumps to CS:0339
and if it isn't then it just continues on. Now we want to fool it into
thinking that the text is correct. So change CS:0312 to read JMP 0339. This
way, the program will jump to 0339 every time, no matter what is entered. Now,
we're not through yet. You'll soon come to this:
CS:0349 9A....... CALL 415E:0419
CS:034E 7404 JZ 0354
CS:0350 B000 MOV AL,00
CS:0352 EB02 JMP 0356
Now we have another comparison here. The CALL statement is calling a
compare routine, and when it's finished, if the value is equal to 0, it will
jump to CS:0354, and if not, it will simply continue on. We need to fool the
computer once again, and change CS:034E to read JMP 0354, so that it will
always jump to 0354. This is the last change that needs to be made. Go ahead
and type G<cr> to test it out. When you're done, be sure to make the changes
permanent, as described above.
--------------------------------------------------------------------------------
Disk Checks:
(INT-13)
Some copy protection schemes use the disk interrupt (INT-13). INT-13 is
often used to either try to read in an ilegally formatted track/sector, or to
write/format a track/sector that has been damaged.
INT-13 is called like any normal interrupt with the assembler command
INT 13 (CD 13). The AH register is used to select which command is to be used,
with most of the other registers used for data.
Now, the copy protected file 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 cp scheme. There are two common ways to do this
1) Use Quaid Analyzer to keep track of INT-13 activity
2) Use Locksmith to track down unusual traks/sectors.
With Locksmith you can analyze the diskette. Write down any tracks/sectors
that seem abnormal. These are most likely part of the protection routine. Now
we must enter debug and load in the file to execute a search for CD 13. Record
any addresses shown. (i.e. S CS:100 FFFF CD 13).
If no addresses are picked up, then either the interrupt is encoded, or
it's in a part of the program not yet loaded. Here's what a sector of hidden
code might look like:
CS:0000 31DB XOR BX,BX
CS:0002 8EDB MOV DS,BX
CS:0004 BB0D00 MOV BX,000D
CS:0007 8A07 MOV AL,[BX]
CS:0009 3412 XOR AL,12
CS:000B 8807 MOV [BX],AL
CS:000D DF13 ...........
In this section, AL is set to DF at location CS:0007. When you XOR DF
and 12, you would get a CD (hex) for the INT code, which is placed right next
to a 13, thus giving uou CD13 or INT-13.
---------------------------Finding Hidden INT-13s-------------------------------
A good way to find hidden INT-13s is with Quaid Analyzer, or Step-13 (or
Trap-13, or PC-Watch....all work equally as well). Step-13 traps the interrupts
and will print where they were called from. Once running this, you can jut
disassemble around the address until you find a code that looks like it is
setting up the disk interrupt.
Another way to decode the INT-13 is to use the G (go) command in DOS DEBUG.
Just set a breakpoint at the address given by Step-13. i,e, G CS:000f (see
above code). When debug stops, you will have encoded not only the INT-13 but
anything else leading up to it.
--------------------------------------------------------------------------------
Once you find the INT-13, all that is left to do is to get the computer to
think that the protection has been found. To find out what the computer is
looking for, examine the code right after the INT-13. Look for anything having
to do with the CARRYFLAG or any CMP to the AH register. If a JNE or JC (etc.)
happens, then unassemble (u address<cr>) the address listed with the jump. If it
is a CMP then just read on.
Here you must decide of the program was looking for a protected 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 completed the read/format of that track and that the disk had
been copied thus jumping back to DOS (usually -with INT 19). If this is
the case, just NOP the bytes for the CMP and its corresponding 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. For example:
CS:0002 INT 13 (Reads the sector)
CS:0004 JC 0345 (Jump comparison)
CS:0006 INT 19 (reboot)
CS:0345 Rest of program..
The program carries out the INT and finds an error (the ilegally formatted
sector) so the carry flag is set. The computer, at the next instruction, sees
that the carry flag is set and knows that the protection has not been breached.
But, when you make a copy, it will see the breached protection, and execute the
INT 19. To avoid this, change the JC 0345 to read JMP 0345.
* Note that the protection routine might be found in more then just one
part of the program *
Here is a chart describing INT-13 using the AH register to select
the function to be used.
AH=0 Reset Disk
AH=1 Read the status of the disk system into AL
AL ERROR
-----------------
00 - Successful
01 - Bad Command given to INT
*02 - Address mark not found
03 - Write attempted on a 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 - Attatchement failed
* Represents the most commonly used in the Copy protection
input:
DL = Drive Number (0-3)
DH = Head Number (0 or 1)
CH = Track Number
CL = Sector Number
AL = # of sectors to read
ES:BX = Load address
output:
AH = error number (shown above)
[Carry flag set]
AL = Number of sectors read
AH=3 Writes (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)
--------------------------------------------------------------------------------
Cracking Overlays:
Sometimes the copy protection is executed in an overlay file. The best
way to find out which file it is in, is to use Quaid Analyzer to track the
INT 21 calls and see which program is loaded in. Next, if it was an INT-13
type protection, then you'll do as usual and just look for it in the overlay
file.
If it was a doc check, then you'll proceed through the .EXE file as usual
(with DEBUG or whatever), and go up to the doc check. Now the changes you make
might have to be made in the overlay file. What I mean, is if you search the
.EXE file and don't find the HEX values, then search the overlay file. You'll
have a high probability of finding them there. Then, just change the bytes in
the overlay file as usual and execute the game. It should run, this time with
the crack entact.
--------------------------------------------------------------------------------
Hopefully this will aid you on your quest to become a crackist. And remember,
don't get in over your head by attempting to crack something difficult, 'cause
it will benefit you 0%. Laterz...
- The Psychopath
+450
View File
@@ -0,0 +1,450 @@
Midnights Hackers Private Club
Where members or hackers groups come to exchange ideas, and show
off skills.
**** A Cracking Guide For Advanced Amateurs ****
An Article By:
The Psychopath
TABLE OF CONTENTS
-------------------
I. Introduction and Overview
II. Types of Cracks
A) Documentation Protection
B) Config/Setup Protections
III. Closing Remarks
--------------------------------------------------------------------------------
Introduction:
This is my second edition on cracking tutorials. This one will provide
more information on the art of cracking as well as some more advanced cracking
walkthrus. Take the learning process slow, and just let it come to you. Don't
try tackling too much at once. Again I emphasize the importance of practice and
experience as being the best teacher. And I think I'll mention this now...
ALWAYS, ALWAYS make backup copies of the programs before you tamper with them
with your debuggers and sector editors, because if you screw up and write to
your only copy, you're plain outta luck.
Cracking programs used in this issue:
DOS Debug
Turbo Debugger
Quaid Analyzer
Acquire these if you don't already have them. These are not the only
cracking utilities, but they are the ones that I will be using in my lecture
today.
Here's a basic list of Debug commands in case you've forgotten:
Command Function
------------------------------------------
*A [address] Assemble
C range address Compare
D [range] Dump
E address [list] Edit
F range list Fill
*G [=address [address..]] Go
H value value Hex
I value Input
L [address [drive:record record] Load
M range address Move
N filename [filename] Name
O value byte Output
*P [=address][value] Proceed
*Q Quit
*R [register-name] Register
*S range list Search
*T [=address][value] Trace
*U [range] Unassemble
*W [address [drive:record record] Write
[* Indicates the only ones you need worry about for now. They are the main
commands that you use). Basically, you will enter the letter command and then
return (<cr>). Addresses only need to be specified based on necessity. (for
example, you could just enter G<cr> and it would execute. Specifying an address
would set a break point. (run the program up to that address). For P and T,
just enter the letter name and <cr>. It's quicker.]
Further explanation of the commands is provided in your DOS users manual.
Read it for yourself.
*** Note that not all forms of copy protection, nor their ways of removal are
discussed in this news letter ****
--------------------------------------------------------------------------------
Cracking Documentation Checks Part II:
Okay, the most common form of copy protection is the documentation check.
Doc checks are usually at the beginning of the software, with a few exceptions
(some being in the middle or at the end). They range in variety from simple
text questions, to having graphic and mouse interfacing. They, of course,
range in difficulty from being extremely easy to being near impossible.
In the past issue, I gave an extremely simple copy protection to remove
(Fiendish Freddy, if you remember). Here, after a refresher course on what to
do to remove the doc checks, we'll take a look at a complicated doc check.
There are three basic ways to remove the Doc check:
1) Remove the CALL statement.
a) By the NOP command.
b) By jumping from the first byte to the last.
2) By changing the comparisons.
a) By changing the CMPs to compare registers to themselves.
b) By changing the jump statements that follow.
3) By Jumping around the Doc check to get to the part of the program
that loads in the rest of the game.
In the first option, as you know, we can remove the CALL statement by
writing the assembly command NOP (No Option) in place of the CALL statement
itself. Or we can simply jump from the first byte in the CALL statement to
the last byte in the call statement (This has the same effect).
The second option involved leaving the doc check entact, but making it so
that what you enter (wether it be right or wrong) will be accepted by the
computer, thus allowing you to continue with your game. You will usually find
a CMP statement (i.e. CMP AX,[BP+2307]) after it calls for the text to be
entered. What it's doing is comparing the value you entered (stored in the
registers) to the value it wants. You can fix this by either changing the
compare statement so that the register is compared to itself, (i.e. CMP AX,AX),
or by changing the jump statements that follow. You'll get a jump statement
similar to JNZ 1355, which will only jump to CS:1355 if the value from the
compare is not zero. So just change it to read JMP 1355, which tells the
program to always jump to CS:1355.
The third option involves jumping past the doc check. Often times you'll
execute the copy protection, and then it will take you to a new part of the
program when it's finished, where it will make it's comparison, and then decide
wether it will execute the remainder of the program (if you answered the
question right) or boot you out to DOS (giving a wrong answer). If you know
what one of the answers is (and you should if you have the originals with the
docs included), then enter the correct answer and follow the program through
until it executes the rest of the game. (Make note of where it executes the
remainder of the game). Then, you exit out of the game, get back into your
debugger, and go back before the doc check is called. Now, jump from the doc
check over to where it executes the remaining portion of the game. This will
remove the doc check completely if done properly.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Sample Crack-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Software Name: Martian Dreams
Software Company: Origin
Here is a walk through for cracking a moderately complicated doc check in
the above mentioned game. I will present you with one way of cracking it.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Method : Jumping around the Doc Check (Method #3 as mentioned above).
Find an uncracked copy of Martian Dreams. If you notice, there are 2
executable files. MARTIAN.EXE is the introduction file, and GAME.EXE is the
actual game. (This can be found out by using Quaid Analyzer to watch the INT-21
output while tracing through MARTIAN.EXE) Now, make sure that you have a
character created. You're going to need to get the prybar from the cowboy and
move your character right above the hatch and then save the game and exit to
DOS. Now we're ready to begin.
Load GAME.EXE into your debugger (I'll be using good ol' DOS debug).
Proceed through the program, making note of any loops you get into. (To get
out of a loop such as something that makes a jump comparison and then sends you
to a previous part of the program, just look at what address is after the jump
and then go to that address (with the G <address> <cr> command) i.e.
CS:003C JNZ 0034 is in the early part of the game. We notice that CS:003E lies
just after this call statement, so jump to it--G 3E<cr>).
Now, keep going until you come to the following:
CS:00FC CALL 14C8:0941
(The 14C8 segment may be different on your machine, depending on you memory).
Trace through this call statement (proceeding through it will execute the
game, so don't). Now, start proceeding again. You'll come to the following
address:
CS:0C5E CALL 2015:0013
This will switch graphics modes, so we know we're on the right track. Keep
proceeding. Next you'll start hitting addresses that will call parts of the
picture to the screen. At the following:
CS:0CEA CALL 0509
CS:0F69 CALL 3433:04B1
Each of these calls in a different picture...we're getting close, so keep
going. When you come to the following address:
CS:0FD7 CALL 2409:133A
Trace through it. (Proceeding through will execute the game). Now, keep going.
Again, you'll hit CALL statements that load in graphics pictures, at the
following addresses:
CS:1B51 CALL 0A47
CS:1B64 CALL 0084
CS:1B83 CALL 18B4
CS:1B95 CALL 0221
Keep proceeding until you come to:
CS:1BA5 CALL 3433:28CC
Trace through this (proceeding through will execute the "command entering" part
of the game. It will execute a full command at once, so we need to trace
trough it to break up the command into parts). Tracing trough, and proceeding
on, we come to the following:
CS:2902 CALL 20AD
This allows one key movement/command to be entered at a time. Proceed through
this call statement and type a "U" to get the character to use an item. Now
you're back at the program. If you proceed on, you'll hit the RETF and
eventually come to the following:
CS:1BC5 LOOP 1BBB
This will loop back and take control of the program until your command has
been fully executed, then you'll be back at the debugger again. We don't want
this, because we need to proceed through and see what happends step by step,
before it calls the doc check, so do the following. at the CS:2902 address,
you proceeded though the first time right? and you entered a "U", well jump back
to CS:2902 (i.e. G 2902<cr>) and proceed through again. Keep doing this until
you have entered all the following commands:
U = to get your character to use an item.
TAB, Left arrow key = moves over to your inventory, then select
prybar.
Down arrow key = Points at hatch.
Now, after you do the last input, proceed on through the program. When you
come to the following:
CS:0831 CALL FAR [BP-0E]
Trace through this call statement (proceeding through it will execute the game).
After tracing through, you'll see this:
CS:0066 INT 3F
This is another form of a CALL statment. Trace through it (proceeding through
will execute the game). Now, keep going until you come to the following:
* CS:0A81 JNZ 0A9D
CS:0A83 PUSH AX
CS:0A84 CALL 2D04:4759
CS:0A89 PSUH AX
CS:0A8A MOV AX,3DAF
CS:0A8D PUSH AX
CS:0A8E MOV AX,183C
CS:0A91 PUSH AX
CS:0A92 CALL 3433:33F8
CS:0A97 ADD SP,+06
CS:0A9A JMP 0B51
CS:0A9D MOV AL,[6ED6]
CS:0AA0 MOV AH,00
CS:0AA2 TEST AH,0010
* CS:0AA5 JZ 0AC2
CS:0AA7 MOV AL,[6ED6]
Here's the deal. Those two marked jump statements are the key to the whole
thing. The comparisons made are trying to determine if you have answered the
question already and correctly. What you want to do is get the program to
go to the addresses listed in the statements all the time. So change them
to say:
CS:0A81 JMP 0A9D
CS:0AA5 JMP 0AC2
This will jump past the copy protection completely. Now, to explain how I knew
to do this. What I did is proceed through to the doc check itself, and then
entered a correct answer, followed the program through until it got back to
where you could enter commands again (CS:2902), and then I did those commands
again (if you recall, you have to open the door twice). This time, I followed
through, making note of all the jump statements, seeing where it went, until
it opened the door for me. Next, I went back in with the debugger and got back
up to the doc check and entered a wrong answer, then followed it through, until
it got back to CS:2902, and then I entered the commands again, and followed it
through, making note of the jump statements. After I got past a certain point
(past the address where it opened the door on a correct answer) I compared
the jump statements between the two scenerios, and found the differences, so
I changed the jumps to always think that you've already entered a correct
answer (As shown above). You'll need to know some right answers to do this,
so what I reccommend is either getting a copy of the docs, or get your
encyclopedias handy (some of the questions asked are actual historical facts).
I'll now describe how to get to the doc check, if you want to try this out
for yourself.
Okay, you've traced throught CS:0831 and CS:0066, right? And now you're
proceeding on. You'll eventually come to the following:
CS:0ABA CALL 417E:0034
Trace through this, to get to this:
CS:0034 INT 3F
Trace through this as well. (Remember what I said above about it being a type
of call statement). Now, proceed on. You'll next come to the following:
CS:0396 CALL 0000
Trace through this and then proceed on. You'll next come upon this:
CS:0156 CALL 4183:0034
Tracing through will once again bring you to this:
CS:0034 INT 3F
Trace through again, and then proceed on. You'll next hit a bunch of CALL
statements that will load in graphics pictures and text. Just keep proceeding
on. (Just so you know where you are, some of these CALL statements will be at
these addresses):
CS:1A0F CALL 2015:1E2B
CS:1A67 CALL 1675:024B
Now, you'll come up to the following:
CS:1E9E CALL 1756
This is the doc check. Proceed through, so that it is loaded in. It will ask
the question and then boot you back to the program, so proceed on. You'll next
come to:
CS:1B6B CALL 3433:33F8
This will wait for you to press enter, then put you back in the program. So
press <cr> and proceed on. Next you'll come to this:
CS:1B80 CALL 3433:2AF1
This will wait for you to enter your response to the question. So enter a right
answer, and then press <cr>, and now proceed on. Keep going on until you get
back to where I described up above, and do as I mentioned. This will show
you why I changed those jump statements. So, when you're through with this,
be sure to save the changes, and if you've forgotten how to save, here's a
little memory refresher:
-----------------------Saving the Changes-----------------------
Remember now, that debuggers can only write to .COM and files
other then .EXE (with the W<cr> command). One way to save the
changes (the more unreliable way) is to rename the .EXE file to
Something like .HEY or whatever, and then going in and searching
for the data to be changed (with the S command). Now edit the
data as normal, and save with the W<cr> command. Exit out
(Q<cr>) and rename the .HEY file back to .EXE
*** This will not always work ***
Another way to save changes is with a sector editor (The two most
widely used are Norton Utilities and PCTools). Search for the
HEX values (the values I told you to write down) of the data in
front of, including, and after the statement. When you find
The statement, edit it. (i.e. Changing the HEX values of a CALL
statement to read 90 90 90 90 90 (90 is the HEX value for NOP)).
Also, make sure that you write down the new hex values after
changing the assembly code in the program with the debugger.
Then you'll replace the original HEX values with what you want
them to be.
------------------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Sample Crack-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Software Name: Castles
Software Company: Interplay
Here is a walkthru for cracking a config/setup type copy protection. This will
be fairly simple to crack, so get relaxed.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Method: Changing Jump Statements
Obtain an uncracked copy of Castles, and prepare your debuggers. First
off, you'll notice that you need to run the setup program to get the game
configured for your system so it can be properly run. When you enter the
options to fit your system, you'll then be asked a question from the manual, and
it will then write a number into the batch file it saves. If you answer wrong,
it will write a "wrong" number in the batch file, and if you answer right, it
will write a "right" number in the batch file. To remove any possible
complications and hassles, we're going to remove the question and remove where
the game checks to see what the number is. So, two cracks will be needed. One
in SETUP.EXE, and the other in CASTLES1.EXE. Load SETUP.EXE into your debugger
and start proceeding.
Now, you'll come up to the following:
CS:00EF CALL 14DD:0B69
Trace through this and start proceeding.
*** Note that I will not be mentioning when the graphics mode is switched or
when it calls in graphics pictures. You should know what they are by now ***
You'll come up into a loop that goes back and redraws the menu screen. IF you
keep proceeding through the loop, it will be a slow process trying to configure
your system, so just jump past that jump statement to CS:0BC5. This will allow
you to enter your setup options. After doing this, select continue, and press
enter. Now, proceed on. You'll notice the following soon:
CS:0BCD CALL 033A
This is the doc check. Proceed on and see what happends. At CS:0BD8 CALL 04E3
it will write that number to the batch file. So, let's get rid of the question.
We want it to just jump past the doc check, and save the configuration to the
batch file, so do this. Notice before the doc call at CS:0BCA there is a
JZ 0BDF. This can be changed to: JMP 0BD7, thus jumping past the doc
CALL, and onto the part where it writes the number. Next, proceed on, and
you'll come to this:
CS:0BE8 JZ 0BF0
This is comparing what you entered and if it's wrong, it will exit out and
tell you to try again, and if it's write, it'll jump to CS:0BF0. So let's
just tell it to jump to 0BF0 all the time. (i.e. CS:0BE8 JMP 0BF0).
Now, save the changes and let's start on the game. Load CASTLES1.EXE into your
debugger (Make notice of the parameters set in the batch file, because you'll
need to specify these when loading it into the debugger, so that it will run
the way you configured it on your system - i.e. DEBUG CASTLES1.EXE /VGA
/NOTITLE /NOMUSIC) Start proceeding through.
You'll come up to the following:
CS:00EF CALL 1DDD:0752
Trace through this and proceed on. Next you'll come to some jump and CALL
statements. If you proceed through, it will kick you out to DOS, so make note
of the following jump statements, and what they are doing:
CS:0669 JZ 0670
CS:0678 JNZ 0680
CS:067E JZ 0691
If you notice what happends when you proceed through on a wrong number, you'll
see that the following needs to be done to those jump statements, so that
we jump around the statements that call to verify the copy protection:
CS:0669 JMP 0670
CS:0678 NOP NOP
CS:067E JMP 0691
Now, save these changes, and you're all done. The Setup program will no longer
ask the question, and the game itself will no longer check to see if you
answered the question right. So you're congratulate yourself.
--------------------------------------------------------------------------------
Hopefully this will aid you on your quest to become a crackist. And remember,
don't get in over your head by attempting to crack something difficult, 'cause
it won't help ya at all, G. Laterz...
- The Psychopath
+344
View File
@@ -0,0 +1,344 @@
Midnights Hackers Private Club
Where members or hackers groups come to exchange ideas, and show
off skills.
**** A Cracking Guide For Advanced Amateurs Part II****
An Article By:
The Psychopath
TABLE OF CONTENTS
-------------------
I. Introduction and Overview
II. Types of Cracks
A) Doc Check with a small Loader
B) Doc Check with a complex Loader
III. Closing Remarks
--------------------------------------------------------------------------------
Introduction:
This is my third edition on cracking tutorials. This one will provide
more information on the art of cracking as usual, and will provide a comparison
of 2 similar doc checks that vary in difficulty. Take the learning process slow,
and just let it come to you. Remember, don't try tackling too much at once.
Experience is the best teacher. Just a friendly little reminder here...
ALWAYS, ALWAYS make backup copies of the programs before you tamper with them
with your debuggers and sector editors, because if you screw up and write to
your only copy, you're plain outta luck holmes.
Cracking programs used in this issue:
DOS Debug
Acquire this if you don't already have it. This is the basic cracking
tool, and is my favorite. There are some advanced debuggers out there with
menus and fancy features, but when they fail, debug will come through for ya.
But of course, having the other debuggers can be handy at times, so I suggest
finding them if you don't already have them. Some good ones to get are:
Turbo Debugger (2.0 or greater)
Soft Ice (2.5 or greater)
Code View
I will no longer tell you how to access a debug command, so here's the
last time that I will refresh your memory as to what they are. If you don't
know what they mean by now, then you should go back and re-read my previous
articles.
Command Function
------------------------------------------
*A [address] Assemble
C range address Compare
D [range] Dump
E address [list] Edit
F range list Fill
*G [=address [address..]] Go
H value value Hex
I value Input
L [address [drive:record record] Load
M range address Move
N filename [filename] Name
O value byte Output
*P [=address][value] Proceed
*Q Quit
*R [register-name] Register
*S range list Search
*T [=address][value] Trace
*U [range] Unassemble
*W [address [drive:record record] Write
[* Indicates the only ones you need worry about for now. They are the main
commands that you use). Basically, you will enter the letter command and then
return (<cr>). Addresses only need to be specified based on necessity. (for
example, you could just enter G<cr> and it would execute. Specifying an address
would set a break point. (run the program up to that address). For P and T,
just enter the letter name and <cr>. It's quicker.]
Further explanation of the commands is provided in your DOS users manual.
Read it for yourself.
--------------------------------------------------------------------------------
Cracking Documentation Checks With Game Loaders:
Okay, the most common form of copy protection is the documentation check.
Doc checks are usually at the beginning of the software, with a few exceptions
(some being in the middle or at the end). They range in variety from simple
text questions, to having graphic and mouse interfacing. They, of course,
range in difficulty from being extremely easy to being near impossible.
In this issue, we're going to take a look at a programmers attempt to
cause frustration for us crackists. Someimtes you'll come upon a game that will
have you run one program, which will in turn run the main program. And of
course, you have to run the first (loader) program or the game won't work right.
Well, this poses a problem with debugging, for you can only load in one program
at a time, and most likely you won't be able to trace through one program to
get to the other, so how do we get to the copy protection and remove it? Well
let's go through two sample cracks and find out for ourselves eh.
Hopefully you remember what types of copy protection ASSEMBLY commands
to look for, and how to couteract them, cause I won't refresh your memory for
you....you'll have to re-read the past articles if you forgot.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Sample Crack-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Software Name: Gateway to the Savage Frontier
Software Company: S.S.I. & Beyond Software
Here is a walk through for cracking a simple attempt at a loader along with
a simple doc check. This should be eazy to follow, so let's get going eh.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Find an uncracked copy of Gateway to the Savage Empire. Now then, you'll
notice that there is a batch file entitled START.BAT This is what we run to
load in the game. Well, let's see what it's doing. Type the batch file out.
You should see this:
@echo off
start1
if errorlevel 1 goto end
go
:end
Now, if we run this batch file, it will execute START1.EXE which will
allow you to specify your graphics, sound, mouse, etc. etc., and when that's
done, it returns to the batch file, where you'll notice GO.BAT is then executed.
Let's look at GO.BAT and see what it's doing. You'll see something similar
to this (depending on the graphics and sound and such that you selected):
ibmsnd
game UseStart
ibmsnd U
Notice that the UseStart is a parameter specification on the game. If we
try running GAME.EXE it will tell us to run start. Well, this is so simple
it's not even funny. Notice what start does. It sets up your system
specifications, then loads in the game. That UseStart parameter is the key
to the whole thing. Instead of typing just "debug game.exe" specify the
parameter as well (this will happen quite often with games that use parameters.
They must be specified in the debugger if you want them loaded in). Type "debug
game.exe UseStart" (and the capital/lower case letters ARE significant in the
paramater settings). Now, we're ready to begin. Start proceeding.
At CS:0037 CB RETF, you'll do a far return to a new code segment address,
at CS:0038, here you'll proceed on. You'll hit a bunch of comparison jumps
that will keep looping you around till you eventually get to CS:00DE, where you
can start proceeding forward again. ('Course if you're smart you'll just take
my advice and jump from CS:0038 to CS:00DE and proceed from there). Next
you'll come to:
CS:00FE 2E CS:
CS:00FF FF2F JUMP FAR[BX]
Proceed through this and you will be at a new code segment address at
CS:0019, where you will find a long series of CALL statements. Start proceeding
through them. You'll hit some that will load in the graphics and the title
screen and such (if you press control-C when the Beyond Software screen appears,
it will skip the intro screens). You should eventually come to:
CS:01CE CALL 1303:002A
This address calls in the option that will ask you if you want to PLAY the
game or view a DEMO. We of course, want to play, so select play and press
enter. Now, proceed on. It will eventually bring you up to this address:
CS:0208 JNZ 0216
CS:020A CMP BYTE PTR [5D8E],00
CS:020F JNZ 0216
Now, we've already selected that we want to play the game, so what do you
think this comparison means? Could it be that it's determining wether or not to
load in the doc check? Well I do believe so. If you don't believe me, proceed
on. You'll hit a CALL statement at CS:0211 That will load in the copy
protection. So how do we remove this? Well, what I suggest doing is changing
the jump at CS:0208 to read CS:0208 JMP 0216.
This will tell the program to jump directly to CS:0216, thus skipping over
the copy protection completely. Now, wasn't that simple. Just save the
changes and you're done.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Sample Crack-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Software Name: Time Quest
Software Company: Legend
Here is a walkthru for cracking a more complex loader that calls in a
moderately difficult doc check.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Obtain an uncracked copy of Time Quest, and prepare your debuggers. Okay,
Here's the situation. The main part of the game is in the file TIMEMAIN.EXE,
but we have to run TQ.EXE in order to play the game. If you try running
TIMEMAIN.EXE, it will (as I mentioned) tell you to run TQ.EXE to load the game.
So what do we do? Unlike the previous sample crack, there are no parameters
that are displayed that we could load into the debugger. The TQ.EXE file loads
in part of the title screen, and determines your graphics and sound modes, so
we're in a bad situation.
If you try debugging TQ.EXE to get to TIMEMAIN.EXE, the following will
happen. You'll eventually reach the part where a CALL statement loads in
TIMEMAIN.EXE. The program will take control or lock up. So naturally, you
try tracing through, till you get to another CALL statement that does the same
thing. You'll keep doing this until you get to the INT-21 that loads in the
TIMEMAIN.EXE, and it will lock up there....if you trace through, it will take
you to a part of the program that you don't ever want to tamper with. You'll
be where it makes all the jump comparisons for all the INT-21's. Proceeding
through this area will most likely bring up a message like "System Halted. Can
Not load Command.com" so now were stuck....or are we?
Now think for a minute and get creative. TQ.EXE somehow loads in
TIMEMAIN.EXE. So what if we can trick TIMEMAIN.EXE into thinking that TQ.EXE
has already been run. All we'll do in the process is leave out the Legend
Software title screen. And, hopefully, we'll enact the default settings, which
will bring in CGA graphics. This will make it easier to see what's going on,
because with the CGA graphics, it's in black and white, and very simple
structure, which is what we want when stepping through a debugger. So, let's
get started. Load TIMEMAIN.EXE into your debugger and start proceeding.
You should come to CS:0548 JMP 29B1:09A2 where you will proceed through,
jumping to a new code segment address. Keep proceeding on. You'll come to
CS:0A20 where you'll then be kicked into a new code segment address. Proceeding
on will just bring you back to CS:0A21, so instead of going through all that,
jump to CS:0A21 before you reach CS:0A20, and then keep proceeding.
After you reach the following:
CS:0A41 CALL 232E:1AFB
Trace through here, and keep going (proceeding through this call statement
will terminate the program and bring up that message telling you to run TQ.EXE
first). Keep proceeding till you come to the following:
CS:1B12 CALL 18CA
Trace through here, and keep going (proceeding through will have the same
result as the above mentioned). Now, you'll soon see the following:
CS:18D6 CMP WORD PTR [BP+06],+09
CS:18DA JZ 18F6
If we just proceed through these, the program will soon terminate as
above mentioned, but if we jump to 18f6, the game will start to load, so let's
fix this by changing CS:18DA to be the following:
CS:18DA JMP 18F6
Note, that this change is not to be permanent. It is merely a temporary
change to allow us to load in the game so we can make the permanent chane to
the copy protection. Now then, proceed on. You'll hit a CALL statement that
will switch to the graphics mode, then you'll eventually reach:
CS:1AFA RETF
Proceed through this, and you'll return back to CS:1BC5. Proceed on. You
will hit a few calls along the way that will load in the screens, and eventually
you'll reach:
CS:1C68 CALL 1F6F:188B
This will call in the option that lets you type in a command, so type in
the following commands in this order (and note, that after you press enter,
you'll be back in the debugger. Instead of proceeding on, which will
eventually bring you back to CS:1C68, just go to 1C68 again and proceed through.
It will wait for you to input another command. Keep doing this until you've
input all the commands).
wait
wait
w
open drawer
take card
enter interkron
put card in slot
timeset rome 44
Now, after entering the last command, (DO NOT JUMP back to 1C68 again)
proceed on. You will eventually come to:
CS:2496 CALL 0D40
Trace through this call statement (proceeding through will bring up the
doc check). Now, proceed on until you eventually come to:
CS:106E CALL 1B46:05C5
Trace through here (for the same reason as mentioned above), and then
proceed on and you'll eventually reach:
CS:05F5 CS:
CS:05F6 JMP [BX+0B14]
Proceed through this (If you ever try jumping (with the go command) to a
two part jump statement like this, make sure you go to the address with the
"CS:" and not the JMP, otherwise you will screw up the program and it will
jump you to the wrong place). Trace through:
CS:09FC CALL 1CA7:1520
Now, proceed on till you come to:
CS:160C CALL 45EA:1F8E
Trace through this, and then trace through the call statement that you
immediately come upon, which is:
CS:1F8E CALL 4537:0307
If you proceed through this, it will try to access your floppy drive,
because it won't be able to find the overlay file, so trace through it. Now,
proceed on till you get to CS:0379, where you will be taken back to CS:1F95, now
keep proceeding on, and you will go through a series of jump compare statements,
if you keep going on, you will eventually hit:
CS:029F CALL 1E35:000C
This is where the doc check will pop up. These jump comparisons are the
key to the doc check. If you notice, at:
CS:029D JNZ 02B5
Here, is where it makes an obviously important comparison. Why is it
important you ask, well because look at what happends. If the value it's
comparing is zero, it proceeds on to CS:029F, where the doc check comes in,
so what happends if the value is not zero? Well, let's find out. Change
CS:029D to read CS:029D JMP 02B5 and then proceed on. You will soon hit a CALL
statement that will give a message displayed only after you pass the doc check,
thus we know we made it to the right area. So just make that change at CS:029D
permanent. And just to give you a little hint, the change you need to make will
have to go in the overlay file. So, now we're done. Wasn't so tough after all
now was it.
** Notice. This cracking scenario for Time Quest was done without any saved
games. Having saved games will effect the debugging process. You will
have a few other detours along the way before you get to CS:1C68, so either
try it on your own, if you have saved games, or move your saved games to
a different directory and try it without them first. It'll be easier. **
--------------------------------------------------------------------------------
Hopefully this will aid you on your quest to become a crackist. And remember,
don't get in over your head by attempting to crack something difficult, 'cause
it won't help ya at all, G. Laterz...
- The Psychopath