Moved

This blog has moved to www.raptorfactor.com. Mirroring/forwarding is in effect for the time being (but may not be forever). Please update bookmarks accordingly.

HadesMem and MinGW-w64

In an earlier post, I mentioned that HadesMem v2 now works under GCC and Clang (both of which use the MinGW-w64 runtime on Windows). This is still true, but the question now is, for how long? I have been trying recently to get GCC and Clang to play nice on a personal project of mine which uses a lot of COM and ATL code, but it seems to be a lost cause. There are entire header files which are missing from MinGW-w64, and a lot of COM APIs which are missing from the existing header files.

Up until now, supporting GCC and Clang in HadesMem has been a bit of a maintenance headache, but nothing that couldn't be overcome with some simple workarounds and #ifdefs. Now however, it seems that I need to pick between having full access to the Windows APIs, or having support for MinGW-w64 (I simply don't have the time nor the motivation to add support for all these APIs to MinGW). For the lower level components it seems that MinGW-w64 contains everything I need, but problems quickly arise when trying to write higher-level code (using the Shell COM interfaces, ATL, WTL, etc), which is of interest to me for HadesMem because I'd like to write a couple of basic GUI tools on top of the library.

So, I guess the point of this whole post is to find out whether there is actually any interest from library users in support for compilers other than MSVC. If there is please let me know, using whatever method suits you best (the comments, email, etc). I haven't made up my mind yet, but it seems that the drawbacks are very quickly piling up against the benefits...

EDIT:

It is of course possible I could simply continue to support all compilers for the library portion, then make the tools written on top of it MSVC-only, but then that becomes a pain when maintaining the build system. The other alternative is to simply 'suck it up' and rewrite all the code (where possible) to support MinGW, and where it isn't to actually fix/extend MinGW, however I'm not sure I really want to put that much work into a platform I don't really use other than to make sure my code is as portable as possible.

[Planetside 2] v0.483.26.180118 Update

A new and rather large patch was released last night, and I was curious whether they had fixed the teleport hack so I updated it. They haven't...

Download for v0.483.26.180118.

[Planetside 2] Teleport and Below Ground Hack

Abused this for a couple of days, now I'm bored with it. This is just a very basic teleport hack, and also a hack that will let you either walk under the ground or 'skywalk'.

The main reason I'm releasing this is that Planetside 2 is really boring, and that this hack was so easy to write that I wouldn't be surprised if 50% of Planetside players were already teleporting around. I could probably teach my cat to find the player coordinates and change them with a memory editor.

It's all pretty straight forward, run the hack from a command prompt once you've launched the game, then use the following controls:
Numpad+ = Walk higher
Numpad- = Walk lower
Numpad/ = Reset height
Numpad* = Teleport to personal waypoint

The teleport hack is a tad buggy because occasionally the pointer(s) I'm using to read out the personal map waypoint will decide to change. Just go into your map then do a "Clear Waypoints" then reset it to whatever waypoint you want and it will work again.

As for the walking height hack, I have no clue what's going on there as far as the physics engine is concerned. I found it by accident whilst looking for something else so I didn't bother investigating what's actually going on. It's really weird and buggy if you try to walk underneath vehicles etc (read: it will teleport you up in the air and likely kill you), but if you're careful you should be able to go on an insane killing spree. For example, I went 350-0 on my server before getting bored and killing myself. It's a little glitchy though when you're walking under the terrain, so you'll need to practice and learn where you can and can't go, how to get past certain walls (usually just go really really low then pop back up), where to get ammo down (typically inside rocks, on stairwells, etc, you normally don't need to come back up to ground level to get it down), etc.

Anyway, code and binary below. The code is disgusting and I don't care (code is bad and I should feel bad, etc). I whipped it up really quickly as a PoC for some friends, then got bored with it when we realized how boring Planetside was. This hack has survived at least 3 client patches that I'm aware of without needing to be updated, so it should be fairly 'low maintenance'. Nevertheless, don't expect updates from me, the hack is extremely trivial to update for even the most dimwitted of monkeys (any old memory scanner and debugger should do). That being said, if you actually go to the trouble of finding a more reliable way to read the personal waypoint (there's probably an engine function for it, but I haven't looked) or find something else useful please do post it here for others.

Now I'm rambling to the point where this post has nearly taken longer to write than the actual hack, so I'll shut up now...

Enjoy!

Download:
Planetside2 v0.473.22.176761 **SHIPPING**
Planetside2 v0.483.26.180118 **SHIPPING**


14/12/12:
Uploaded updated hack for new client patch (Planetside2 v0.483.26.180118 **SHIPPING**).

HadesMem v2 Compiler Support

So, it's been a while since I've started work on HadesMem v2 and I wanted to give a status update. So far everything is going relatively smoothly... I'm still working on rewriting and reintegrating all the v1 components (fixing bugs and adding minor features along the way), however one of the biggest changes made so far is that HadesMem now compiles and runs (examples and tests) on every major C++ compiler for Windows. This means that HadesMem now works under the latest versions of MSVC (11), Intel C++ (13), GCC (4.7), and even Clang (3.1)! Please note that support for compilers other than MSVC is still considered experimental and subject to change, but I'm quite happy with the state of things now, so I believe I will be able to maintain compatibility across all compilers from this point onward (however when v2 is finally 'finished' the required compiler versions will probably be newer than those listed here).

More information on other new developments to come Soon.

Boost Addressof Warning/Error under Intel C++ 13

Another quick post to provide a patch which fixes a warning in Boost.Utility/Addressof. This warning occurs under Intel C++ 13 (and probably other versions) when compiling at the highest warning level. Unlike other warnings though, it apparently cannot be disabled with #pragma directives, so if you compile with warnings as errors it results in an error which you cannot disable.

The root of the problem seems to be that the compiler thinks an rvalue is being passed to a function taking a non-const reference, however in this case it is a false positive (the rvalue has an implicit conversion operator which returns a reference to the underlying lvalue which it is wrapping). I have worked around it by turning the wrapper into an lvalue and passing that instead.

Boost.Test Warning under Intel C++ 13 Beta Update 2

Just a quick post to provide a patch to fix a warning that I was unable to silence with pragmas when using Boost.Test under ICC v13 Beta Update 2 (does not happen on all uses of Boost.Test, I'm unsure of the exact trigger).