Jump to content

  • Log In with Google      Sign In   
  • Create Account


Help me understand how to hook DX application, to copy screen buffer


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Shuun   Members   -  Reputation: 123

Like
-1Likes
Like

Posted 02 July 2012 - 01:17 PM

I'm developing application in C#, and i'm currently strugling in finding the general correct steps required to sucessfully hook DX function in order to send screen buffer to my main application for some processing.

Here is a list of what i think i should be doing so far:

1. Attach a custom C++ dll into target application, from my main application (written in C#)
2. DLL hooks some (Device Present and Reset) functions in d3d9.dll that is loaded in target application.
3. After even occurs, i need to send a callback event from the custom dll to my main application, containing the screen data

Can someone please correct me where i could have gone wrong and help me with point 3? I'm not expirerenced in dll callbacks, let alone not a C++ interop guru and im having a trouble understanding how i could possibly have a callback to my main application from a C++ dll loaded in another application.

Sponsor:

#2 DevLiquidKnight   Members   -  Reputation: 834

Like
-1Likes
Like

Posted 02 July 2012 - 04:49 PM

Why don't you simply use detours.

#3 Shuun   Members   -  Reputation: 123

Like
-1Likes
Like

Posted 03 July 2012 - 11:33 PM

Why don't you simply use detours.


Why would i use complete library only to install a hook to 2 functions? Its also not free for commercial and limited in express edition, lets not be ridicilous here.

#4 DevLiquidKnight   Members   -  Reputation: 834

Like
-1Likes
Like

Posted 03 July 2012 - 11:53 PM

Why would i use complete library only to install a hook to 2 functions? Its also not free for commercial and limited in express edition, lets not be ridicilous here.

Because its a lot simpler and safer then doing it manually. If your doing this for a commercial reason, I see no reason why you wouldn't benefit from buying it, and I am pretty sure the express version is all your going to need for what you specified. I also would question why your trying to do this? Typically this is the type of thing game hacks do, which I am willing to guess is exactly what your trying to do.

But a quick google search produced the following: http://spazzarama.co...ct3d-api-hooks/

Edited by DevLiquidKnight, 03 July 2012 - 11:57 PM.


#5 Shuun   Members   -  Reputation: 123

Like
-1Likes
Like

Posted 04 July 2012 - 01:31 AM

I also would question why your trying to do this? Typically this is the type of thing game hacks do, which I am willing to guess is exactly what your trying to do.

But a quick google search produced the following: http://spazzarama.co...ct3d-api-hooks/


Copying screen buffer is not a hack, it does not change or automate any of the behaviour of the software, if doing that would be considered hack, then using things like fraps or any other screen recording software would be bannable offense.

I know about that spazzarma api hook, but its overly bloated with extra threads, and probably even changes running application by running CLR runtime host on it, and i dont want that. Also requires your assembly to be installed in GAC.

#6 Bacterius   Crossbones+   -  Reputation: 8523

Like
1Likes
Like

Posted 04 July 2012 - 03:25 AM

You can't callback from a DLL located in separate process, they belong in different memory spaces. Your callback will be located in your own process's memory space, whereas the DLL hooked into the game will be in the game's process's memory space. They can't communicate via native function pointers (callbacks).

You will need to use OS-provided functions to achieve inter-process communication at this point. An interesting solution is to use Windows messages to send "I have a frame ready" events (remember to use RegisterWindowMessage to get a system-wide message ID), and use a suitably sized shared memory section to dump the frame buffer in. Then in your main application, you monitor your message queue, and when you receive a message like that, you read the shared memory to get the screen data!

You will need to add synchronization however, or you might end up skipping frames. Obviously you can't send back messages to the game without hooking into its message loop, so instead you want to write some kind of header to shared memory, something along the lines of "ok I'm ready, dump the next frame" with the DLL hook waiting until it reads this. Or you might be happy with skipping frames (depending on what kind of post-processing you are doing, you may not be able to keep up with the game anyway).

Or just ditch messages altogether and use pipes+shared memory to communicate, etc... look up IPC (inter-process communication) and find something that can be done in the hook without too much hassle and overhead.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS