From Collaborative RCE Tool Library

Jump to: navigation, search

DirectX Tools


Tool name: PIX with callstack patch
Rating: 4.0 (1 vote)
Author: arc_                        
Website: http://www.woodmann.com/forum/showthread.php?t=12696
Current version:
Last updated: May 1, 2012
Direct D/L link: Locally archived copy
License type: Free
Description: MSDN describes the DirectX tool "PIX" as follows (at http://msdn.microsoft.com/en-us/library/bb173085(VS.85).aspx):
"PIX is a debugging and analysis tool that captures detailed information from a Direct3D application as it executes. PIX can be configured to gather data, such as the list of Direct3D APIs called, timing information, mesh vertices before and after transformations, screenshots, and select statistics. PIX can also be used for debugging vertex and pixel shaders, including setting breakpoints and stepping through shader code."

Thus, a highly useful tool right from the MS DirectX SDK for e.g. finding the cause of a rendering problem: for any captured frame, you can click through the executed DX API functions and see how the frame is being built up, eventually finding out what part is to blame.

But what about reversing a closed source application's renderer? PIX does not store a call stack; it merely logs *what* DX functions are called, but not from *where*. Therefore it is not very useful for reversing by default.

I didn't want to let such a great tool go to waste. After some reversing work I ended up patching PIX to log and show (part of) the call stack for each DirectX call that the target program makes. Each call stack entry has both the virtual address and the module name.

Example usage of the resulting modified tool is finding out about and messing with a game's renderer, or more simply locating the HUD rendering code and quickly finding the data that it represents (e.g. health, money) rather than having to resort to memory scanning.
Also listed in: API Monitoring Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: D3DLookingGlass
Rating: 0.0 (0 votes)
Author: Admiral                        
Website: http://www.ring3circus.com/gameprogramming/d3dlookingglass-v01
Current version: 0.1
Last updated: May 5, 2008
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: The topic of debugging full-screen Direct3D applications came up a little while ago. If you’ve ever tried it on a single-monitor setup (or even multi-monitor if the app wasn’t designed to handle it) then you’ll know how much of a pain it is. Windows just can’t handle focus being stolen from a suspended exclusive-mode program. The solution’s exactly what you’d expect - to intercept the relevant window- and device-creation calls and coax the debuggee into running in a window. This works, but fiddling with the calls manually each time you restart the process quickly gets boring. So here’s my first attempt at a generic solution.

D3DLookingGlass is a DLL which, if injected into a Direct3D process early enough, will make sure that all video devices are created in windowed mode, allowing the hosting process to coexist with a debugger without any bother. If you can inject this DLL into the target process before the first call to CreateWindow, then everything should go smoothly. I think. Any later than this and your mileage may vary.

I’ve also written a ‘loader’ program that installs the DLL as a system-wide CBT hook, so that you don’t need to inject it manually. This kind of worked for my limited set of test-cases, but there seems to be no Windows-hooks method of injecting a DLL globally and beating the call to CreateWindow. Windows installs the DLL containing the hook at the latest possible moment for its function, and I can find no type of hook that needs to be around before a window is created. I’d love for somebody to prove me wrong (or suggest another way to install the DLL system-wide), but by the looks of things, my loader is of limited use.

In particular, I recall a situation where the game (Call Of Duty 4 Demo, I think) creates a non-overlapped window, which works fine for full-screen mode, but causes problems when you try force the device to bind as windowed. This will still be a problem unless the call to CreateWindow can be intercepted (and a well-formed window induced), which means that D3DLookingGlassLoader will struggle. Confirmation would be nice.

Here’s the small-print:

* The DLL hooks CreateWindowExW and ShowWindow in its DLLMain. I think this is kosher in terms of loader-lock, but it’s obviously not too cool with regard to system stability. Especially if it’s being installed in every running process. If d3d9.dll isn’t found in the address-space then the hooks fall straight through, so that shouldn’t be too much of a problem. But if it is found then all attempts to create or show (or hide) a window will be overridden - possibly to the demise of the process if it’s doing anything but the basic behaviour. So in all cases, watch out, and make sure you aren’t running anything important in the background (in particular, I’ve noticed that it doesn’t play nice with Firefox).
* The loader uses a system-wide hook, and you hate system-wide hooks. I trust that anybody who needs this tool has some degree of technical expertise and is aware of the stability concerns inherent in installing somebody else’s barely-tested system-wide hook.
* This was harder to put together than I anticipated, and that’s probably evident from the slightly shabby code. Again, I intend for this only to be used for debugging purposes, so you’ll have to forgive me for the sub-production-quality code.
* Despite my focus on Direct3D, I’m not really a gamer and I don’t actually have any commercial games installed on this machine. So I only got a chance to test this against my own programs. Obviously, there are several ways to skin the metaphorical Direct3D-initialisation cat, so please leave a comment when you find a game that this chokes on.
Also listed in: (Not listed in any other category)
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DXWnd
Rating: 0.0 (0 votes)
Author: Nightwolve                        
Website: N/A
Current version: 1.20
Last updated:
Direct D/L link: Locally archived copy
License type: Freeware
Description: Quote from readme:

"Want to force a game or application into windowed mode that doesn't support it through its own interface? Now you can, to an extent. Results will vary depending on how your DirectX application was written."

DirectX (D3D) applications are usually written to use full screen mode for their display. This makes debugging and target analysis difficult due to specific DirectX considerations. DXWnd attempts to force a D3D app to use windowed mode, making it much easier for reversers to work with.

This app can't always force a full screen D3D app into windowed mode, however it is quick and easy to try. If this tool fails for you it's still perfectly possible to manually force windowed mode in your target. Search the Woodmann forum for further information.
Also listed in: (Not listed in any other category)
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Direct3D Hooking
Rating: 5.0 (1 vote)
Author: Admiral                        
Website: http://www.ring3circus.com/downloads/direct3d-hooking
Current version: 1.1
Last updated: November 27, 2007
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: A sample for hooking a Direct3D 9 program and drawing on its viewport. Translating this to Direct3D 8 should be trivial.

Notes:

* Vista support added with version 1.1
* This is not safe for 64-bit consumption, though that should be obvious.
* While there’s no reason it can’t be made to work with Unicode, I’ve written everything in ASCII, for simplicity.
* By default, the DLL will increase its own reference count to prevent it being unloaded prior to termination of the host process. This is because there is a small risk of the DLL being unloaded by one thread, while a hooked function in another returns to the now dead memory. I figured that it’s best to waste a little bit of everybody’s memory than to crash unnecessarily.
* The d3d9.dll function addresses (and prologues) are hard-coded, or at least their offsets are. While this may look very unprofessional and rather risky, I can assure you that it’s quite safe. The alternative would be to hack up some virtual-function tables and that’s a whole other story for a whole other post.
* You may notice that the compiled DLL is dependent upon D3DX. This isn’t necessary for the hook itself, but I used ID3DXFont in my example for demonstrative purposes. The only reason I mention this is that there is no way to guarantee the existence of any D3DX DLLs on a DirectX 9 machine, and distributing them yourself is in violation of the DirectX Runtime EULA. So if you happen to need to distribute this code, you’ll either need to carry the huge runtime installer around, or avoid using D3DX altogether.
* The soft-hooks used here will cause problems with PunkBuster if applied to any of its monitored functions. If you need to do this then you’ll have to be a bit cleverer.
* The source assumes that the graphics device will never become invalid. If you suspect that this isn’t the case (which will be true for any full-screen game at a minimum) then you’ll need to add the appropriate sanity checks (see IDirect3DDevice9::TestCooperativeLevel) before attempting to render anything, lest you want to crash and burn.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)


RSS feed Feed containing all updates and additions for this category.

RSS feed Feed containing all updates and additions for this category, including sub-categories.





Views