Monthly Archives: September 2015

Basic Keygen Creation Process

Ever wondered how a keygen works? You have probably used keygens at least once before, so I am sure you are curious as to what happens under the hood. Here is a simple tutorial on how to obtain a valid name an keypair using a debugger. I will be using a really old crackme from 2005, which you can download from here.

So first, lets look at the instructions:


When we first run the crackme program, there is a pop-up message which is quite irritating. Let us load the binary in a debugger and patch the pop-up.


Once loaded in the debugger, the obvious way to remove the irritating pop-up is to patch the call instruction at ‘0040104A’ to NOPs. However, for this crackme program, simply patching that address does not work.


This is because the instructions at ‘00401037’ reverts the NOPs that we have placed at ‘0040104A’. In order to quickly bypass this protection check, we can simply replace the call instruction at ‘00401037’ to NOPs. Save the executable and run it. You should notice that the pop-up message box is no longer appearing.


From here, you should notice that clicking the ‘Check’ button closes the application immediately. What we need to do now is find out where the button’s click event is handled. We could add the following breakpoint:


After that is set, proceed to click on the button. The binary execution should pause and hit the breakpoint at ‘0040113E’.


Proceed to step through the instructions one by one you will reach a point where an access violation occurs, which causes the program to crash at address ‘004015C2’ as shown in the snapshot below.


If we backtrack from this location, we could avoid this access violation by simply patching the call instruction at ‘00401449’ with NOPs as shown below. Proceed to save the changes and re-run the executable. Clicking the button now should no longer crash.


From here, we can start the process of obtaining the name and key pair. For my case I chose the string ‘v00d00sec’. However, it still did not work. I realised why it did not worked as the algorithm checks the that the length of the name must not be lesser than 5 characters and not greater than 8 characters (CMP EAX,5 and CMP EAX,8). So, I chose ‘v00d00’ instead.


Now that we know what is going on, we can proceed to step through the instructions and see what is happening. It takes a bit of trial and error, but you will soon realise that the address at which the full key is generated is at address ‘00401373’.


So there we have it, the password for the username ‘v00d00’ is ‘Q]-CWUAB-DEf’!


Manually Adding Shellcode to Windows Executables

Here is a short and simple proof-of-concept tutorial on how you can manually add shellcode to common Windows executables, without using msfconsole or the backdoor-factory scripts to generate the binaries. In this example, we will be using putty.exe, downloaded from: here.

Firstly, add a new code section to the executable using a PE editor such as LordPE. Remember to allocate enough space. In the example below, a size of 1000 bytes is allocated to the .NewSec section. Save the modified binary and try running it. You should get an error and the application crashes.


Next, open the modified binary in a hex editor and allocate the ‘1000’ byte value at the end of the file. Save the binary, and you should notice that the application now runs as per normal.


The binary is now ready for ‘backdoor code insertion’. Open the binary in a debugger such as OllyDBG or Immunity, whichever is your preference. Notice the first 5 instructions in the application:


Copy and paste the instructions somewhere, as we will need to refer to this later.

In the debugger, open the ‘memory view’ to view the address of ‘.NewSec’, which we added in the earlier steps. In this case the starting address to the section we created earlier is @ memory address ‘00484000’. We want the code execution of the binary to jump to this address, as this is where we will be placing our shellcode.


Now that we got the starting address of our new code section, we can proceed to modify the instructions. Modify the first instruction of the application to ‘JMP 00484000’.


Double-click the newly modified instruction to move to the ‘.NewSec’ section. You should see a lot of ‘free’ space.


Next, we proceed to add 2 instructions, PUSHAD, PUSHFD to ‘preserve’ the current registers and flags.


Now that we have push the current registers to the stack, we can start adding the shellcode from address ‘00484002’ onwards. The shellcode can be generated using msfpayload. Paste the shellcode as ‘binary paste’ in the debugger from address ‘00484002’ and you are all set. Note the ESP address when the binary execution is at address ‘00484002’. In the below case, it is pointing to ‘0012FF68’. We will need this address to re-align the ESP register to its original position later.


The addresses will vary depending on what shellcode you decided to use. Next, you have to manually step through the pasted code to see which line actually spawns the shell. Opening a netcat listener will greatly help to determine this, and it is usually at a ‘CALL’ instruction. In the below case, the shell is spawned after the ‘CALL EBP’ instruction at the memory address ‘0048411B’. Note the ESP register value at ‘0048411D’ when the binary is executed. In this case, it is pointing to ‘0012FD70’. To re-align the ESP register to its original position, we will have to find the difference, which is ‘0012FF68’ – ‘0012FD70’ and that gives us a value of ‘1F8’. Edit the instruction after ‘CALL EBP’ to ‘ADD ESP,1F8’ in order to align the ESP register. Now that the ESP register is aligned, we can also restore the other registers and flags with the ‘POPFD’ and ‘POPAD’ instruction as shown below. Now to enable the application to function as intended, we need to replace the instructions that were removed at the beginning of the binary. Proceed to do that as shown below.


Save the changes and attempt to run the executable, remembering to setup a netcat listener. You should receive your shell.


In my case, the application did not run as intended although the shell is spawned. After debugging, I realized that the shellcode that was generated by metasploit passed an argument of value ‘-1’ to the ‘WaitForSingleObject’ method which caused the putty program to not run until the shell is terminated. Changing the value of ‘-1’ to ‘0’ does the trick. In my case, replacing 1 instruction in the shell code fixed the issue.

Now you have a putty.exe binary that has a ‘backdoor’ shellcode that still functions as intended. Most AVs will detect this though, so it really depends on how you try to ‘obfuscate’ the shellcode, as the ones generated by metasploit are detected by most AV software out there.

Summarized Application Flow

Application flow
[Original Code]
[Original Code]
[Original Code]
[Code Cave with PUSHAD; PUSHFD]
[Start of MSFVenom code] // Set a break-point here and note the value of ESP. 0012FD70 in this example.
[End of MSFVenom code; ending will CALL EBP]
[Address to align the offset of ESP]
// Set a break-point, hit it and note the ESP register, example 0012FF68. So, 0012FF68–0012FD70 and that gives us an offset of 1F8. So for this example you will change this instruction to ADD ESP, 1F8.
[Restored instructions that were overwritten at entry point]