So I thought: “this could be useful to the people read me”. Why not? Perhaps you got some doubt waiting to be solved and is unable to find a guy who knows something about this. Perhaps this f* guy even exists and has a blog where he could share some knowledge that is stuck in that empty programmer head.

In this case, it follows bellow a brief description of my professional life, with the things I could remember I did since December 2000. What I haven’t remember probably is not worth of.

• Software and hardware inventory
• Clipboard and PrintScreen protection using windows hooks and global messages manipulation
• Driver writing system event log
• DeviceIoControl user/kernel communication
• Desktop remote control using VNC technique
• Remote execution tool PsExec (SysInternals) like
• Print control using regex (Boost) and shell hook
• Access policies management during user logon/logoff (register and hooks)
• Datgabase migration CTree -> SQL (OLE classes)
• Windows authentication using custom GINA and DCOM; Credential Provider (Vista)
• CTree database synchronism using custom DCOM service
• Bootable Linux CD with bash scripts and disk cryptography tools using C language
• Hard disk encryption and PenDrive (USB) storage control
• Blue Screen analysis using memory dumps and WinDbg live (Gflags)
• System account execution using custom COM service
• MBR (Master Boot Record) customization library
• Blowfish/SHA-1 encryption library using C++ and 16 bits Assembly
• Log access driver using shared memory between user and kernel mode
• Kernel mode API hook for 9X and NT platforms
• 16 bits Assembly loader; debugging using debug.com tool
• Executable protection using embedded domain authentication recorded inside files resources
• Internet Explorer 6/7 and Firefox 1/2 browsing protection using Assembly 32 bits code injection
• Code, strings and execution protection library (using Win32 interruptions)
• Centralized log generation library using shared memory and global events
• Internet Explorer 6/7 BHO (Broser Helper Object) and ActiveX; Mozilla/Firefox XPI plugin
• Projects management using Source Safe, Bazaar and Batch (Win) scripts
• Kernel mode debugging using SoftIce and WinDbg for NT platform, SoftIce and WDeb98 for 9X platform
• Trojans reverse engineering (C++, Visual Basic, Delphi) using WinDbg and IDA
• Diagnostic tool listing files, services, drivers, register, disk partitions, processes, etc
• Jobs monitoring in Win2000+ to installation and update control
• Application use monitoring using noninvasive and invasive windows hooks
• Houaiss reverse engineering and Babylon importation (dictionaries)
• Build control with Cruise Control .NET, symbol server with Debugging Tools
• Projects documentation using Doxygen and Wiki (Trac)
• Management interfaces using C++ Builder 5/6 and Visual C++ custom libraries
• E-mails analyzer using regular expressions (ATL classes)
• Configuration interfaces using Visual C++ (MFC /ATL/WTL)
• Project and tracing analysis using regular expressions (Vim and Grep)
• Articles development using technical blog and Code Project community.

Perhaps I update this list frequently. Although I guess the rightest choice would be to update the list with articles about my every day “brushing bits” life . After all, I got a technical blog already!

int sum(int x, int y);
double sum(double x, double y);
 
int main()
{
    int zi = sum(2, 3);
    double zd = sum(2.5, 3.4);
    return 0;
}
 

Immediately the compiler would blame you about the following errors:

overload.c

overload.c(2) : warning C4028: formal parameter 1 different from declaration
overload.c(2) : warning C4028: formal parameter 2 different from declaration
overload.c(2) : error C2371: 'sum' : redefinition; different basic types
        overload.c(1) : see declaration of 'sum'

This happens because in C the identifiers are unique into the scope. This is the reason why the following code is wrong also:

int main()
{
    int x = 0;
    int x = 1;
    return 0;
}
 

overload.c
overload.c(5) : error C2374: 'x' : redefinition; multiple initialization
        overload.c(4) : see declaration of 'x'

Back to the 90’s, this is also wrong in C++. Even for a logic issue: how the compiler can pick a variable if we’re using the same name for both of them?

Even though, there’s a little trick to stop the ambiguity when we talk about functions: the parameters that they receives.

int sum(int x, int y);
double sum(double x, double y);
 
