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: