Pointer in c++

01/24/2012 23:45 MoepMeep#16
"Eine Fehlermeldung"
Alles klar, du musst dies und das ändern!

Übrigens, was Sm!th dort gepostet hast, funktioniert nur wenn du im Prozess bist. Für Zugriff von außerhalb musst du Read/WriteProcessMemory nutzen.
01/26/2012 12:09 Tyrar#17
Quote:
Originally Posted by MrSm!th View Post
Weil ihr das Offset zur Adresse addiert, allerdings gehört das Offset auf den Wert an der Adresse addiert, schließlich ist es ein Pointer!

Code:
int *ptr = reinterpret_cast<int*>( *(DWORD*)0xAdresse + 0xOffset );
wäre richtig, bzw. mit einem weiteren reinterpret_cast, um es noch schöner zu machen.
dann werde ich mein beispiel direkt mal anpassen:
Code:
*(unsigned int*)(*(unsigned int*)0xAdresse+0x0ffset)=0x13371337
ob DWORD jetzt unsigned int oder unsigned long ist kann ich nichtmehr genau sagen :|

btw. ich bin c coder, c++ is aber cooler wegen dan ganzen klassen <- mein codestil is also bestes beispiel was bei raus kommt wenn man beides gleichzeitig lernt und dann auchnoch ohne buch/lehrer ;)

Quote:
Originally Posted by republicaner View Post
Hab es jetzt so gemacht wie MrSm!th es gemacht hat, allerdings bekomme ich eine Fehlermeldung, wenn ich die exe starte und sie schließt sich sofort.
01/26/2012 12:33 yihaaa#18
@HeavyHacker: Müsste es nicht so heißen?
Code:
*(unsigned int*)((unsigned int*)0xAdresse+0x0ffset)=0x13371337
Edit: DWORD is unsigned long
01/26/2012 14:12 jacky919#19
Nein, du musst die Addresse dereferenzieren, weil zu dem Wert der Addresse das Offset addiert wird.

btw: typedef unsigned long DWORD, *PDWORD, *LPDWORD;
01/26/2012 16:28 Nightblizard#20
Man sollte Pointer aus Kompatibilitätsgründen nicht in einem DWORD speichern. DWORD_PTR oder UINT_PTR sind die bessere Wahl und erzeugen keine unfindbaren Fehler, wenn ihr später auf 64 bit Programme umsteigt (bzw. umsteigen solltet).

Und um es vorweg zu nehmen:
Nein, das sind keine Pointer! Die Typen garantieren groß genug zu sein, um einen Pointer beinhalten zu können.
01/26/2012 16:42 jacky919#21
Ein DWORD sollte eigentlich mehr Speicher als ein UINT_PTR bieten.

DWORD -> unsigned long
UINT_PTR -> unsigned int
01/26/2012 16:49 Dr. Coxxy#22
DWORD = 4 byte, egal ob 64 oder 32 bit.
auf einem 64 bit system sind pointer aber leider 8 byte groß, d.h. wenn du deinen compiler auf 64 bit umstellst wird der dir aus DWORD einen unsigned short machen (4byte) und wenn du da versuchst einen pointer reinzukopieren ...
01/26/2012 16:57 MrSm!th#23
Ob long oder int ist egal.
Beides ist 4 byte groß.

Mir ist die 64bit kompatibilität btw scheiß egal, dafür gibts WOW64.

Ja Heavy, es wäre richtig, sieht aber absolut bescheuert aus.
01/26/2012 17:59 MoepMeep#24
UINT_PTR und nichts anderes.
01/26/2012 18:36 Nightblizard#25
Quote:
Originally Posted by jacky919 View Post
Ein DWORD sollte eigentlich mehr Speicher als ein UINT_PTR bieten.

DWORD -> unsigned long
UINT_PTR -> unsigned int
Nope.

Siehe BaseTsd.h:
Code:
#if defined(_WIN64)
    typedef __int64 INT_PTR, *PINT_PTR;
    typedef unsigned __int64 UINT_PTR, *PUINT_PTR;

    typedef __int64 LONG_PTR, *PLONG_PTR;
    typedef unsigned __int64 ULONG_PTR, *PULONG_PTR;

    #define __int3264   __int64

#else
    typedef _W64 int INT_PTR, *PINT_PTR;
    typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;

    typedef _W64 long LONG_PTR, *PLONG_PTR;
    typedef _W64 unsigned long ULONG_PTR, *PULONG_PTR;

    #define __int3264   __int32

#endif
32 bit:
sizeof(unsigned long) == 4 //DWORD
sizeof(unsigned int) == 4
sizeof(UINT_PTR) == 4

64 bit:
sizeof(unsigned long) == 4 //DWORD
sizeof(unsigned int) == 4
sizeof(UINT_PTR) == 8
01/26/2012 19:27 xNopex#26
Quote:
32 bit:
sizeof(unsigned long) == 4 //DWORD
sizeof(unsigned int) == 4
sizeof(UINT_PTR) == 4

64 bit:
sizeof(unsigned long) == 4 //DWORD
sizeof(unsigned int) == 4
sizeof(UINT_PTR) == 8
Nur so nebenbei: Die Größen der Datentypen sind nicht näher festgelegt. Der C++ Standard schreibt nur die Zahlenmenge vor, die der Datentyp zu speichern im Stande sein muss. Aber dass unsigned long immer 4Byte sein müssen, ist nirgends festgelegt. Solange garantiert ist, dass die vorgegebene Zahlenmenge abspeicherbar ist, kannst du dich auch nicht beschweren, wenn ein unsigned int auf einmal 8Byte groß ist.
01/26/2012 19:45 Nightblizard#27
Quote:
Originally Posted by xNopex View Post
Nur so nebenbei: Die Größen der Datentypen sind nicht näher festgelegt. Der C++ Standard schreibt nur die Zahlenmenge vor, die der Datentyp zu speichern im Stande sein muss. Aber dass unsigned long immer 4Byte sein müssen, ist nirgends festgelegt. Solange garantiert ist, dass die vorgegebene Zahlenmenge abspeicherbar ist, kannst du dich auch nicht beschweren, wenn ein unsigned int auf einmal 8Byte groß ist.
Jup, das stimmt. Jedoch ist es jetzt im Moment eher ungünstig Pointer in Variablen mit 32 Bit zu schreiben.
Zumal die Aussage "Hmm, kann ja noch größer werden" das Desaster nicht ungeschehen macht. :p
Sollten unsigned int Typen ab morgen 8 Byte groß sein, dann will ich absolut nichts gesagt haben! Jedoch wage ich zu bezweifeln, dass das - wenn überhaupt - in naher Zukunft passieren wird.
Doch was weiß ich schon? :)

Aber im Grunde hast du natürlich recht!
01/26/2012 23:17 MrSm!th#28
Visual Studio vergibt jedenfalls an long 4 Byte.

Ich wüsste nicht, wieso 32bit Pointer unvernünftig sein sollten.
Die meisten Spiele sind für 32bit programmiert und laufen in der WOW64 VM, da haben auch 32bit Dlls mit ihren 32bit Pointern keine Probleme.
01/27/2012 01:35 MoepMeep#29
Quote:
Originally Posted by MrSm!th View Post
Visual Studio vergibt jedenfalls an long 4 Byte.

Ich wüsste nicht, wieso 32bit Pointer unvernünftig sein sollten.
Die meisten Spiele sind für 32bit programmiert und laufen in der WOW64 VM, da haben auch 32bit Dlls mit ihren 32bit Pointern keine Probleme.
Von dir hätte ich eigentlich erwartet, dass du sowas verstehst.