int main()
{
    int zi = sum(2, 3); // two int types: call sum(int, int)
    double zd = sum(2.5, 3.4); // two double types: it just can be sum(double, double)
    return 0;
}
 

C:\Tests>cl /c overload.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

overload.cpp

C:\Tests>

This allowed in C++ the creation of static overload, that is exactly this: to call a function not just by its name, but also to match its signature, the number and the type of the received parameters. We call static because this is done just by the compiler, not creating any overhead during the execution.

Among the most common uses some are as it follows:

• Functions with the same name treating different parameters;
  • sum(int, int);
  • sum(double, double);
  • Obs.: This ignores, of course, the templates usefulness.
• New version of the same fuction with addictional parameters;
  • export_data(void* buffer, int size);
  • export_data(void* buffer, int size, unsigned long options);
• Same method name to set and get the value of a class property;
  • Class::Property(int x); // setter
  • int x Class::Property() const; // getter
• Well, whatever your imagination and needs demand =)

The antiattaching technique

The purpose of this protection is to detect if some debugger tries to attach into our running process. The attach to process operation is pretty common in all known debugger, as WinDbg and Visual Studio. Different from the DebugPort protection, this solution avoids the attach action from the debuggee program. In this case the protection can make choices about what to do on the event of attach (terminate the process, send an e-mail, etc).

The code I've found does nothing more than to make use of the attach process function that's always called: the ntdll!DbgUiRemoteBreakin. Being always called, we can just to put our code there, what is relatively easy to do:

#include <windows.h>
#include <iostream>
#include <assert.h>
 
using namespace std;
 
 
/** This function is triggered when a debugger try to attach into our process.
*/
void AntiAttachAbort()
{
	// this is a test application, remember?
	MessageBox(NULL, "Espertinho, hein?", "AntiAttachDetector", MB_OK | MB_ICONERROR);
 
	// this is the end
	TerminateProcess(GetCurrentProcess(), -1);
}
 
 
/** This function installs  a trigger that is activated when a debugger try to attach.
@see AntiAttachAbort.
*/
void InstallAntiAttach()
{
	PVOID attachBreak = GetProcAddress(
		GetModuleHandle("ntdll"), // this dll is ALWAYS loaded
		"DbgUiRemoteBreakin"); // this function is ALWAYS called on the attach event
 
	assert(attachBreak); // attachBreak NEVER can be null
 
	// opcodes to run a jump to the function AntiAttachAbort
	BYTE jmpToAntiAttachAbort[] =
	{ 0xB8, 0xCC, 0xCC, 0xCC, 0xCC,   // mov eax, 0xCCCCCCCC
	0xFF, 0xE0 };                     // jmp eax
 
	// we change 0xCCCCCCCC using a more useful address
	*reinterpret_cast<PVOID*>(&jmpToAntiAttachAbort[1]) = AntiAttachAbort;
 
	DWORD oldProtect = 0;
 
	if( VirtualProtect(attachBreak, sizeof(jmpToAntiAttachAbort), 
		PAGE_EXECUTE_READWRITE, &oldProtect) )
	{
		// if we can change the code page protection we put a jump to our code
		CopyMemory(attachBreak, 
			jmpToAntiAttachAbort, sizeof(jmpToAntiAttachAbort));
 
		// restore old protection
		VirtualProtect(attachBreak, sizeof(jmpToAntiAttachAbort), 
			oldProtect, &oldProtect);
	}
}
 
 
/** In the beginning, God said: 'int main!'
*/
int main()
{
	InstallAntiAttach();
	cout << "Try to attach, if you can...";
	cin.get();
}

To compile the code above, just call the compiler and linker normally. Obs.: We need the user32.lib in order to call MessageBox API:

cl /c antiattach.cpp
link antiattach.obj user32.lib

antiattach.exe
Try to attach, if you can...

After the program has been running, every try to attach will show a detection message and program termination.

windbg -pn antiattach.exe

Code peculiarities

Yes, I know. Sometimes we have to use "brute force codding" and make obscure codes, like this:

