Ollydbg Cracking Tutorial

Ollydbg Cracking Tutorial Average ratng: 4,8/5 4128 votes

OllyDbg has many context menus. You can right-click on almost anything in OllyDbg to get a context menu to examine your many debugging options. Reversing with Olly. With our tour of Olly behind us, we are now ready to start doing some real work: reversing and cracking a “trial” piece of software. OllyDbg is a 32-bit assembler level analysing debugger for Microsoft ® Windows ®. Emphasis on binary code analysis makes it particularly useful in cases where source is unavailable. OllyDbg is a shareware, but you can download and use it for free.

  1. Ollydbg Cracking Tutorial 2017
  2. Ollydbg Download
  3. Ollydbg Tutorial Pdf
  4. Ollydbg Tutorial Beginners
  5. Ollydbg Cracking Tutorial
  6. Ollydbg Cracking Tutorial 64bit
  7. Ollydbg Cracking Tutorial Pdf
28 Oct 2014CPOL

In this tutorial, we will look at one of the most widely used and free debuggers, OllyDbg. OllyDbg is a general purpose Win32 user-land debugger. It has an easy-to-use and fairly intuitive GUI making it a relatively quick study. Although OllyDbg is free, it is NOT open source as we do not have access to the source code. Downloaded 'snd-reversingwithlena-tutorials.rar' which is the 'reversing for newbies- complete' from that website. I'm on Windows 8 and windows defender is throwing up a bit of hissy fit when I extracted it.

The objective of writing this paper is to manifest, how to crack an executable without peeping its source code by exercising OllyDbg tool.

Abstract

The objective of writing this paper is to manifest, how to crack an executable without peeping its source code by exercising OllyDbg tool. Although, there are much of tools that can achieve the same objective but the beauty behind OllyDbg is that, it is simple to operate and freely available. We have already done much of reversing of .NET application earlier. This time, we are confronting with an application which origin is unknown altogether. Sccm software inventory not running. In simple term, what we are implying that we don’t have the actual source code indeed. We just have only the executable version of a particular application which is in fact, a tedious task in context of Reverse Engineering.

Essentials

The security researcher must have rigorous knowledge of Assembly Programming language. It is expected that their machine must be configured with the following tools;

  • OllyDbg
  • Assembly Programming knowledge
  • CFF explorer

Patching Native Binaries

When the source code is not provided, it is still possible to patch the corresponding software binaries in order to remove various security restrictions imposed by vendor as well as fix the inherent bugs in the source code. A familiar type of restriction built into software is copy protection which is normally forced by software vendor in order to test the robustness of software copy protection sachem. Typically in copy protection, the user is obligatory to register first for the product before use. The vendor stipulates a time restrictions condition over the beta software in order to be license misuse and permitting the product to run only in a reduced-functionality mode until the user registers.

Executable Software

The following sample shoes a way, how to bypass or remove the copy protection sachem in order to use the product without extending the trail duration or in fact, without purchasing the full version. The copy protection mechanism often involves a process in which the software checks whether it should run and, if should, which functionality should be exposed.

One type of copy protection common in trail or beta software, allows a program to run only until a certain date. In order to explain reverse engineering, we have downloaded the beta version of software from internet which is operative till 30 days. As you can see, the following trail software application is expired and not working further and showing an error message when we try to execute it.

We don’t know, in which programming language or under which platform this software is developed. So, the first task is to identify its origin. We can engage CFF explorer, which display some significant information such as this software is developed by using VC++ language as following.

So, we can easily conclude that this is a native executable and it is not executing under CLR. We can’t use ILDASM or Reflector in order to analyze its opcodes. This time, we have to elect some different approach to crack the native executable.

Dissembling with OllyDbg

When we attempt to load SoftwareExpiration.exe file, it will refuse to run because the current date is past the date on which the authorized trial expired. How can we use this software regardless of the expiration of the trail period? The following section illustrates the steps in the context of removing the copy protection restriction as;

The Roadmap

  • Load the expired program in order to understand what is happening behind the scene.
  • Debug this program into OllyDbg.
  • Trace the code backward to identify the code path.
  • Modify the binary to force all code paths to succeed and to never hit the trail expiration code path again.
  • Test the modifications.

Such tasks however, can also be accomplished by one of the powerful tool IDA pro but it is commercialized and not available freely. OllyDbg is not as powerful like as IDA pro but useful in some scenario. First thing first, download OllyDbg from its official website and configure it properly onto your machine. It looks like as following;

Now open the SoftwareExpiration.exe program in OllyDbg IDE from File à open menu and it will decompile that binary file. Don’t afraid with the bizarre assembly code because all the modifications are performed in the native assembly code.

