It is about a minor project that i recently completed. That is writing a virtual machine to slow down the process of reverse engineering. This is not a tutorial to do the same however I have included the presentation that i used during the final presentation, the PDFs for System Design and Sample Runs and one step by step sample run.

#Presentation

#Code

#Sample Run

In this sample run I am going to implement the POC expansion algorithm that was the final program that was written for OIVM.1. Make sure bootrom.txt and OIVM.exe are in the same folder.
2. Open the Bootrom.txt using a Hex Editor (example : Hex Workshop) and write the following hex stream to it.

3F 11 25 00 2F 08 3F 38 3F 38 41 3D 09 1B 3C 4C 21 25 00 2F 14 7C 67 63 55 64 61 38 67 7C 63 38 55 64 61 38 37 41 3D 15 C9 45 3F 11 3F 12 18 68 3C 25 00 2F 08 12 86 C5 38 41 3D 09 00 02 04 06 08

3. Save the file. This is basically in the format of [STUB][Compressed Code]. The stub is 60 Bytes long and extends till the 0x09 in the second line of the hexadecimal stream. The parallel assembly for this code is as follows :

[EXPANSION STUB]
scanf(“%d”,&STACK[SP])
MOV A,STACK[SP]
FLAG=A-ROM[++IP]
JE 8 BYTES
scanf(“%d”,&STACK[SP])
++SP
scanf(“%d”,&STACK[SP])
++SP
–A
JMP -9 BYTES
MOV B,ROM[++IP] //STUB LENGTH
A = fileLen
A=A-B
FLAG=A-ROM[++IP]
JE 14 BYTES
MOV C ,ROM[B]
MOV D,SP
MOV SP,C
MOV C,STACK[SP]
MOV SP,D
MOV STACK[SP],C
++SP
MOV D,SP
MOV C,ROM[B]
MOV SP,C
++SP
MOV C,STACK[SP]
MOV SP,D
MOV STACK[SP],C
++SP
++B
–A
JMP -21 BYTES
ROM=(char *)realloc(ROM,ROM[++IP]) //FILE EXPANDED
scanf(“%d”,&STACK[SP])
MOV A,STACK[SP]
scanf(“%d”,&STACK[SP])
MOV B,STACK[SP]
MOV SP,B
MOV C,ROM[++IP]
FLAG=A-ROM[++IP]
JE 8 BYTES
MOV B,STACK[SP]
MOV ROM[C],B
++C
++SP
–A
JMP -9 BYTES
[COMPRESSED FORM]
00 02 04 06 08

4. Now run the program.If however you dont speak assembly that doesnt matter here is the algorithm for it :

1. Enter the Number of elements in the dictionary.
2. Enter the dictionary.
(Dictionary is stored on the stack)
(The dictionary is looked up for values corresponding to compressed code)
(The new Values are updated over the stack)
3. Enter the New Size.
4. Enter the SP (which could have been hardcoded as well)
(The code expands)
(The execution is now passed on to the expanded program)
5. Enter the first element. Hit Enter.
6. Enter the second element. Hit Enter.
7. The sum is Displayed.
8. OIVM halts.

Results/Output

#Thanks

Special thanks to Mr. Atul Alex Cherian, Ms. Nishtha Jatana and Ms. Kritika Sobti.

Hi, non technical reader.

Introduction

So basically this is the small program I wrote, which we are going to play with. In this program there are two functions : func1() and func2(). func1() is called from main, but func2() is never called.

So our aim is to execute func2 at run time.Here is the first run :

As you can see we do not go inside func2.

Reverse Engineering solution The first and the lot easier approach to this is, a RE solution. In this solution i just change some return addresses on the stack and we are done. Lets go step by step.

Step1 : Loading the program in OllyDbg

As can be seen there are three functions main, func1 and func2. These are indicated by the square brackets. The order of these functions is func1, func2 and lastly main.

Step2 : Now I am going to put a breakpoint on func1 and then observe the stack.

