Methods Documentation

***NOTE***: This page does not contain the full list of Classes/Methods available. Please click here to go to the download page and get the full project.

Class: DirectDebuggerDetection

1. DirectDebuggerDetection()

This method is the constructor used in order to create a new instance of the class.

2. bool DebuggerPresent()

This method uses the win API IsDebuggerPresent in order to directly detect if the process is being debugged.

This method returns true if a debugger has been detected, otherwise it returns false.

3. int RemoteDebuggerPresent()

This method uses the win API CheckRemoteDebuggerPresent in order to directly detect if the process is being debugged.

This method returns 1 if a debugger has been detected, 0 if a debugger has not been detected, -1 if an error occurs while trying to obtain a valid handle to our process with the necessary access rights, and -2 if the win API fails.

***Note***: Both methods will trigger a “false alarm” while you debug the code in your IDE.

Class: IndirectDebuggerDetection

1. IndirectDebuggerDetection()

This method is the constructor used in order to create a new instance of the class.

2. bool DebugString()

This method uses the win API OutputDebugString in order to indirectly detect if the process is being debugged. If a debugger is not attached then the return value will be 0 or 1 depending on the windows version. By retrieving the return value from EAX immediately after the execution goes back to our code we can determine if the process is being debugged.

This method returns true if a debugger has been detected, otherwise returns false.

***Note***: This method will trigger a “false alarm” while you debug the code in your IDE.

3. int OpenServicesProcess()

Our process normally does not have the SeDebugPrivilege enabled, which means that we are not able to obtain a valid handle through OpenProcess win API to a vital system process such as “services.exe” with process_all_access rights.

In case a debugger is attached to our process *and* has enabled the SeDebugPrivilege we will manage to obtain such a handle so we can presume that our process is being debugged.

This method returns 1 if a debugger has been detected, 0 if a debugger has not been detected, -1 if we failed to obtain a snapshot of all running processes, and -2 if we failed to retrieve info regarding the first running process.

***Note***: This detection method should not be used in case that you have programmatically enabled the SeDebugPrivilege for the needs of your application.

The debugger of your IDE may also enable the SeDebugPrivilege to the process, which means that in that case this method will trigger a “false alarm” while you debug your code.

Class: WindowDebuggerDetection

1. WindowDebuggerDetection()

This method is the constructor used in order to create a new instance of the class.

2. bool SpecificWindowNameDetection(string windowname)

This method can be used in order to detect the window of a debugger or a specific reversing tool through its title name. This it is achieved by trying to obtain a valid handle to its top-level window by using the win API FindWindow.

3. bool SpecificWindowClassDetection(string classname)

This method can be used in order to detect the window of a debugger or a specific reversing tool through its class name. This it is achieved by trying to obtain a valid handle to its top-level window by using the win API FindWindow.

Both methods will return true if the desired window has been detected, otherwise they will return false.

4. string * SetReverseToolsList()

This method will fill a dynamic array with a predefined list of some popular window class names of debuggers and reversing tools and it will return a pointer to it.

It is the first parameter of ListWindowClassDetection method.

You may modify the list, but in case you do so, you must set the correct size in the SetListSize method.

5. void SetListSize()

This method sets the size of the list and it is used by GetListSize() method.

You should modify the size only in case that you have modified the size of the list inside the SetReverseToolsList() method itself.

For example, in case that you have deleted or added one or more class names of windows that you want to be detected through the ListWindowClassDetection method.

6. int GetListSize()

This method will use the SetListSize method and it will return the size of the list.

It is used as the second parameter of ListWindowClassDetection method.

7. bool ListWindowClassDetection(string * arraymemlocation , int listsize)

This method is used in order to check through a list of popular windows class names of debuggers and reversing tools if any of them is running.

Check methods above regarding the predefined list.

This method will return true if a debugger or a reversing tool  from the predefined list gets detected by its top-level window class name, otherwise it will return false.

Class: ProcessDebuggerDetection

1. ProcessDebuggerDetection()

This method is the constructor used in order to create a new instance of the class.

2. string * SetProcessList()

This method will fill a dynamic array with a predefined list of some popular process names of debuggers and reversing tools and it will return a pointer to it.

It is the first parameter of ProcessDetection method.

You may modify the list, but in case you do so, you must set the correct size in the SetListSize method.

3. void SetListSize()

This method sets the size of the list and it is used by GetListSize() method.

You should modify the size only in case that you have modified the size of the list inside the SetProcessList()method itself.

For example, in case that you have deleted or added one or more process names of that you want to be detected through the ProcessDetection method.

4. int GetListSize()

This method will use the SetListSize method and it will return the size of the list.

It is used as the second parameter of ProcessDetection method.

5. int ProcessDetection(string * arraymemlocation , int listsize)

This method is used in order to check through a list of popular process names of debuggers and reversing tools if any of them is running.

Check methods above regarding the predefined list.