// opcodes to run a jump to the function AntiAttachAbort
BYTE jmpToAntiAttachAbort[] =
{ 0xB8, 0xCC, 0xCC, 0xCC, 0xCC,   // mov eax, 0xCCCCCCCC
0xFF, 0xE0 };                     // jmp eax
 
// we change 0xCCCCCCCC using a more useful address
*reinterpret_cast<PVOID*>(&jmpToAntiAttachAbort[1]) = AntiAttachAbort;

There are a lot of ways to do the same thing. The example above is what is normally called in the crackers community as a shellcode, what is a pretty name for "byte array that is really the assembly code that does interesting things". Shellcode for short =).

Alternative ways to do this are:

1. To declare a naked function in Visual Studio, to create an empty function just after, do some math to calculate the size of the function to be copied into another place (aware of Edit and Continue option).
2. To create a structure whose members are masked opcodes. This way, is possible in the constructor to receive the values and use it as a "mobile function".

Both have pros and cons. The cons are related with the environment dependency. In the first alternative is necessary to configure the project to disable "Edit and Continue" option, whilst in the second one is necessary to align 1 byte the structure.

Anyway, given the implementation, the main advantage is to isolate the code in only two functions - AntiAttachAbort and InstallAntiAttach - an API local hook (in the same process) that should never be called in production code. Besides, there are C++ ways to do such thing like "live assembly". But this is matter for other future and exciting articles.

Among these events we can tell the most frequent:

• Activated breakpoints
• Thrown exceptions
• Threads creation/termination
• DLLs load/unload
• Process exit

In the case of connecting into a existent process, the API DebugActiveProcess is called. Since this call, if successful, the caller program is free now to call the API DebugActiveProcess, looking for debugging events. The main loop for a debugger is, so, pretty simple:

void DebugLoop()
{
	bool exitLoop = false;
 
	while( ! exitLoop )
	{
		DEBUG_EVENT debugEvt;
 
		// Wait for some debug event.
		WaitForDebugEvent(&debugEvt, INFINITE);
 
		// Let us see what it is about.
		switch( debugEvt.dwDebugEventCode )
		{
			// This one...
 
			// That one...
 
			// Process is going out. We get out the loop and go away.
			case EXIT_PROCESS_DEBUG_EVENT:
			exitLoop = true;
			break;
		}
 
		// We need to unfreeze the thread who sent the debug event.
		// Otherwise, it stays frozen forever!
		ContinueDebugEvent(debugEvt.dwProcessId, debugEvt.dwThreadId, DBG_EXCEPTION_NOT_HANDLED);
	}
}

The interesting detail about this communication process is that a program can be debugged actively only for ONE debugger. In other words, while there's a process A debugging process B, no one besides A can debug and break B.Using this principle, we can imagine a debugging protection based on this exclusivity, creating a protector process that connects to the protected process and "debugs" it:

/** @brief Antidebug protection based on DebugPort aquisition.
* @author Wanderley Caloni (wanderley@caloni.com.br)
* @date 2007-08
*/
#include <windows.h>
 
/* Every debugger needs a debugging loop. In this loop it catches
debugging events sent by the operating system.
*/
DWORD DebugLoop()
{
	DWORD ret = ERROR_SUCCESS;
	bool exitLoop = false;
 
	while( ! exitLoop )
	{
		DEBUG_EVENT debugEvt;
 
		WaitForDebugEvent(&debugEvt, INFINITE);
 
		switch( debugEvt.dwDebugEventCode )
		{
			// Process going out. We get out the loop and leave.
			case EXIT_PROCESS_DEBUG_EVENT:
			exitLoop = true;
 
			break;
		}
 
		// Necessary, since the current thread is frozen.
		ContinueDebugEvent(debugEvt.dwProcessId, debugEvt.dwThreadId, DBG_EXCEPTION_NOT_HANDLED);
	}
 
	return ret;
}
 
/* Attachs to the protected process againt debugging. Actually, we protect it
againt debugging being its debugger.
*/
DWORD AntiAttach(DWORD pid)
{
	DWORD ret = ERROR_SUCCESS;
 
	if( pid )
	{
		BOOL dbgActProc;
 
		dbgActProc = DebugActiveProcess(pid);
 
		if( dbgActProc )
			DebugLoop();
		else
			ret = GetLastError();
	}
	else
		ret = ERROR_INVALID_HANDLE;
 
	return ret;
}
 
