Showing posts with label OllyDbg. Show all posts
Showing posts with label OllyDbg. Show all posts

Sunday, December 01, 2013

You already know that the malware developers create packed executables in order to try to thwart the security analyst job and make a lighter file easier to download... If the executable is packed we cannot examine the original program which obstructs us from employing a static analysis to know what the malware does...

In this post we have a malware sample called DEMO.exe which we will work with.

If we open the file with PEiD we can check that it has been compressed with UPX. You already know that it is a common compression...


The majority of times we are able to unpack this type of compression automatically with the UPX program. But this time, we haven't been lucky...


If we want to make a static analysis, first we need to unpack the file. To achieve this purpose, we need to follow the next steps:

  • To unpack the original file into memory.
  • To resolve all of the imports of the original file.
  • To find and transfer execution to the original entry point (OEP).

The key to this technique is to run the packed file until it is decompressed by itself, setting a breakpoint, dumping it and setting the OEP and rebuilding their imports.

To follow these steps we will use OllyDbg v1.10 and the plugin OllyDump.

The first thing we need to do is to load the executable in OllyDbg. We can see that an advertisement appears telling us what we already know: "...reports that its code section is either compressed, encrypted ,or contains large amount of embedded data..."


Ok, let's go. Just loaded the file we can see the program stop at PUSHAD. Press F7 or click on the button to Step into.


Right click at the ESP value and select Follow in Dump...


 ... select the first four characters and set a Breakpoint.


Press the play button and wait until the program stops at the breakpoint. Now we can see the tail jump at 00ACD7BD. The tail jump is the last instruction of the uncompressing action and in this type of compression is usually followed by a lot of 0x00 bytes. These 0x00 bytes are filling to ensure that the section is properly byte-aligned. Notice that function jumps to a site which is very far away, 004090E8. Just in that instruction, the original program will start.


We can set a breakpoint at the tail jump.


We resume the program again and it is stopped at the tail jump. We need to press F7 or click on the Step Into bottom.


Now we are in the OEP. Right-clik on this line and click on Dump debugged process in order to dump the process to a disk.


Notice that the OEP (004090E8) is the same that the last address in the "Modify" field, 90E8 . You can press the "Get EIP as OEP". Untick the "Rebuild import" because the import will be rebuilt using Import REConstructor. It is a good idea to copy the value "90E8" for the future...


Save the dump where you want. I have saved the file as "Dumped.exe". Notice if you want to run the program it will fail because it doesn't have the imports. To fix that, just open Import REConstructor and select the file which is being debugged with OllyDbg. In this case "demo.exe"


The next window will appear.


Just paste the value which was copied before in the OPE section and click on IAT AutoSearch.


Click on the Get Imports first and then click on the Fix Dump buttom.


Just pressed "Fix Dump" select the file which was dumped.


Now, we have two files, the first one which was dumped with OllyDbg and the last one, Dumped_.exe which has the imports rebuilt.


If  you look at the strings in OllyDbg you can see the differences. In the picture below you can see on the left the strings detected in the packed file and on the right, you can see the strings of the unpacked file.



Now, if we open the unpacked file we can detect that is was developed in Visual basic and we can start with the static analysis.


With VB Decompiler we could try to decompiler it...



Posted on Sunday, December 01, 2013 by Javier Nieto

No comments

Sunday, November 03, 2013

Last 22-24 October 2013 hack.lu was celebrated in Luxemburgo. Hack.lu is an open a security convention where usually there is a CTF (capture the flag) competition.

This year the competitors need to get two passwords of a program called RoboAuth.exe which can be downloaded here:


The flag to pass the test is: password1_password2

Ok. Let's go to try to get the first one. To achieve this purpose, we are going to use OllyDbg. Just open the file with this program and click on the play button  to run the program.


We can see a MS-DOS windows which requests us the first Password.


One of the first things I usually do in these cases is to look at "All referenced test strings" in order to find something which draws my attention.


In this case, we can see the string "You passed level1!". We can suppose that just before that, the assemble code will compare our password with the real one.


To go to this string in the assemble code, we right-click on this line and select "Follow in Disassembler".


Now we can see the string mentioned above in the assemble code. Two lines before that, we can see the function "TEST EAX, EAX" wich will make a comparison between our password and the real one. Depending on the result, the program will make a decision. If the password is correct, we will pass the test, if not, the program will be closed.


We can set a breaking point at this point in order to stop the program just when the program is comparing the passwords in order to see the good one in the Stack. To do that, just right click on the line which contains "TEST EAX, EAX", select Breakpoint and select for example, "Memory, on access".


The next step is to write a password and wait until the program stops in the breakpoint.


