HadesMem

Just in-case anyone reading this doesn't follow either MMOwned or Game Deception's forums, I've released a memory hacking library, similar to 'BlackMagic' by Shynd, except aimed at C++.

Anyway, for the full description and details, check the release thread on GD here.

Beware when hooking window procedures returned by GetWindowLongPtr

I'm currently rewriting (read: improving) a bunch of stuff for Hades, and one of those things is the window management. Previously I was using a messy system in which I used window subclassing in order to 'hook' the window procedure of the display window(s) of the game.

The problem with this approach is that window subclassing is quite 'ugly', and it required me to hook several APIs, for which the implementation was also quite 'ugly'.

I solved this by moving to a detour-based system on the window procedure for the game's display window. Whilst there are some obvious problems with this approach too (which I will not get into now because they're complex and irrelevant) I believe the pros outweigh the cons.

One problem I ran into whilst implementing this new system however is the behaviour of GetWindowLongPtr when retrieving a window procedure, and how that behaviour changes depending on whether your module is ANSI or Unicode, and whether the target is ANSI or Unicode.

If the character sets don't match, GetWindowLongPtr does not return a true pointer, it returns a special internal handle which is then 'translated' by CallWindowProc. MSDN actually documents this behaviour but I accidentally skimmed over it and ended up reversing this behaviour myself. >_>

Long story short, if you want to detour the window procedure you need the 'real' pointer, so the obvious solution is to call both functions, detect which one is the handle, and throw it away (hence leaving you with the real pointer).

Here's the code to do that, thankfully the handle detection is very simple, I just wish I had read MSDN more closely the first time:

HookWindow-v20100117a

New Loader Build

New build of my loader released. Fixes a few bugs, including one very annoying one in the GUI. Download link available on the original post.

Custom RtlSetProcessIsCritical Implementation

Project:
WinNinja

Description:
RtlSetProcessIsCritical is an undocumented API that was added in Windows XP. It is a light wrapper around NtSetInformationProcess with the ProcessBreakOnTermination information class. When this flag is enabled on a process, it causes a bugcheck to be raised when the process is terminated. It is used by system processes (for example CSRSS), however, with the right privileges, we can use it too.

To use the API you will need the debug privilege (SeDebugPrivilege), which of course requires your application to be running as Administrator. To ease the testing/implementation process of this code I have provided sample code to request the privilege.

The API is defined as follows (parameter names, parameter types, and the return type are of course educated guesses as no documentation and no symbolic information is available):
NTSTATUS RtlSetProcecssIsCritical(BOOLEAN NewValue, PBOOLEAN OldValue OPTIONAL, BOOLEAN NeedBreaks);

NewValue = The new value to set for the ProcessBreakOnTermination flag.
OldValue = The old value of the ProcessBreakOnTermination flag.
NeedBreaks = If this is set the API will only enable the ProcessBreakOnTermination  flag if the 'Enable system critical breaks' flag is also enabled for the process.

I'm sure you've noticed by now that this API does not allow you to choose the process that the code is run on. Because I needed to use this API on an arbitrary process, I reverse engineered it, rewrote it in C, and extended it to support arbitrary processes.

One minor thing I haven't fixed yet is the system critical breaks checks. If you use this custom implementation on an arbitrary process, the NeedBreaks parameter is ignored. It's an easy fix, I just haven't done it yet because I have no need for that particular parameter and I'm lazy. It's on my todo list however so when I do get around to it I'll post an update here.

In case anyone is interested, here is the implementation of the function (in IA32 ASM) as it appears on my machine under a 32-bit process. I'm running Windows 7 x64.

Notes:

• The code snippets are 'incomplete' in the sense that they are pulled from a larger library and hence have minor dependencies on internal libraries I use (such as the EnsureCleanup libraries). Also, the custom structures, enumerations, and API importing code is not provided. None of this should be hard to fix up though.
• My implementation is based off the implementation of the API on Windows 7 x86. It appears to work on both x86 and x64 machines (with both native x86 and x64 implementations/processes), on Windows versions of XP and above. However I give no guarantees as to OS compatibility.

