Neophytes read me : How to crack software

Questions about programming languages and debugging
Post Reply
User avatar
Digital Mercenary
Digital Mercenary
Posts: 6114
Joined: 24 Feb 2006, 17:00
Location: Michigan USA

Neophytes read me : How to crack software

Post by DNR »

This should cover many basic questions of 'how do I crack ** software', please read this before posting broad/complex questions related to cracking of software. This site BTW does not condone cracking of copyright materials.

Knowing a higher level language such as Basic, Pascal, or C++ will help crackers somewhat. But it really doesn't matter what language a program was written in in order to crack it, because all programs do the same thing. And that is issue commands to the microprocessor. And all programs when broken down to their simplest form are nothing more than a collection of 80XXX instructions and program specific data. This is the level of assembly language. In assembly they have total control of the system. This is also the level that the debugger operates.

The debugger and disk editor are the crackers most used tools. The debugger is what they will use to crack the program. When they load a program to crack into the debugger, it will load the program and stop at the first instruction to be executed within the code segment. Or, they can also optionally break into an already running program and it will halt the program at the instruction they broke into it at and await further input from them. At this point, they are in control of the program. They can then dynamically interact with the program and run it one line of code at a time, and see exactly what the program is doing in real time as each line of code is executed. They will also be able to re-assemble instructions (in memory only), edit the contents of memory locations, manipulate the cpu's registers, and see the effects their modifications have on the program as it's running.

The debugger will only modify the program while it's up and running in memory. In order to make permanent changes, they need to load the program file to be patched into the disk editor and permanently write the changes they've made to disk.

So, they need a few essential tools... The first one is a good debugger. They will also need a disk editor, it doesn't matter which one as long as it will load the program file, search for and edit the bytes they want to change.

They should be able to translate HOTKEYS and COMMANDS instructions to the actual key strokes and commands that their debugger uses...

The register window contains the general purpose and flags registers of the cpu. The general purpose registers contain hexadecimal values. These values are just what happened to be in there when crackers brought up the debugger. Some of the flags are highlighted while some are not. Usually, the highlighted flags are the ones that are SET. While the ones that are not highlighted are CLEARED. The layout of this window will vary from debugger to debugger, but they all basically are the same. From this window crackers will be able to manipulate the contents of the cpu's registers. Some debuggers accomplish this by clicking on the register to modify with the mouse and then entering a new value. Other more powerful debuggers use a command line interface. Crackers change the values of the registers while debugging a program in order to change the behavior of the running program.

By the same token, crackers can modify the general purpose registers in the same manner.

The data window will display data as it exists in memory. From this window crackers can usually display, search, edit, fill, and clear entire ranges of memory. The two most common commands for this window are display and edit. The search command is also useful in cracking.

The code window is the window in which crackers will interact with the running program. This is the most complex window, and it is where the bulk of debugging occurs.

The layout of the window is pretty simple, the group of 8 numbers with the colon in the middle of them to the far left of the window is the address:offset of that line of code. Each line of code in this window is an instruction that the program will issue to the microprocessor, and the parameters for that instruction. The registers that contain the address for the current instruction waiting to be executed are the CS:IP registers (code segment and instruction pointer).

There is a group of hex numbers to the right of the addresses, this group of numbers is the hexadecimal equivalent of the mnemonic instructions. The next group of words and numbers to the right of the hex numbers are the mnemonic instructions themselves.

The RESTORE USER SCREEN KEY: This key will toggle the display between the debugger and the program crackers are debugging without actually returning control to the program itself.

The HERE KEY: This key is the non-sticky breakpoint key. When (and if) the program reaches that line, program execution will halt, control will be returned to the debugger and the breakpoint will be removed.

The TRACE KEY: This key will execute one line of code at a time and will trace into all calls loops and interrupts.

The BREAKPOINT KEY: This is the sticky breakpoint key. This will enable a permanent (sticky) breakpoint on the line of code that the cursor is on. When a sticky breakpoint is enabled, program execution will halt and control will be returned to the debugger every time that line of code is encountered within the running program until you manually remove it.

The SINGLE STEP KEY: The most used key on the keyboard. This key will execute one line of code at a time but will not trace into calls loops or interrupts.

The RUN KEY: This key will return control to the program being debugged and allow it to execute as normal. Control will not be returned to the debugger unless a breakpoint that you've set is encountered.

Now for a few commands:

The GO TO command functions like the HERE key in that it will insert a non-sticky breakpoint at the specified address. When crackers enter this command the debugger will return control to the program until the line of code they specified in the GO TO command is reached. When (and if) the CS:IP registers equal the address they typed in, the program will halt, control will be returned to the debugger and the breakpoint will be removed.

The ASSEMBLE command is the command crackers will use to re-write the programs instructions. This command will allow them to assemble new instructions beginning at the address they type in, or at the current CS:IP. The instructions they enter will replace (in memory only) the existing program code at the address they specified. This is another method they use to alter the running program to behave as they wish and not as the programmer intended it to.

