Suppose I have an OpenGL game running full screen (Left 4 Dead 2). I'd like to programmatically get a screen grab of it and then write it to a video file.
I've tried GDI, D3D, and OpenGL methods (eg glReadPixels) and either receive a blank screen or flickering in the capture stream.
Any ideas?
For what it's worth, a canonical example of something similar to what I'm trying to achieve is Fraps.
There are a few approaches to this problem. Most of them are icky, and it totally depends on what kind of graphics API you want to target, and which functions the target application uses.
Most DirectX, GDI+ and OpenGL applications are double or tripple-buffered, so they all call:
void SwapBuffers(HDC hdc)
at some point. They also generate WM_PAINT messages in their message queue whenever the window should be drawn. This gives you two options.
You can install a global hook or thread-local hook into the target process and capture WM_PAINT messages. This allows you to copy the contents from the device context just before the painting happens. The process can be found by enumerating all the processes on the system and look for a known window name, or a known module handle.
You can inject code into the target process's local copy of SwapBuffers. On Linux this would be easy to do via the LD_PRELOAD environmental variable, or by calling ld-linux.so.2 explicitly, but there is no equivalient on Windows. Luckily there is a framework from Microsoft Research which can do this for you called Detours. You can find this here: link.
The demoscene group Farbrausch made a demo-capturing tool named kkapture which makes use of the Detours library. Their tool targets applications that require no user input however, so they basically run the demos at a fixed framerate by hooking into all the possible time functions, like timeGetTime(), GetTickCount() and QueryPerformanceCounter(). It's totally rad. A presentation written by ryg (I think?) regarding kkapture's internals can be found here. I think that's of interest to you.
For more information about Windows hooks, see here and here.
EDIT:
This idea intrigued me, so I used Detours to hook into OpenGL applications and mess with the graphics. Here is Quake 2 with green fog added:
Some more information about how Detours works, since I've used it first hand now:
Detours works on two levels. The actual hooking only works in the same process space as the target process. So Detours has a function for injecting a DLL into a process and force its DLLMain to run too, as well as functions that are supposed to be used in that DLL. When DLLMain is run, the DLL should call DetourAttach() to specify the functions to hook, as well as the "detour" function, which is the code you want to override with.
So it basically works like this:
You have a launcher application who's only task is to call DetourCreateProcessWithDll(). It works the same way as CreateProcessW, only with a few extra parameters. This injects a DLL into a process and calls its DllMain().
You implement a DLL that calls the Detour functions and sets up trampoline functions. That means calling DetourTransactionBegin(), DetourUpdateThread(), DetourAttach() followed by DetourTransactionEnd().
Use the launcher to inject the DLL you implemented into a process.
There are some caveats though. When DllMain is run, libraries that are imported later with LoadLibrary() aren't visible yet. So you can't necessarily set up everything during the DLL attachment event. A workaround is to keep track of all the functions that are overridden so far, and try to initialize the others inside these functions that you can already call. This way you will discover new functions as soon as LoadLibrary have mapped them into the memory space of the process. I'm not quite sure how well this would work for wglGetProcAddress though. (Perhaps someone else here has ideas regarding this?)
Some LoadLibrary() calls seem to fail. I tested with Quake 2, and DirectSound and the waveOut API failed to initalize for some reason. I'm still investigating this.
I found a sourceforge'd project called taksi:
http://taksi.sourceforge.net/
Taksi does not provide audio capture, though.
I've written screen grabbers in the past (DirectX7-9 era). I found good old DirectDraw worked remarkably well and would reliably grab bits of hardware-accelerated/video screen content which other methods (D3D, GDI, OpenGL) seemed to leave blank or scrambled. It was very fast too.
Related
i need to block any screen capture software on the computer from taking screen shots. Since all of them are work on standard API-functions, i think i could monitor and block them.
I need to use C#.
All i have found is how to monitor and block them in a certain program (screen capture program). They are looking for a function in the program, then they change it address on mine function address.
But how can i do it, if i haven't any certain programs? I need to block anyone which tries to take a screenshot.
If your final goal is possible or not I don't know, but for the hooking the API portion I can help you out.
I have used the library EasyHook many times in the past, this will let you hook and intercept system function calls from C# code fairly easily. Just read through the PDF tutorial for setup instructions.
For actually finding the API's I recommend Rohitab's API Monitor, it's still in Alpha stages but it works really well and is free. You just hook it on to a processes and it tells you every external DLL call it makes (with the parameters it passed if you have the xml definition file for the DLL, the program comes with almost all of the windows API dll's pre-defined).
The combination of EasyHook and API Monitor is a great 1-2 punch for mucking with other program's calls.
It is not possible to prevent screenshots from being taken. The battle is already lost because of the DWM (Desktop Window Manager). It's lower level than Win32 and device contexts.
If you want to protect the text in your program, there are a lot easier ways to extract it than doing screenshots and OCR. TextOut and/or Direct2D hooking and accessibility APIs.
If there's a lot of IP in your program. Then don't make it all available onscreen. Make sure it's tedious to crawl the GUI for text, and hard to automate it. And don't load whole texts in memory of the program.
Possible solutions:
1. To prevent copying of text. Draw the text as an image.
2. To prevent accessibility technologies, like screen readers - override WndProc in your control, handle and ignore the window message WM_GETOBJECT.
3. To make it harder if they try to use OCR. Draw graphics behind the text. Human readable, but much harder for a machine to interpret it.
Neither of these methods are invasive for the user.
** A very invasive suggestion **:
If you are really serious about preventing anyone from "stealing" your content.
Implement mouse and keyboard hooks. Filter out typical copy shortcuts. Prevent the mouse from leaving the boundaries of your application.
Allow your application to only run when the OS runs well-known processes and services.
If any process starts which you don't recognize, black out the application and notify the user about it, and request the user to close it. And ofc make sure someone is not just spoofing a well-known process.
Monitor the clipboard as you suggested yourself.
You can ofc soften some of these suggestions based on the context of your application.
As Scott just posted it likely can be prevented with API hooks to see that paint events only go to desktop bound handles and not others, and refuse to paint otherwise. However, you need to consider the following scenarios and see if they're relevant threat to your approach or not:
Your software may be running in a virtual machine like VMWare. Such software has capapbilities to capture screen that does so at "virtual hardware" level, and your API hooks will not be able to discern it - and this would be the easiest way approach if I wanted to bypass your protections.
As a post suggests here, nothing also prevents someone to take monitor cable and plug it into another computer's capture card, and take screenshot that way. Again, your hooks will be helpless here.
Bottom line, you can make it somewhat harder to do, but bypassing such protection may be pretty trivial thing to do.
My 2c.
Please help me create hook for AP.I function GetSystemMetrics.
I want that when some app(for example calc.exe) call GetSystemMetrics they receive my value(for example 500x500) and other apps get correct screen size.
And if somebody can tell me how can I do this use C# and .net CF 2.0 I'll be very happy.
Thanks and hope for you help.
I don't think it's possible to do in C#/.NET without writing any native code. However, the good news is that there is a wonderful library called madCodeHook which is really easy to use. Take a look at http://madshi.net/
You can't do that, even in native code (at least not without ugly, bad-idea, vtable/kernel memory hacks that may or may not continue to work across versions of the OS). GetSystemMetrics calls down to the OS to get information about the platform. There's no way, short of recompiling the OS and changing those values, that you can "override" thse values and get the OS to report other numbers (unless, of course, the OS was already built in such a way that those numbers came from somewhere your app can modify - like the registry).
EDIT
Based on your comments, your actual problem is that you're trying to create some form of "taskbar" type application and you'd like other apps outside of your control to not overlay your taskbar when they maximize. This is exactly how the exisiting Explorer taskbar works, so my suggestion is to go look in the default shell source code and see how it is accomplished there.
The end result is likely going to be that you will either clone the existing shell code and modify the existing taskbar to meet your needs, or you'll create an entirely new shell application that has the behavior you want, but you almost certainly are going to have to replace the shell, and that can only be done with native code.
So I have this SDK provided by a third party which is used for viewing streaming video from a remote source. The remote source runs a server provided by the third party that captures and stores video, and I can connect to that server and get video via the SDK. I am referencing the SDK via COM, and basic nongraphical operations like connecting to the server, selecting a video feed etc are all working just fine.
The problem is that the main (only) method for actually showing video to the user using this SDK is to pass an hWnd (as an int) into a method that will then asynchronously paint the video onto the client area of that window. "Window" here, to my knowledge, has the meaning of a GUI window, which in .NET terms would be any WinForms control with a window handle. In my case, I'm using PictureBox controls (one per feed the user wishes to see).
The problem is that I apparently cannot just drop a managed PictureBox control's handle into this SDK method, because when I do so I receive an AccessViolationException from the unmanaged thread. I'm working off of an example program written in VB 6 (which works on my computer against a test server) which does the same thing with a VB PictureBox, and that works just fine, but apparently whatever the SDK is trying to do to our nice safe .NET sandbox objects is not flying with the CLR.
Help? I wish I could give more information or a code sample, but I can't provide anything sanitized enough that it would work in the general case and I can't divulge the SDK being used. I think that what I need is simply to tell .NET that my referenced code should be trusted to do what it wants with the window, OR to somehow move the window to an less-managed memory space outside my program's comfy sandbox.
EDIT: OK, a little progress has been made. I am now verifying that the handle for the control has been created using IsHandleCreated, before giving the handle to the method. However, as Hans Passant said, an IntPtr is not an int. So, how do I fit this square peg in the round hole? I have tried both the ToInt32() function and an explicit cast to (int). Neither works, even when compiling my library for 32-bit architecture. Do I go back to the third party and say their SDK is a POS for not letting me pass a pointer?
This should work fine. A Control.Handle for a windows forms control is just a standard HWND from the Windows API. Many DirectX samples use this exact technique.
That being said, make sure this isn't passed into the native code until after the control is created. If you pass the handle during a form's constructor (prior to Load), for example, the Handle will be invalid at that point.
I'm trying to automate a hidden .NET application, with another .NET application (written in c#) using the easiest way possible. It's NOT for testing purposes, it's a way to fulfill the lack of scripting for this application.
I already tried white framework, but there is one major problems with it: the way it's working. It's slow and it's not working on hidden windows and controls (like the winAPI does). Whats more, when "clicking" white moves the mouse, brings it's targeted window to the front and so on.
I was also thinking about using a user32.dll wrapper, because the way it's handling it's target is what I need, but I've red it's not working with .NET applications. It also would be a problem working with it, because my targeted application got 5 button labeled "...", and would be really hard finding 2 of them I need. I also would like to use the controls .NET id (the name the developer gave to it's controls when designing the GUI).
BTW, my targeted application is MeGUI if that helps. We do a lot of video encoding and a tool like this would help us a lot. I need the MeGUI to be hidden, because I'm the only programmer, others using my tool shouldn't see what happens in the background, not to talk about the many windows popping all around.
You can add a reference to the exe from your project and then create an AppDomain to run its main method. From there, it should be possible to queue delegates to its main thread's loop. With a bit of reflection, you could have those delegates invoke the click events and whatnot directly.
I've never attempted this approach, but it should work.
You should try Stephens idea instead of scripting a hidden app. A .NET Windows Forms App (EXE) is still a .NET Assembly and that means you can use that the same way as a DLL, just add a reference and use the public classes.
If you still want to try some scripting, take a look on the "Microsoft UI Automation" API and the "System.Windows.Automation" namespace.
Nice article here: http://msdn.microsoft.com/en-us/magazine/cc163465.aspx
MSDN Doc: http://msdn.microsoft.com/en-us/library/system.windows.automation.aspx
i'm trying to control the VLC Media Player from C#. I tried getting a handle on the window with the FindWindow() command from .Net but as i found out the name of the window changes every time a file is played. The biggest problem i have is sending wm_commands to vlc..This approach worked with Winamp and Windows Media Player but with VLC it appears that it won't work.
I read that VLC can be controlled from a browser but i don't whant that...i've seen in it's settings that it has some hot keys that can be called..but they can be changed and if i call them from my code somehow...and the user changes them..bummer...
i'm a little bit stuck..any help would be fantastic...
Sorin
I have some code that is able to control it using sockets on the RC interface. This worked to a degree but has a lot of quirks. go to full screen seems to do nothing for a few seconds after play is invoked. Overall it sort of works.
The other options are:
Write a DirectDraw filter (very hard) but once this is done VLC can be used instead of or in conjunction with FFMPEG. Existing code that drives media player could use vlc.
Write an interop wrapper for libvlc, recently the VLC team split out libvlccore from libvlc so to the best of my knowledge all the interop is out of date. Once you write a wrapper you could embed vlc in a windows app. (if you need to support x64 you need to compile these libs under x64.
Look through the VLC code and find out if there is a way to send these windows messages.
EDIT This appears to have come out this week.
As Eoin mentioned, libvlc can be used to interact with VLC. As a C# user, you may want to try the .NET bindings offered by the libvlc-sharp project.
Edit: Seems like this project has not been maintained for years. I will leave the link anyway, in case you wish to take a look at it and maybe put some of its source to use.
Have you looked at libvlc
You might be able to wrap that up in a library and interact with VLC through that.
If what you are trying to do is control a previously running executable, check out the Process class to enumerate through all the current processes or do it by name. Check the executable to match vlc.exe. You can then get a handle to the main window and do some P/Invoke to send messages as you are doing with your other executables. This is obviously riddled with potential problems such as if the there are changes to the keyboard shotcuts.
How use libvlc in C++ http://unick-soft.ru/art/files/libvlcProject.zip
I think, use libvlc in C# very similar.
There's also the rc interface and even a telnet one: http://wiki.videolan.org/Console
However, I'd prefer libvlc if possible.