ntquery

Windows 10: New Anti-Debug OutputDebugStringW

ntquery — Mon, 07 Sep 2015 17:52:54 +0000

Prior to Windows 10, OutputDebugStringW was only a dummy implementation. The function converted the input Unicode string to a simple Ansi string and calls the Ansi version of the function OutputDebugStringA internally. Now with Windows 10, Microsoft implemented the real Unicode function for OutputDebugString. Therefore, in the past it was enough to handle OutputDebugStringA for Anti-Anti-Debug purpose, now we have to defeat another Anti-Debug possibility.

The magic behind OutputDebugString is to raise an exception. This exception should be handled by a debugger and most debugger swallow this exception, so we can easily detect that the exception was swallowed by a debugger.

The simplified Ansi version of the function with implemented Anti-Debug:

void __stdcall _OutputDebugStringA(LPCSTR lpOutputString)
{
	ULONG_PTR args[2];
	args[0] = (ULONG_PTR)strlen(lpOutputString) + 1;
	args[1] = (ULONG_PTR)lpOutputString;

	__try
	{
		RaiseException(0x40010006, 0, 2, args);//DBG_PRINTEXCEPTION_C
		ShowMessageBox("DBG_PRINTEXCEPTION_C -> Debugger detected");
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		ShowMessageBox("DBG_PRINTEXCEPTION_C -> Debugger NOT detected");
	}
}

RaiseException is used to create an exception for the debugger. There are 2 special arguments for the debugger. The buffer and the length of the string. The exception code is 0x40010006 which is DBG_PRINTEXCEPTION_C.

Now the new simplified Unicode implementation for Windows 10 looks like this:

void __stdcall _OutputDebugStringW(LPCWSTR lpOutputString)
{
	char outputDebugStringBuffer[1000] = {0};
	WideCharToMultiByte(CP_ACP, 0, lpOutputString, -1, outputDebugStringBuffer, sizeof(outputDebugStringBuffer), 0, 0);

	ULONG_PTR args[4];

	//unicode
	args[0] = (ULONG_PTR)wcslen(lpOutputString) + 1;
	args[1] = (ULONG_PTR)lpOutputString;

	//ansi for compatibility
	args[2] = (ULONG_PTR)wcslen(lpOutputString) + 1;
	args[3] = (ULONG_PTR)outputDebugStringBuffer;

	__try
	{
		RaiseException(0x4001000A, 0, 4, args);//DBG_PRINTEXCEPTION_WIDE_C
		ShowMessageBox("DBG_PRINTEXCEPTION_WIDE_C -> Debugger detected");
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		ShowMessageBox("DBG_PRINTEXCEPTION_WIDE_C -> Debugger NOT detected");
	}
}

Windows creates a new exception with RaiseException: DBG_PRINTEXCEPTION_WIDE_C (0x4001000A). This new exception code needs 4 parameters. For backwards compatibility it also requests the Ansi version of the string.

Scylla and Api Set Map

ntquery — Mon, 31 Mar 2014 06:29:55 +0000

Microsoft introduced a new technique for API redirection with Windows 7. Microsoft splits the kernel32 functions in different DLLs e.g. api-ms-win-core-libraryloader-l1-1-0.dll. This special DLLs follow a strict naming convention. A special DLL called apisetschema.dll is injected in every process with the redirection information. It is possible to manually resolve these redirections but Scylla is not doing it manually right now. I tried to investigate this a little bit because Scylla didn’t/doesn’t work very well on Windows 8. I wrote a tool to manually parse these redirections and the result is surprising (read more here).

Windows 7 has 35 special DLLs for redirection (full list). This is not too much I guess… but now I looked at Windows 8 and Windows 8 has 356 redirections (full list). Ten times more redirections than Windows 7, so it looks like this technique becomes more and more important. I wasn’t aware of this until now. Microsoft also has 2 prefixes for this kind of dlls: “API-” and “EXT-” (ext stands for extension). I don’t know what the difference between extension and api is, but Scylla handles this wrong, because I thought that all DLLs start with “api-ms-win-“. I committed a little hotfix here: https://github.com/NtQuery/Scylla/commit/5bb28e45df7b8045b3176a4bd4c1fc156ff9a73d. But probably this is not enough, maybe I really need to resolve the redirections manually. Microsoft provides the full definition of the structures in the header file apiset.h

Source code and x86/x64 binaries of the parse tool here:
https://bitbucket.org/NtQuery/teststuff/src/19a44d1d6a0550c607b30c784cda078d15b24b3b/ApiSetMap.cpp?at=master
https://bitbucket.org/NtQuery/teststuff/downloads/ApiSetMap.rar

Anti-Debug NtQueryObject