/* In the beginning, God said: 'int main!'
*/
int main(int argc, char* argv[])
{
	DWORD ret = ERROR_SUCCESS;
 
	if( argc > 1 )
	{
		DWORD pid = atoi(argv[1]);
		ret = AntiAttach(pid);
	}
 
	return (int) ret;
}

The needed steps to test the code above are:

1. Compile the code
2. Run notepad (or another victim)
3. Get its PID (Process ID)
4. Run the protector process passing the notepad PID as the argument
5. Try to attach to the notepad using a debugger (e.g. Visual C++)

After the attach process, the debug port is occupied, and the communication between the debugger and debuggee is made throug LPC. Bellow we can see a little illustration of how things work:

Basically the process stay receiving debugging events (through the LPC message queue) until the final event, the process exit. Notice that if someone try to terminate the protector process the debuggee process will be terminated, too.

Flawless? OK...

The strength in this protection is that it doesn't affect the code understanding and readability. In fact the code that protects is in another process. The weakness, I would say, it is your visibility. Everyone that will try to attack the solution will se two processes being created, what gives him/her something to think about...

That's why thinking about the implementation is vital. Particularly the main point to be thought is the debugger/debuggee union. As much as better these two pieces were packed, harder to the attacker will be to separate them. An additional idea is to use the same technique in the opposite way, in other words, the debuggee process to attach into the debugger.

This time I'm not going to say that there's a easy solution. Maybe because I haven't though enough about the problem. Ideas?

The upgrade showed here still uses the exception throwing intrinsically, but now it doesn't depends on the code division in minifunctions and minicalls. Instead, we just need to get code traces and put them inside a miraculous macro that will do everything we want. This, of course, after some "hammer work" that will be explained here.

// Go back to place pre-defined by the restoration point.
void LongJmp(restorePoint)
{
	// Here we will generate an exception to make things difficult.
	// @todo Make a breakpoint exception and catch it.
 
	// 3. We return to the if without using the stack, but from the restoration point.
	GoBackToTheStartFunction(restorePoint);
}
 
// Here everything begins.
int Start()
{
	// Obs.: follow the agreement flow according to the numbers.
 
	// 1. First pass: we define a restoration point to the return of LongJmp.
	// 4. Second pass: we go back from the LongJmp function, but this time we get into the else.
	if( RestorePointDefined() == Defined )
	{
		// 2. We call the function that will return to the if.
		LongJmp( if );
	}
	else
	{
		// 5. Call the real function, our true target.
		CallTheUsefulFunction();
	}
 
	// 6. End of execution.
	return 0;
}

The solution above is explained in pseudocode to make things clearer. Notice that exist some kind of invisible return, not stack based. To handle it, however, we can use the good for all C ANSI standard, using the setjmp (step one) and longjmp (step 3). To understand the implementation for theses functions running on the 8086 platform we need to get the basic vision of the function calls in a stack based environment (the C and Pascal way).

Registers, stack frame and call/ret

Registers are reserved variables in the processor that can be used by the assembly code. Stack frame is the function calling hierarchy, the "who called who" in a given execution state. Call and ret are assembly instructions to call and return from a function, respectively. Both change the stack frame.

Imagine you have a function, CallFunc, and another function, Func, and one calls the other. In order to analyse just the function call, and just that, let's consider Func doesn't receive any argument and doesn't return any value. The C code, would be like bellow:

void Func()
{
   return;
}

void CallFunc()
{
   Func();
}

Simple, huh? Being simple, the generated assembly will be simple as well. In CallFunc it should have the function call, and inside Func the return from the call. The rest of the code is related with Debug version stuff.

Func:
00411F73 prev_instruction ; ESP = 0012FD38 (four bytes stacked up)
00411F74 ret ; *ESP = 00411FA3 (return address)

