Majong hack geht nicht [source]

[hansewurst]

Hey, habe einen majong hack halbwegs versucht zu machen, hier ist mal der source:

#include <windows.h>
#include <stdio.h>

#define Base 0xFF5E74D4


void injection(){


	*(int*)(0xFF29758C)= 200;
}


void TheHacks()
	{
for(;;)
{
	injection();
}}

BOOL WINAPI DllMain(HINSTANCE mod, DWORD DWORD_GRUND, LPVOID res)
{
switch(DWORD_GRUND)
{
case 1:
// -->
CreateThread(0, 0, (LPTHREAD_START_ROUTINE)TheHacks , 0, 0, 0);
break;
case 2:
break;
}
return TRUE;
}

Was ist an dem code falsch? weil wenn ich den injecte passiert nichts :/
PS: Benutze Perx injector

[.SkyneT.]

Originally Posted by hansewurst

Was ist an dem code falsch?

Was ist an dem Code richtig ?

[xxfabbelxx]

moved

BOOL WINAPI DllMain(HINSTANCE mod, DWORD DWORD_GRUND, LPVOID res)
{
switch(DWORD_GRUND)
{
case 1:
// -->
CreateThread(0, 0, (LPTHREAD_START_ROUTINE)TheHacks , 0, 0, 0);
break;
case 2:
break;
}
return TRUE;
}

Das ist schonmal von vornherein falsch.

hier eine mögliche Verbesserung:

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
 switch(fdwReason)
 {
  case DLL_PROCESS_ATTACH:
  CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)TheHacks , NULL, 0, NULL);
  break;
  case DLL_PROCESS_DETACH:
  CloseHandle(hinstDLL);
  break;
 }
return true;
}

Grundsätzlich musst du immer darauf achten, Pointer nicht mit 0, sondern mit NULL zu initialisieren. Auch auf die Benennung der Funktion selbst sowie die Parameter z.B. von fdwReason. Klar geht case 1 etc auch, aber soetwas beim Namen aufzurufen ist eindeutig besser.

void injection(){


	*(int*)(0xFF29758C)= 200;
}

Warum benutzt du C-Casts, wenn C++ seine eigenen, sichereren Funktionen dafür hat? Warum dereferenzierst du, wenn du nichtmal einen Pointer da drinne stehen hast?

void EditScore(  )
{
 *reinterpret_cast<int *>(POINTER + ADDRESS);
}

void TheHacks()
	{
for(;;)
{
	injection();
}}

Man sollte immer einen Sleep bei einer FOR-Schleife haben.

void TheHacks(  )
{
 for( ;; )
 {
  Injection(  );
  Sleep( 50 );
 }
}

-


Warum setzt du Macros, wenn du diese ganicht benutzt?
Es ist durchaus sinnvoll Makros zu setzen (bei größeren Projekten) bzw die Adressen vorher zu initialisieren.

const DWORD dwGamePointer 0x000000
const DWORD dwOfsScore 0x000000

[Hiris]

Ach du kacke.
Base 0xFF5E74D4
Warum nutzt du die nicht? Ich gehe mal davon aus das du einfach die Adresse aus Cheat engine genommen hast, die hilft dir aber nicht viel weil sie sich immer ändert.

[hansewurst]

Ich kann cheat engine benutzen ^^ und das is der pointer nur mit den offset adressen ausgerechnet,, der pointer ist constant und zeigt auch immer auf den score, egal ob neustart oder nicht

[snow]

Originally Posted by xxfabbelxx

Grundsätzlich musst du immer darauf achten, Pointer nicht mit 0, sondern mit NULL zu initialisieren.

Naja, NULL oder 0 ist das selbe, da würde ich dann eher zu nullptr greifen, das kann nur als Zeiger oder Boolean verwendet werden.

void injection(){


	*(int*)(0xFF29758C)= 200;
}

Hier evtl. lieber direkt DWORD_PTR verwenden. Auch würde ich die Anweisung nicht in eine extra Funktion hauen, da geht ja mehr Zeit für den Aufruf drauf als für das Modifizieren des Speichers.

Originally Posted by xxfabbelxx

void TheHacks()
	{
for(;;)
{
	injection();
}}

Man sollte immer einen Sleep bei einer FOR-Schleife haben.

Hier würde ich den Funktions-Prototypen vor allem noch anpassen, das ist hier jetzt nicht so tragisch, aber je nach Calling Convention des Prototypen kann hier einiges schief gehen. Der Return Wert ist natürlich auch recht wichtig.

Originally Posted by xxfabbelxx

const DWORD dwGamePointer 0x000000
const DWORD dwOfsScore 0x000000

Kompiliert das bei dir? Hau noch Klammern vor und nach den Wert und es passt, aber das sind dann keine Makros mehr.

@TE: wat? Das ist dann kein Pointer mehr, ist dir das bewusst? Du musst schon die Werte jedes Mal aufs neue auslesen, da sich das ja durchaus ändert.

