Good to hear it works for you.

There’s no need to create a separate thread from DllMain as Initialise returns almost immediately. However I wouldn’t recommend calling Initialise from DllMain as it invokes a lot of heavy work while in a fragile state and could potentially create a deadlock. Perhaps moreover, if the DLL is injected early on (in particular, by a system-wide hook) then the Initialise event is liable to fail since d3d9.dll may not have been loaded.

For this reason it’s a much better idea to periodically invoke Initialise by a remote call (i.e. from a different process) until it succeeds. I suggested using CreateRemoteThread for this, with a similar method to that described in the DLL Injection post.

Greg

Thanks for sharing, KozmoK.

I’m aware that these soft hooks are PunkBuster-incompatible for the more sensitive functions, but I have no plans to address that. Detours may well be a solution - maybe you’d be so kind as to let us know if you get it working that way.

And about the crashes in Crysis. I’ve experienced the same thing with a few other programs. The problem lies with a lost device. Presumably, Crysis switches graphics mode between maps, which invalidates the device. Any subsequent rendering calls predictably cause a crash. The situation could quite easily be rectified with a call to TestCooperativeLevel. Maybe I’ll add this to the source when I get a chance.

Greg

Hi Joel.

Yes, the code has been tested on Vista, but like you say, it needs some modification. The main source of problems is that Vista uses a different version of d3d9.dll from XP, with the functions having different addresses and prologues. All that would need changing are the hard-coded addresses and the five-byte buffers of their default opcodes (and some conditional checks, if both OSs need to be supported simultaneously). Note that this all lies under the assumption that the DLL is uniform and not a part of the side-by-side assemblies scheme - I think this is the case, but haven’t verified it.

I would post the details of the source changes right here, but I don’t have access to a Vista computer. It would only take a few minutes in a debugger if you know what you’re doing, but the learning-curve is perhaps a little steep if you’ve never debugged a foreign binary before. Alternatively, you could get creative and implement the virtual-address resolution discussed here. Drop me an email if you want to go into further detail.

Good luck
Greg

A Direct3D program can be forced to run ‘windowed’ by altering the D3DPRESENT_PARAMETERS struct passed to IDirect3D9::CreateDevice - this can be done by means of a hook just like the others. Set Windowed to 1 and FullScreen_RefreshRateInHz to 0. This will at least prevent the program from acquiring exclusive access to the screen (and so allows you to flip back and forth to the debugger) but depending on other factors, the device-context may not be bound to a movable window in the way we’re all used to. I’ll have a poke around with this and report any success I have.

As for a debugger recommendation, I would advise against anything other than OllyDbg, which gets my full approval.

And as for Vista’s DLL-basing, this may be a problem. As of XP, all DLLs are necessarily relocatable with the exception of ntdll, user32 and kernel32, which always reside at the respective addresses. The Direct3D hooking sample itself doesn’t take advantage of this, but the DLL Injection class does. The fix simply involves using EnumProcessModules to find the base of kernel32.dll in the remote process and updating the LPTHREAD_START_ROUTINE in DLLInjection::InjectDLL accordingly, but as I say, I don’t have Vista so I can’t make any promises. It may be worth a try, replacing the call to GetProcAddress with the corresponding GetRemoteProcAddress (in InjectDLL), as this would do exactly that, IIRC.

Greg

As of Direct3D 10, at least, multithreading is not supported. That means that you need not concern yourself with asynchronous calls to a function while its in the process of hooking or unhooking itself. I couldn’t vouch for Detours’s effectiveness in this situation, but from what I can tell it’s a powerful and mature library - certainly worth a look. I shall have to make a post about Detours once I’ve fully evaluated it, as it bears much more relevance to my recent work than I initially understood.

From what I’ve gathered, the Direct3D functions mentioned here are in PunkBuster’s demilitarised zone, so to speak. This is presumably to maintain compatibility with Fraps, XFire and the likes. However, if you try to mess with DrawIndexedPrimitive or its friends then you’ll quickly find yourself in trouble.

Joey, are you running XP SP1/2? The code here doesn’t work for anything else, and will presumably crash before very long. I’m now running Vista and so I’ll get to making this sample compatible as soon as I get the opportunity. If you really can’t wait for that then you’re free to replace the relevant constants with the appropriate values yourself.

If that isn’t the problem then you could give me a little more input so as to fix the problem. In particular, what OS are you running, which game are you injecting into and what are the details of the exception that’s raised? Are you checking all the return-values?

Greg

All you Vista-users, see the project update. I’ve tested it on Vista 64; would like confirmation that it also works on the 32-bit version.

Greg

Microsoft explicitly dictate that nothing too involved should go into DllMain. This certainly includes an idle loop that waits for another DLL to load - indeed, the single-threaded nature of DirectX suggests that if the first GetModuleHandle fails then no amount of waiting around will do any good as the entire program is being blocked. So when the DLL-loading operation inevitably times out, the program doesn’t know how to continue.

For some information on the CreateRemoteThread method of remote procedure calling, see this post. You need only adapt it to call Initialise rather than LoadLibraryA - I deliberately made Initialise have the same prototype for this reason.

Alternatively, unless you’re using your own methods to inject the DLL (such as a system-wide hook - yuck) then you could get all the work done for you by my injection framework. Then the remote call would reduce to a single call to:

injection.CallThreadProc(”Initialise”, NULL, 5000, exit_code);

This will only work with a valid injection object, which means you won’t be able to inject via your own methods. If that’s necessary then you can still cannibalise the code to see how to make the call.

Greg

I downloaded the Xenimus demo, and it seems there’s a very good reason the D3D9 hook isn’t working. While the website says that the game requires DirectX 9, and it does indeed reference the d3dx9_34 helper library, all the rendering is done in Direct3D 8. This is evident from the presence of d3d8.dll and the absence of d3d9.dll in the process’s address-space (and the fact that Initialise returns -1).

So you could port my code to work with DX8, which should be fairly straightforward, if a little tedious, provided you can work a debugger. Failing that, I’m sure there are some other code samples out there targeted towards Direct3D 8. I’m afraid I’m not prepared to do the all work for you though, as DX8 is pretty dated and I’d rather not clutter up the code.

Since we’re now off-topic, I’d appreciate it if you directed any further questions to me via email rather than commenting on the post.

Good luck
Greg

That’s a little worrying. Perhaps there is more than one version of d3d9.dll in the wild for 32-bit Vista. If that’s the case, I’ll have to resort to using the method in this post (which you evidently found and I hope answers your questions). That would involve a compromise somewhere along the line, though, as it requires an initialised IDirect3DDevice9 object in order to function.

So indeed, can anybody confirm that the new offsets are causing problems?

Austin. Take a look here. There’s currently a little doubt surrounding the effectiveness of this method as I’ve received (but not yet investigated) reports of it producing entirely erroneous results. It worked for me though, so it’s certainly worth a try.

If that doesn’t work out for you, it should be simple enough to code up a program with a call to the virtual function in question immediately after something easily identifiable (say, two successive calls to IsDebuggerPresent). Now by throwing the resulting executable at your debugger and setting an appropriate breakpoint you can trace into the call (which will almost certainly be of the form CALL ) and see where you end up. Once you have the absolute address of the function, subtract the base address of the DLL (where the PE header begins in memory) for the relative offset which can be used under all circumstances.

For the record, it’s not generally too easy to find these function locations in a debugger using somebody else’s binary as the compiler trashes all easily processable mappings of function names to addresses. If for some reason you are entirely unable to debug your own Direct3D program then you’ll have to be a little creative and reverse-engineer the target to find the pertinent call, paying attention to stack parameters and comparing the arguments with those specified by the Direct3D docs.