CallFunc:
00411F9C prev_instruction
00411F9E call Func (411424h) ; ESP = 0012FD3C
00411FA3 next_instruction

From the assembly above we can conclude two things: 1. The stack grows down, since its value decremented four bytes (0012FD3C minus 0012FD38 equal four) and 2. The return value from the calling is the address of the very next instruction after the call instruction, in the case 00411FA3.

Well, in the same way we can follow this simple execution, the attacker will do as well. That's why in the middle of this call we will throw an exception and, in the return, we will not do the return in the conventional way, but using another technique that, instead using the ret instruction, sets manually the esp value (stack state) and jumps to the next instruction in CallFunc.

Func:
00411F60 throw_exception
00411F61 ...
00411F73 catch_exception
00411F74 mov ESP, 0012FD3C ; ESP = 0012FD3C, just like CallFunc
00411F75 jmp 00411FA3 ; jumps to CallFunc::next_instruction

Back to the Middle Earth

All this assembly stuff doesn't need to be written in assembly level. It was just a way I found to illustrate the differences between the stack return and the jump return. As it was said, to the luck and well being for all, this same technique can be implemented using ANSI C functions:

jmp_buf env; // Contains the next instruction (stack state).
 
void Func()
{
	// 3. Return using the "nonconventional" way
	longjmp(env, 1);
}
 
void CallFunc()
{
	// 1. If we're setting, returns 0.
	// 2. If we're returning, returns a value different from 0.
	if( setjmp(env) == 0 )
		Func();
 
	int x = 10; // 4. Next instruction.
}

That was the new trick for the trowing of exceptions. The final code is clearer, now:

/** The only purpose of this function is to generate an exception.
*/
DWORD LongJmp(jmp_buf* env)
{
	__try
	{
		__asm int 3
	}
		__except( EXCEPTION_EXECUTE_HANDLER )
	{
		longjmp(*env, 1);
	}
 
	return ERROR_SUCCESS;
}
 
 
/** And God said: 'int main!'
*/
int main()
{
	DWORD ret = ERROR_SUCCESS;
 
	while( cin )
	{
		string line;
 
		cout << "Type something\n";
		getline(cin, line);
 
		jmp_buf env;
 
		if( setjmp(env) == 0 )
		{
			LongJmp(&env);
		}
		else
		{
			cout << line << endl;
		}
	}
 
	return (int) ret;
}

At first sight, it seems a waste the if being directly in the code (remember we gonna use the same conditional structure in several parts in the code). To turn things clearer, resume the protected call and allows the protection to be disabled in debug version code, let's create a macro:

/** Use this macro instead LongJmp
*/
#define ANTIDEBUG(code)
{
	jmp_buf env;
 
	if( setjmp(env) == 0 )
	{
		LongJmp(&env);
	}
	else
	{
		code;
	}
}
 
/** And God said: 'int main!'
*/
int main()
{
	DWORD ret = ERROR_SUCCESS;
 
	while( cin )
	{
		string line;
 
		cout << "Type something\n";
		getline(cin, line);
 
		ANTIDEBUG(( cout << line << endl ));
	}
 
	return (int) ret;
}

Now we allow the antidebugging selection by call, what turns things much easier than to choose the protected points inside the code.

The main idea in this protection is to take care these exceptions during the application execution. Doing this, we can make use of this fact and, in the handling code, run the protected code. The solution here looks like a script interpreter. It consists basically of two threads: The first one read an instructions sequence and tells the second thread to run it step to step. In order to do this the second thread uses a small functions set with well defined code blocks. Here's the example in pseudocode:

// the well-defined functions are functional blocks of code and have
// the same signature, allowing the creation of a pointer array to them
void WellDefinedFunction1( args );
void WellDefinedFunction2( args );
void WellDefinedFunction3( args );
//...
void WellDefinedFunctionN( args );
 
// this thread stays forever waiting execution commands from some
// well-defined function. the parameter that it receives is the function number
void ExecutionThread()
{
	// 2. ad aeternum
	while( true )
	{
		// 5. it runs some well-defined function by number
		ExecuteWellDefinedFunction( functionNumber );
	}
}
 
