GeDoSaTo 0.19 “Chaos Flare” – Completely revamped injection

I just released a new version of GeDoSaTo, 0.19 “Chaos Flare”. This release completely changes the injection method. The goal is to be:

  • More consistent. There is now only one method of injection for everything.
  • More compatible. The first injected dll is extremely small, adheres to the Windows standards for DllMain and has no dependencies on any libraries.
  • Safer. The inital dll is written in a very defensive fashion, always loads correctly, and always unloads itself from processes.

This required switching to a 2-stage injection process. Instead of directly injecting the full GeDoSaTo dll, dragging in all its dependencies, and then checking whether it should unload itself, there is now a separate, minimal “shim” dll which has the sole task of injecting the full GeDoSaTo only into whitelisted processes. The entire injection workflow now looks like this:

injectionIn some more detail, the advantages of this are primarily that the “shim” dll, gedoshim.dll, has no dependencies at all except for kernel32.dll, which can be assumed to be present. Furthermore, it doesn’t perform any extensive processing in its DllMain entry point, but rather defers it to a thread it launches. Finally, it always unloads itself, regardless of what happens. All of these properties together should make it almost impossible for it to crash arbitrary processes, even if something does go wrong.

All of this required somewhat major changes, over the course of which I also got rid of some features which shouldn’t really have been used anyways. There are also some drawbacks to this, the extent of which will only be apparent after more people test this latest release:

  • The blacklist feature is gone completely. Every executable you want to run with GeDoSaTo now needs to be whitelisted. It’s safer, reduces complexity, and is really not much work at all.
  • Due to purging the old dual-injection method, the “delayDetouring” option no longer exists. The hope is that games which required it will now simply work anyway, due to the more solid implementation.
  • As you can already see to some extent in the illustration, it’s possible that the new injection mechanism leads to hooks being initialized only after a game has already performed some processing. This has not occurred in my limited testing so far, but it could nevertheless be an issue.

I’ve also used this opportunity to clean up the interface a bit, particularly in Windows 10, and update the readme for the first time in a while.

I’m looking forward to some user feedback on this release. I knew that these changes have been necessary for a while, but I dragged it out due to the high degree of annoyance caused by the shim dll implementation. String processing in C++ isn’t that great in the first place, but without any libraries (including the standard library!) it’s just terrible.

You can get the latest version and test this injection method with the installer provided here. And, as always, you can donate to support GeDoSaTo development (including annoying injection shims!) here.

Note that the main GeDoSaTo dll still requires the latest VC libraries.

Update:
From feedback on Github, it sounds like this update accomplished what it was supposed to. Whew, I’d have hated for all this work to be in vain.

Wrapper_gen, a wrapper generator for COM interfaces

DSfix was based on a Direct3D9 wrapper, which was mostly taken from an existing code base and extended manually.

Recently, I’ve needed to hook Direct3D9Ex, and came to the conclusion that the manual busy work of writing the initial wrapper is better left to a computer than a human. Therefore, I wrote a Ruby script which takes a Microsoft COM dll header interface specification, and generates the C++ code for a wrapper class for it.

Here’s the script (wrapper_gen.rb), it’s rather tiny:

To use it, you specify the interface name, input header file, output file base name, and optionally whether you want logging information to be generated for each wrapped method.

For example, ruby wrapper_gen.rb IDirect3DTexture9 d3d9.h d3d9tex true would generate a wrapper for the IDirect3DTexture9 interface, get the information from d3d9.h, and store the generated wrapper on d3d9tex.h and d3d9tex.cpp. The implementations for the latter would include logging.

Here’s are the generated files for this test case.

d3d9tex.h:

d3d9tex.cpp:

You can adjust the code generated for the logging in the Ruby script. As you can see, this can save you a lot of rote work, particularly if you want to intercept multiple large interfaces.

Update:

The original script didn’t deal with unnamed function parameters correctly. Now it should.

 

Dll injection and error 0xc0000007b

I’m currently writing a DirectX wrapper dll (before you ask, it’s purpose is to improve graphics, not to cheat) and had the issue that most programs I tried it with immediately failed with error 0xc0000007b before even executing the dll entry point.

Many posts on the internet will point to a 64/32 bit version mismatch, which is probably the case for most end users. But in my case, the reason was much simpler: I tried to load a .dll built in debug mode. As most executable are likely shipped in release mode that leads to the incompatibility. Just something to keep in mind.