[Frage] Memory

[.SnoX]

Hey,

ich brauche da ein wenig hilfe bei der denkweise um etwas umzusetzen.

Undzwar habe ich ein Programm was ich gerne ein wenig absichern möchte.
Das große Problem besteht darin, das alle meine memory page nach belieben ändern können like CE oder ollydbg. Dies möchte ich nun verhindern indem ich das memory editing like ReadProzessMemory WriteProcessMemory blocken möchte. Schön ung gut, würde sagen aus dem Bauch heraus, ich assoziiere eine neue Memory Page, lasse sie so wie sie ist einfach im Speicher und rufe dauernt QueryWorkingSet auf, wenn sie dann bereits initialisiert wurde.. machts boom und mein Programm schließt sich oder what ever.

Das problem ist ich brauche da ein paar Tipps wie ich das ganze umsetzen könnte, vielleicht hat wer ein Link oder sonstige denkhilfen ect. Vielleicht auch eine bessere Methode.

[bloodx]

mhm, den Memory bereich um den es geht auf Veränderungen Prüfen regelmäßig ?

[buFFy!]

Wird auf user-ebene nicht klappen. Idealerweise schreibst du gleich ne eigene VM.
Man hat immer die Option der statischen Analyse oder das Erstellen eines suspendierten Prozesses.

[Master674b]

Originally Posted by .SnoX

Hey,

ich brauche da ein wenig hilfe bei der denkweise um etwas umzusetzen.

Undzwar habe ich ein Programm was ich gerne ein wenig absichern möchte.
Das große Problem besteht darin, das alle meine memory page nach belieben ändern können like CE oder ollydbg. Dies möchte ich nun verhindern indem ich das memory editing like ReadProzessMemory WriteProcessMemory blocken möchte. Schön ung gut, würde sagen aus dem Bauch heraus, ich assoziiere eine neue Memory Page, lasse sie so wie sie ist einfach im Speicher und rufe dauernt QueryWorkingSet auf, wenn sie dann bereits initialisiert wurde.. machts boom und mein Programm schließt sich oder what ever.

Das problem ist ich brauche da ein paar Tipps wie ich das ganze umsetzen könnte, vielleicht hat wer ein Link oder sonstige denkhilfen ect. Vielleicht auch eine bessere Methode.

Hey, welche Infos brauchst du? Ich hatte das mit der QueryWorkingSet Methode vor ner Weile hier schon mal erwähnt, das könnte allerdings leicht in die Hose gehen, wenn irgend eine aggressive Antiviren-SW installiert ist, oder ein Treiber der aus irgend einem Grund über deinen Speicher geht.

Du könntest sonst noch mit den NT-APIs die Prozesshandles durchgehen und schauen ob ein anderer Prozess eine Handle auf deinen Prozess hat, falls ja nimmst du sie ihm weg. Das geht über DuplicateHandle mit DUPLICATE_CLOSE_SOURCE.

Dann kannst du wenn du das richtig umsetzt den Prozess nicht mehr lange genug aufhalten, da du dem Prozess andauernd die Handle wegnimmst.

[buFFy!]

Originally Posted by Master674b

Hey, welche Infos brauchst du? Ich hatte das mit der QueryWorkingSet Methode vor ner Weile hier schon mal erwähnt, das könnte allerdings leicht in die Hose gehen, wenn irgend eine aggressive Antiviren-SW installiert ist, oder ein Treiber der aus irgend einem Grund über deinen Speicher geht.

Du könntest sonst noch mit den NT-APIs die Prozesshandles durchgehen und schauen ob ein anderer Prozess eine Handle auf deinen Prozess hat, falls ja nimmst du sie ihm weg. Das geht über DuplicateHandle mit DUPLICATE_CLOSE_SOURCE.

Dann kannst du wenn du das richtig umsetzt den Prozess nicht mehr lange genug aufhalten, da du dem Prozess andauernd die Handle wegnimmst.

Und an dieser Stelle tritt dann wieder mein Post in Kraft.
Außerdem nimmt DuplicateHandle 'nen handle zum Prozess - genau die gleiche Technik kann der "angreifende" Prozess nutzen um dich daran zu hindern sein handle zu schließen

Bin mir auch nicht sicher, aber ich glaube DUPLICATE_CLOSE_SOURCE geht nicht wenn du dein eigenes, offenes handle zum Prozess mit HANDLE_FLAG_PROTECT_FROM_CLOSE flagst.