// the well-defined functions script is an integer array indicating 
// the number for the next function that is going to be called
int FunctionsToBeCalled[] = { 3, 4, 1, 2, 34, 66, 982, n };
 
int Start()
{
	// 1. we create the thread that is going to run commands
	CreateThread( ExecutionThread );
 
	// 3. for each script item (each function number)
	for( int i = 0; i < sizeof(FunctionsToBeCalled); ++i )
	{
		// 4. tells the thread to run the function number N
		TellExecutionThreadToExecuteWellDefinedFunction( FunctionToBeCalled[i] );
	}
 
	// 6. end of execution.
	return 0;
}

The protection isn't there yet. But it will as intrinsic part of the execution thread. All we need to do is to add a exception handling and to throw lots of int 3. The thrown exceptions are caught by a second function that runs the instruction before to returning:

// filter exceptions that were thrown by the thread below
DWORD ExceptionFilterButExecuteWellDefinedFunction()
{
	// 5. run some well-defined function by number
	ExecuteWellDefinedFunction( number );
 
	return EXCEPTION_EXECUTE_HANDLER; // goes to except code
}
 
// this thread stays forever waiting execution commands from a 
// well-defined function. its "parameter" is the function number
void ExecutionThread()
{
	// 2. ad aeternum
	while( true )
	{
		__try
		{
			__asm int 3 // breakpoint exception
 
			// it stops the debugger if we have an attached debugger in
			// the process, or throws an exception if there is no one
		}
		__except( ExceptionFilterButExecuteWellDefinedFunction() )
		{
			// it does nothing. here is NOT where is the code (obvious, huh?)
		}
 
		Sleep( someTime ); // give some time
	}
}

The execution thread algorithm is the same. Just the point where each instruction is executed depends to the exception throw system. Note that this exception has to be thrown in order to the next instruction run. This is fundamental, since this way nobody can just rip of the int 3 code to avoid the exception. If one does that, so no instruction will be executed at all.

In practice, if one tries to debug such a program one will have to deal with tons of exceptions until find out what's happening. Of course, as in every software protection, is's not definitive; it has as a purpose to make hard the reverse engineering understanding. That's not going to stop those who are really good doing that stuff.

Nothing is for free

The price paid for this protection stays on the source code visibility and understanding, compromised by the use of this technique. The programming is state machine based, and the functions are limited to some kind of behavior standard. So much smaller the code blocks inside the minifunctions, so much hard the code understanding will be.

The example bellow receives input through a command prompt and maps the first word typed to the function that must be called. The rest of the typed line is passed as arguments to the functions. The interpreter thread reads the user input and writes into a global string variable, at the same time the executor thread waits the string to be completed to starts the action. It was used the variable pool to let the code simpler, but the ideal would be some kind of synchronise, just like events, by example. You can download the source code here.

/** @brief Sample demonstrating how to implemente antidebug in a code exception based.
@date jul-2007
@author Wanderley Caloni
*/
#include <windows.h>
 
#include <iostream>
#include <map>
#include <sstream>
 
#include <string>
#include <stdlib.h>
 
using namespace std;
 
// show available commands
bool Help(const string&)
{
 
   cout << "AntiDebug Test Program\n"
      << " Echo string to be printed\n"
      << " System command [params]\n"
      << " Quit\n\n";
   return true;
}
 
// run system/shell command
bool System(const string& cmd)
{
   system(cmd.c_str());
   return true;
}
 
// print string to output
bool Echo(const string& str)
{
   cout << str << endl;
   return true;
}
 
// quit program
bool Quit(const string&)
{
   exit(0);
   return false;
}
 
// minifunctions array
bool (* (g_miniFuncs[]) )(const string&) = { Help, System, Echo, Quit };
 
// "minifunction -> index" mapping
map<string, int> g_miniFuncIdx;
 
// start minifunctions mapping
void InitializeMiniFuncIdx()
{
   g_miniFuncIdx["Help"] = 0;
   g_miniFuncIdx["System"] = 1;
   g_miniFuncIdx["Echo"] = 2;
   g_miniFuncIdx["Quit"] = 3;
}
 