There are a whole host of other commands available in this window depending on what debugger are using, including commands to set breakpoints on interrupts, memory locations, commands that list and clear breakpoints, commands to un-assemble instructions etc etc...

There are basically three categories that shareware programs fall into... They are begware, crippleware, and deadware.

The begware category is comprised of programs that have all the registered features enabled but every time you run them they will display screens that bug you to register. This is usually the easiest form of protection to remove.

The crippleware category is comprised of programs that in the unregistered version have certain functions disabled, and maybe nag screens as well. This type of protection can be more complex, but often times is just as easy to defeat as a simple nag screen.

The deadware category is comprised of programs that are totally stripped of the code for the registered features so there is really nothing to crack.

Most forms of copy protection have one weak spot, and this is the spot crackers will concentrate on. They have to perform the protection check and then make a decision based on the results of that check. And that decision is usually a conditional jump.

Crackers step through the code until something significant happens like a nag screen gets displayed, or a doc check comes up or the program tells them that the function they just tried to use is only available in the registered version. When they reach that point they can then start to evaluate what portion of code to begin studying.

The passive doc check is easier to defeat than the active. In the passive doc check, the program will issue a call to the copy protection routine. And if it is unsuccessful will either abort the program, or loop back to the beginning of the routine and give them a few more tries before aborting. The entire protection routine will be included in a single call, so merely nopping out or bypassing the call will be sufficient to remove the copy protection.

The active doc check is more complex. The program will issue the check and unlike the passive protection, will set a variable in memory somewhere and reference it later on in the program. If crackers didn't crack it right, later on when the next episode gets loaded or they reach a crucial point in the program, this will reference a memory location and bring up the copy protection again, or abort.

There are several other tools that crackers can utilize. These tools were not designed with the cracker in mind, but they can be adapted to serve their purposes rather than the ones which they were written for.

Special programs were written to remove the compression envelopes from exectables so they would be able to scan those files with a virus scanner among other things. If someone were to attach a virus to an exe file and then compress it, the file for all intents and purposes would be encrypted. Now when they downloaded that file and ran their virus scanner on it, it might not find the virus. But crackers found a different use for these types of programs. They use them to remove the compression envelope so that they can find the byte strings they want to search the files for. Most of the programmers who wrote these programs never intended them for this purpose. There are some out there though that were written by crackers with this exact purpose in mind.

If the program is encrypted, their only recourse in this instance is to reverse engineer the encryption routine while the program is decrypting to memory, and modify their search string to search for the encrypted version of the bytes. Or they could write a tsr patcher that impliments their patch after the program is decrypted to memory.

There is another category of programs they can adapt to use and they work in conjunction with the file expanders. These types of programs will scan entire directories of files and pop up a window that displays which files are compressed and what they are compressed with. They won't remove the compression routines from the files themselves, but will only inform them which files are compressed and which are not.

Another type of program will scan entire disks/directories/subdirectories of files for specific hex or ascii byte patterns contained within those files. One method to determine if a shareware program is registerable or not before actually loading it into the debugger is to use this tool. This will show all files that contain the string unREGistered and REGistered. If it returns a string that contains REGistered in a file other than the doc files, the program can be made into the version. This is just a quick check.

An added feature of this program is that after they've cracked a program and have a byte string to search for, they can run this program in hex mode and input their search string. Now it will search all of the programs files and return the name of the file that contains their search string, then they can just load that file into the disk editor and make the patch. It will also let them know if their search string is contained in more than one location within the file

<<this post taken>>
He gives wisdom to the wise and knowledge to the discerning. He reveals deep and hidden things; he knows what lies in Darkness, and Light dwells with him.

User avatar
Suckopithicus chickasaurus
Suckopithicus chickasaurus
Posts: 513
Joined: 22 Mar 2006, 17:00
Location: Brussel

Post by LaBlueGirl »

Wow...that was a very good read...
"Hey, Crash!
Ever tried walking with no legs?

It's real slow!"
~Crunch, Crash Bandicoot TTR

User avatar
Posts: 1
Joined: 27 Oct 2006, 16:00

Post by MacLeod »

I hope I do not offend anyone by posting to something that was closed so long ago...but I am really curious as to how stuff works. I was wondering if you could give me some examples of some really good debuggers and disk editors so i can play around with this stuff. Any help is greatly appreciated.

User avatar
Posts: 3275
Joined: 25 Jun 2005, 16:00

Post by Gogeta70 »

OllyDBG is a good and common debugger. You can google for it.
¯\_(ツ)_/¯ It works on my machine...

cyber messiah
cyber messiah
Posts: 1201
Joined: 30 Apr 2006, 16:00

Post by pseudo_opcode »

oh i have done a lot of cracking... i mainly used. softice and ollydbg, wdasm, and a hex editor, plus a few unpackers.

Post Reply