HadesMem - A Windows Memory Hacking Library for C++

[flo8464]

If I remember right, it's GPL compatibel if you just compile a library to a dynamic library and include that DLLs source.

[Cypher]

If I remember right, it's GPL compatibel if you just compile a library to a dynamic library and include that DLLs source.

Not in this case:
Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation (FSF)

I'm not a lawyer, but as far as I'm aware the relationship between my library and the program using it would be too close for it to constitute two separate programs.

At any rate, even if you try to abuse that potential ambiguity (and my good will), it's definitely something I would fight you over (not you specifically of course, I mean that in the general sense), because I'm pretty sure my understanding is accurate.

[XTZGZoReX]

Actually, I'm pretty sure one could legally ship your library as a DLL with their program.

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

An executable interfacing with a DLL would be what I call "arms length", and doesn't make it a "single program", since another program could use it as well.

Regardless, it'd still be in bad taste to use the program/library (yours in this case) commercially if the developer doesn't want this to happen.

[Sednogmah]

If I remember right, it's GPL compatibel if you just compile a library to a dynamic library and include that DLLs source.

The LGPL (Lesser/Library GPL) definitely allows you to do that. The case is a bit blurry for the GPL.

There seem to be two different strands of opinion. The FSF holds that dynamic linking creates a derivative work, and so any program designed to run with a GPL-ed DLL, must be GPL itself; see http://www.fsf.org/licenses/gpl-faq.html. The only exception they make is for DLL's that come with the compiler and the kernel, such as the MS VC run-time DLL's; see http://www.fsf.org/licenses/gpl-faq....sRuntimeAndGPL. On the other hand some OpenSource lawyers hold that dynamically linking does not make your program GPL. See http://www.nusphere.com/products/lib...401openmag.pdf and the discussion in http://www.linuxjournal.com/article.php?sid=6366.
There is no doubt that programs that link dynamically to DLL's from libraries with the LGPL or with the GPL with special provisions, may be GPL free.

All in all, I agree with some previous posters. It's just plain rude to disrespect the author's wishes.

[Cypher]

Actually, I'm pretty sure one could legally ship your library as a DLL with their program.

An executable interfacing with a DLL would be what I call "arms length", and doesn't make it a "single program", since another program could use it as well.

Regardless, it'd still be in bad taste to use the program/library (yours in this case) commercially if the developer doesn't want this to happen.

I guess it depends on what constitutes "arms length" in that context. I'd actually be interested to know, so maybe I'll shoot off an email to the FSF and see if I can get that clarified.

At any rate, it's definitely (as you put) "in bad taste".

[flo8464]

Don't misunderstand me, I just discuss the legal background, I don't even use this lib as I wrote my own one month ago.

[XTZGZoReX]

I guess it depends on what constitutes "arms length" in that context. I'd actually be interested to know, so maybe I'll shoot off an email to the FSF and see if I can get that clarified.

Indeed; sadly, a lot of the GNU licenses have paragraphs that are vague and subject to interpretation...

[GliderPro]

Wasn't the LGPL created because someone got sued for using GPL code compiled as a SO file with their closed-source application? The SO file in Linux is the same thing as a DLL in Windows. I agree that the GPL is fuzzy on this subject but I wouldn't bank a business venture on fuzzy logic.

Should programs that link to GPL'ed DLLs from GnuWin32 also be released under the GPL?

There seem to be two different strands of opinion. The FSF holds that dynamic linking creates a derivative work, and so any program designed to run with a GPL-ed DLL, must be GPL itself; see Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation (FSF). The only exception they make is for DLL's that come with the compiler and the kernel, such as the MS VC run-time DLL's; see Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation (FSF). On the other hand some OpenSource lawyers hold that dynamically linking does not make your program GPL. See http://www.nusphere.com/products/lib...401openmag.pdf and the discussion in Derivative Works | Linux Journal.

There is no doubt that programs that link dynamically to DLL's from libraries with the LGPL or with the "GPL with special provisions", may be GPL free.

If some asshat pulls this with Cypher's code I would gladly petition the FSF to go after them. Also, Cypher's coding style is pretty unique/evolved so I'm pretty sure you could detect binaries that used it even if the code was refactored.

[Cypher]

Was reading some blogs that I haven't been up to date with for quite some time, and came across this post which I believe hits the nail fairly squarely on the head:
Thoughts About Open Source Community In RE Insanely Low-Level

[Cypher]

* Removed IatHook class for now. Sorry, I'll bring it back later, but for now I want to work on a more generally applicable patching library.
* Added Patcher lib. Currently contains both raw and inline patch support, with VEH hook support coming soon. Tested and working on both x86 and x64. There is of course more work that needs to be done, but it's a decent base.
* Misc other changes and fixes.

[Cypher]

Currently working on a fairly substantial rework internally. Made a lot of progress so far but there's still a lot left to go.

The main changes so far are:
1. HUGE speed improvements for some APIs which were retardedly slow. (The Module library for example was stupidly slow, I didn't even notice until recently. Sorry about that. >_>)
2. A much better scripting layer. All modules which I have finished the rework of so far have been fully exposed to the Lua layer. Example scripts are attached.
3. HadesMemHack is now nothing more than a basic Lua interpreter. From now on I'm just going to use the scripting layer for all that type of stuff. It makes it easier to maintain, less work when new features are added, aids in testing, etc.
4. I am adding a 'base hook' to the library for injected hacks and what-not. Currently it's just a placeholder, but once I finish on the library portion I'm going to be adding all my D3D hooks, process hooks, input hooks, etc to it. Eventually it will be what is effectively a "lightweight InnerSpace".
5. Lots of minor bug fixes, cleanups, etc.

It's currently not up on the SVN because it's not yet of release quality, but if you'd like a sneak peek just shoot me a PM with your details and I'll email you off new builds every now and again.

Here's some of what I've been working on (these are some of the scripts I've written just to quickly test various parts of the API, some modules have not yet had test scripts written because they have not yet been reworked, however it's on the todo list):
http://dl.dropbox.com/u/74751/HadesM...-20100516a.zip

[Robske]

The lua scripting is awesome! Very nice work.

[Cypher]

Just realized that LuaBind has much better STL support than I knew about. Currently STL containers are 'wrapped' for use in the Lua layer, however I just found out I should be able to provide implicit conversions from Lua's native array and table types to their STL counterparts. Woot.

EDIT:

Maybe not. Can't get the ****ing policy class working properly.

[Cypher]

Finally added 'official' support for suspended process creation and injection.

Script example:

MyInjectInfo = HadesMem.CreateAndInject("C:/Users/Public/Games/World of Warcraft/WoW.exe", "", "Hades-Kernel_IA32.dll", "_Initialize@4");
MyMem = MyInjectInfo.Memory;

HadesMem.WriteLn("");
HadesMem.WriteLn("Process ID: " .. MyMem:GetProcessID());
HadesMem.WriteLn("Hades-Kernel Base: " .. HadesMem.ToHexStr(MyInjectInfo.ModBase));
HadesMem.WriteLn("Hades-Kernel Initialize: " .. MyInjectInfo.ExportRet);

[GliderPro]

Finally added 'official' support for suspended process creation and injection.

Excellent! Now I can rip my hack out of my injector.