[Master674b]

Originally Posted by buFFy!

Und an dieser Stelle tritt dann wieder mein Post in Kraft.
Außerdem nimmt DuplicateHandle 'nen handle zum Prozess - genau die gleiche Technik kann der "angreifende" Prozess nutzen um dich daran zu hindern sein handle zu schließen

Bin mir auch nicht sicher, aber ich glaube DUPLICATE_CLOSE_SOURCE geht nicht wenn du dein eigenes, offenes handle zum Prozess mit HANDLE_FLAG_PROTECT_FROM_CLOSE flagst.

Hey, selbstverständlich könnte er dich auch damit bekämpfen. Anti-Debugging Techniken bleiben immer ein Katz-und-Mausspiel.

Wenn dein Gegenüber weiß, was du machst kann er es sowieso im Handumdrehen umgehen. Der Trick ist einfach Dinge zu verwenden auf die man nicht so leicht kommt und die nicht so verbreitet sind.

[.SnoX]

Hey danke erstmal für die Informationen, dass das mit QueryWorkingSet auch schnell in die Hose gehen kann, wie das hier schon erwähnt wurde, ist mir auch bewusst. Dachte allerdings das wäre eine "gute" Methode um mein Problem zu verhindern.

Bin ja auch noch recht neu auf diesem Gebiet, weil ich auch noch nicht viel daran arbeiten musste, deswegen wollte ich euch mal Fragen was ihr empfehlen würdet.

Ich bin gerade noch gerade am googeln, und schaue mir die zwei Sachen an. Falls jemand da ein "schlichtes" Beispiel gerade hat, wäre das sehr hilfreich.

Ansonsten bin ich auch noch für alternativen gerne zu haben.

[Lazeboy]

Originally Posted by Master674b

Hey, welche Infos brauchst du? Ich hatte das mit der QueryWorkingSet Methode vor ner Weile hier schon mal erwähnt, das könnte allerdings leicht in die Hose gehen, wenn irgend eine aggressive Antiviren-SW installiert ist, oder ein Treiber der aus irgend einem Grund über deinen Speicher geht.

Du könntest sonst noch mit den NT-APIs die Prozesshandles durchgehen und schauen ob ein anderer Prozess eine Handle auf deinen Prozess hat, falls ja nimmst du sie ihm weg. Das geht über DuplicateHandle mit DUPLICATE_CLOSE_SOURCE.

Dann kannst du wenn du das richtig umsetzt den Prozess nicht mehr lange genug aufhalten, da du dem Prozess andauernd die Handle wegnimmst.

Kannst auch falls du ein offenen Handle zu deinem Process findest ne Dll injecten, die Read/WriteProcessMemory blockt sobald als Parameter ein Handle zu deinem Process übergeben wird. Über den Handle kommste mit NtQueryInformationProcess an die Prozess-ID und darüber dann an Namen

[Schlüsselbein]

Erstmal solltest du dir Gedanken über Aufwand/Nutzen (ggf. auch Kosten/Nutzen) machen. Ist es nur ein 0815-Tool, dass hier auf epvp landet, kannst es sowieso direkt lassen. Wenn es was "größeres" wird, solltest du eher mit gutem Support glänzen und somit die Kunden holen.
Wer es geknackt haben möchte, knackt es - da lohnt es sich meist nicht, so viel Arbeit in einen Schutz zu stecken.
Das erstmal zum Cracken.

Wenn es dir darum geht, dein Spiel vor Hacks/Cheats zu sichern, bleibt dir eigentlich nur, alles wichtige auf einen Server auszulagern.

[Slicktor]

Mit einem BaseThreadInitThunk hook ist so einiges möglich:

Sollte eine Dll mit CreateRemoteThread injected werden, kannst du das leicht checken.
Beispiel(im Hook):

if (pfnExecuteAddr == GetProcAddress(GetModuleHandle("Kernel32.dll"),"LoadLibraryA")   ||
    pfnExecuteAddr ==  GetProcAddress(GetModuleHandle("Kernel32.dll"),"LoadLibraryW"))

Sollte ein Debugger (Ollydbg) life attachen, könntest du auch einfach mal prüfen, ob die AusführungsAddresse DbgUiRemoteBreakin ist und einfach zu 0 jumpen (führt zum crash, aber da ollydbg den process debugged, wird es zu 0 gejumpt : Access Violation )