This method will return 1 if a debugger or a reversing tool from the predefined list gets detected through it process name, 0 if no suspect process has been detected, -1 if an error occurs while trying to obtain a snapshot of all running processes, and -2 if an error occurs while trying to retrieve info about the first running process.

Class: ModuleDebuggerDetection

1) ModuleDebuggerDetection()

This method is the constructor used in order to create a new instance of the class.

2) string * SetModulesList()

This method will fill a dynamic array with a predefined list of some specific modules/plugins of debuggers and reversing tools and it will return a pointer to it.

It is the first parameter of ModuleDetection method.

You may modify the list, but in case you do so, you must set the correct size in the SetListSize method.

3) void SetListSize()

This method sets the size of the list and it is used by GetListSize() method.

You should modify the size only in case that you have modified the size of the list inside the SetModulesList()method itself.

For example, in case that you have deleted or added one or more modules/plugins names that you want to be detected through the ModuleDetection method.

4) int GetListSize()

This method will use the SetListSize method and it will return the size of the list.

It is used as the second parameter of ModuleDetection method.

5) int ModuleDetection(string * arraymemlocation, int listsize)

This method will take a list of all running processes and then for each process will go through its loaded modules in order to detect a debugger or a reversing tool through its own loaded modules and/or plugins.

Check methods above regarding the predefined list.

This method will return 1 if a debugger or a reversing tool gets detected through a module name, 0 if no suspect module has been detected, -1 if an error occurs while trying to obtain a snapshot of all running processes, and -2 if an error occurs while trying to retrieve info about the first running process.

Class: ParentProcessDetection

1. ParentProcessDetection()

This method is the constructor used in order to create a new instance of the class.

2. int CheckParentProcess()

This method will retrieve the parent process id of our process and then will verify that this id corresponds to the process id of windows explorer. If it is not then it means that probably our process is being debugged or it has been launched through a loader that will attempt to modify our code on run-time in memory.

This method will return 1 in case the parent of our process is not windows explorer, 0 if the parent is windows explorer, -1 if an error occurs while trying to obtain a snapshot of all running processes, and -2 if an error occurs while trying to retrieve info about the first running process.

***Note***: This method should not be used in case you plan to design an application that it will be launched from another one that you already know that it is legitimate.

This method will trigger a “false alarm” while you debug the code in your IDE.

Class: CodeTraceTimeDetection

1. CodeTraceTimeDetection()

This method is the constructor used in order to create a new instance of the class.

2. DWORD StartExecutionTime()

This method is going to use the GetTickCount win API in order to retrieve the number of milliseconds that have elapsed since the system was started and the result is going to be stored for later.

It is used by the SetStartTime method in order to store the initial result.

This method returns the number of milliseconds that have elapsed since the system was started.

3. DWORD EndExecutionTime()

This method is going to use the GetTickCount win API in order to retrieve the number of milliseconds that have elapsed since the system was started and the result is going to be stored for later.

It is used by the SetEndTime method in order to store the initial result.

This method returns the number of milliseconds that have elapsed since the system was started.

4. void SetStartTime()

This method uses the StartExecutionTime method and stores the value returned by it.

5. void SetEndTime()

This method uses the EndExecutionTime method and stores the value returned by it.

6. void SetTimeLimit()

This method sets the time limit for execution of the code block that we want to 1000 ms.

You may change it to lower or to a higher value depending on your needs.

This method is used from the GetTimeLimit method.

7. DWORD GetTimeLimit()

This method returns the value of the time limit by using the SetTimeLimit method.

This method is used by the IsCodeBeingTaced method.

8. void SetTotalTime()

This method sets the total time that has elapsed during the execution of a specified code block of our choice.

It is used by the GetTotalTime method.

9. DWORD GetTotalTime()

This method returns the value of the total time that has elapsed during the execution of a specified code block of our choice by using the GetTotalTime method.

This method is used by the IsCodeBeingTaced method.

10. bool IsCodeBeingTaced()

This method will use the GetTotalTime method in order to retrieve the total time that has elapsed during the execution of a specified code block of our choice and then it will retrieve the time limit that we have set by using the GetTimeLimit method.

This method returns true if the value returned by GetTotalTime method is greater than the value returned by GetTimeLimit method which means that our code is being traced, otherwise it returns false.

***Note***: This method may trigger a “false alarm” while you debug the code in your IDE.

Class: HardwareBreakPointDetection

1. HardwareBreakPointDetection()

This method is the constructor used in order to create a new instance of the class.

2. int HwdBreakPoint()

This method will use the win API OpenThread in order to obtain a valid handle with the necessary access rights to the current thread the functions runs and then it will use the GetThreadContext win API in order to check if any of the debug registers Dr0, Dr1, Dr2, Dr3 is not equal to zero which means that one or more hardware breakpoints have been set.