In the end, we just need to see the Stack window which shows the state of the stack in memory for the thread being debugged. This window is at the bottom right. In the picture below you can see our password "COMPARE..." followed by other string "r0b0RUlez!". It seems to be the password.


If we go to our program and type the password "r0b0RUlez!" on the program, you can check that "You passed level1!".


I've spent some time trying to resolve the second Password but it is more complicated than the previous one. When I have some spare time, I will try it again and I will write a post with the solution.


Posted on Sunday, November 03, 2013 by Javier Nieto

No comments

Monday, September 30, 2013


Some months ago, I participated in something like a "Hacker Competition" to get a job in a CERT. One of the tests consisted of getting the serial key of a simple program. The organizer sent me an executable called reversing_test.exe

We are going to work with OllyDbg v1.10. You can download this awesome tool from here: OllyDbg v1.10.



You can see its details in the picture below.



The first thing I usually do in these cases is to check if the executable is compressed or not. Some programs pack some of their codes in order to limit our attempt to statically analyze it. To achieve this purpose we are going to use PeID. In the picture below you can see that the program does not detect any compression "Nothing found *". If the file were compressed with UPX for example, the program would advise us about it and we could uncompress it with this tool.



If we click on the "EP Section" bottom, we will see some executable's details.



We can see the R. Size (Raw Size) "400" and the V.Size (Virtual Size) "350" are similar in ".text" . The .text section contains the instructions that the CPU executes and it should be the only section that includes the code. If some day you detect that the R.Size is "0" and the V.Size is "1000" for example, it would be an indicator that the executable is compressed because in the disk it does not have any size (it is packed) and in the memory it has a size (it is unpacked itself).


Now we have the assurance that the file has not been compressed. This is one of the first steps in a static analysis. We are going to make a dynamic analysis with OllyDbg but I want to know if the developer has made an effort in order to try to hide some code. Notice if the executable is packed then we are not going to be able to read a lot of strings within the file. It is possible I will talk about that in future posts...


The next step would be to run the program by double clicking on the executable. After that, we can see that a MS-DOS window is launched and the program requires us to type the serial number. We type a sentence in order to check the program's behavior.


We have not figured out the serial number... It seems logical...


Now, we are going to run OllyDbg. It does not need installation, just download it and uncompress it. When OllyDbg is opened, just load the executable clicking on File -> Open.



Now we can see the binary code. Don't worry, remember this post is focused on beginners. We are going to click on the play button in order to run the executable just loaded in our debugger and check the file behaviour.



The program has started and we can see the firsts strings like "Press ENTER to finish"...

(Please, click on the picture to see the entire details)


But... Something happens... The program doesn't require us to type the serial number like it occurs when we open the application without using a debugger... It's really strange... It's like the program knows about our intentions and it is closed by itself when we try to run it with a debugger tool...



If we reload the file again on OllyDbg, one line of the code draws our attention... The program is calling to the "IsDebuggerPresent" API.



If we seek this API on Microsoft we can see that "This function allows an application to determine whether or not it is being debugged, so that it can modify its behavior".


Ok, the program is closed when it is open within a debugger. There are many options to avoid being detected by this technique... To achieve this purpose we are going to use the "Hide Debugger 1.2.4" plugin. Just download it and uncompress the DLL in the same OllyDbg's folder.


It is necessary to restart OllyDbg in order to work with this plugin. If you click on Plugins tab you can see Hide Debugger plugin. You don't need to do anything else.



We have just installed the plugin to avoid being detected and now, we are going to load and play the executable again. Now the program requires typing the serial number. Great news...



We are going to type a sentence which will be easily recognizable.



If we come back to OllyDbg we can see our sentence in the Arg1.

(Please, click on the picture to see the entire details)


If we continue looking for this sentence through the code we can locate the code below. We can see the String2="28939387", the String1="I'm going to looking for this sentence in OllyDbg now..." and the API call CompareStringA.

We can figure out that the executable is comparing these strings to each other in order for you to check if both have the same value. We can suppose that the string "28939387" is serial number.

(Please, click on the picture to see the entire details)


OllyDbg offers us to copy the value of this line by left clicking on the line we are interested in.



Then, we are going to paste the line's value to the notepad and then, we are going to copy only the "String2" value: 28939387.



In the end, we just need to try paste the value just copied in our program and... Well!!! We have obtained the serial number of our program!!!



This post could be applied to many of the simple programs which have a keygen integrated but it is needed to have more knowledge if you want to crack more complex programs.

This post is focus on show you some techniques using OllyDbg. It is only a game to get more reversing engineer skills to research malware. Please, don't contact me to crack programs, it is illegal... I recommend you use to use free software!!!! :P


Posted on Monday, September 30, 2013 by Javier Nieto

14 comments