HadesMem - A Windows Memory Hacking Library for C++

[KOS0937]

wow





just wow



When I read the first post I thought: "Nice. To learn memory reading / editing in c++ I can look at this source and even see some nice stile of coding while learning what I wanted."... To bad this has become sooooo huge
Very nice job though =) And thank you very much for sharing this. I might take a look at this... even though i don't really know where to start..

Some small questions though, if you don't mind ^^. It's just that I'm learning c++ right know and don't want to keep using java habits or something else I might have picked up in the past
1. While quickly scanning your code i saw some "#ifdef _DEBUG". I thought this was somewhat errorprone and thus not adviced. The compiler should detect that

const bool debug=false;
if (debug) {...}

is never executed and thus remove it from the final .exe...
2. Is there some reason, why you only use headers? It's not really helping the overview.

[Cypher]

wow





just wow



When I read the first post I thought: "Nice. To learn memory reading / editing in c++ I can look at this source and even see some nice stile of coding while learning what I wanted."... To bad this has become sooooo huge
Very nice job though =) And thank you very much for sharing this. I might take a look at this... even though i don't really know where to start..

Some small questions though, if you don't mind ^^. It's just that I'm learning c++ right know and don't want to keep using java habits or something else I might have picked up in the past
1. While quickly scanning your code i saw some "#ifdef _DEBUG". I thought this was somewhat errorprone and thus not adviced. The compiler should detect that

const bool debug=false;
if (debug) {...}

is never executed and thus remove it from the final .exe...
2. Is there some reason, why you only use headers? It's not really helping the overview.

1. Your example makes no sense. The '_DEBUG' is defined by the COMPILER in debug builds, not me. It's a way to detect whether the code is being compiled for debug or release mode. What you have proposed does not do that, and is in fact more error prone than what I'm currently doing because I rely on the compiler to tell me whether or not we're compiling a debug build, whereas the solution you've suggested requires me to determine that and set that flag manually.

In short: No. You're coming at it from the wrong angle.

2. I use headers only for Hades-Memory because originally the implementation was very template-heavy, and templates must be defined in headers*. It also makes consuming the library easier because you don't need to worry about linking the library. The only overhead is a bit of extra compilation time, which I really don't care about at the moment.

I may eventually move it to a more 'conventional' format, but for now I'm happy with it the way it is.

* Don't even mention the export keyword. Not a single mainstream compiler supports it, so for all practical intents and purposes it doesn't exist.


EDIT:

Also, it's not as big as you probably think. Hades-Memory (the generic library) can be used independently of the injected framework. The latter depends on the former, but not the other way around.

Though, that being said, it's definitely a 'large' project as far as these things go.

[KOS0937]

Ok

I didn't know, the _DEBUG is defined by the compiler. In "Professional C++" by Solter and Kleper the const bool debug is favored. It might be, that this book is just a bit outdated.

Thank you for your quick answer =)

[Cypher]

Ok

I didn't know, the _DEBUG is defined by the compiler. In "Professional C++" by Solter and Kleper the const bool debug is favored. It might be, that this book is just a bit outdated.

Thank you for your quick answer =)

Could you post the passage where they say that? I think you may just be misinterpreting it.

I could understand if they're suggesting this:

bool const Foo = false;
if (Foo) { DoStuff(); }

Over this:

#ifdef FOO
DoStuff();
#endif

However the '_DEBUG' macro is special. You can't replace it with a boolean flag, because it needs to be set by the compiler, not a human.

EDIT:

Going out, I'll be back in an hour or two, so if you've replied I'll deal with it then.

[KOS0937]

I've looked through the book, but apparently they use the _DEBUG macro as well. 8[ (they mention the non-const bool debug flag as an alternative though, in case you want to have the debug code in the release-build...)

I'm sorry, I must have picked it up somewhere else. the argument being something like
"There is more error-checking for if-statements. no compiler will say anything against something like

#ifdef _DEBUG
	int i=0;
#endif
	cout <<i;

but every compiler will stop at

	if (debug) {
		int j=0;
	}
	cout << j;

or similar. (returns inside the debug code etc. as well)"

It must have sounded perfectly logical when I heard it or I wouldn't have remembered it. Too bad I (apparently) don't know where it's from :-(

EDIT: of course the above example is not really "error-checking", as the if-statement just has it's own stack-frame. The int variable thus doesn't even exist in the second case when it is needed. But there are other examples, like a 'return'. If the only return is in an if-block, the compiler will notice that there should be a return value even without this 'if'.

EDIT2: there is a lot that can go wrong with preprocessor commands. for example

if (something) {
	cout<<"can't do that"<<endl;
#ifdef _DEBUG
	cout<<"so line 99 didn't work after all..."<<endl;
}
#endif

in a more complex situation this might not be as simple to see.
Personally I will use something like:

#ifdef _DEBUG
	const bool DEBUG = true;
#else
	const bool DEBUG = false;
#endif

[Cypher]

Errr, k...

[Cypher]

I know that I'm probably the only person using the x64 builds of Hades, but just in case there's one other person out there who is also using them, I've patched LuaBind to fix scripting support. Previously you could not use 64-bit integers due to a LuaBind limitation, that is now fixed however so all the functions which return pointers/addresses should now work correctly in your scripts.

Since my last post I've also fixed some bugs and started work on a GUI to manage the injected portion of Hades, though I'm writing it in unmanaged code and I've only just started so right now it's mostly just test code. Eventually I'd like to wrap a GUI around the non-injected part too (effectively a Cheat Engine replacement), but that's further down the track.

[GliderPro]

Cypher, I'm curious about how you specify the include and library paths for boost and the DXSDK. I haven't messed around with VS2010 much but I understand they use property sheets now and you can no longer set global paths from the Tools|Options menu. I can get HadesMem to compile by modifying all the individual projects but that is a pain since they are source controlled. How are you specifying these paths in your build?

[caytchen]

View -> Other Windows -> Property Manager -> edit Microsoft.Cpp.Win32.user property sheet since projects will inherit from it automatically. Google could have told you.

[Cypher]

View -> Other Windows -> Property Manager -> edit Microsoft.Cpp.Win32.user property sheet since projects will inherit from it automatically. Google could have told you.

Correct. Though for Hades you'll also have to modify the x64 property sheet as well because I have it set up to build for it too if requested.

[GliderPro]

View -> Other Windows -> Property Manager -> edit Microsoft.Cpp.Win32.user property sheet since projects will inherit from it automatically. Google could have told you.

Google did tell me but I wasn't able to get it to work. I messed around with it some more today and I found the problem. I was editing the "additional include directories" property in the Microsoft.Cpp.$(Platform).user.props sheets but the properties weren't being inherited. It wasn't until I hit the dropdown next to that property in the HadesGUI sheet and chose "edit..." that I noticed the "inherit" checkbox was unchecked. I checked it and everything worked fine.

So that brings up another question. Which property are you adding these paths to? If you are using the "additional include directories" property is there some global setting to force inheritance that I need to set.

[Cypher]

[GliderPro]

Thanks Cypher.

[Cypher]

Np. (Filler)

[GliderPro]

HadesMem has changed a lot since I worked with it last. Here are the steps I had to perform to get it to build completely.

1) Get boost
2) Get DirectX SDK
3) Get WTL
4) Edit the Microsoft.Cpp.Win32.user/Microsoft.Cpp.x64.user property sheets and add the include and library paths from the libraries above to the VC++ Directories property.
5) Disable signing of the Hades-AD project. I tried creating a new key file but I kept getting "access denied".

EDIT: For step 5 above you can create a new key if you start VS2010 with elevated privileges.