Here, the red box showing, the entry point instructions of the program referred to as 00401204. The CPU main thread window displaying the software code in form of assembly instructions which are executed top to down fashion. That is why as we stated earlier, assembly programming knowledge is necessary when reversing with native executable.

Unfortunately, we don’t have the actual source code so how we inspect the assembly code. Here the error message “Sorry, this trail software has expired” might help us to get rid of this problem because by help of this error message, we can identify the actual code path that lead to occur this message.

While the error dialog box is still displayed, start debugging by pressing F9 or from Debug menu. Now, you can find the time limit code. Next press F12 in order to pause the code execution so that we could find the code that causes the error message to be displayed.

Ok. Now view the call stack by pressing the Alt+ K. Here, you can easily figure out that the trail error text is a parameter to MessageBoxA as following;

Select the USER32.MessageBoxA near the bottom of the call stack and right click and choose show call as following;

It shows the starting point in which the assembly call to MessageBoxA is selected. Notice that the greater symbol (>) next to some of the lines of code which indicates another line of code jumps to that location. Directly before the call to MessageBoxA (in red color right-pane), four parameters are pushed onto the stack. Here the PUSH 10 instruction contains the > sign which is referenced by another line of code.

Select the PUSH 10 instruction located at 004011C0 address, the line of code that reference the selected line are displayed in the text area below the top pane in the CPU windows as following;

Select the text area code in the above figure and right click to open the shortcut menu. It allow you to easily navigate to code that refers to a selected line of code as shown;

Up till now, we have identified the actual line code that is responsible for producing the error message. Now it is time to do some modification in the binary code. The context menu in the previous figure shows that both 00401055 and 00401063 contains JA (jump above) to the PUSH 10 used for message box.

So, first select the Go to JA 00401055 from the context menu. You should now be on code at location 0x00401055. Your ultimate objective is to prevent the program from hitting the error code path. So this can be accomplished by changing the JA instruction to NOP (no operation) which actually do nothing. Right click the 0x00401055 instruction inside the CPU window and select binary where click over Fill with NOPs as following;

Waptrick music download 2018. This operation fills all the corresponding instruction for 0x00401055 with NOPs as following.

Go back to PUSH 10 by pressing hyphen (~) and repeat the previous process for the instruction 0x00401063 as following;

Now save the modifications by right clicking in the CPU windows. Clicking Copy to Executable, and then clicking All Modifications. Then hit the Copy all button in the next occur dialog box as shown below;

Right after hitting the Copy all button, a new window will appear named SoftwareExpiration.exe. Here, right-click in this window and choose Save File as following.

Finally, save the modified or patched binary with new name. Now load the modified program, you can that no expiration error message is shown. We successfully defeated the expiration trail period restriction.

Final Note

This article demonstrates one way to challenge the strength of the copy protection measure using OllyDbg and identify ways to make your software more secure against unauthorized consumption. By attempting to defeat the copy protection of your application, we can learn a great deal about how roust the protection mechanism. By doing this testing before the product become publically available, we can modify the code to make circumvent of copy protection more sophisticated before its release.

Well, I originally did a video on this last night, but on my internet, uploading wasn’t going to happen. So, since three (four?) people requested that I post something like this; I’ll give it a shot. This is a simple introduction to the program OllyDBG. (Also known as Olly Debugger, and, as I like to call it; Olly).
Edit: Added three more 'Crack Me' applications for you guys to mess with/learn with. Check attachments for extra_crackmes.rar
Edit 2: Added a quick video on solving 'Crack Me's 3, 4, and 5. Check the bottom of the post.

First of all, a question many people ask is: What is Olly? The answer is simple, really. Olly is an x86, 32bit debugger originally intended for developers who had problematic errors in their applications. It allowed them to go through their application step-by-step, monitoring most every action that the application took. And by doing so, this allowed them to find where the error actually happened in real-time, and made it much easier for them to fix it. Now you may be wondering, what does Olly have to do with you, then? Well, it has quite a lot to do with you, actually. Aside from the basics of the debugger, it is more widely used for the purposes of reverse engineering. The act of being able to walk through a program step-by-step makes it enormously easier to find things that normally you couldn’t (or rather, had a very hard time finding.) And at the same time, it allows us to go to things like conditional statements, and either change the condition, or change the whole statement, all in real-time without even having to recompile or restart the application.
So, first things first, let’s take a look at the interface, keeping in mind that I am using OllyDBG v2.01 Alpha 4. At the top portion of Olly, we have a long line of horizontal buttons that will save us having to even use the menus for the majority of the time. Let’s go ahead and take a second to give a brief explanation as to what each of these buttons does.
1. This is the Open button. As you’ve probably already guessed, it opens a file into Olly.
2. This is the Restart button. Fairly obvious, it restarts our executable.
3. This is the Close button. It closes down the executable we’re working with so we can load a new one.
4. This is the Run button. It starts our executable, so we can begin stepping through/analyzing it.
5. This is the Run Thread button. It does the same as above, but only runs the current thread.
6. This is the Pause button. It pauses out executable so we can look around or do other things.
7. This is the Step Into

