Have you ever wanted to crack a program? Have you ever pirated an application that contained a crack with it? Ever wondered what happens when an application is run? If you're reading this, the answer to one of those is probably yes. I'm hoping to start slow with some intro tutorials, then work my way up to showing you how to crack current applications (or at least mimic the protections used).
First, let's answer some questions about assembly, cracking, and reversing. Afterwards some brief descriptions of things we're going to see within the debugger.
I saw a tutorial online that said "crack any software." How come you're not showing that?
Those videos only implement string checks (which is my first tutorial). They're using click bait titles to get you to watch. Any video without dialog but with loud, annoying trance music shouldn't be worth your time.
What program(s) do you use?
A combo of x32dbg/x64dbg, Ollydbg, Immunity Debugger, IDA for Windows; dnSpy, dotPeek, .net Reflector for .Net applications; GDB for Linux; CFF Explorer, Lord PE, PEBrowse32/64 for PE Editors; ResHacker, Hex Workshop, 010 Editor for hex and text editing.. It all depends on the application I'm reversing and type of binary it is. I don't do much kernel debugging, so I don't really use Windbg although it's a powerful tool.
I heard that X cracking group uses a specific program. Shouldn't I be using that too?
This is similar to most anything in life. There's never a single tool to do the job. The best crackers will use multiple tools depending on what they're trying to achieve.
You didn't explain X in one of your tutorials OR you explained X wrong.
Please feel free to reach out to me on my contact form if you feel that I need more detail for a specific tutorial or stated something incorrectly. Most tutorials will be in Windows, but I'll try to through some Linux GDB for good measure.
Do I need to learn assembly?
This all depends how deep you would like your understanding of reversing to go. You might be able to follow most tutorials, but without a deeper understanding of what's going on, you're only going to be cracking simple applications.
For a deeper understanding of assembly and reversing I highly recommend:
-Reversing: Secrets of Reverse Engineering
-Reverse Engineering for Beginners
-Introductory Intel x86: Architecture, Assembly, Applications, & Alliteration
-Lena's tutorials - Assumes a basic understanding of assembly
What exactly is the difference between cracking, reversing, patching, and keygenning?
Cracking is the art of modifying or altering software usually in a way that benefits the person using the application. Some cases may be to register something illegally (pirating), disable DRM, or modification of software. Reversing does not necessarily need to include cracking and is more of a way to figure out what is going on with software or hardware. Reversing can include figuring out what an out-of-date piece of hardware does and how to change it so that it works with newer technology. Patching is the actual alteration of software. Where a program may say to jump to a specific location in the program or memory, you can force the application to jump to a different location or not take a jump (usually goes hand-in-hand with cracking). Keygenning is similar to cracking with the addition of an external or in-line way to generate a key or serial the same way that the application does.
Can you crack X for me or put up a tutorial for it?
I don't take requests. The reversing portion of my site is geared toward user-generated code, crackmes, reversemes, and keygenmes. I may through in an actual application but only if it's defunct and/or I have approval from the vendor. Although what is taught or my site and other reverse engineering sites may be applied to current applications.
Inside of the debuggers there are some shortcuts that we'll be using and terms and sections that you should know:
Spacebar = open the assembly option so that you can change the instruction
F2 = put a breakpoint on a line of code within the program - stops the program from moving forward once it's hit
F7 = step into - runs the next line of code including a call to another function
F8 = step over - skips over calls to functions
"Goodboy" and "badboy" = Short names for the correct and incorrect password, dialog box, function, or password prompt
The top-left section holds the virtual addresses (memory locations), OPcodes, our human-readable code, and comments put in by the debugger. Our registers are found in the top-right section. The stack at the bottom-right (where our PUSH and POP values come into play). The dump window is displayed at the bottom-left and may look familiar if you've ever used a hex edit before.
This tutorial will address the most basic version of reversing available and that's through a string or text search. This is what makes up a lot of the tutorials you find on Youtube with titles such as "crack any program." The truth is, you'll be hard-pressed to find this in the wild anymore. For this tutorial, the programs Easy1Cplus.exe and Easy1noOP.exe were created using C++ 2008 Express but with C and C++ code optimizations (source at the end). I'll show 2 different versions from Immunity so that you can see how the debugger is affected by compiler optimizations.
Using Easy1Cplus.exe, the first thing I like to do is check to see if the program is obfuscated or packed. I use both PEiD and Die (Detect-It-Easy). In PEiD we can see that the application detects C++ 2008. In Die, the entropy line correlates to a default application without obfuscation. We can also see that Die displays "not packed" for this application.
The first thing we always do is test the application. We receive a password string and a way to enter the serial number. Next, we take a look at the application in Immunity. We see that there is an immediate "Module 'Easy1Cpl' has entry point outside the code. You'll see this on a lot of Microsoft applications produce that message. The application believes this might be a packed executable but from our previous checking we know this isn't the case. So now we're presented with a bunch of code and we'll see why as soon as we get into the program's instructions. What we now see is assembly code and the closest a human can get to those 1s and 0s. Each instruction displays how the debugger translates the compiled code. In here we can see that we're stopped at a location inside ntdll.dll. This is a kernel space function and will load all the functions that allow our program to run. If we were to step through the entirety of its functions we would eventually hit our application. But because nobody has time for that, we're going to hit play and stop inside our application. Here's the reason why Immunity thought we were outside of our code. We're starting at mainCRTStartup instead of the main function. mainCRTStartup is the entry point for the runtime library while main is the entry point of our code. Looking down a bit we can see a jump to main. We'll add a breakpoint and hit play (disregard breakpoint messages if you receive them).
We're now at the beginning of our code. In assembly, it's always a PUSH EBP instruction. This pushes the location of EBP onto the stack so that when the application completes and returns control back to the operating system and the processor knows where to return to (POPs off). This is an entry level tutorial, so I'll dive into what's going on with each instruction when I explain assembly in more detail at a later date.
While inside the application we can see calls, stack pushing, moves, exclusive-ORs, load effective addresses, adding, and other functions. At the moment we're serial phishing and only interested in immediate strings and variables we can find. There's a few calls to the MSVCP90D.dll and a few ASCII strings. One of which is a "Please enter the password:" string and the other a random bunch of numbers and letters. Scrolling down we can see our goodboy and badboy text. And at this point we're actually done. Since it's a basic string phishing tutorial, we can grab the alphanumeric string and enter it into our program. When we do we see that the program registers successfully with the "correct password" message.
We can also pull the password another way. While in our program (check the title bar to make sure you've hit play and aren't in ntdll), right-click inside our code section, select Search For, then All referenced text strings. In the strings window the ASCII text is displayed and once again we find our password. There is also a new string: '%s'. We'll see this often when reversing and especially throughout IDA. The debugger was able to figure out that the application is looking for a string value as an answer.
The first method is to adjust the jump so that it always hits the correct password string. At 012A1037 (your virtual address will be different) we see the TEST instruction after the _strcmp (string compare) function. This tells us that we're testing to see if what we put into the string matches what the program is looking for. If it is, we jump to the goodboy, if not the badboy is hit. We put a breakpoint at the TEST address, play, and enter a password of "123."