We have two images here the first one represents the assembly view of print2.cpp when i hitthe breakpoint and the second one represents the stack when I hit the breakpoint. In figure 1 it can be seen that the func1 starts at 401334 and it(the address) is in read with black background. Which indicates that we have hit the breakpoint. In figure two we can see that the return address for func1() is 0040139A. If we look up this address in the assembly dump, it is the one just after func1() is called that is 401395. Hence, things are fine here, the function always returns to the immediate expression after a call to it. So we have two deductions from here. First that the return address is 40139A which can be changed to make the func1() jump somewhere else. and secondly that this address is placed on the memory address starting 28FF0C.  

Step3 : Now we are going to edit 40139A to 401359 so that we can jump over to func2().

After the modification even the comment changes to print2.00401359, which suggests that it is call. And as expected we enter the func2().

However this is not enough. In a similar way we have to edit the return address of func2 to 40139A which was the original return address of func1. Now to be able to identify where is the return address of func2, we single step through func2 till we reach RETN.

Step4 : Here the top address on the stack is the return address for the stack. We need to change this address. In order to return and exit normally.

As can be seen on the stack 0028FF10 is the address where the return address 00403050 is stored. We modify this and then run the program.

We are able to do it neatly. :)

Program Solution

Now the RE solution was though easy, it wasn’t automated, and i had no fuckin idea about how do i make a permanent modification. What i mean here is like if you want to completely change an instruction you can do that and simply save changes to the new executable. But the stack is a dynamic memory region, it is not a part of the exe file that you save. So there was something more, some workaround that was needed. And thanks to Atul Alex Cherian, who told me about loader. So a loader is basically a program that lets the entire exe load in memory and then plays around with it. I first thought about using a tool for this, but then why not just code this shit out. So here is the algorithm that i followed for this.

Step1. Use fread to read the bytes of print2.exe to an array.

Step2. In this array modify the byte that represents beginning of func1 to CC (breakpoint).

Step3. Save this array to a new myf.exe

Step4. Detach pointer to myf.exe and open process myf.exe as a DEBUG_PROCESS

Step5. Waitforadebugevent and use a simple condition to check that it orignates from the one that you forced.

Step6. On receiving the EXCEPTION_BREAKPOINT DEBUG_EVENT suspend the thread using process information of myf.exe

Step7, Now change the CC that you placed to the original byte

Step8. Getthreadcontext of this thread and access the context structure to decrement EIP.

Step9. Now change return addresses of func1 and func2. For func1 only one byte is edited and for func2 one has to edit 2 bytes.

Step10. Resume thread. Myf.exe should exit after you press the first enter, then loader.exe should exit after you press the second enter. Here is the code :

Here is the screen shot showing its execution.

And special thanks to Dhanesh sir. :)

H3LL Y34H! :)

#include “stdafx.h”
#include “windows.h”

void antidebug();
void antidebug()
{
HMODULE lib;
FARPROC _ZwSetInformationThread;
lib = LoadLibrary(“ntdll.dll“);
_ZwSetInformationThread = GetProcAddress(lib, “ZwSetInformationThread“);
(_ZwSetInformationThread)(GetCurrentThread(),0x11,0,0);
MessageBox(NULL, “Debugger Detached“, “Debugger Detached“, MB_OK);
}

int _tmain(int argc, _TCHAR* argv[])
{
antidebug();
MessageBox(NULL, “Double Check…“, “Double Check“, MB_OK);
return 0;
}

Before I get into the BUGs lemme just try and explain what is happening here, so we are basically loading a handle to ntdll.dll by calling the LoadLibrary process and then we load the callback to _ZwSetInformationThread which is of datatype FARPROC[more on FARPROC] then we call ZwSetInformationThread routine which has four parameters as per http://msdn.microsoft.com/en-us/library/windows/hardware/ff567101%28v=vs.85%29.aspx .