This method returns 1 if a hardware breakpoint is detected, 0 if no hardware breakpoints are detected, -1 if an error has occurred while trying to obtain a valid handle to the thread, and -2 if the GetThreadContext win API fails.

Class: ApiBreakPointDetection

1. ApiBreakPointDetection()

This method is the constructor used in order to create a new instance of the class.

2. int ApiBreakPoint(char * DLL, char * API)

This method is used in order to detect any software breakpoints at the entry point of an API.

It uses the LoadLibrary and GetProcAddress win APIs in order to obtain a handle to the dll of our choice in order to retrieve the virtual address of the specified API in memory.

It will then use a BYTE * pointer in order to check if in the first 5 bytes of the entry point of the API there is a 0xCC byte which means that a software breakpoint has been set there.

This method returns 1 if a software breakpoint has been detected, 0 if a software breakpoint has not been detected, -1 if an error occurs while we try to obtain a valid handle to the dll of our choice, and -2 if an error occurs while we try to retrieve the virtual address of the selected API.

Class: SehDbgDetection

1. SehDbgDetection()

This method is the constructor used in order to create a new instance of the class.

2. bool CloseHandleExcepDetection(HANDLE invalid)

In this method we are using CloseHandle win API by pushing and invalid

handle to it.

If there is no debugger attached to our process CloseHandle will just return an error code and the execution will continue.

However, if a debugger is attached then an exception will be raised and execution will be transferred inside our SEH.

3. bool SingleStepExcepDetection()

In this method we trigger a single step exception by pushing the EFLAGS to the stack and then setting the trap flag bit.

Finally, we restore them back with the trap flag bit set.

If a debugger is attached it will intercept the exception raised during the execution of the next instruction, so execution will never reach our SEH.

***Note***: These methods may work or not depending on the configuration of the debugger regarding exceptions.

For example, regarding the INVALID HANDLE exception in Olly Debugger, in case you don’t pass the generated exception to the program, execution will never reach our SEH, so the method will return false.

However, if you have instructed the debugger to automatically ignore this specific exception or you manually pass the exception to the program, then the execution will be transferred to our SEH and the method will return true.

Of course this is just for detection purposes, but think what it can happen in this case if the code inside your SEH creates some havoc to mislead the attacker.

Class: AntiAttach

1. AntiAttach()

This method is the constructor used in order to create a new instance of the class.

2. int AntiAttachSet()

This method can be used in order to forbid to a debugger to attach to our running process.

More specifically, since it is known that each time a user mode debugger attaches to our process, there will be a call to the APIs DebugUiRemoreBreakin and DbgBreakPoint (exported by the ntdll) from our process, we can alter these 2 functions by changing their entry point with a RET instruction in order to forbid to the debugger to successfully attach to our process.

This method uses the OpenProcess win API in order to obtain a valid handle with read/write access rights to our process and the LoadLibrary and GetProcAddress in order to retrieve the virtual addresses of the 2 APIs mentioned before.

It will then use the WriteProcessMemory win API in order to write a RET instruction (0xC3) at the beginning of the 2 APIs mentioned before so that they will not be able to be used and the debugger will not manage to attach to our process.

This method returns 1 if the antiattach has been se successfully, -1 if an error occurs while trying to obtain a handle to our process, -2 if an error occurs while trying to obtain a handle to the ntdll, -3 if an error occurs while we try to retrieve the address of the 2 win APIs we are interested to, and -4 if an error occurs while we try to write a RET instruction to the entrypoint of both APIs.

3. void AntiAttachSelfDebug()

This method will create a child process and it will debug it on run time.

The execution of the code will take place on the child process in which we will not be able to attach a user mode debugger because it will be already being debugged by its parent process.

This is a more sophisticated anti-attach method and anti-debug method since the normal execution of the does not take place in the process we are currently debugging, but from the child process.

***Note***: In case you decide to use this anti-attach method keep in mind that you should use it inside your main() function as the first thing to do, or after calling the previous method discussed in order to protect also the parent from attaching a debugger to it on run-time.

This method should not be used along with the following debugger detection methods because since the child process from which the application will run it will be debugged by the parent process, those methods will trigger a “false alarm”:

i) bool DebuggerPresent()

ii) int RemoteDebuggerPresent()

iii) bool DebugString()

iv) int CheckParentProcess()

v) bool CloseHandleExcepDetection(HANDLE invalid)

vi) bool SingleStepExcepDetection()

However, you could use the rest of the methods before or after calling AntiAttachSelfDebug() in order to detect the presence of a debugger.

Those that will be used before calling AntiAttachSelfDebug() method will run at both parent and child processes.
Those that will be used after calling AntiAttachSelfDebug() will run only in the child process.

***TIP***: You could use also the above methods with a little bit of imagination. In other words, since you know that your protected program will constantly be debugged by its parent process, you could use those methods in the opposite way after calling AntiAttachSelfDebug() so that if the child process is *not* debugged, then our code it is probably under attack.

Share