[Nightblizard]

Originally Posted by xxfabbelxx

Grundsätzlich musst du immer darauf achten, Pointer nicht mit 0, sondern mit NULL zu initialisieren.

Das ist Käse, da "#define NULL 0". Richtig wäre nullptr!

Originally Posted by xxfabbelxx

Warum dereferenzierst du, wenn du nichtmal einen Pointer da drinne stehen hast?

Wenn die Adresse statisch ist, dann passt das.

Originally Posted by xxfabbelxx

Man sollte immer einen Sleep bei einer FOR-Schleife haben.

void TheHacks(  )
{
 for( ;; )
 {
  Injection(  );
  Sleep( 50 );
 }
}

Das Sleep(50) ist Käse. Wenn man es richtig machen will, dann nutzt man Sleep(1). Siehe:

Originally Posted by xxfabbelxx

Warum setzt du Macros, wenn du diese ganicht benutzt?
Es ist durchaus sinnvoll Makros zu setzen (bei größeren Projekten) bzw die Adressen vorher zu initialisieren.

const DWORD dwGamePointer 0x000000
const DWORD dwOfsScore 0x000000

Nein, Macros sind in diesem Kontext falsch. Außerdem erstellst du in dem Beispiel keine Macros, sondern Fehler beim compilen. Abgesehen davon ist die ungarische Notation total unschön und veraltet und DWORD ist der falsche Datentyp für Pointer.
Richtig wären konstante UINT_PTR:

const UINT_PTR SOME_PTR = 0xBAADF00D;
const UINT_PTR ANOTHER_PTR = 0xC00FFEE;

[MrSm!th]

Das ist Käse, da "#define NULL 0". Richtig wäre nullptr!

Naja, 100%iger Käse ist es nicht, eher so 90%iger. Immerhin ist nullptr eine C++11 Neuerung und davor gab es nunmal nur die Äquivalenz von 0 und einem Zeiger ins Nichts. Da macht es durchaus Sinn, NULL zu verwenden, so als Verdeutlichung der Pointer-Operation. Zudem kann man so alle Verwendungen von NULL leicht durch nullptr ersetzen, während du bei Verwendung von 0 jeden Fall selbst ansehen und ggf. anpassen müsstest.
Wäre C++ nicht dazu verdammt, zu C abwärtskompatibel zu sein, hätte man mit C++11 auch einfach die Anweisung int *ptr = 0; ungültig machen können, wenn es doch jetzt den schönen nullptr gibt :<
Naja, ich schweife ab..

Warum dereferenzierst du, wenn du nichtmal einen Pointer da drinne stehen hast?

Weil er doch an die Adresse schreiben will ;O Ein Pointer ist es ja trotzdem, nur halt nur ein Level, ohne Offset und nicht in Form einer Variablen, sondern direkt als hardcoded Adresse.
Du würdest doch auch schreiben:

int x = 0;
int *ptr = &x;
*ptr = 1; //dereferenzierung
//äquivalent im pösen c-stil:
*(int*)(0xDEADBEEF) = 1;
//und nicht
0xDEADBEEF = 1; //ergibt keinen sinn

[Nightblizard]

Originally Posted by MrSm!th

Naja, 100%iger Käse ist es nicht, eher so 90%iger. Immerhin ist nullptr eine C++11 Neuerung und davor gab es nunmal nur die Äquivalenz von 0 und einem Zeiger ins Nichts. Da macht es durchaus Sinn, NULL zu verwenden, so als Verdeutlichung der Pointer-Operation. Zudem kann man so alle Verwendungen von NULL leicht durch nullptr ersetzen, während du bei Verwendung von 0 jeden Fall selbst ansehen und ggf. anpassen müsstest.
Wäre C++ nicht dazu verdammt, zu C abwärtskompatibel zu sein, hätte man mit C++11 auch einfach die Anweisung int *ptr = 0; ungültig machen können, wenn es doch jetzt den schönen nullptr gibt :<
Naja, ich schweife ab..

Der Grund dafür ist weniger die Abwärtskompatibilität zu C, sondern viel eher die Kompatibilität zu bereits bestehendem Code. In einem der C++11 Videos auf Channel9 wurde das mal kurz erwähnt. Die wollten "#define NULL 0" mit "#define NULL nullptr" ersetzen und bekamen tausende Fehler beim erstellen ihrer Office Produkte. Die haben NULL also beispielsweise auch so genutzt:

int foo = NULL;

Und weil nicht abzusehen ist wie viele andere Leute das so nutzen und in wie vielen millionen Zeilen von Code das so genutzt wird, haben sie NULL nicht geändert.

Abgesehen davon ist "das ist aber C++11" kein Grund es nicht zu benutzen. Wer noch immer C++03 nutzt hat entweder den Knall nicht gehört oder arbeitet bei einer miesen Firma. Das bietet so viele gute Neuerungen, das muss man einfach nutzen!