The firstparameter is the handle to the current thread and since we want to run this function within our program we use the GetCurrentThread() function call which returns a handle to the current thread. Next is a value 11. This is basically the value because of which the debugger would get detached from the process. Now how did i get this value. As per documentation on msdn the second parameter is of the enumeration type _THREADINFOCLASS which is as follows [source] :

typedef enum _THREADINFOCLASS {
ThreadBasicInformation,
ThreadTimes,
ThreadPriority,
ThreadBasePriority,
ThreadAffinityMask,
ThreadImpersonationToken,
ThreadDescriptorTableEntry,
ThreadEnableAlignmentFaultFixup,
ThreadEventPair_Reusable,
ThreadQuerySetWin32StartAddress,
ThreadZeroTlsCell,
ThreadPerformanceCount,
ThreadAmILastThread,
ThreadIdealProcessor,
ThreadPriorityBoost,
ThreadSetTlsArrayAddress,
ThreadIsIoPending,
ThreadHideFromDebugger,
ThreadBreakOnTermination,
MaxThreadInfoClass
} THREADINFOCLASS;

So ThreadHideFromDebugger is 17 which is basically 11 in hex. And the remaining two parameters are obviously not of importance to us. :D

Now coming to the bugs. “|17|error: too many arguments to function|” But MSDN said that it needed four :O and now i started removing one parameter at a time and the function ran when i did not pass any arguments. After having searched a lot! The only solution that i could think of was to use the asm function and pass these arguments manually.

So i made the following changes.

(_ZwSetInformationThread)();
GetCurrentProcess();
asm(“pushl 0“);
asm(“pushl 0“);
asm(“pushl 0x11“);
asm(“pushl %eax“);

Oh and by the way the assembly syntax utilized on GCC is the AT&T asm. So yeah! I had to first read that because i have being doing the intel format. I read [this]

So this was some success because atleast the exe compiled, i had already though that now i would easily debug everything on OllyDbg and get it through. But this is what GCC(or i) had done to the code. :

So this wasnt the best solution.But it was some success since i was atleast able to compile the exe now and look it up in Olly (Somehow i am more comfortable with that.)

I decided that since the value passed as the handle to the process is the only thing that i do not know lemme pass other values by modifying the assembly code manually in Olly and changed the code to the following :

HANDLE hndle = GetCurrentThread();
(_NtSetInformationThread)();

The exe did compile and i was getting the pop up messages too.

Next thing was to immediately load this exe into my dearest OllyDbg and get started. Here is the very first look.

You can see that a call gets made to GetCurrentThread at 00401365 and the value is returned into EAX which is them moved to our variable “handle” (EBP-14). So after a couple of runs i realized that this value was always the same and always returning FFFFFFFE i am not sure if this is a fixed constant for a each system or is it just the local handle to every thread. But this is what it was in the case that I had in front of me. Then later you can see that a different value is moved into EAX and at 00401370 we make a call to that address (call eax) hence this is the handle to the ZwSetInformationThread.

So far so good. Next i had to modify the code so that i could push values to the stack before the call eax is executed. If you at the address 00401362 you would see that MOV EBP-10,EAX instruction is executed just after GetProcAddress so basically this is the place where the handle to ZwGetInformationThread is placed on the stack hence we can only modify the code after this. That is from 401365 to 40136D where the value is pushed back into EAX. (Or we could NOP both of these so that the value remains unchanged)

So here are the modifications that i did, wait and after this modification i clicked analyse code. So you’d see that now Olly recognizes this as a function ^_^

so we have obviously overwritten the call to GetCurrentThread but the code seems to fit just fine! :)

Now do you see a push -2 at 0040136B i had assembled PUSH 0xFFFFFFFE. :) And also since this is windows you would have to push the last argument first… just in case you did not know this.
Now before you run the code remember to save all modifications to exe because if the code is successful you would be detached from the debugger.
And finally we run the program. We Get the pop ups. And next we are detached from the debugger. :) (The code screen goes blank. Try reloading with << button.
The Blank Screen :

The Error :

H3LL Y34H! B)