// last line read from input
string g_currentLine;
 
// how much time are we going to wait for the next line?
const DWORD g_waitTime = 1000;
 
// run minifunctions
DWORD FilterException()
{
   DWORD ret = EXCEPTION_CONTINUE_EXECUTION;
 
   if( ! g_currentLine.empty() )
   {
      istringstream line(g_currentLine);
      g_currentLine.clear();
 
      string function;
      string params;
 
      line >> function;
 
      getline(line, params);
 
      // 5. run some well-defined function by number
      if( ! g_miniFuncs[g_miniFuncIdx[function] ](params) )
         ret = EXCEPTION_CONTINUE_SEARCH;
   }
 
   return ret;
}
 
DWORD WINAPI AntiDebugThread(PVOID)
{
   InitializeMiniFuncIdx(); // start minifunction mapping
 
   // 2. ad aeternum (or almost)
   while( true )
 
   {
      //FilterException();
 
      __try // the extern try waits for an exit command
      {
         __try // the intern try stays generating exceptions continuously
         {
            __asm int 3
         }
         // FilterException is the function who runs minifunctions
         __except( FilterException() )
         {
				// we can put some fake code here
         }
      }
      __except( EXCEPTION_EXECUTE_HANDLER )
      {
         break; // get out from ad aeternum (to the limbo?)
      }
 
      Sleep(g_waitTime);
   }
 
   return ERROR_SUCCESS;
}
 
/** and God said: 'int main!'
*/
int main()
{
 
   DWORD ret = ERROR_SUCCESS;
   DWORD tid = 0;
   HANDLE antiDebugThr;
 
   // 1. we create the thread that is going to run the commands
   antiDebugThr = CreateThread(NULL, 0, AntiDebugThread, NULL, 0, &tid);;
 
   if( antiDebugThr )
   {
      // 3. for each item in the script (function numbers)
      while( cin )
      {
         cout << "Type something\n";
 
         // 4. tells the thread to run the function number N
         getline(cin, g_currentLine);
 
         if( WaitForSingleObject(antiDebugThr, g_waitTime * 2) != WAIT_TIMEOUT )
            break;
      }
 
      GetExitCodeThread(antiDebugThr, &ret);
      CloseHandle(antiDebugThr), antiDebugThr = NULL;
   }
 
   // 6. end of execution.
   return (int) ret;
}

The strength in this protection is to confound the attacker easily in the first steps (days, months...). Its weakness is the simplicity for the solution, since the attacker eventually realize what is going on. It is so easy that I will let it as an exercise for my readers.

In the next part we will se an alternative to make the code clearer and easy to use in the every day by a security software developer.

Today I’ve figured out a pretty interesting shortcut to achieve it.

Service Controller (or SC)

An Alex Ionescu article talks about this command line application used to create, initiate and remove services. Even not being the article focus, I found the information pretty useful, since I didn’t know such app. Soon some ideas starting to born in my mind:

“What if I used this guy to run notepad?”

Well, the Notepad is the default test victim. Soon, the following line would prove possible to run it in the system account:

sc create Notepad binpath= "%systemroot%\NOTEPAD.EXE" type= interact type= own

However, as every service, it is supposed to communicate with the Windows Service Manager. Since Notepad even “knows” it is now a superpowerful service, the service initialization time is expired and SCM kills the process.

>net start notepad
The service is not responding to the control function.

More help is available by typing NET HELPMSG 2186.

As would say my friend Thiago, “not good”.

“Yet however”, SCM doesn’t kill the child processes from the service-process. Bug? Feature? Workaround? Whatever it is, it can be used to initiate our beloved msvcmon:

set binpath=%systemroot%\system32\cmd.exe /c c:\Tools\msvcmon.exe -tcpip -anyuser -timeout -1
sc create Msvcmon binpath= "%binpath%" type= interact type= own

Now, when we start Msvcmon service, the process cmd.exe will be create, that on the other hand will run the msvcmon.exe target process. Cmd in this case will only wait for its imminent death.

Let's imagine a trace macro that's enabled in debug mode, whilst kept in silence in release builds:

