You can access IRC using an IRC Client (try mIRC, for Windows).
If youre having difficulty finding an EfNet server that will let you on, try one of these: irc.idle.net, irc2.homelien.no, irc.core.com
Cracking is the manual deprotection of software, and the automation of the creation of keys that will 'unlock' programs.
Cracking has nothing to do with CD-Writers, Hacking, Netbus/Back Orifice, or using ready-made cracks.
If youre wanting to learn cracking, you must understand fundamental concepts of programming, and machine architecture, and possess a good working knowledge of the operating system youre working with. If you dont have all three, chances are youre not really going to progress much. If you have some programming experience, then this generally helps, depending on the language. But many newbies decide they want to instantly become crackers without any programming experience. Do yourself a favour, and learn how to program first ;-)
I am often asked by people, what is the best programming language to learn ? The answer to this is never clear cut, as it depends on what your ultimate aims are. A good knowledge of Assembly language is a great help in reversing, but many people are able to crack well without necessarily being able to program in assembly. As long as you can fully understand the flow and effects of the instructions, this is often enough.
Additionally, you might want to consider learning a higher level language such as C. The web is infested with programming tutorials, do a web search. Also, Borland produce a free C compiler. LCC is another alternative which I use personally. Knowing C will allow you to quickly produce keygens, patches and any other tools you need to complete a crack, although a good assembly coder is able to produce these in about the same time scale.
Knowing a language like C will also aid you in studying disassembly. Various compilers produce different object code, and you can often tell what compiler was used, just by studying the generated opcodes. Although this is less of an issue as you can use IDA flirt recognition to identify the compiler too.
High level languages such as Visual Basic are not really much of a benefit to your cracking adventures. Although you can produce equivalent tools in VB, if youre writing a complex keygen, and its not quite write, you lose the ability somehwat to study the disassembly to see where exactly its going wrong.
So to summarise, if youre not technically minded, learn C, otherwise immerse yourself in assembly language. But then if youre not technically minded, why are you even wanting to become a cracker ? :-)
It should be noted that if you struggle to even install softice, you might be better
ditching your cracking aspirations, and sticking to games for a few more years ;)
Once softice has completed its install procedure, it will have (providing you asked it to)
modified your autoexec.bat so that softice gets loaded on boot-up. If you run a boot-up menu
you better check your autoexec.bat to make sure its in the right place. The line
is the only thing required in your autoexec, to load softice. The path may obviously differ.
After rebooting, if you press CTRL-D in windows, and softice does not appear, then Softice
is NOT active. Check your autoexec.bat. When softice is visible, you can close the console window
by pressing CTRL-D again, or F5.
After SoftICE has been installed, there are a few ways in which you need to, or might want to
configure it. The default options are pretty poor.
First of all, in order to set breakpoints on API, you need to have the symbols for the
corresponding modules loaded into SoftICE. You can either run Symbol Loader and load the modules
manually. This saves having to reboot, but only loads the symbols for the duration of the
current windows session.
A better idea is to modify your winice.dat, so that commonly used symbols are loaded by default.
Thankfully, those nice guys at numega already place a decent set of symbols to load into the winice.dat,
only they are commented out.
To uncomment these, open winice.dat in any text editor. Scroll down to the lines which start with
and delete the ';' from the start of each EXP line. If you know what youre doing, you may only
want to uncomment a selection of them. If you're a newbie, you should uncomment all of the lines
starting with EXP.
While your EDITING your Winice.dat you might as well add these lines:
There are known issues with SoftICE and some graphics drivers on Windows 2000. Typically nVidea cards are affected, (notably GE Force and TNT).
The problem is that when the SoftICE console window is opened, it doesnt display at all. It has been reported than reverting to an older version of the graphics drivers fixes this problem. Its worth noting that Detonator 2 drivers will not work, so decide whether you want to be a gamer or a cracker, and act accordingly :-)
SoftICE uses DirectX to display its console window, so be sure to check youre card is compatible with this (this shouldnt be a problem for anything other than very old gfx cards).For incompatible cards, you can download the legacy video drivers for SoftICE here.
First of all, check you have configured SoftICE correctly. If you are trying to break on an API call by name (ie bpx GetDlgItemTextA), the symbol information for this API must be loaded into symbol loader. This is so that SoftICE can resolve the API name to an actual address, and place a breakpoint on that. Read the FAQ on Configuring SoftICE if this is the case.
If you are placing a breakpoint on the entrypoint of an applciation, using Symbol Loader, and SoftICE does not break, there are several reasons why this might occur. If the exe is packed or compressed you may find that it doesnt break at the entrypoint. This could be due to the fact that the section characteristics for the code section need modifying.
There is a flaw in SoftICE whereby if an executable PE section cannot be found, or it is not the first section in the PE, winice will fail to recognise the target as the one that symbol loader asked it to break on, and execution will continue with no breakpoint being hit. (thanks to The Owl for his forum post highlighting this problem).
If you have set a breakpoint on a linear address, you may have set it in the wrong address context. For more information on address contexts, see the related FAQ.
This most commonly occurs to newbies when they bring up the SoftICE console by pressing CTRL-D, and setting a bpx in the current context, which more often than not is actually referring to the kernels address space. To prevent this, make sure SoftICE is referring to the address context of your target before setting your breakpoint. This can be done using the ADDR command. The names of all currently running tasks can be found using TASK.
When you use symbol loader to break on the targets entry point, SoftICE automatically refers to the targets context when it pops up.
Maybe SoftICE isnt loading at boot up, because it hasnt been included in the autoexec.bat (in which case see FAQ #1), or it is attempting to load at boot up and failing, in which case step through your boot sequence and view any errors SoftICE outputs as it loads.
Also, if youve just installed SoftICE, you obviously need to reboot before it can load.
By default, every time a GPF occurs in Windows, SoftICE will catch it, and appear,
enabling you to debug the error. This can be a major irritant for newbies if youre
not interested in debugging the error.
You can disable SoftICE's error catching by typing FAULTS OFF in softice, and then
pressing F5 to close the console window. A better idea is to add FAULTS OFF to your INIT
line, in winice.dat.
The INIT line in your winice.dat contains a series of commands you can automatically run,
as soon as SoftICE loads. This is the best place to configure your SoftICE console, with regard
to windows sizes, and positions.
Heres some sample commands you can put in your INIT line... There are many more. Read the Manual!
Sets the softice console window to be XX lines in height
Sets the data window to visible, with a height of XX lines
Sets the code window to visible, with a height of XX lines
Sets the opcodes of each instruction to be visible|not visible
Sets SoftICE to trap|dont trap windows faults
Closes the SoftICE window. Your INIT line may terminate with X; so that SoftICE is not immeditely visible when you boot into Windows. Note that X is equivalent to pressing F5 while SoftICE is open, and is NOT the same as EXIT.
Commands in the INIT lines are separated by ';'. Some commands only seem to work after the SoftICE window closes for the first time.
If you find some settings in your INIT line arent applied, try putting them after. the "X;" in your INIT line.
You may then add another "X;" to close the SoftICE window again.
Occasionally during the tracing of a process, you will encounter a situation where SoftICE displays a long series of INVALID's in the code window. This most often occurs when a process is first loaded, and you have breakpointed the entrypoint. To understand this, you need to know a little about paging and virtual memory.
Physical memory is divided up into 4K regions, called pages. Each page may either be present in physical memory, or paged out to disk at any given time. When an attempt is made to access a page which is currently paged out to disk, a Page Fault exception is generated by the processor. The Windows kernel handles this exception, loads the page from disk into physical memory, and then re-executes the instruction which caused the page fault (and execution continues as normal). Normally, this is totally transparent to applications, and they are completely unaware there was ever a page fault in the first place.
Since SoftICE is a kernel mode debugger, it operates below the windows kernel, and therefore can make attempts to access any memory region, without resulting exceptions being handled by Windows. If SoftICE determines that a page cannot be read because it is paged out to disk, it will display INVALID throughout the absent region of code. When some memory you want to inspect is paged out, you can force it to be loaded from disk (paged in), by issuing a 'PAGEIN <address>' command in SoftICE. Softice is then able to read the memory and show its actual content.
If you single step over an instruction which is currently paged out (ie, INVALID), the page handling mechanism I described earlier will kick in. The address is not present, and therefore a Page Fault occurs. Windows handles this and loads the absent page from disk into memory. It then re-executes the command which caused the page fault, and SoftICE will instantly show the memory as being present. Again, the fault itself is transparent to the SoftICE user, all he sees is that memory which was previously not there, now is ;-)
If the currently visible address space is present in physical memory, SoftICE may still show INVALID for some lines of code. This indicates that the opcodes at this address could not be disassembled because it did not form a valid opcode sequence. Perhaps the address is used to hold static data, rather than code, or it could be an intentional anti-disassembly trick by the softwares author. An old trick which manages to choke w32dasm simply performs a jumps over a series of illegal opcodes. Because w32dasm ploughs through the code in a purely linear fashion, rather than attempting to trace the flow of execution like IDA does, w32dasm tries to disassemble the illegal opcodes, and either fails miserably, or the opcodes offset the rest of the disassembly, producing corrupted output.
One of the best sites to visit for info about configuring SoftICE is +Sandmans Code Reversing For Beginners site.
There you will find the SoftICE Resource Center, which has every tute you will need to get a working knowledge of SoftICE.
Please read these before asking any SoftICE questions in #cracking4newbies.
Also, get a copy of the SoftICE Manual. And when you get it, be sure to actually READ IT !
Debug information is included into modules when they are compiled, for development purposes.
This allows intergrated debuggers in languages such as VC++/Delphi etc, to associate the object code with the source code.
When an application is released, debug info is typically not included in the object code, as to normal users it provides nothing but bloat.
If you find debug info in a released app, then thats great, but dont be surprised to find thats its not included. That doesnt mean you cant crack the app, nor does it mean its anything to worry about.
More than likely you have the app open in w32dasm at the same time.
This is notorious for placing a lock on the file leaving it unwritable.
Close w32dasm or whatever other app is accessing the target file, and then you will be able to edit in HIEW.
IDA is a disassembler.
It takes a code module, and analyses it to produce an assembly dead-listing,
regardless of the language the module was written in. This isnt the same as a decompiler, which takes
a module and attempts to get the module back into an equivalent source listing, for example C++.
You cannot trace through code step by step using IDA. For this, you require a debugger.
SoftICE is one such debugger.
It enables you to step through each assembly instruction in a module,
and view exactly what is occurring as it happens.
W32Dasm is a subtle mix of a disassembler and a debugger, although its debugger is pretty duff (and I personally
think its disassembly engine is duff also, but anyway..;).
W32dasm is often the tool of choice for newbies presumably because its an integrated disassembler and debugger, and its very simple to use.
For more power you should be aiming to be familiar with SoftICE and IDA. I very rarely use W32dasm for much, other than to briefly examine a file which would otherwise take IDA a while to disassemble.
The test instruction performs a logical AND of the two operands, without saving the result. The instruction does, however, update the flags.
Put in laymans terms, this means that it is an efficient way of testing to see if a register is zero in value.
If eax = 0, then test eax, eax will set the Z flag, otherwise Z will be reset. You'll notice that typically, the test instruction is followed by a jne, je.
Of course :)
The cracking/reversing scene thrives on the web. As you'd expect, there are a lot of websites dedicated to helping newbies get off to a flying start.
Be sure to check out the following sites..
This used to be a great resource for reversing discussions but has somewhat lost the plot in the last year or so. Still, many knowledgable people hang out here, and if you ask an intelligent question, youll usually get a good response. Of course, the old rule of Garbage In -> Garbage Out applies ;)
>"I've read many tutes, but some are to 'deep' to understand without help.
>"It's needed to follow a progressive knowledge on cracking, only achieved by a teacher."
This is the sort of mentality you should aim to avoid. As a cracker, its up to you to use the resources available and work off your own back. Although many ppl are available for help and guidance, no-one is going to be willing to tutor you on a one-to-one basis. This was originally a posting in the RevEnge Forum. Ive included my reply here because a few people found it useful.
Many tutes are rated from beginners to advanced to help form a sort of teaching curriculum in itself. If you dont understand a specific tute, most authors will usually be willing to explain a little more if you mail them nicely. If not, the messageboards are here. Quote specific parts which you fail to understand.
>"I need to be guided. There's a beginning, a middle and an end, that isn't so easy to find."
I agree there is a beginning with cracking. However, the middle and end are only defined by yourself :)
It might be helpful if I list the general set of progression steps I encourage newbies to take with cracking..
1) Follow plenty of tutes using w32dasm, learn how to disable standard cd checks, nag screens, serial checks etc.. Settle with a good hexeditor like ultraedit and hiew, and learn their functionality inside out.
Cracking is *not* about blindly swapping jne's to be je's. It is about combing over the code, understanding what it is doing, and then striking the specific weak point. Before following a tute, study the target yourself. Try to crack it without the tute, and then if you fail, refer to the tute to see where you went wrong, or what you missed. You can read a hundred tutes, but if you dont get your hands dirty, you'll learn very little.
2) Follow another bucketload of tutes, using SoftICE. Serial fishing, more nags, keyfiles etc..
Be familiar with your tools! Get a copy of the softice manual and read it thoroughly. Get a copy of ICEdump from Protools. Install and learn its use.
3) Time to get more acquainted with assembly language..
Code a few windows apps in masm/tasm. As a cracker, the Windows API is your freind. Learn it !!
Download Art of Assembly. Study the basic instructions and their subtleties. If you see an instruction in a target you dont understand, rather than skip over it hoping to get back ontrack, refer to AOA and learn the instruction before proceeding. Although it certainly helps, you dont need to know assembly inside and out in order to crack. If you have a working knowledge of the basic instruction set, you can study more obscure instructions as and when you encounter them. This is even perhaps a better way to learn the instruction set, than trying to digest all instructions at once.
4) Study various anti debugging tricks. Learn how to sidestep them, or even bluntly bludgeon them ;)
Get a copy of FrogsICE and ICEPatch from Protools, which will help you in this task. As from version 6.0.19, IceDump also provides good protection from anti-debug tricks.
5) Code your own protections in assembly and then reverse them. This is not as pointless as it sounds. Code protections in a high level language (such as C++) and study the disassembly, reverse these too. This will familiarise you with how certain high level languages compile certain cnstructs (such as case, switch etc..), and will give you better insight when reversing a target coded in a high level language.
6) PE Knowledge. Often overlooked by newbie crackers (and many more experienced ones!). The format of the PE is valuable knowledge and its in your interests to learn it well. This often provides insight into problems which could otherwise appear bizarre. Get PE format docs from my site
7) Aquire a copy of IDA. Learn how to use it (this will take time, time, time ;) Quine's web site should help you as will Mammons tutorial on setting up and using IDA. IDA is a FAR better disassembler than w32dasm. Due to the way it disassembles, it will often succeed to disassemble an app which chokes w32dasm. Also, IDA will take a DOS app to pieces, along with lots of other platforms. You do not need the *latest* version of IDA. I personally use 3.85b, and I have no real need to upgrade to the elusive version 4.00 ;)
8) Packed apps. Get and learn how to use Procdump. Download unpacking tutes from the same site and from Immortal Descendants Unpack several other non-tute apps using the same methods, widely available from your favorite shareware download site. Grab various packers from www.suddendischarge.com, pack some apps on your drive (notepad, calc whatever), and learn how to unpack these using the same methods. Keep a list of things youve tried to do but failed. From time to time refer to this and see if you can complete them with the extra knowledge youve picked up along the way.
9) Tsehp's (formerly +fravia's) site contains a huge wealth of knowledge. Download some intermediate and advanced tutes, and read them. Even if you dont understand the finer points of the advanced ones, you can still study the techniques being used.
By this time you should be adept enough to decide your own direction. You might decide to concentrate on areas you understand less in order to widen your horizons, or specialise in a set area of cracking (dongles, encryption etc). Although DOS is not as widely used, learning to crack DOS apps can also be a valuable exercise. When your assembly becomes more advanced, you might want to study virii source code. LOTS to be learnt here :)
This list isnt complete. Its just a brief guide to give you an general path of progression.
RegMon - Windows Registry Monitor. Used for spying to see calls to the windows registry. Useful for cracking time expiry apps which use the registry to store their expiration info. Get it from SysInternals
Hiew - The connosieurs choice of hex editor. Able to assemble/disassemble to a certain extent. Can be used for applying a patch manually to a file. Get it from Protools
FileMon - Monitors file access, filterable by task and/or operation. Very useful for keyfiles and preliminary checks on a new target. Get it from SysInternals
Windows API Reference - This is an absolute essential. For selecting a suitable breakpoint in a windows app, you need to be familiar with the various API which an app could be using. You will also need to be aware of the various parameters and conventions when it comes to actually reversing an apps behavior. Get it from Iczelions win32asm Page
ProcDump - Another absolute essential. Allows you to unpack a wide range of compressors in a semi-automated manner. Get it from The ProcDump Homepage
IceDump - A 'plugin' for SoftICE, allowing you to dump memory to disk. Also provides a huge range of other features, including a version of tetris inside softICE :-) Availble from The ICEDump Homepage
IDA - Interactive Disassembler by DataRescue. Simply THE best disassembler. Version 3.85B has now been released for FREE !! Available here from DataRescue
IDA Param Scripts - Version 4.15 of IDA introduces a nice feature which automatically identifies and annotates parameters of most Windows API calls. This feature isnt present in the free 3.85B version that DataRescuse have released. However, +spath has written an IDA script which implements the same functionality in earlier versions. Grab it from +Frogs Print's Site (Warning: This site is IE Hostile. Use a different browser!).
C/C++ Compiler - There are many times when youll want to write a program to aid you in your cracking. Whilst you can write anything in assembly language, for complex tasks you may prefer to use C. There are many free C compilers around, Borland recently released their v5.5 C++ compiler for free (get it here). Personally I use LCC, which is also freeware, with UltraEdit as my editor.
This is here purely for completeness sake. As a newbie, you dont necessarily need to understand the details of it yet, although it never harms to try.
In the early days of the 80x86 processor, operating systems such as DOS operated in real mode, whereby all processes shared the same address space. This had an inherent flaw that processes could overwrite each others memory and code with no real checking being done by the OS or processor. Since any address in real mode can formed using a segment (loaded into the segment register) and an offset from the start of that segment, a process could gain access to another processes state merely by loading the segment register with another value.
When it was introduced, the 80286 introduced another processor mode, called protected mode, allowing a larger physical address space to be accessed. When the 386 came along, Intel added support for paging and improved upon the 286's attempts at protected mode in many ways. Among other things, it allowed each task to have its own linear address space, of around 4 gigabytes. Of course, due to VM and paging, the machine obviously does not require 4G of physical RAM for this. Protected mode applies to all processes, the CPU is either running in protected mode for all processes, or it is not. Windows and the vast majority of other modern OS's kick the CPU into protected mode during the initialisation of the OS.
In protected mode, the segment registers no longer directly reference a segment in memory, as they do in real mode. In P/M, the value in the segment register is called a selector, and is used to retrieve information about the location of a segment from the Descriptor Tables, either global (GDT) or local (LDT). When you access a linear address in protected mode, you are actually providing an offset from the base of a segment in memory. The segments physical base in memory is looked up from the descriptor tables, and the offset is applied to this base. Since it appears to each task that it owns the entire 4G of address space, an address of (for example) 0x600000 means nothing unless we know exactly which task it is referring to. Put another way, the address needs to be in the context of a specific task for it to have any meaning.
If you break into SoftICE randomly using CTRL-D, you are most likely not going to luckily land in the address context of the task you are trying to attack. The segment registers may be loaded with a selector describing a different task, and therefore if you set a breakpoint on linear address 0x600000, winice sets the breakpoint in the current context, and not in the context of the task you want to break on. (You can see instantly which task SoftICE is currently referring to by looking to the bottom right of the status bar).
Put simply, always be aware of address contexts, and be sure SoftICE knows exactly which context you want it to refer to.
The PE (Portable Executable) is the name given to the format of executables (applications and dll's) written for Windows 95 and NT.
For C programmers, you can find definitions of the structures used when dealing directly with PE's in the header file WINNT.H.
Each PE comprises of a series of structures, and areas of binary data (or code), known as sections. Simplistically, these structures primarily tell the operating system how to load into memory, and execute the program, and how various sections within the PE 'image' can be accessed.
Knowledge of the PE format is very useful as a cracker. Its also very interesting, IMHO anyway ;) With PE compressors and cryptors becoming increasingly popular, it is more and more likely you will have to manipulate various areas of the PE's structure to crack a target. For newbie crackers, you can worry about this later, but if you're confident with your tools, and looking for a new direction in learning to crack, then read up on the PE.
You can find several documents (Pietrek, O'Leary, Microsoft) about the PE format from my site.
You should also read the excellent tute written by Neural_Noise, on PE manipulation of Notepad.
This question seems to be getting asked more and more in #cracking4newbies lately.
I believe Iczelion even wrote a little tool to do it, but I haven't seen this, and most archives of it
are corrupt. But its simple to do by hand.
Anyway, as I think its important (and of course interesting) to understand how it's done, and it's
quite time consuming to explain to newbies individually, I decided to write a naff little tute ;)
I'll demonstrate the process of converting between disk offsets and virtual addresses using Winzip
7.0, as it has properties in its sections which make it a good example for this task.
Imagine you're in SoftIce, and you decide you want to perform a disk patch of the address youre looking at.
Now, I have chosen a completely random address within WinZip. Lets say the instruction at..
0045ADEB 5B pop ebx
Ok, now we need a half decent PE editor, to view the section headers in our PE.
I have chosen to use ProcDump, mainly through habit ;)
Fire up ProcDump, and click on the PE Editor button.
Then select winzip32.exe from the resulting file dialog.
ProcDump now presents you with a brief summary of winzip's PE header.
Make a note of the image base, (this is the location where the PE should be loaded, and is
important in our calculations). In winzips case, the image base is unsurprisingly, 400000h.
Now click on the sections button, we'll take a look at the section headers within the PE.
This brings up a dialog showing the various properties of each section.
We are interested in the .text section, since this is where our code is located.
Amongst other things, ProcDump shows us the following information about the .text section..
.text Virtual offset=1000h Raw Offset=400h
Now we have all the information we need to convert our virtual address to the corresponding
offset in the executable on disk.
Taking our address of 45ADEBh, we first want to calculate how far into the code section
this instruction lies. We can do this by subtracting both the imagebase and the virtual
offset of the code section, from our virtual address.
So 45ADEBh - 400000h - 1000h = 59DEBh
So we now know that our instruction lies 59DEBh bytes into the code section.
ProcDump tells us that the code section starts at byte 400h (raw offset) in the exe file,
on disk. So by adding this value onto our previous result, we can calculate the disk
offset of our instruction.
59DEBh + 400h = 5A1EBh
So there we have it. Open winzip32.exe in any hexeditor, go to offset 5A1EBh, and
there you will see the opcode of our instruction (5B).
If you try this on your target, but the opcodes still dont match what you see in SoftICE,
it tends to suggest the target is either packed or crypted. Your options are then to unpack,
decrypt or to write an in memory process patcher (a loader).
If you still dont understand, or just want more explanation, please feel free to approach
me in #cracking4newbies.
If you've written a tute, you can distribute it to like minded reversers, by sending it to the RE Knowledge Mailing List. This is a list I set up to help lubricate the flow of reversing knowledge without spending hours trawling the web.
A Visual Basic 5/6 annotated disassembler (josephco@..hotmail.com) http://members.xoom.com/c4n4ever/.space/c4nexdec.zip
Written by josephCo. Currently in very early beta testing. Mail him with bugs, or suggestions.
type !exdec in #cracking4newbies to recieve the latest version.
A PalmPilot resource editor, disassembler and debugger (carpathia_uk@..mail.com) http://palmdemon.cjb.net
Written by Carpathia. Please mail him if you can supply any info about the format of prc x-refs section, or if you want to beta test.
A disassembler takes a code module (.exe, .dll, .vxd etc), and analyses it to produce an assembly listing,
regardless of the language the module was written in. This disassembly can be studied, and with a good
disassembler, the representation of it can be modified (ie, rename variables, stack params etc in IDA).
A pure disassembler, will not allow you to execute the code step by step, or see any of the program
internals in a live state. For this reason, a disassembly listing is sometimes called a dead-listing.
A decompiler takes a code module, and attempts to produce an equivalent listing in a high level langauge.
Note that for most high level languages, an exact or accurate representation is impossible to produce.
Decompilers for languages which compile to native code, (such as C,C++ etc) are generally not used in cracking.
The reasons for this is that they are usually too inaccurate, and a disassembly listing provides a far better
solution to studying the target.
Decompilers are used for languages which compile to p-code (pseudo-code). Such examples are some
Visual Basic apps, Installshield scripts, and various macro languages.
A debugger allows you to break execution of a program, and step through the code instruction by instruction.
Debuggers come in all different flavors: Most modern programming languages come with an integrated debugger,
which allows you to view the code in the same programming language as it is written in. To do this, the debugger
uses the source code files, and debug info which is compiled into the executable. As a cracker, you will rarely
have access to either of these.
What interests us, is an assembly level debugger, for which we need neither source code nor debug info. SoftICE can be
used as an assembly level debugger.
In addition to tracing through the code, a debugger allows you to view virtually any aspect of the internal contect of
the target. You can view and change areas of memory and assemble and execute code on the fly.
One of the most useful features of SoftICE is the range of breakpointing mechanisms it provides. You can break on a whole
range of conditions, such as when a particular address or function is executed, when a certain memory address is read,
or written to, and when a certain windows control handles a specific windows message. Theres several other ways to set
breakpoints in SoftICE. I cant stress how important it is to be familiar with these. Read The Manual !!
Contrary to what a lot of newbies initially think, a hex editor generally doesnt allow you to do anything other than
modify the disk image of a target. Unless you are unpacking a target, or modifying the PE structure, you generally
dont use a hex editor until you have disassembled or debugged your target, and have already decided the location which
Popular hex editors include hiew (which includes a built in assembler/disassembler), hex workshop, and ultraedit. I
personally use a mix of hiew and ultraedit.
A packed target is simply one that has been compressed with a packer. PE Compressors pack the given executable, and then
wrap unpacking code around this compressed data. When the program is executed, the unpacking code (or loader, as its more
commonly referred to) unpacks the compressed data into memory. It then jumps to the OEP (original entry point) of the exe,
in memory, and the program runs as normal.
The benefits of packing an exe are obviously that the size of it is usually significantly less. But more commonly, packers
are used as a form of anti-cracking. Packed targets cannot be disassembled until they are unpacked. While tools exist for a
whole range of popular packers, we are increasingly seeing more packers which must be unpacked by hand, or at least in a semiautomated way.
For this, Procdump is a great tool. It allows you to wait until a target has unpacked itself into memory, and then procdump will allow you
to dump the unpacked memory to disk. After this, you can repair any lost PE structure by hand, and end up with an unpacked target, which
you can then disassemble.
Modern packers which concentrate on anticracking protection, often include antidebug measures, and encyrption, to attempt to prevent you tracing through the
loader code. Packers such as AsProtect encrypt the exe in such a way that the import tables are not immediately recoverable, even after dumping.
Also includes measures such as copying windows API code into memory, to prevent debuggers such as Softice from breaking on key API breakpoints.
Although AsProtect is possibly the most advanced packer we have to face today, as always, there are still ways to defeat it ;-)
Patching is the process of modifying the image of a particular target (usually on disk). It's generally the quickest way to remove mundanely simple
protections, and generally doesnt involve any real expertise other than understanding assembly language.
Whilst good for newbies during learning, patching is generally a bad way to crack a target. It is inelegant (patching can be easily detected by the app),
unsafe (because you are changing the exe itself, it may have side effects that are not immediately apparent. Also one patch may lead to many more patches,
just to avoid being detected, or because their are multiple checks). Finally, patching is typically incompatible with future versions (as the binary image for
different builds will change, the patch offset wont be the same for each version. This can potentially be avoided by searching for a string of opcode bytes,
instead of patching at a hardcoded offset, but then it only takes a subtle change in the authors algorithm to break even this patch, whereas a valid serial
would still commonly be usable in future versions). Patching can also be done in memory, by use of a loader.
A loader is the term given to any entity which is responsible for preparing and launching a process. When you launch any application in windows,
the windows loader reads the disk image of the app, parses the structure of it, prepares it into memory, and then passes control to the processes entrypoint.
In cracking terms, a loader is more commonly used to describe a program which performs a memory patch of an application, in order to remove the protection.
This technique could be used for several reasons, perhaps the application cannot be registered elegantly via a serial/keyfile, and is compressed or encrypted and a disk patch cannot be made.
The loader launches the target, waits for a delay or predetermined condition to occur, and then applies a patch to the processes code. Memory patchers / loaders are made simple thanks to the
ReadProcessMemory / WriteProcessmemory Windows API's.
ALL tools and tutorials can be found by searching the web, and from the download sites in the tools section.
If youre looking for a pre-made crack, try the search engine at astalavista or #Cracks.
If you still cant find it, please do NOT ask us, because we are not interested in spreading cracks.
If you have suggestions or errata for this FAQ, please contact Carpathia or Thesmurf.
I generally update this document at least once a week, and I have *many* things I want to add when I get the time.
Thanks to Lazarus and Kwazy Webbit for feedback and suggestions :)
Created and maintained by Carpathia
Last updated 31st March 2001
ome idiot flaming you. Crack requests are still a nono.