Beispiel(im Hook):

if (pfnExecuteAddr == GetProcAddress(GetModuleHandle("ntdll"), "DbgUiRemoteBreakin")){
		__asm mov eax, 0
		__asm jmp eax
}

Würde dir auch empfehlen die Handles zu closen.
Ansonsten könntest du den ganzen Speicher noch nach Modifikation checken.

[buFFy!]

Originally Posted by Master674b

Wenn dein Gegenüber weiß, was du machst kann er es sowieso im Handumdrehen umgehen.

Stimmt, ziemlich cool ist es hier übrigens alle Referenzen zu intermodular calls aufzulösen.
Das geht indem man sich über die modulelist die kernel32.dll holt und in dieser nach GetProcAddress sucht. Damit kann man sich dann den Rest holen, idealerweise mit compile-time string encryption odar gar stringhashs/patterns.

Beispiel für die Encryption aus privatem Archiv:

 Spoiler

#ifndef _ESTRING_H
#define _ESTRING_H

template<size_t N, size_t I>
struct XORImpl
{
	static char* XOR(char(&data)[N], char k)
	{
		data[I] ^= k;
		return XORImpl<N,I-1>::XOR(data, k);
	}
};

template<size_t N>
struct XORImpl<N, 0>
{
	static char* XOR(char(&data)[N], char k)
	{
		data[0] ^= k;
		return data;
	}
};

template<size_t N> char* XOR(char(&data)[N], char k)
{
	return XORImpl<N, N-2>::XOR(data, k);
}

template<size_t N> std::string XORRuntime(char(&data)[N], char k)
{
	char* res = new char[N];
	for (size_t i = 0; i < N-1; ++i)
		res[i] = data[i] ^ k;
	res[N - 1] = 0;

	std::string ret(res);
	delete[] res;

	return ret;
}

#endif

Originally Posted by Slicktor

Sollte ein Debugger (Ollydbg) life attachen

Das kannst du auch viel leichter verhindern, einfach den PE Header deleten.
Das bringt so ziemlich jeden Debugger ohne built-in/plugged-in PE Fix zum crashen oder Error's schmeißen.

Generell lässt sich aber sagen, was Schlüsselbein bereits betont hat.
Es geht nicht darum, das Programm komplett zu sichern - geht auch garnicht.
Dein Ziel sollte maximal sein, die Software so zu sichern, dass sich das Cracken nicht mehr lohnt.

Wie bereits vorher von mir erwähnt finde ich persönlich das Virtualisieren des eigenen Codes am effizientesten (z.B. VMProtect).
Auch sehr nett kann self-attaching sein - richtig implementiert wahrscheinlich die beste Lösung für epvp Releases.

Hab auf CodeProject mal vor Ewigkeiten nen interessanten Thread gefunden, der könnte was für dich sein:

[Master674b]

Originally Posted by buFFy!

Stimmt, ziemlich cool ist es hier übrigens alle Referenzen zu intermodular calls aufzulösen.
Das geht indem man sich über die modulelist die kernel32.dll holt und in dieser nach GetProcAddress sucht. Damit kann man sich dann den Rest holen, idealerweise mit compile-time string encryption odar gar stringhashs/patterns.

Beispiel für die Encryption aus privatem Archiv:

 Spoiler

#ifndef _ESTRING_H
#define _ESTRING_H

template<size_t N, size_t I>
struct XORImpl
{
	static char* XOR(char(&data)[N], char k)
	{
		data[I] ^= k;
		return XORImpl<N,I-1>::XOR(data, k);
	}
};

template<size_t N>
struct XORImpl<N, 0>
{
	static char* XOR(char(&data)[N], char k)
	{
		data[0] ^= k;
		return data;
	}
};

template<size_t N> char* XOR(char(&data)[N], char k)
{
	return XORImpl<N, N-2>::XOR(data, k);
}

template<size_t N> std::string XORRuntime(char(&data)[N], char k)
{
	char* res = new char[N];
	for (size_t i = 0; i < N-1; ++i)
		res[i] = data[i] ^ k;
	res[N - 1] = 0;

	std::string ret(res);
	delete[] res;

	return ret;
}

#endif

Das kannst du auch viel leichter verhindern, einfach den PE Header deleten.
Das bringt so ziemlich jeden Debugger ohne built-in/plugged-in PE Fix zum crashen oder Error's schmeißen.