#ifdef NDEBUG
 
#define MYTRACE( message ) /* nothing */
 
#else
 
#define MYTRACE( message )        \
	{                              \
		char buffer[500];           \
		sprintf(buffer,             \
			"MYTRACE: %s(%d) %s\n",  \
			__FILE__,                \
			__LINE__,                \
			message);                \
		OutputDebugString(buffer);  \
	}
 
#endif /* NDEBUG */ 
 

Nothing much, but it seems to work. But, as we going to see in the following lines, it is really a buggy piece of code, since a call inside an if-else construction simply doesn't work.

if( exploded() )
	MYTRACE("Oh, my God");
else
	MYTRACE("That's right");

error C2181: illegal else without matching if

Why's that? In order to answer this question, we need to look closer into the result code from the preprocessor, just replacing the macro for its piece of code:

if( exploded() )
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"Oh, my God");
		OutputDebugString(buffer);
	};
else
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"That's right");
		OutputDebugString(buffer);
	};

So, that's why. When we call a macro, generally we use the funcion-call syntax, putting a semicolon in the end. This is the right way to call a function, but in the macro case, it's a disaster, because it creates two commands instead of one (an empty semicolon, despite doing nothing, it's a valid command). So that's what the compiler does:

if( instruction )
{
	/* a lot of comands */

} /* here I would expect an else or new instruction */

; /* a new command! okay, no else this time */

else /* wait! what this else is doing here without an if?!?! */
{
	/* more commands */
}

Think about the empty command as if it was a real command, what is the easier way to realize the compiler error:

if( error() )
{
	printf("error");
}

printf("here we go");

else /* llegal else without matching if! */
{
	printf("okay");
}

For this reason, the tradicional way to skip this common error is to use a valid construction who asks for a semicolon in the end. Fortunately, language C has such construction, and it is... right, the do-while!

do
{
	/* multiple commands here */
}
while( expression ) ; /* I expect a semicolon here, in order
                         to end the do-while instruction */

So we can rewrite our trace macro the right way, even being a funcky one:

#ifdef NDEBUG
 
#define MYTRACE( message ) /* nothing */
 
#else
 
#define MYTRACE( message )        \
	do                             \
	{                              \
		char buffer[500];           \
		sprintf(buffer,             \
			"MYTRACE: %s(%d) %s\n",  \
			__FILE__,                \
			__LINE__,                \
			message);                \
		printf(buffer);             \
	}                              \
	while( 0 )
 
#endif /* NDEBUG */ 
 

Using a do-while (with a false expression inside the test to execute the block just once) the if-else construction is allowed and working properly:

if( exploded() )
	do
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"Oh, my God");
		OutputDebugString(buffer);
	}
	while( 0 );
else
	do
	{
		char buffer[500];
		sprintf(buffer,
			"MYTRACE: %s(%d) %s\n",
			__FILE__,
			__LINE__,
			"That's right");
		OutputDebugString(buffer);
	}
	while( 0 );

Let's say you have to manage a big solution in Visual Studio made of more than 30 projects, and needs to rebuild all them. Suddenly, something goes wrong. The question is: how to discover, in a heartbeat, what project has failed?

Note that you need to enable "Regular Expressions" option in the Find Dialog (not shown here).

What I'm saying inside this regex is "find the first number different from zero followed by a space and the letters err". This lead us to the first project who has at least one error:

------ Build started: Project: FailedProj, Configuration: Release Win32 ------
Compiling...
stdafx.cpp
Compiling...
FailedProj.cpp
.\FailedProj.cpp(2477) : error C2039: 'Blablabla' : is not a member of 'IBlabla'
Build log was saved at "file://c:\Projects\...\Release\BuildLog.htm"
FailedProj - 2 error(s), 0 warning(s)

If you think "what about when a project generates more than 9 errors? the regex wouldn't be able to catch this case", well, you're right. Anyway, that's the quicker form to search for the unsuccessful project inside a big solution. A more complex yet complete regex would be:

[1-9][0-9]* err

For me, the first version is enough. It is faster to type, simpler to catch and solves my problem. I hope it can solve yours =)