How to let a Sniffer fail !

[buFFy!]

Hello ! In this tutorial i'm gonna show you how to let sniffers like "WPE Pro" or "Cain and Abel" fail.

What we know if we inform us a a bit about Sniffers is, that they Hook the ws2_32.dll function "send" to log outgoing packets. We also know that

int send(
  __in  SOCKET s,
  __in  const char *buf,
  __in  int len,
  __in  int flags
);

has the argument 'SOCKET s'. The usual way to retrieve the IP Address / Port from this socket is

int getpeername(
  __in     SOCKET s,
  __out    struct sockaddr *name,
  __inout  int *namelen
);

Since we know that, we gotta find a opportunity to let 'getpeername' fail. The answer is: Hooking !
There are several methods to hook a function. I'll keep it as simple as possible and use the 0xE9-jmp-method.

Now open up a new Project in VS (i use 08) and select DLL->empty project.

Since we also want to see the original Packets, we have to use the ws2_32.dll functions.
Create a Main.h and add:

#include <windows.h>
#include <stdio.h>
#pragma comment(lib, "ws2_32.lib")

should be clear.

We also know what we want to hook:
-"send" to see the original packets

typedef int (__stdcall * send_t)(SOCKET sock, const char* buffer, int len,int flags);
send_t pSend;

-"getpeername" (of course )

typedef int (__stdcall * getpeername_t)(SOCKET sock, struct sockaddr* name, int* namelen);
getpeername_t pGetPeerName;

void* detourFunc(BYTE *src, const BYTE *dst, const int len) //gamedeception. i rather use windows detours, but however :P
{
	BYTE *jmp = (BYTE*)malloc(len+5);
	DWORD dwback;

	VirtualProtect(src, len, PAGE_READWRITE, &dwback);

	memcpy(jmp, src, len);   jmp += len;

	jmp[0] = 0xE9;
	*(DWORD*)(jmp+1) = (DWORD)(src+len - jmp) - 5;

	src[0] = 0xE9;
	*(DWORD*)(src+1) = (DWORD)(dst - src) - 5;

	VirtualProtect(src, len, dwback, &dwback);

	return (jmp-len);
}

It writes a jump (0xe9) to our function to the given address.

We also want to add a console to print our logged original packets !

void GetConsole(LPCSTR sTitle) {
	FILE *fh;
	AllocConsole();
	freopen_s(&fh, "CONOUT$", "wb", stdout);
	SetConsoleTitleA(sTitle);
}

Thats all for the Main.h (for the functions, you can also add a Functions-header or smth.)
Now open up the Main.cpp:

#include "Main.h"

And the usual DLLMain:

int __stdcall DllMain(HANDLE _HDllHandle, DWORD _Reason, LPVOID _Reserved)
{
	if(_Reason == DLL_PROCESS_ATTACH)
	{
		CreateThread(0, 0, (LPTHREAD_START_ROUTINE)SetupHook, 0, 0, 0);
		return 1;
	}
	return 0;
}

As you see it contains a CreateThread for "SetupHook". Should be self-explaining.

void SetupHook()
{
	GetConsole("Sendlog");
}

Now we want to get the Address of our first function (send).
We do that as following:

	DWORD dwSend = (DWORD)GetProcAddress(GetModuleHandleA("ws2_32.dll"), "send");

You can add some error handling if you want - this works for me.

Now we have our address and can install the Hook itself:

	if( GetLastError() == 0)
	{
		pSend = (send_t)detourFunc((byte*)dwSend, (byte*)hkSend, 5);
	}

and the same for getpeername:

	DWORD dwGetPeerName = (DWORD)GetProcAddress(GetModuleHandleA("ws2_32.dll"), "getpeername");
	if( GetLastError() == 0)
	{
		pGetPeerName = (getpeername_t)detourFunc((byte*)dwGetPeerName, (byte*)hkGetPeerName, 5);
	}

Alright. Now the hooked functions containing our own code:

int WINAPI hkSend(SOCKET sock, const char* buffer, int len,int flags)
{
	sockaddr_in ip;
	int length;

	getpeername(sock, (struct sockaddr*)&ip, &length);
	printf("ip: %s\n", inet_ntoa(ip.sin_addr));
	printf("buffer: %p\n", buffer);
	printf("length: %i\n", len);
	printf("flags: %i\n", flags);
	printf("---------------------\n");
	
	return pSend(sock, buffer, len, flags);
}

As you can see, we retrieve the Address from the Socket using "getpeername". inet_ntoa(ip.sin_addr) formats it to the usual ip format (e.g. 127.0.0.1)

Afer that we simply print the single parameters to the console we allocated below.

Now lets come to getpeername:

int WINAPI hkGetPeerName(SOCKET sock, struct sockaddr* name, int* namelen)
{
	
}

If we check out MSDN link of getpeername () we will see:

If no error occurs, getpeername returns zero. Otherwise, a value of SOCKET_ERROR is returned, and a specific error code can be retrieved by calling WSAGetLastError.

That means, we will simply return out of getpeername without doing anything !

int WINAPI hkGetPeerName(SOCKET sock, struct sockaddr* name, int* namelen)
{
	return 0;
}

Now compile it and inject it to ur exe (i took gw.exe from Guild Wars)


As you can see, the destination is always zero. Some networksniffers dont even display the packet if they dont have the destination (e.g. Cane and Abel).

I hope this tutorial helped you in some way.
It's not meant to fully hide your connection.
However, it will probably prevent the kidz from sniffing your data.
Though its not hard to bypass.

[MrSm!th]

CreateThread(0, 0, (LPTHREAD_START_ROUTINE)SetupHook, 0, 0, 0);

|
v

void SetupHook()

ლ(ಠ益ಠლ) Wieso schreibt wirklich jeder normale void Funktionen als Thread Entries?
Weißt du nicht, dass das ganz fatal enden kann, besonders, wenn die Standard-Calling-Convention in deinem Projekt __cdecl ist?

Finde den Schluss nicht ganz schlüssig (lol meine Wortwahl um diese Zeit), wie du von send zu getpeername kommst.
Erst sprichst du davon, einen Sniffer failen zu lassen.
Das könnte zb. auch das Entfernen eines Hooks sein. Und dann redest du plötzlich was von getpeername und der IP, zumal die IP doch gar nicht zwingend notwendig für einen Sniffer ist o.ô

[buFFy!]

Originally Posted by MrSm!th

ლ(ಠ益ಠლ) Wieso schreibt wirklich jeder normale void Funktionen als Thread Entries?
Weißt du nicht, dass das ganz fatal enden kann, besonders, wenn die Standard-Calling-Convention in deinem Projekt __cdecl ist?

Finde den Schluss nicht ganz schlüssig (lol meine Wortwahl um diese Zeit), wie du von send zu getpeername kommst.
Erst sprichst du davon, einen Sniffer failen zu lassen.
Das könnte zb. auch das Entfernen eines Hooks sein. Und dann redest du plötzlich was von getpeername und der IP, zumal die IP doch gar nicht zwingend notwendig für einen Sniffer ist o.ô

liegt wohl daran, das ich kein Buch gelesen habe ! was kann denn da schief gehen?

das ganze tutorial war eher etwas spezieller in relation zu einem alten projekt von mir, jedoch in einem anderen forum. darum kommt das ganze hier nicht klar rüber. es ging eben darum, das man die destination im sniffer nicht angezeigt bekommt.

send wird nur gehookt, um das korrekte packet anzuzeigen.

[link]

"Weißt du nicht, dass das ganz fatal enden kann, besonders, wenn die Standard-Calling-Convention in deinem Projekt __cdecl ist?"
Soweit ich weiß kann dabei nichts passieren. Nach einem Thread kommt nichts außer ExitThread, da auch der Context des Threads gelöscht wird, kann sowohl der Stack upgefuckt, als auch ebx, esi und edi überschrieben sein. Trotz cdecl findet retn ja noch die Rücksprungadresse und mehr ist nicht wichtig.