Generell lässt sich aber sagen, was Schlüsselbein bereits betont hat.
Es geht nicht darum, das Programm komplett zu sichern - geht auch garnicht.
Dein Ziel sollte maximal sein, die Software so zu sichern, dass sich das Cracken nicht mehr lohnt.

Wie bereits vorher von mir erwähnt finde ich persönlich das Virtualisieren des eigenen Codes am effizientesten (z.B. VMProtect).
Auch sehr nett kann self-attaching sein - richtig implementiert wahrscheinlich die beste Lösung für epvp Releases.

Hab auf CodeProject mal vor Ewigkeiten nen interessanten Thread gefunden, der könnte was für dich sein:

Noch besser: Ein eigenes GetProcAddress. Dort sollte man dann aber aufpassen. Windows PEs unterstützen Forwarded Exports, die muss man dann nochmals auflösen. Habe mir da Spaßeshalber mal GetModuleHandle und GetProcAddress nachgebaut, das ganze dann in ein Modul wie Warden gepackt (ohne CRT, extrem kompakt).

Sobald sich dann wer mit der Software Authentifiziert sende ich ihm das verschlüsselte Modul (hat nen custom PE header), der Client holt das über Manual Map rein und lädt das Modul und benutzt es, um die Authentifizierung abzuschließen.

Aber ich glaube ich verrate hier schon zu viel. Egal ist ja eh einfach ein Proof-of-Concept.

[.SnoX]

Wew, haha. Denke habe da erstmal genug Stoff bekommen.
Schaue mir natürlich alles durch, um zu sehen was objektiv gesehen für mich am besten geeignet ist. Falls jemand jetzt wissen wollte für welchen Bereich das wäre, wäre das fürs Gamehacking, bzw das live bearbeiten am memory like ce ect.

Aber postet ruhig weiter wissen ist macht, und das ist immer jut, zudem auch immer gern gesehen.

[buFFy!]

Originally Posted by Master674b

Noch besser: Ein eigenes GetProcAddress. Dort sollte man dann aber aufpassen. Windows PEs unterstützen Forwarded Exports, die muss man dann nochmals auflösen. Habe mir da Spaßeshalber mal GetModuleHandle und GetProcAddress nachgebaut, das ganze dann in ein Modul wie Warden gepackt (ohne CRT, extrem kompakt).

Sobald sich dann wer mit der Software Authentifiziert sende ich ihm das verschlüsselte Modul (hat nen custom PE header), der Client holt das über Manual Map rein und lädt das Modul und benutzt es, um die Authentifizierung abzuschließen.

Aber ich glaube ich verrate hier schon zu viel. Egal ist ja eh einfach ein Proof-of-Concept.

Jop, stimmt - so habe ich das damals auch mal implementiert.
Wobei das ewig her ist, kann sein dass die func nicht von mir ist.
Habs auf jeden Fall vor Ewigkeiten mal gebastelt - dieses ganze intermodular prevention Zeugs.

FARPROC customWINAPI::GetProcAddress(HMODULE hModule, LPCSTR lpProcName)
{
	UINT_PTR uiLibraryAddress = 0;
	FARPROC fpResult          = NULL;

	if( hModule == NULL )
		return NULL;

	uiLibraryAddress = (UINT_PTR)hModule;

	__try
	{
		UINT_PTR uiAddressArray = 0;
		UINT_PTR uiNameArray    = 0;
		UINT_PTR uiNameOrdinals = 0;
		PIMAGE_NT_HEADERS pNtHeaders             = NULL;
		PIMAGE_DATA_DIRECTORY pDataDirectory     = NULL;
		PIMAGE_EXPORT_DIRECTORY pExportDirectory = NULL;

		pNtHeaders = (PIMAGE_NT_HEADERS)(uiLibraryAddress + ((PIMAGE_DOS_HEADER)uiLibraryAddress)->e_lfanew);

		pDataDirectory = (PIMAGE_DATA_DIRECTORY)&pNtHeaders->OptionalHeader.DataDirectory[ IMAGE_DIRECTORY_ENTRY_EXPORT ];

		pExportDirectory = (PIMAGE_EXPORT_DIRECTORY)( uiLibraryAddress + pDataDirectory->VirtualAddress );

		uiAddressArray = ( uiLibraryAddress + pExportDirectory->AddressOfFunctions );
		uiNameArray = ( uiLibraryAddress + pExportDirectory->AddressOfNames );
		uiNameOrdinals = ( uiLibraryAddress + pExportDirectory->AddressOfNameOrdinals );

		if( ((DWORD)lpProcName & 0xFFFF0000 ) == 0x00000000 )
		{
			uiAddressArray += ( ( IMAGE_ORDINAL( (DWORD)lpProcName ) - pExportDirectory->Base ) * sizeof(DWORD) );

			fpResult = (FARPROC)( uiLibraryAddress + DEREF_32(uiAddressArray) );
		}
		else
		{
			DWORD dwCounter = pExportDirectory->NumberOfNames;
			while( dwCounter-- )
			{
				char * cpExportedFunctionName = (char *)(uiLibraryAddress + DEREF_32( uiNameArray ));

				if( strcmp( cpExportedFunctionName, lpProcName ) == 0 )
				{
					uiAddressArray += ( DEREF_16( uiNameOrdinals ) * sizeof(DWORD) );
					fpResult = (FARPROC)(uiLibraryAddress + DEREF_32( uiAddressArray ));

					break;
				}

				uiNameArray += sizeof(DWORD);

				uiNameOrdinals += sizeof(WORD);
			}
		}
	}
	__except( EXCEPTION_EXECUTE_HANDLER )
	{
		fpResult = NULL;
	}

	return fpResult;
}

