114 lines
5.7 KiB
Plaintext
114 lines
5.7 KiB
Plaintext
|
|
HOW TO CRACK, A TUTORIAL - LESSON 3 (1)
|
|
by +ORC (the old red cracker)
|
|
|
|
How to crack, an approach LESSON 1
|
|
How to crack, tools and tricks of the trade LESSON 2
|
|
-> How to crack, hands onn, paper protections LESSON 3 (1/2)
|
|
How to crack, hands on, time limits LESSON 4
|
|
How to crack, hands on, disk-CDrom access LESSON 5
|
|
How to crack, funny tricks LESSON 6 (1/2)
|
|
How to crack, intuition and luck LESSON 7
|
|
How to crack windows, an approach LESSON 8
|
|
How to crack windows, tools of the trade LESSON 9
|
|
How to crack, advanced cracking LESSON A (1/2)
|
|
How to crack, zen-cracking LESSON B
|
|
How to crack, cracking as an art LESSON C
|
|
How to crack INDEX
|
|
|
|
LESSON 3 (1)
|
|
HOW TO CRACK, HANDS ON - Password protected programs
|
|
|
|
SOME PROBLEMS WITH INTEL's INT
|
|
The INT instruction is the source of a great deal of the
|
|
flexibility in the PC architecture, because the ability to get
|
|
and set interrupt vectors means that system services (included
|
|
DOS itself) are infinitely extensible, replaceable and
|
|
MONITORABLE. Yet the Int instruction is also remarkably
|
|
inflexible in two key ways:
|
|
- an interrupt handler DOES NOT KNOW which interrupt number
|
|
invoked it.
|
|
- the int instruction itself expects an IMMEDIATE operand:
|
|
you cannot write MOV AX,x21, and then INT AX; you must
|
|
write INT x21.
|
|
That would be very good indeed for us cracker... unfortunately
|
|
many high level language compilers compile interrupts into PUSHF
|
|
and FAR CALL instruction sequences, rather than do an actual INT.
|
|
Another method is to PUSH the address of the handler on the stack
|
|
and do RETF to it.
|
|
Some protection schemes attempt to disguise interrupt calls,
|
|
this is particularly frequent in the disk access protection
|
|
schemes (-> see LESSON 5) that utilize INT_13 (the "disk"
|
|
interrupt).
|
|
If you are attempting to crack such programs, the usual
|
|
course of action is to search for occurrences of "CD13", which
|
|
is machine language for interrupt 13. One way or another, the
|
|
protection scheme will have to use this interrupt to check for
|
|
the special sectors of the disk. If you examine a cross section
|
|
of the program, however, you 'll find programs which do not have
|
|
"CD13" in their machine code, but which clearly are checking the
|
|
key disk for weird sectors. How comez?
|
|
There are several techniques which can be used to camouflage
|
|
the protection scheme from our nice prying eyes. I'll describe
|
|
here the three such techniques that are more frequent:
|
|
1) The following section of code is equivalent to issuing an
|
|
INT 13 command to read one sector from drive A, side 0, track
|
|
29h, sector ffh, and then checking for a status code of 10h:
|
|
cs:1000 MOV AH,02 ;read operation
|
|
cs:1002 MOV AL,01 ;1 sector to read
|
|
cs:1004 MOV CH,29 ;track 29h
|
|
cs:1006 MOV CL,FF ;sector ffh
|
|
cs:1008 MOV DX,0000 ;side 0, drive A
|
|
cs:100B XOR BX,BX ;move 0...
|
|
cs:100D MOV DS,BX ;...to DS register
|
|
cs:100F PUSHF ;pusha flags
|
|
cs:1010 PUSH CS ;pusha CX
|
|
cs:1011 CALL 1100 ;push address for next
|
|
instruction onto stack and branch
|
|
cs:1014 COMP AH,10 ;check CRC error
|
|
cs:1017 ... rest of verification code
|
|
...
|
|
...
|
|
cs:1100 PUSHF ;pusha flags
|
|
cs:1101 MOV BX,004C ;address of INT_13 vector
|
|
cs:1104 PUSH [BX+02] ;push CS of INT_13 routine
|
|
cs:1107 PUSH [BX] ;push IP of INT_13 routine
|
|
cs:1109 IRET ;pop IP,CS and flags
|
|
Notice that there is no INT 13 command in the source code, so if
|
|
you had simply used a debugger to search for "CD13" in the
|
|
machine code, you would never have found the protection routine.
|
|
|
|
2) Another technique is to put in a substitute interrupt
|
|
instruction, such as INT 10, which looks harmless enough, and
|
|
have the program change the "10" to "13 (and then back to "10")
|
|
on the fly. A search for "CD13" would turn up nothing.
|
|
|
|
3) The best camouflage method for interrupts I have ever
|
|
cracked (albeit not on a INT 13) was a jump to a section of the
|
|
PROGRAM code that reproduces in extenso the interrupt code. This
|
|
elegant (if a little overbloated) disguise mocks every call to
|
|
the replicated interrupt.
|
|
Bear all this in mind learning the following cracks.
|
|
|
|
CRACKING PASSWORD PROTECTED PROGRAMS
|
|
Refer to lesson one in order to understand why we are using
|
|
games instead of commercial applications as learn material: they
|
|
offer the same protection used by the more "serious" applications
|
|
(or BBS & servers) although inside files that are small enough
|
|
to be cracked without loosing too much time.
|
|
A whole series of programs employ copy protection schemes
|
|
based upon the possess of the original manual or instructions.
|
|
That's obviously not a very big protection -per se- coz everybody
|
|
nowadays has access to a photocopier, but it's bothering enough
|
|
to motivate our cracks and -besides- you'll find the same schemes
|
|
lurking in many other password protected programs.
|
|
Usually, at the beginning of the program, a "nag screen"
|
|
requires a word that the user can find somewhere inside the
|
|
original manual, something like: "please type in the first word
|
|
of line 3 of point 3.3.2". Often, in order to avoid mistakes, the
|
|
program indicates the first letter of the password... the user
|
|
must therefore only fill the remaining letters.
|
|
|
|
Some examples, some cracks:
|
|
|