ntquery — Sun, 30 Mar 2014 14:03:19 +0000

NtQueryObject is another example of a known and underestimated anti-debug measurement. Most anti-debug articles describe (here or here) that we must call NtQueryObject with the class ObjectAllTypesInformation (Index number 3, but the correct name is ObjectTypesInformation). This class will return a list with all existing object types. But it is much better to call this function with class index number 2 ObjectTypeInformation. ObjectTypeInformation will only return the type information of the supplied handle. So how to get a debug handle? We simply create our own debug handle. This technique is very powerful to detect any debugger and no anti-anti-debug tool/plugin is currently able to defeat this.

We simply create the debug handle with the NtCreateDebugObject API:

NTSYSCALLAPI
NTSTATUS
NTAPI
NtCreateDebugObject (
    OUT PHANDLE DebugObjectHandle,
    IN ACCESS_MASK DesiredAccess,
    IN POBJECT_ATTRIBUTES ObjectAttributes,
    IN ULONG Flags
);

The call is very simple and it could look like this:

	HANDLE debugObject;
	OBJECT_ATTRIBUTES oa;
	
	InitializeObjectAttributes(&oa,0,0,0,0);

	if (NtCreateDebugObject(&debugObject, DEBUG_ALL_ACCESS, &oa, 0) >= 0)

Now we have our own debug handle + object. Let’s query this handle with NtQueryObject:

		POBJECT_TYPE_INFORMATION objectType = (POBJECT_TYPE_INFORMATION)memory;
		if (NtQueryObject(debugObject, ObjectTypeInformation, objectType, sizeof(memory), 0) >= 0)
		{
			if (objectType->TotalNumberOfObjects == 1) //there must be 1 object...
			{
				ShowMessageBox("Everything is ok!");
			}
			else if (objectType->TotalNumberOfObjects == 0) //bad
			{
				ShowMessageBox("Anti-Anti-Debug Tool detected!");
			}
			else
			{
				ShowMessageBox("Debugger detected!\r\n\r\nTotalNumberOfHandles %d\r\nTotalNumberOfObjects %d\r\n", objectType->TotalNumberOfHandles, objectType->TotalNumberOfObjects);
			}
			
		}

If successful there are three possibilities. We know exactly that there must be 1 handle/object. If there are more objects, a debugger is present. It is also possible to detect anti-anti-debug tools because they probably return zero, but we know that this cannot be true!

Source code and x86/x64 binaries here:
https://bitbucket.org/NtQuery/teststuff/downloads/NtQueryObject.rar
https://bitbucket.org/NtQuery/teststuff/src/eb4adfbe5ccedd3e938b38434ae99ee42992994d/NtQueryObject.cpp?at=master

Anti-Debug Fiber Local Storage (FLS)

ntquery — Sat, 29 Mar 2014 14:50:53 +0000

Peter Ferrie mentioned a nice trick in his Anti-Debugging Reference article http://pferrie.host22.com/papers/antidebug.pdf with RtlProcessFlsData. He provided a “cryptic” example code in assembler. Although his example will work, there are a lot of open questions he doesn’t answer. His code is not usable in a productive environment and I wanted to demonstrate this trick with a more readable and solid example. This trick is very undocumented and I couldn’t find any further information with Google. This trick works since Vista. Fiber Local Storage (FLS) is similar to Thread Local storage (TLS), because a thread is created which can be used to execute some hidden stuff.

Let’s start with the function RtlProcessFlsData, the real declaration is unknown, but it must be similar to this:

NTSYSCALLAPI
NTSTATUS
NTAPI
RtlProcessFlsData (
	PRTL_UNKNOWN_FLS_DATA Buffer
);

The API takes some unknown struct pointer as parameter. The structure must be similar to this:

typedef struct _RTL_UNKNOWN_FLS_DATA {
	PVOID unk1;
	PVOID unk2;
	PVOID unk3;
	PVOID Argument;
} RTL_UNKNOWN_FLS_DATA,*PRTL_UNKNOWN_FLS_DATA;

Only one structure member is relevant for this anti-debug trick. The trick further involves the Process Environment Block (PEB). We must replace two values. Again, the declaration/definition is unknown and not documented.

First we must replace a callback structure inside the PEB. The structure could look like this:

typedef struct _FLS_CALLBACK {
	PVOID Unknown;
	PVOID StartAddress;
} FLS_CALLBACK, *PFLS_CALLBACK;

#define UNKNOWN_MAX_CALLBACKS 5

typedef struct _FLS_CALLBACK_INFO
{
	PVOID Unknown;
	FLS_CALLBACK Callbacks[UNKNOWN_MAX_CALLBACKS];
} FLS_CALLBACK_INFO, *PFLS_CALLBACK_INFO;