[Master674b]

Originally Posted by buFFy!

Jop, stimmt - so habe ich das damals auch mal implementiert.
Wobei das ewig her ist, kann sein dass die func nicht von mir ist.
Habs auf jeden Fall vor Ewigkeiten mal gebastelt - dieses ganze intermodular prevention Zeugs.

FARPROC customWINAPI::GetProcAddress(HMODULE hModule, LPCSTR lpProcName)
{
	UINT_PTR uiLibraryAddress = 0;
	FARPROC fpResult          = NULL;

	if( hModule == NULL )
		return NULL;

	uiLibraryAddress = (UINT_PTR)hModule;

	__try
	{
		UINT_PTR uiAddressArray = 0;
		UINT_PTR uiNameArray    = 0;
		UINT_PTR uiNameOrdinals = 0;
		PIMAGE_NT_HEADERS pNtHeaders             = NULL;
		PIMAGE_DATA_DIRECTORY pDataDirectory     = NULL;
		PIMAGE_EXPORT_DIRECTORY pExportDirectory = NULL;

		pNtHeaders = (PIMAGE_NT_HEADERS)(uiLibraryAddress + ((PIMAGE_DOS_HEADER)uiLibraryAddress)->e_lfanew);

		pDataDirectory = (PIMAGE_DATA_DIRECTORY)&pNtHeaders->OptionalHeader.DataDirectory[ IMAGE_DIRECTORY_ENTRY_EXPORT ];

		pExportDirectory = (PIMAGE_EXPORT_DIRECTORY)( uiLibraryAddress + pDataDirectory->VirtualAddress );

		uiAddressArray = ( uiLibraryAddress + pExportDirectory->AddressOfFunctions );
		uiNameArray = ( uiLibraryAddress + pExportDirectory->AddressOfNames );
		uiNameOrdinals = ( uiLibraryAddress + pExportDirectory->AddressOfNameOrdinals );

		if( ((DWORD)lpProcName & 0xFFFF0000 ) == 0x00000000 )
		{
			uiAddressArray += ( ( IMAGE_ORDINAL( (DWORD)lpProcName ) - pExportDirectory->Base ) * sizeof(DWORD) );

			fpResult = (FARPROC)( uiLibraryAddress + DEREF_32(uiAddressArray) );
		}
		else
		{
			DWORD dwCounter = pExportDirectory->NumberOfNames;
			while( dwCounter-- )
			{
				char * cpExportedFunctionName = (char *)(uiLibraryAddress + DEREF_32( uiNameArray ));

				if( strcmp( cpExportedFunctionName, lpProcName ) == 0 )
				{
					uiAddressArray += ( DEREF_16( uiNameOrdinals ) * sizeof(DWORD) );
					fpResult = (FARPROC)(uiLibraryAddress + DEREF_32( uiAddressArray ));

					break;
				}

				uiNameArray += sizeof(DWORD);

				uiNameOrdinals += sizeof(WORD);
			}
		}
	}
	__except( EXCEPTION_EXECUTE_HANDLER )
	{
		fpResult = NULL;
	}

	return fpResult;
}

