Home of Gamehacking - Archiv
Best Practise C++ - Druckversion

+- Home of Gamehacking - Archiv (http://archiv-homeofgamehacking.de)
+-- Forum: Gamehacking (http://archiv-homeofgamehacking.de/forumdisplay.php?fid=3)
+--- Forum: Gamehacking (http://archiv-homeofgamehacking.de/forumdisplay.php?fid=6)
+--- Thema: Best Practise C++ (/showthread.php?tid=2335)

Seiten: 1 2


Best Practise C++ - Prototype - 21.10.2013

Moin,

nach längerem Probieren habe ich glaube ich mein Lieblingsweg gefunden Adressen zu überschreiben bzw. zu benutzen. Meistens springe ich mit Code caves an die Stelle, in der meine gewollte Speicheradresse liegt und kopiere sie mir dann aus dem Register. Wie geh ich nun am besten vor.

Mein Code Cave befindet sich in einer .dll. Ein RemoteThread injected ein Thread in den Prozess und führt mein Code aus.

Hier mal meine Funktion die mir die Adresse des Highscores liefert.

Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
__declspec(naked) void GetHighscorePointer(void)
{

		__asm
	{
		// The first thing we must do in our codecave is save the return address from the top of the stack
		pop ExtractScoreRetAddr

		
		PUSHAD
		PUSHFD
	}
	


	__asm 
	{
		// Restore everything to how it was before
		POPFD
		POPAD

		
		
	
	//code which was overidden 
		CMP EDX, 0x3B9ACA00
		//eax holds the adress to the current score 
		mov adressPointer,eax
		// The last thing we must do in our codecave is push the return address back onto the stack and then RET back
		push ExtractScoreRetAddr
		ret
	

		}
	
}


Die Adresse steht jetzt in einem DWORD (unsigned int). Was ist der beste Weg die Adresse einem DWORD Pointer zu geben? Soll meine GUI später den Pointer bekommen oder eine Methode der DLL aufrufen um an den richtigen Wert zu kommen?


RE: Best Practise C++ - Acubra - 22.10.2013

Hey,
da du schon mit der dll im Prozess bist, kannst du die Werte der Adressen auch direkt von der dll aus manipulieren.
Die Adresse übergibst du am Besten folgendermaßen:

Code:
DWORD adressPointer = 0x1234 //fiktive Adresse
//Wir brauchen zunächst einen Pointer der auf den Wert von adressPointer zeigt (0x1234) und dann einen, der auf den Wert zeigt, den die Adresse enthält. Also einen Pointer auf einen Pointer
DWORD** dwPointer = (DWORD**)&adressPointer;
//Neuen wert schreiben
**dwPointer = 90; //90d== 5a hex




RE: Best Practise C++ - Prototype - 22.10.2013

Ah interessant. Wenn ich das richtig verstehe deutest du auf einen Pointer der wiederum auf den Wert zeigt.

Da stinkt natürlich memcpy gegen ab Happy

Edit:

Vielleicht noch eine kleine eher unwichtige Frage, baut ihr für euren Trainer einen Loader, sprich das Spiel startet mit dem Trainer oder hängt ihr euch in den laufenden Prozess? Letztes ist denke ich vor allem bei Code caves eher suboptimal


RE: Best Practise C++ - Acubra - 22.10.2013

Hey,
bei uns läuft alles extern. Ich alloziiere zunächst Speicher im Spielprozess und schreibe dahin dann per WriteProcessMemory meine Cheats (in ASM). Anschließend wird der Sprung zur jeweiligen "Cave" geschrieben. Manchmal reicht es ja auch einzelne Befehle zu "noppen".
Manchmal suche ich auch Pointer für bestimmte Adressen und arbeite dann mit diesen (also per ReadProcessMemory die Pointer + Offsets auslesen bis man bei der gewünschten Adresse ist).
Ich habe auch ne Trainerbase als .dll geschrieben, die dann immer injiziert werden müsste, hat mir aber nicht gefallen.


RE: Best Practise C++ - iNvIcTUs oRCuS - 22.10.2013

In der Regel funktionieren unsere Trainer, und Trainer anderer Groups, nachdem Prinzip das diese die laufenden Prozesse überwachen.
Überwachen aber nur in sofern das darauf gewartet wird bis der Spieleprozess gestartet wurde.
Schau mal in die MSDN und die API CreateToolHelp32Snapshot, dann sollte dir das schnell klar werden.
Im Prinzip ist es dann unwichtig ob zuerst der Trainer oder das Spiel gestartet wurde.


RE: Best Practise C++ - Prototype - 22.10.2013

Okay, okay. Ich denke die Basis habe ich schon langsam.

Eine eher theoretische Frage. Kann eine Anti cheat engine eine injizierte Dll erkennen? Wenn ja wäre es eigentlich immer besser memory in dem Prozess zu allozieren und da seinen cave rein zu laden.


RE: Best Practise C++ - Acubra - 22.10.2013

Hey,
die guten AntiCheats erkennen heutzutage beide Methoden. Da muss man sich schon mehr einfallen lassen, um das AntiCheat auszutrixen.



RE: Best Practise C++ - iNvIcTUs oRCuS - 22.10.2013

Die meisten Anti Cheat Systeme basieren unter anderem darauf das der eigene Spieleprozess oder einzelne Dateien entweder mit nem simplen CR Check versehen sind, oder der Speicher des Spiels auf Manipulationen überwacht wird.
Bestes Beispiel hierfür ist XLive. Oder auch Crysis 3 hat einen ausgefeilten, aber nicht unüberwindbaren Cheat Schutz. Wobei man aber auch strikt zwichen Cheat Schutz und Kopierschutz unterscheiden solle.
Bei Onlinegames dürfte das ganze schwieriger sein. Serverseitiger Datenabgleich/speicherung...
Aber cheaten in Online Games wird hier (von uns) ohnehin nicht toleriert.


RE: Best Practise C++ - Prototype - 22.10.2013

Gibt es irgendwo vielleicht den src einer trivialen anti cheat engine? Bzw. eine Beschreibung? Das ganze kann eigentlich nur überwacht werden, wenn bestimmte win api funktionen gehooked werden. Und das auf einem möglichst lowen Level. So ein tutorial speziell für anti cheat engines ist da bestimmt interessant


RE: Best Practise C++ - iNvIcTUs oRCuS - 22.10.2013

Da allerdings in Singleplayermodi von nahezu jedem Spiel nie eine Anti Cheat Routine auftaucht, würde ich behaupten das Du für solche Zwecke eher in einem Forum für Online Cheats fündig werden könntest.