We can define different callback addresses which will be executed one by one. The second PEB manipulation is the number of callbacks we have in our structure.

A working example code for x64 and x86 can look like this:

	info.Callbacks[0].StartAddress = ContinueExecution;

	rtl.unk1 = UnknownReturnBuffer;
	rtl.unk2 = UnknownReturnBuffer;
	rtl.unk3 = UnknownReturnBuffer;
	rtl.Argument = (LPVOID)0x1337;

	DWORD_PTR pPeb = 0;
#ifdef _WIN64
#define PEB_FLS_CALLBACK_OFFSET 0x0320
#define PEB_FLS_NUMBERCALLBACKS_OFFSET 0x0350
	pPeb = (DWORD_PTR)__readgsqword(12 * sizeof(DWORD_PTR)); //PEB Address
#else
#define PEB_FLS_CALLBACK_OFFSET 0x020C
#define PEB_FLS_NUMBERCALLBACKS_OFFSET 0x022C
	pPeb = (DWORD_PTR)__readfsdword(12 * sizeof(DWORD_PTR)); //PEB Address
#endif

	pFlsNumberOfCallbacks = (ULONG *)(pPeb + PEB_FLS_NUMBERCALLBACKS_OFFSET);
	pFlsCallbackInfo = (DWORD_PTR *)(pPeb + PEB_FLS_CALLBACK_OFFSET);

	//backup
	backupFlsNumberOfCallbacks = *pFlsNumberOfCallbacks;
	backupFlsCallback = *pFlsCallbackInfo;

	//we have only 1 callback in the struct
	*pFlsCallbackInfo = (DWORD_PTR)&info;
	*pFlsNumberOfCallbacks = 1;

	RtlProcessFlsData(&rtl);
	
	//restore everything like nothing happened
	*pFlsCallbackInfo = backupFlsCallback;
	*pFlsNumberOfCallbacks = backupFlsNumberOfCallbacks;

We must fill the RTL_UNKNOWN_FLS_DATA structure with the thread argument and some return buffer. In the FLS_CALLBACK_INFO structure we only have to fill in our thread start address. After RtlProcessFlsData, we should restore the original values in the PEB.

Source code and binaries here:
https://bitbucket.org/NtQuery/teststuff/downloads/RtlProcessFlsData.rar
https://bitbucket.org/NtQuery/teststuff/src/bf9561261acb36bf992f0da2ca143d531086aa01/RtlProcessFlsData.cpp?at=master

Anti-Debug NtCreateThreadEx

ntquery — Sat, 29 Mar 2014 12:18:39 +0000

NtCreateThreadEx is a new API since Vista and it is very powerful. It is mostly used for DLL injection, but it can be used as an anti-debug trick aswell. No anti-anti-debug tool/plugin can defeat this.

NtCreateThreadEx lets you create a new thread, but the important feature is the CreateFlags parameter. The API declaration looks like this:

NTSYSCALLAPI
NTSTATUS
NTAPI
NtCreateThreadEx (
    _Out_ PHANDLE ThreadHandle,
    _In_ ACCESS_MASK DesiredAccess,
    _In_opt_ POBJECT_ATTRIBUTES ObjectAttributes,
    _In_ HANDLE ProcessHandle,
    _In_ PVOID StartRoutine,
    _In_opt_ PVOID Argument,
    _In_ ULONG CreateFlags,
    _In_opt_ ULONG_PTR ZeroBits,
    _In_opt_ SIZE_T StackSize,
    _In_opt_ SIZE_T MaximumStackSize,
    _In_opt_ PVOID AttributeList
);

The CreateFlags can be the following:

//SOURCE: http://processhacker.sourceforge.net/doc/ntpsapi_8h_source.html
#define THREAD_CREATE_FLAGS_CREATE_SUSPENDED 0x00000001
#define THREAD_CREATE_FLAGS_SKIP_THREAD_ATTACH 0x00000002 // ?
#define THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER 0x00000004
#define THREAD_CREATE_FLAGS_HAS_SECURITY_DESCRIPTOR 0x00000010 // ?
#define THREAD_CREATE_FLAGS_ACCESS_CHECK_IN_TARGET 0x00000020 // ?
#define THREAD_CREATE_FLAGS_INITIAL_THREAD 0x00000080

So with the THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER flag we can hide our newly created thread without calling NtSetInformationThread like demonstrated in my previous blog article.

Example code can look like this:

int CALLBACK WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
	HANDLE hThread = 0;
	NTSTATUS ntStat = NtCreateThreadEx(&hThread, THREAD_ALL_ACCESS_VISTA, 0, NtCurrentProcess, (LPTHREAD_START_ROUTINE)ContinueExecution, 0, THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER, 0, 0, 0, 0);
	if (ntStat >= 0)
	{
		WaitForSingleObject(hThread, INFINITE);
	}
	else
	{
		ShowMessageBox("NtCreateThreadEx failed!");
	}
	return 0;
}

void WINAPI ContinueExecution(LPVOID param)
{
	BOOLEAN check = FALSE;

	ShowMessageBox("This thread is hidden from debugger!");

	if (NtQueryInformationThread(NtCurrentThread, ThreadHideFromDebugger, &check, sizeof(BOOLEAN), 0) >= 0)
	{
		if (!check)
		{
			ShowMessageBox("Anti-Anti-Debug Tool detected!\n");
		}
		else
		{
			ShowMessageBox("Everything ok!\n");
		}
	}
	else
	{
		ShowMessageBox("Query ThreadHideFromDebugger not available!\n");
	}
}

Source code and binaries here:
https://bitbucket.org/NtQuery/teststuff/downloads/NtCreateThreadEx.rar
https://bitbucket.org/NtQuery/teststuff/src/7745ace377dfe6f63f455b51ab2917815c28e59b/NtCreateThreadEx.cpp?at=master

Anti-Debug NtSetInformationThread

ntquery — Sat, 29 Mar 2014 11:38:47 +0000

Most people who work with debuggers don’t really care about anti-debug tricks, because there are plenty of anti-anti-debug plugins e.g. StrongOD, Phantom, Stealth64, IdaStealth, HideDebugger, etc. and they do a great job against standard anti-debug tricks found in “anti-debug reference” articles (e.g. here). But most anti-debug articles simply copy & paste known source code without adjusting it. Most tricks work fine with Windows XP, but don’t work with Windows Vista/7/8, e.g. one of the worst anti-debug trick ever is kernel32!OutputDebugString. And some other known tricks can be updated and improved to work even better with Vista/7/8.

A side note: Microsoft will drop all updates for Windows XP on 8. April 2014. Most reverser use XP for reversing and most software is still working fine on XP. But this will change soon. Starting from this date, protector/software developers could drop XP support entirely, so anti-debug tricks for Vista+ will become more and more important.

So now I want to show you an updated known anti-debug trick: NtSetInformationThread. In my opinion this API offers one of the best anti-debug tricks you can find. All current existing anti-anti-debug plugins handle this API wrong, so it is very easy to detect debuggers.

	//invalid parameter
	ntStat = NtSetInformationThread(NtCurrentThread, ThreadHideFromDebugger, &check, sizeof(ULONG));
	if (ntStat >= 0) //it must fail
	{
		ShowMessageBox("Anti-Anti-Debug Tool detected 1!\n");
	}

	//invalid handle
	ntStat = NtSetInformationThread((HANDLE)0xFFFFF, ThreadHideFromDebugger, 0, 0);
	if (ntStat >= 0) //it must fail
	{
		ShowMessageBox("Anti-Anti-Debug Tool detected 2!\n");
	}

	ntStat = NtSetInformationThread(NtCurrentThread, ThreadHideFromDebugger, 0, 0);

	if (ntStat >= 0)
	{
		//only available >= VISTA
		ntStat = NtQueryInformationThread(NtCurrentThread, ThreadHideFromDebugger, &check, sizeof(BOOLEAN), 0);
		if (ntStat >= 0)
		{
			if (!check)
			{
				ShowMessageBox("Anti-Anti-Debug Tool detected 3!\n");
			}
			else
			{
				ShowMessageBox("Everything ok!\n");
			}
		}
		else
		{
			ShowMessageBox("Query ThreadHideFromDebugger not available!\n");
		}
	}
	else
	{
		ShowMessageBox("Anti-Anti-Debug Tool detected 4!\n");
	}

We call NtSetInformationThread two times with wrong parameters and this will reveal most anti-anti-debug plugins. Since Vista it is possible to use NtQueryInformationThread and this makes it much more powerful. Currently no anti-anti-debug plugin is hooking NtQueryInformationThread to prevent this check.

Source code and binaries can be downloaded here:
https://bitbucket.org/NtQuery/teststuff/downloads/NtSetInformationThread.rar
https://bitbucket.org/NtQuery/teststuff/src/d2ade28bd7ea941a897cf7a5d452c4df29603986/NtSetInformationThread.cpp?at=master

New RCE Blog!

ntquery — Sat, 29 Mar 2014 10:02:10 +0000

Now I have a blog too.

Visit my code projects here:

https://bitbucket.org/NtQuery

https://github.com/NtQuery/Scylla