0% found this document useful (0 votes)
15 views2 pages

Cracking Password Protected Programs

Uploaded by

zin lynn naing
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views2 pages

Cracking Password Protected Programs

Uploaded by

zin lynn naing
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

howto3a.

txt
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
Page 1
[Link]
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:

Page 2

Common questions

Powered by AI

Sharing tutorials on cracking software protections raises ethical concerns primarily around promoting unauthorized access and potential infringement of intellectual property rights. While these tutorials aim to educate and develop skills in cybersecurity by demonstrating vulnerabilities, they inherently risk enabling malicious activities if accessed by individuals with unethical intents . They blur lines between legitimate educational purposes and illicit misuse, posing challenges in governing content dissemination and enforcing responsible use while potentially leading to broader discussions on cybersecurity vulnerability disclosure and the balance between security and open knowledge dissemination .

The initiative to tackle the 'CD13' machine code camouflage issue epitomizes broader trends in cybersecurity focusing on uncovering hidden vulnerabilities and disarming sophisticated cloaking tactics. Such techniques demonstrate evolving defense mechanisms against increasingly advanced protective obfuscations, reflecting a shift towards strategic decoding and deep reverse engineering in cybersecurity . This trend emphasizes comprehensive analysis beyond superficial signature checks, necessitating an understanding of both broader contexts and intricate code details, thereby signaling the growing complexity of cybersecurity measures against structural and procedural sophistication designed to outmaneuver simple detection techniques .

The 'PUSHF' instruction is significant in the INT 13 camouflaging technique as it saves the processor's flag register to the stack, preserving the current processor state and setting up for controlled machine state alterations without showing direct intent . This allows the program to initiate further manipulations needed for the camouflaging of the interrupt call by establishing a temporary environment that can handle the jump and return sequences required for disguising the INT 13 operation, leading to execution flow that implies certain operations without explicit call records .

Software protection schemes often use techniques to camouflage interrupt calls to prevent easy detection by crackers. One such method involves issuing an INT 13 command (disk interrupt) without using the actual instruction 'CD13' in the machine code. For example, a series of moves and pushes sequentially creates the effect of calling INT 13 without explicitly showing it in the code . Another technique substitutes a harmless INT, like INT 10, then dynamically alters it to INT 13 during execution. This swap circumvents static searches for 'CD13' . The most sophisticated method replicates the interrupt's code within the program, mocking every call to the original interrupt, thus making camouflage even more complex .

'Nag screens' act as an obstacle by requiring the user to input information found only in original instruction manuals, delaying unauthorized access . They typically prompt the user for a specific word or phrase found in a particular manual locale, sometimes providing partial cues like the first letter, increasing user difficulty in cracking the software without the manual . Circumvention can involve altering the program code to bypass this prompt altogether, patching the execution flow to reflect a 'correct' input, or using reverse engineering tools to understand and manipulate how the software verifies this input .

The INT instruction in PC architecture is flexible because it allows system services to be infinitely extensible and replaceable through interrupt vector manipulation. It facilitates a high degree of extensibility, as services and functionalities can be altered or monitored by changing the interrupt vectors . However, it is also inflexible because it doesn't allow interrupt handlers to determine the interrupt number during invocation, and requires an immediate operand; you must use a specific instruction like 'INT x21' instead of a variable interrupt number ['MOV AX,x21; INT AX']. This rigidity limits dynamic handling of interrupts.

Using manual-based authentication represents simplicity in that it relies on something users physically possess—a manual—to prevent unauthorized access, which can be easily bypassed with modern technology like photocopying . However, it is sophisticated in its integration into software as it leverages user interaction with the program narrative, often employing psychological elements like cues in 'nag screens' that guide user input based on a manual, thus blending user experience with protection mechanism . Further sophistication is evident as these schemes can be unpredictably altered and combined with other methods, increasing complexity for potential crackers .

Cracking password-protected programs that rely on user possession of original manuals involves addressing challenges like bypassing authentication that demands input from the manual (e.g., a specific word from a location within the manual). Such schemes include 'nag screens' requesting words from particular sections of a manual . To crack these, one might have to circumvent or manipulate the part of the program that checks for correct input, often involving reverse engineering or altering program flow. Understanding typical methods employed by such schemes, including hinting the first letter of the password, can inform effective cracking strategies .

Many high-level language compilers opt for 'PUSHF' and 'FAR CALL' instruction sequences over direct 'INT' instructions to gain consistent software behavior across different systems and potentially to align with certain procedure call protocols that offer more controlled flow and stack management . Direct use of 'INT' might be avoided due to its immediate operand requirement, which limits dynamic flexibility and increases dependency on architecture-specific parameters, thus making compiled code less adaptable or portably transferable to varied environments .

Lesson 3 focuses on practical, hands-on application through 'cracking' password-protected programs, contrasting with theoretical or concept-based approaches in other lessons. It involves directly interacting with the protection mechanism and applying practical decryption skills, like deconstructing breakpoints and observing memory operations, to bypass these mechanisms . Other lessons may focus on abstract methodologies or specific tool usage (e.g., Lesson 1's overview of approaches and Lesson 2's tools), while Lesson 3 immerses the practitioner in live scenarios to build intuition and practical experience .

You might also like