[MrSm!th]

Msvc10 unterstützt nur verdammt wenig C++11 :<
Ich wollte damit auch nicht sagen, dass man es nicht nutzen soll, sondern dass es vorher mit nullptr in Aussicht durchaus Sinn gemacht hat, NULL für Pointer, aber nur für Pointer, zu verwenden.

[Master674b]

Originally Posted by Nightblizard

Der Grund dafür ist weniger die Abwärtskompatibilität zu C, sondern viel eher die Kompatibilität zu bereits bestehendem Code. In einem der C++11 Videos auf Channel9 wurde das mal kurz erwähnt. Die wollten "#define NULL 0" mit "#define NULL nullptr" ersetzen und bekamen tausende Fehler beim erstellen ihrer Office Produkte. Die haben NULL also beispielsweise auch so genutzt:

int foo = NULL;

Und weil nicht abzusehen ist wie viele andere Leute das so nutzen und in wie vielen millionen Zeilen von Code das so genutzt wird, haben sie NULL nicht geändert.

Abgesehen davon ist "das ist aber C++11" kein Grund es nicht zu benutzen. Wer noch immer C++03 nutzt hat entweder den Knall nicht gehört oder arbeitet bei einer miesen Firma. Das bietet so viele gute Neuerungen, das muss man einfach nutzen!

Das versteh ich nicht so ganz. Die Leute haben sich an den Standard zu halten und nicht anders herum.

Wenns nach mir ginge wäre nie irgend etwas deprecated. Es wäre einfach schlichtweg nicht mehr vorhanden, um den Benutzern guten Stil aufzuzwingen.

[MrSm!th]

Das ist nicht praktikabel. Der Standard muss sich auch an der Nutzerschaft orientieren und abwägen, was sinnvoll ist. Wer definiert denn guten Stil? Ist doch ebenso eine Mehrheitssache, das kann das Standardkomitee nicht diktieren.
Du kannst nicht einfach große Projekte (die eventuell sogar die Weiterentwicklung von C++ finanziell fördern ;O) mit einer Änderung nicht mehr kompilierbar machen.
Mit so einem bevormundenden Verhalten und so einer Einstellung wird deine Sprache sehr bald gar keine Nutzer mehr haben.
Außerdem ist ein Grund für den Erfolg von C++ die Kompatibilität mit C, die damit ebenfalls zerstört würde.

[Dr. Coxxy]

Originally Posted by Master674b

Das versteh ich nicht so ganz. Die Leute haben sich an den Standard zu halten und nicht anders herum.

Wenns nach mir ginge wäre nie irgend etwas deprecated. Es wäre einfach schlichtweg nicht mehr vorhanden, um den Benutzern guten Stil aufzuzwingen.

was dann darin resultiert, dass viele leute uralte compiler benutzen, weil neue compiler ihren alten code nicht mehr kompilieren können.

EDIT:
ich sollte die seite mal öfter updaten, smitty war eine ganze stunde schneller als ich :/

[hansewurst]

Ist das jetzt so besser?:

#include <windows.h>
#include <stdio.h>

#define Base 0x0723BB74



void injection(){

	

*(int*)(Base)= 3000;
}


void TheHacks()
	{
for(;;)
{
	injection();
	Sleep (50);
}}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
 switch(fdwReason)
 {
  case DLL_PROCESS_ATTACH:
  CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)TheHacks , NULL, 0, NULL);
  break;
  case DLL_PROCESS_DETACH:
  CloseHandle(hinstDLL);
  break;
 }
return true;
}

[snow]

Naja, du hast keinen Thread-Prototypen und der Aufruf von injection dürfte länger dauern als die eigentliche Ausführung der Funktion, aber evtl. ist der Compiler nett und inlined das.
Konstanten mit const deklarieren und nicht als Makro & zum Casten die Casts von C++ nutzen (reinterpret_cast<> in dem Falle).

@Master674b: Es ist nicht so, dass man sich da nicht dran halten will, aber vor allem in Unternehmen gibt es da 2 Faktoren:
1) ein neuer Standard bedeutet, dass die Mitarbeiter geschult werden müssen, was Kosten bedeutet. Erklär mal nem Zahlenschubser, dass der neue Standard notwendig ist, wenn seine Zahlen zeigen, dass es bisher auch ging.
2) je nach Branche ist nicht nur ein Standard ausschlaggebend, hier geht es in erster Linie um Normen und was weiß ich der Branche. Ich kann das nur von meinem Arbeitgeber berichten, aber es gibt genaue Richtlinien, was erlaubt ist - teilweise gesetzlich / branchenweit. Bis da C++11 übernommen wird, vergehen noch 2-3 Jährchen. :/ Wenn da der Compiler nicht mehr den alten Standard unterstützt, wird C++ halt fallen gelassen und das ist ja auch nicht im Sinne der Entwickler.