As always, comments and constructive criticisms are appreciated.

This may not appear elsewhere without permission, but may be linked to.

Releases:

RtlSetProcessIsCritical-v20091125

WinNinja File Hiding Code

Project:
WinNinja

Description:
This is a code example from WinNinja, showing how to hide files by hooking the NtQueryDirectoryFile API.

Notes:

• You will need to provide your own hooking library. I'm not posting mine (yet?).
• You will need to provide your own "ShouldHideFile" function (and obviously your own "ToLower" if you want to convert the string to lower-case).
• This is designed as a BASE, not a full implementation. Hence my next point.
• There are quite a few potential holes and stability issues in the code. I have purposefully left these in for the public version, and removed the comments documenting them. This has been done to try and stop people copy-pasting this into their malware without knowing what they're doing.
• In order to further stop the copy-pasters using this without understanding it, I have removed entirely the section of code commented with "REMOVED". This is because the implementation of it should prove easy to anyone who knows what they're doing, but difficult to anyone who doesn't.
• There are still other things you need to hook if you want to hide files entirely. It's up to you to figure out what.
• You will obviously need to provide your own custom structures, information class enums, status codes, etc. They're not hard to find in a lot of open source projects, however you need to keep in mind their licences (normally GPL). So if you want to use this in public closed-source software I suggest you reverse the Windows kernel and get them yourself.

Anyway, if you're not a moron this should provide a quick and dirty starting point for you.

As always, comments and constructive criticisms are appreciated. Also, if you notice any of the holes and want to help out the other readers you're free to post them in the comments. I just didn't want to post them myself because I thought it would be more fun to see how many you guys can find.

This may not appear anywhere else without permission, but may be linked to.

Releases:

NtQueryDirectoryFile_Hook-v20091101a

Advanced Generic DLL Injector

Project:
Loader


Description:
A generic, advanced, and portable DLL injector.


Features:

• Native IA32 injection. (Inject 32-bit DLLs into 32-bit processes.)
• Native AMD64 injection. (Inject 64-bit DLLs into 64-bit processes.) 
• Injection via process id. (On the fly injection.)
• Injection via window title. (On the fly injection.)
• Injection via process creation. (On the fly injection.)
• Injection via process name. (On startup injection.)
• Ejection via process id. (On the fly ejection.)
• Ejection via process title. (On the fly ejection.)
• Ejection via process creation. (On the fly ejection.)
• Ejection via process name. (On startup ejection.)
• Remote export calling. (Call an export remotely in the module. Allows for safe injected DLL programming.)
• Batch scriptable command line interface.
• Suspends the process while injecting or ejecting to help prevent potential race conditions present primarily in DLLs that perform hooking.

Compatibility:
Should work on all Windows versions after and including Windows XP SP2. Support for Windows versions earlier than SP2 is unofficial. If you get it to work that's great, however I have no interest in officially maintaining anything earlier than XP SP2.


Personally, I run Windows 7, the only reason I support anything earlier than that is for when I make public releases. I'd love to be able to drop XP and Vista support entirely, however there are still too many people still using them.


Tested and working natively on both IA32 and AMD64 .


Notes:

Binaries only for this release. Source may/will come later, once I am ready to open-source some new dependencies or fork the loader project internally to avoid them altogether.


Suggestions and criticisms are as always appreciated.


This may not appear anywhere else without permission, but may be linked to.


Releases:

v20091027a - Initial release. No known issues.
v20091112a - Minor miscellaneous fixes.
v20091117a - GUI added. Minor miscellaneous fixes.
v20091118a - Minor GUI bug fixed.
v20091119a - Fixed bug with Launch not functioning correctly. Thank you alex.
v20091209a - Fixed a few misc bugs, along with one very annoying one causing the GUI to be unable to launch the Loader in some scenarios (thank you Apoc).