Use DWORD as a pointer replacement?

Learn or Teach General Knowledge Related to Coding or Hacking

Moderators: g3nuin3, SpeedWing, WhiteHat, mezzo

Use DWORD as a pointer replacement?

Postby L. Spiro » Sun Oct 11, 2009 10:52 am

It is time for volume #2 of Knowledge Base fun.

Do you frequently see people struggling to get some C++ code to work as a replacement for a Complex Address, and in order to make the offset additions easier they store the addresses as DWORD values?

You might see a Complex Address such as this:
Code: Select all
[0x005002FC]+0x62988

become code such as this:
Code: Select all
DWORD dwBase = 0x005002FC;
if ( ::ReadProcessMemory( hProc, reinterpret_cast<LPCVOID>(dwBase), &dwBase, sizeof( dwBase ), NULL ) {
    dwBase += 0x62988;
}


The :: on ::ReadProcessMemory() forces it to the global namespace, which defines clearly which ReadProcessMemory() you are using. This is good coding practice; :: should be used on all global functions, and this case is especially important for the hacking scene, since you are very likely to make your own ReadProcessMemory() in order to change how it works, such as adding kernel abilities etc.

C-casts are deprecated in C++. While they still exist and can be used, it is a good idea never to use them, and use C++ casts instead. This shows what part of the value you want to change more clearly. For example, const_cast lets us know you intend to cast away only the const or volatile aspect of a value.

This code stores the base address as a DWORD, dereferences it (in order to replicate the [] operators in a Complex Address) via ::ReadProcessMemory(), saves the new value over dwBase, and adds the offset at the end, taking dwBase all the way from the base address to the final address.



Think for 10 seconds what is wrong with this code.






If 32-bit platforms were the only platforms that existed, nothing would be wrong with this approach. Unfortunately, we live in a world where 64-bit architectures not only exist, but are common.
Addresses on 64-bit machines are not 32 bits in size. You can not use a DWORD to represent these addresses.
So what do you do? Rewrite the code every time you want to port it to a new operating system?

WRONG.
The Windows® headers define a type made specifically to aid in this type of portability.
Refer to UINT_PTR. It is a typedef that is defined as 32 bits on 32-bit compiles and 64 bits on 64-bit compiles.

The code becomes the following:
Code: Select all
UINT_PTR uiptrBase = 0x005002FC;
if ( ::ReadProcessMemory( hProc, reinterpret_cast<LPCVOID>(uiptrBase), &uiptrBase, sizeof( uiptrBase ), NULL ) {
    uiptrBase += 0x62988;
}


Recompiling this for 64-bit machines requires no modifications, although the base address will surely be different.



Very few hacks/trainers/etc. get ported to multiple platforms, but there is still no excuse not to use UINT_PTR.
#1: It shows us (and you) how the value is intended to be used. Look at a trainer full of DWORD values. Which ones are addresses? Which ones are offsets? Which ones are just for regular math? It would sure make things clearer for yourself and anyone else who may view your code if you used UINT_PTR for addresses. It would not even hurt to go the extra mile and use typedef DWORD OFFSET; to make it clear which values are meant as offsets.

#2: Using UINT_PTR removes warnings when casting to and from void * (or LPVOID or LPCVOID). Even a single warning for any reason means your code is not finished.

#3: What if you DO port to 64-bit platforms? The only thing DWORD will have done is bite you in the ass.

#4: Ultimately, UINT_PTR is there for a reason. It facilitates exactly the purpose you need it to serve, so why not use it and make your code “proper”?


L. Spiro
Last edited by L. Spiro on Sun Oct 11, 2009 8:05 pm, edited 1 time in total.
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby toffey » Sun Oct 11, 2009 11:06 am

Lovely tips, I think this might come in handy for me.
User avatar
toffey
Hack-Master Hex
 
Posts: 689
Joined: Fri Sep 05, 2008 5:39 pm
Location: California, USA


Return to Knowledge Base

Who is online

Users browsing this forum: No registered users and 0 guests