Ollydbg Cracking Tutorial 2017

button. It steps down into the next line, or enters the current function.
8. This is the Step Over button. It does the same as above, but executes the function all at once, instead of going into it and stepping through each action.
9. This is the Trace Into button. Same premise as the Step Into button, but works with our run trace.
10. This is the Trace Over button. Same premise as the Step Over button, but works with our run trace.
11. This is the Execute Until Return button. It will keep stepping into the application until it hits a return, either from a function, or the application itself.
12. This is the Execute Until User Code button. It will keep stepping into the application until it hits code that is not part of the system functions.
(The following are windows.)
13. This is the Logger window. Pretty self-explanatory.
14. This is the Executable Modules window. This is very useful for switching to which portion of the application and/or its extensions/libraries you want to look through.
15. This is the Memory Map window. We can use this to find something specific in the memory space of the application. This is a good way to find the un-packed data inside a packed application.
16. This is the Window List. It usually shows us a list of window handles owned by our application. Also very useful.
17. This is the Threads window. This allows us to see and select which thread we want to work with, amongst other things.
18. This is the CPU window. This is where the core of the application is shown: the code. This is usually shown in Assembly code, and this is where we will do most of our work. In this window we can do anything from monitor the actions the application takes, to changing what the application will do next in real-time.
19. This is the Search Results window. Pretty self-explanatory.
20. This is the Run Trace window. This will be more useful later on, and is very helpful for tracing changed in certain things.
21. This is the Breakpoints window. This gives us a list of the breakpoints we currently have set, so we can just double click then to jump straight to that location in the memory. Very useful.
22. This is the Memory Breakpoints window. Pretty self-explanatory.
23. This is the Hardware Breakpoints window. Pretty self-explanatory.
24. This is the Options window. We can change lots of things related to Olly in here, including colors.
That’s it for our basic run-down of the buttons, and those will likely be the only buttons you need for now. So, let’s take a look at actually using Olly. With this thread, I have included two very simple “Crack Me” applications, which were coded in C++ (So they’re very easy to step through.) What I will do now is walk you through how to solve each of the three applications. So, let’s start with the first one. Granted you downloaded the archive and unpacked it already, go ahead and open up crackme01.exe in Olly. You should get something like this once it is done loading: (Ignoring the fact my colors are different.)
Notice that in the bottom right corner, our status indicator says that the application is Paused? That’s the default for when you open an application in Olly. It will not run automatically, but rather pause and wait for input. That’s okay most of the time, since we don’t always need to run it yet.
However, let’s take a shot at it first. Go ahead and click your Run button to run the application, and once it is done loading, the application’s window should look like this:
As with most “Crack Me” applications, it is requesting a password. Let’s go ahead and type a random password, testing should work for now.
Looks like that wasn’t the password, right? So now you’re probably wondering how we go about finding the right password. That’s one of the simplest things to do with Olly, so let’s go ahead and try. First things first, use the Restart button to restart the application. Once it is done loading again, look at your CPU window. One of the first things we always want to do to make sure things are accurate, is make sure that the code has been re-analyzed. To do so, we right click our CPU window (inner top-left pane) and go to Analysis > Analyze code (or you can press CTRL + A.) Once you’ve done that, right click again, but this time go to Search for > All referenced strings. (In older versions, it should be All referenced text strings.) You should get a window that looks like this:
Now, we can ignore those strings up top, because those are just part of the internals. (I compiled the “Crack Me” applications in a CygWin environment.) But look at the strings on the bottom, aren’t those the same as what is shown in the console window? Right, that means that these are the strings stored inside the application. Note that a string does not have to be stored in a variable for it to show up here, so even if you had something like The string TheRealDeal would still show up in this window, because these are referenced strings, meaning any explicit string that is accessed inside our application (they’re stored in the memory.)
Anyway, let’s take a look at this list. Doesn’t something stick out to you? There’s one line that is not output to the console, and it’s all by itself. That line is ASCII “elitepvpers”. The fact that it’s alone by itself means that it is either stored in its own variable, or is accessed in a comparison or the likes. So, if we’re thinking the way we should be, we should know that that is a likely candidate for the password! Let’s go ahead and try and use elitepvpers as the password.
Wow, looks like we solved it! That wasn’t so hard, was it? It’s not often that things are that simple, but it’s not completely out of the equation either. More often than not, the information that we need to continue is right in front of our faces. So, let’s take a look at another method of bypassing simple checks. Let’s go ahead and Close this one and load up the second “Crack Me”, by loading crackme02.exe into Olly. Once we’ve loaded it up, let’s go ahead and Run it.
It looks like this one is going to be slightly more difficult. Not only does it say it has two checks, but it also states that it will not work the same way. By taking a look at the console, we see that this time it is asking us for a username and not a password. Now, if you’re thinking like you should be, you should think that this means given the fact there are supposedly two checks, it wants a username and password. Let’s go ahead and try a random username.
Wow, that didn’t go very far, did it. So we know that if there really are two checks, it checks the username before even taking us to the password, which is slightly more difficult. But not only that, there was mention that it did not work in the same way as the first one. So, let’s go ahead and restart the application, and once it is done, make sure we analyze the code with CTRL + A, and go to Search for > All referenced strings. As the window comes up, we have a little more data than last time.
Now the first things you should see are Administrator and HardToGuessPassword. These very well could be the username and password, but above them we see “You’re looking in the wrong place.” Seems like that’s a hint left for us, doesn’t it. In any case, let’s go ahead and try the username and password anyway.
Obviously it wasn’t a bluff. So, what do we do now? Well, first let’s restart the application. Now, let’s go ahead and learn a second method for bypassing things like this. Go ahead and go back to Search for > All referenced strings. Notice that first of all, there are two “Sorry, you failed.” strings, but only one “Congratulations, you passed!” string. This confirms that: there are two checks, and; you can only pass if you get both right. So, go ahead and double click the first “Sorry, you failed.” string. This will take us to the address that it is referenced at.
Well now, look at that. Right above our failure message we have a jump. What a jump does is it jumps to a certain address in the memory, going right over and ignoring any code in-between the two points. In this case it’s a JE SHORT. First, we look at the JE, what does that mean? Basically, it translates to Jump if Equal. (The opposite being JNE: Jump if Not Equal) So, if the condition in the line before (above) the jump is met, we will take the jump to the address of 0x0040135C, and if not, we will go to the line after (below) the jump. The SHORT simply means that the jump address (target) is within the range of -128 to 127, meaning that it’s either within 128 addresses backwards (up), or 127 addresses forwards (down).
So, let’s take a look at the condition above the jump: TEST BL,BL. That’s basically another way of saying CMP BL,0 (or in other words, Compare BL with 0, or if (BL 0)). Let’s go ahead and click the line TEST BL,BL and hit the F2 key to set a breakpoint at that address. Doing so will cause the application to pause and notify us when it gets to that point. So, once our breakpoint is set, let’s run our application and enter a random username. We should now be at this point after entering the username.
Notice in the small box in the middle (vertically) we see BL=01, which tells us that BL equals 1. Knowing that TEST BL,BL basically tests to see if BL equals 0, we know that the jump will not be taken. This means that instead, we will go over it, and land on the message “Sorry, you failed.” So, what can we do? We can actually do many things: NOP the test line; change it to something like CMP BL,1; change the address of the jump to the address of the success message or the password check; or we can simply change the value of BL. Let’s go with that method, and go over to the top-right box. We see the register list, which looks like this.
Right now we only need to pay attention to our main registers: EAX, EBX, ECX, EDX. EAX contains the registers AL (A Lower), AH