"Wieso schreibt wirklich jeder normale void Funktionen als Thread Entries?"
Abhänging davon, in welchem Thread die Dll geladen wird, blockierst du evtl. den Mainthread bzw. andere wichtige Threads, daher erstellt man normalerweise einen Thread.

[MrSm!th]

Originally Posted by link

"Weißt du nicht, dass das ganz fatal enden kann, besonders, wenn die Standard-Calling-Convention in deinem Projekt __cdecl ist?"
Soweit ich weiß kann dabei nichts passieren. Nach einem Thread kommt nichts außer ExitThread, da auch der Context des Threads gelöscht wird, kann sowohl der Stack upgefuckt, als auch ebx, esi und edi überschrieben sein. Trotz cdecl findet retn ja noch die Rücksprungadresse und mehr ist nicht wichtig.

Stimmt und da es nur einen Parameter gibt, kann eine andere Parameterreihenfolge auch keine Folgen haben (bei cdecl ist die doch umgekehrt oder?), hab ich vergessen, mein Fehler
Ändert trotzdem nichts dran, es ist ein verdammt schlechter Stil es so zu schreiben, das ist nunmal nicht die korrekte Definition eines Threads.

Und Folgen kann zumindest der Rückgabewert haben, zwar keine fatalen, aber es gibt welche. Nämlich dass EAX einen zufälligen Wert haben kann und demnach sonst was für ein Error Code zurückgegeben wird.

"Wieso schreibt wirklich jeder normale void Funktionen als Thread Entries?"
Abhänging davon, in welchem Thread die Dll geladen wird, blockierst du evtl. den Mainthread bzw. andere wichtige Threads, daher erstellt man normalerweise einen Thread.

Darum ging es nicht, es ging mir eher um diese Erstellung eines Threads, die auch so gut wie in jedem C&P Warrock Hack falsch gemacht wird.
Es ist wirklich eine Epidemie.

Außerdem wird idr. ein neuer Thread mit CreateRemoteThread gestartet, demnach wird allerhöchstens der Injector blockiert.

[link]

"Do not declare this callback function with a void return type and cast the function pointer to LPTHREAD_START_ROUTINE when creating the thread. Code that does this is common, but it can crash on 64-bit Windows."
Ach, deswegen hast du das mit void als Thread angesprochen?
Hm, ich wüsste jetzt gar nicht was da schief gehen könnte, da void ja letztlich keinen Unterschied macht, außer halt 'xor eax,eax'/'mov eax,x'..
Heißt der Rückgabewert wäre nicht definiert und hätte einen zufälligen Wert.
Aber wenn du nicht mit arbeitest, wen kümmert's dann?
"but it can crash on 64-bit Windows"
Das ist jetzt aber auch irgendwie ein wenig ungenau...
Leider kenne ich mich mit x64 gar nicht aus und weiß auch nicht, was der Compiler dort aus void macht..

"da es nur einen Parameter gibt"
Selbst mehrere wären egal :P
Der Stack sieht ja so aus:
esp+0 Rücksprungadresse
esp+4 Param1
esp+8 Param2
retn funzt also immer und wie der Stack danach aussieht ist ExitThread egal

"Außerdem wird idr. ein neuer Thread mit CreateRemoteThread gestartet, demnach wird allerhöchstens der Injector blockiert."
Wieso das? Es gibt doch auch unzählige Dlls, die über Imports oder manuell geladen werden und z.B. ihre Daten oder Sonstiges in DllMain initialisieren müssen. Es gibt auch Injectors, die mit SuspendThread und Context.Eip arbeiten, sprich dem Mainthread.
Das so zu pauschalisieren wäre doch auch ein schlechter Stil, da es halt nicht universell ist bzw. ist's generell schlechter Stil, da es halt unschön ist, den Thread unnötigerweise zu blockieren

[MrSm!th]

Originally Posted by link

"Do not declare this callback function with a void return type and cast the function pointer to LPTHREAD_START_ROUTINE when creating the thread. Code that does this is common, but it can crash on 64-bit Windows."
Ach, deswegen hast du das mit void als Thread angesprochen?