Hm du behandelst jedenfalls Forward RVAs nicht richtig. Es gibt 2 Typen von Forwards. Ordinal Forwards und direkte Funktionsforwards. Ordinal-Forwards sehen etwa so aus:

ntdll.#24

das wäre die 24. exportierte Funktion in ntdll.

Hier mein Code dafür:

PVOID getProcAddress(HMODULE hModule, LPCSTR lpProcName) {
	PIMAGE_DOS_HEADER pDosHeader = (PIMAGE_DOS_HEADER) hModule;
	if (!pDosHeader || pDosHeader->e_magic != 0x5A4D)
		return NULL;

	PIMAGE_NT_HEADERS pNtHeaders = (PIMAGE_NT_HEADERS) ((DWORD_PTR) hModule + pDosHeader->e_lfanew);
	if (!pNtHeaders)
		return NULL;

	PIMAGE_DATA_DIRECTORY pExportData = &pNtHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
	if (!pExportData->Size)
		return NULL; // Module does not have any exports

	PVOID pFunction = NULL;
	PIMAGE_EXPORT_DIRECTORY pExportDir = (PIMAGE_EXPORT_DIRECTORY) ((DWORD_PTR) hModule + pExportData->VirtualAddress);
	PDWORD pFunctions = (PDWORD) ((DWORD_PTR) hModule + pExportDir->AddressOfFunctions);

	// Get function by name
	if ((DWORD_PTR) lpProcName > pExportDir->NumberOfFunctions) {
		PDWORD pNames = (PDWORD) ((DWORD_PTR) hModule + pExportDir->AddressOfNames);
		PWORD pOrdinals = (PWORD) ((DWORD_PTR) hModule + pExportDir->AddressOfNameOrdinals);

		for (DWORD i = 0; i < pExportDir->NumberOfNames; ++i) {
			LPCSTR lpProc = (LPCSTR) ((DWORD_PTR) pDosHeader + pNames[i]);
			if (lpProc && strequal(lpProcName, lpProc)) {
				pFunction = (PVOID) pFunctions[pOrdinals[i]];
				break;
			}
		}
	}
	else { // Get function by ordinal
		pFunction = (PVOID) pFunctions[(DWORD_PTR) lpProcName - 1];
	}

	if (!pFunction)
		return NULL;

	// Export RVA?
	if ((DWORD_PTR) pFunction < pExportData->VirtualAddress ||
		(DWORD_PTR) pFunction >= pExportData->VirtualAddress + pExportData->Size)
		return (PVOID) ((DWORD_PTR) hModule + (DWORD_PTR) pFunction);

	// Forward RVA
	LPCSTR lpRedirect = (LPCSTR) ((DWORD_PTR) hModule + (DWORD_PTR) pFunction);
	int nSeparator = lastIndexOf(lpRedirect, '.');
	if (nSeparator == -1) // Forward RVA is in the same module
		return getProcAddress(hModule, lpRedirect);

	INT i = 0;
	WCHAR wcModuleBuffer[MAX_PATH];
	while (i < nSeparator && i < MAX_PATH - 1)
		wcModuleBuffer[i++] = *lpRedirect++;
	wcModuleBuffer[i] = 0;

	// If the next character after the separator is null
	if (*lpRedirect++ != '.' || !(*lpRedirect))
		return NULL;

	// Get the forwarder module handle
	HMODULE hRedirect = getModuleHandle(wcModuleBuffer);

	// Forward RVA is an ordinal?
	if (*lpRedirect == '#') {
		DWORD dwOrdinal = 0;
		while (*(++lpRedirect)) { // Apply Horner-Scheme
			dwOrdinal *= 10;
			dwOrdinal += (*lpRedirect - '0');
		}

		return getProcAddress(hRedirect, (LPCSTR) dwOrdinal);
	}

	INT j = 0;
	CHAR cFunctionBuffer[MAX_PATH];
	while (*lpRedirect && j < MAX_PATH - 1)
		cFunctionBuffer[j++] = *lpRedirect++;
	cFunctionBuffer[j] = 0;

	// If there are still characters left
	if (*lpRedirect)
		return NULL;

	return getProcAddress(hRedirect, cFunctionBuffer);
}

Bitte nicht vergessen, dass ich dafür keine CRT zur Verfügung hatte, d.h. kein strcmp, new, malloc etc.