Ollydbg Download

(A higher), and AX (A Lower & A Higher). AL and AH are both 4 bit registers (two bytes.) AX, the combination of AH and AL is an 8bit register (four bytes.) The same applies to EBX ,ECX, and EDX, but it’s B, C, or D instead of A. So with this in mind, let’s go ahead and

Ollydbg Tutorial Pdf

double click the EBX register (double click the numbers, in this case: 00000001). We should now see this.
We know that we want to change the value of BL, so let’s go ahead and change the 01 to 00. This will apply the changes to the other boxes, so don’t worry about them. Now, go ahead and click OK, and then Run

Ollydbg Tutorial Beginners

the application. We should know be prompted for the password. Go ahead and enter anything.

Ollydbg Cracking Tutorial

Well, would you look at that, we passed! Wasn’t that hard either, was it? This is yet another example of just how useful Olly can be, and yet these are just the basics of what it can truly do.

Ollydbg Cracking Tutorial 64bit


I hope that you’ve learned something from this, and I hope that you now feel more confident in learning to use Olly. You should feel comfortable welcoming Olly into your reservoir of tools, as now you know just how useful it really is. I hope that you continue to learn to use it better, as it really will benefit you down the road.

Ollydbg Cracking Tutorial Pdf


Edit: Here's a quick video walkthrough for solving 'Crack Me' applications 3, 4, and 5. (I got an email asking if they were solvable at all, when they're bloody easy.)Make sure to watch it in HD and FULLSCREEN

I may or may not write more “Crack Me” applications down the road for you to mess with, but for now my time is limited. In any case, I hope you liked the short tutorial.