Um ehrlich zu sein, nein, diese Tatsache war mir nichtmal bekannt
Ich habe es angesprochen, weile es eben mit dem Rückgabewert Komplikationen geben kann, weil es einfach schlechter Stil ist und weil ich mir das schon öfters sagen lassen habe (und dann direkt erstmal auf die Calling Convention geschlossen habe).

Hm, ich wüsste jetzt gar nicht was da schief gehen könnte, da void ja letztlich keinen Unterschied macht, außer halt 'xor eax,eax'/'mov eax,x'..
Heißt der Rückgabewert wäre nicht definiert und hätte einen zufälligen Wert.

Genau das habe ich doch gesagt, der Wert ist eben zufällig, dementsprechend irgendein zufälliger ExitCode.

Aber wenn du nicht mit arbeitest, wen kümmert's dann?

Es ist ja nicht immer gesagt, dass man nicht damit arbeitet.
Außerdem (achtung, nun wirds sehr hypothetisch :P), wenn man zb. in einem Plugin oder einfach für irgendeine externe Funktion einen Thread anbieten muss und die mit dem ExitCode arbeitet, sieht das ganze schon wieder anders aus.
Zumal ein Error Code bei solchen Dingen wie Threads das Debugging ungemein erleichtern kann.

"but it can crash on 64-bit Windows"
Das ist jetzt aber auch irgendwie ein wenig ungenau...
Leider kenne ich mich mit x64 gar nicht aus und weiß auch nicht, was der Compiler dort aus void macht..

Ich weiß auch nichts genaueres über die 64bit Architektur, ich denke weniger, es hat etwas mit void zutun, als mit der Calling Convention.
Die ist ja standardmäßig __cdecl. Eventuell macht die WOW64 VM noch etwas nachdem ein Thread beendet ist.
Sollte es wirklich am void liegen, kann ich mir da auch nichts zusammenreimen.

"da es nur einen Parameter gibt"
Selbst mehrere wären egal :P
Der Stack sieht ja so aus:
esp+0 Rücksprungadresse
esp+4 Param1
esp+8 Param2
retn funzt also immer und wie der Stack danach aussieht ist ExitThread egal

So meinte ich das nicht ganz. Ich war mir nicht mehr sicher über die Reihenfolge der Parameter. Es gibt doch irgendeine Calling Convention bei der die Parameter in umgekehrter Reihenfolge (sprich erster zuerst, letzter zuletzt) gepusht werden, wenn ich mich da richtig entsinne, weiß nun aber nicht mehr, welche es war.
Und da __cdecl und __stdcall so viele Unterschiede haben, habe ich mal darauf geschlossen, __cdecl sei diese. Und das würde sich ja bei mehreren bemerkbar machen, ist aber bei einem Parameter ohnehin bedeutungslos.

"Außerdem wird idr. ein neuer Thread mit CreateRemoteThread gestartet, demnach wird allerhöchstens der Injector blockiert."
Wieso das? Es gibt doch auch unzählige Dlls, die über Imports oder manuell geladen werden und z.B. ihre Daten oder Sonstiges in DllMain initialisieren müssen. Es gibt auch Injectors, die mit SuspendThread und Context.Eip arbeiten, sprich dem Mainthread.
Das so zu pauschalisieren wäre doch auch ein schlechter Stil, da es halt nicht universell ist bzw. ist's generell schlechter Stil, da es halt unschön ist, den Thread unnötigerweise zu blockieren

So war das auch nicht gemeint, ich sprach generell erstmal von Dlls die für die Injection gedacht sind.
Natürlich gibt es auch die Variante, die Dlls in den Main Thread zu injizieren, aber es ist doch definitiv nicht die Regel.
Ich wollte es auch keinesfalls pauschalisieren, ich wollte nur sagen, dass es in den meisten Fällen nur den Injector blockieren wird, der normalerweise auf den Return der DllMain wartet.

[link]

"ich denke weniger, es hat etwas mit void zutun, als mit der Calling Convention."
jo, aber da steht es doch:
"Do not declare this callback function with a void return type [...]. Code that does this is common, but it can crash on 64-bit Windows."
Vllt. hat es auch was mit dem Stack Alignment zu tun.. kA, MSDN scheint ja auch nichts dazu zu sagen..

"Und das würde sich ja bei mehreren bemerkbar machen, ist aber bei einem Parameter ohnehin bedeutungslos."
Aber damit würde der Compiler doch automatisch arbeiten :P
Pascal ist die Calling Convention, die du meinst, da sieht's dann so aus:
esp+0 Rücksprungadresse
esp+4 Param3
esp+8 Param2
esp+12 Param1
Bei cdecl müsste der Caller den Stack bereinigen, was bei der ThreadProc-Stub, da das ThreadProc-Callback eigentlich stdcall ist, nicht passiert.
Das heißt, der Stack würde dadurch upgefuckt werden, was aber wegen ExitThread nicht weiter von Bedeutung ist (weißt du sicher auch, wollt's nur noch mal der Vollständigkeit halber wiederholen)

"ich wollte nur sagen, dass es in den meisten Fällen nur den Injector blockieren wird, der normalerweise auf den Return der DllMain wartet."
Klar, selbst wenn du den Mainthread blockierst, ist es nicht schlimm, heißt aber nicht, dass es nicht auch unschön ist :P

[MrSm!th]

Originally Posted by link

"Und das würde sich ja bei mehreren bemerkbar machen, ist aber bei einem Parameter ohnehin bedeutungslos."
Aber damit würde der Compiler doch automatisch arbeiten :P
Pascal ist die Calling Convention, die du meinst, da sieht's dann so aus:
esp+0 Rücksprungadresse
esp+4 Param3
esp+8 Param2
esp+12 Param1

Aber das Problem wäre ja, der Compiler generiert Funktionscode, der so damit arbeitet, aber das System weiß doch nix davon :P
Gehen wir mal davon aus, ein Thread hätte 2 Parameter, wovon einer ein Pointer ist und der andere nicht, demnach wäre eine Verwechselung kritisch.
Nun pusht das System die Parameter in der Reihenfolge wie es für __stdcall Funktionen üblich ist und deine Funktion greift auf sie zu, wie es für Pascal Funktionen üblich ist, du kannst dir denken, was dann passiert ;O
Darum ging es mir im groben eigentlich.

"ich wollte nur sagen, dass es in den meisten Fällen nur den Injector blockieren wird, der normalerweise auf den Return der DllMain wartet."
Klar, selbst wenn du den Mainthread blockierst, ist es nicht schlimm, heißt aber nicht, dass es nicht auch unschön ist :P

Wenn du den Main Thread blockierst, ist das idr. schon schlimm, da es hier ja um ein Programm geht, das vor einem Sniffer geschützt werden soll und es würde den Zweck verfehlen, wenn das Programm dadurch einfrieren würde ;O
Und bei jedem anderen Fall einer Dll Injection wäre es genau so, zb. bei Game Hacks.
Aber die meisten Injectoren injizieren ja sowieso mit CreateRemoteThread, von daher...

Wie gesagt, es ist nicht egal, ich mache ja auch keine Endlosschleife in der DllMain, zumal die afaik für jeden weiteren erstellten Thread nach der Injection aufgerufen wird ;O Aber es blockiert zumindest nicht immer den Main Thread, darauf wollte ich hinaus.

[link]

Ich weiß, was du meinst, nur wird standardmäßig bei C++-Compilern entweder cdecl verwendet oder du benutzt stdcall wegen der WinAPI.
Alles andere als cdecl muss halt explizit angegeben werden und da wäre es schon schön doof, wenn man sowas wie Pascal extra angibt, obwohl es falsch ist (wobei VC++ Pascal afaik nicht mal unterstützt)

[MrSm!th]

Das war ja auch ein Irrtum meinerseits, weil ich dachte, __cdecl handhabt das genau so mit den Parametern wie Pascal ;O