How to simulate keyboard input in ALL applications? - c#

I'm writing an app (in C#) which as a part of it must simulate and send some key strokes to another application. I'm using http://inputsimulator.codeplex.com/ project for simulating keys, and it works in many applications, but in some it doesn't - i.e. Mortal Combat 4.
I've googled about it, and found many answers varying from 'it's impossible' to 'you must use XXX library' etc. Those answered scared me a lot, and even nearly convinced I'm not able to do it at that time, BUT...
M$ Virtual Keyboard works. It works in ALL applications. So it IS possible... Does anyone of you, clever guys, know how can I achieve this?

Ok, I think I finally got it to work. I used API Monitor recommended by Neal P and it showed just minimal differences between OSK calls and mine. A bit later I've tried to make my calling thread sleep some time between sending messages with press and release key and that was it.

Although you were able to achieve your purpose, the way you achieved it does not fundamentally answer your question: How to simulate keyboard input in ALL applications?
There's a bunch of situations where the common user mode Microsoft API already mentioned does not work, like game applications that use the DirectInput API or protected games.
I have built a library that can help in this situations, it provides a simple C API that internally communicates with device filter drivers. It is able to send input for DirectInput based games and also is able to bypass some game protections. I have checked and it is still able to bypass some known game protections by using the x64 version of the library. Game protections commonly hook only the x86 system's api. Well, at last now, 18 February 2012, this is what I'm seeing happening.

Take a look at SendKeys on MSDN

Related

Which Browser for a Touch-Enabled WPF Application?

I looked at this thread here searching for a Web Browser to embed into a touch-enabled WPF application (on Windows 8 or 10).
I need to support manipulations (meaning be able to zoom, pane, rotate with touch events).
If possible, I would like also to support one of the game frameworks being either Adobe Flash, Unity or Web GL. Or a really working HTML 5 support with touch events.
Investigations performed so far:
- I have tried Awesomium, but I have too many issues with it. I created two questions on their forums two months ago and still don't have any reply.
Also, I tried CEF, but it crashes when the main application is stopped. Also, it does NOT support touch events.
Obviously, I also tried the default WebBrowser, but this one is an ActiveX control so it does not support manipulations.
So, I am about to test dotnetbrowser and EO.WebBrowser. Both require licenses which is less attractive to me but anyway if this the only way to go.
However, none of these browser implementations describe if they support a touch
interface.
Do you have any input on this issue?
Thanks a lot for your help
Best regards
Christophe
Finally I made it work by using a wrapper above CEF called Xilium.CEFGlue.
I could dive into the source code and add the touch support myself.
It works pretty well.
Thanks a lot for your help.
Christophe

Writing a program to stop another program from taking screenshots [duplicate]

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.

How can I know if the user has made a screenshot?

I'm writing a small c# program, I don't want the final user to take screenshots while using my program, is it possible? Or even if he takes one, how can I know it?
Thanks in advance and sorry if this is a poor-content question due to my lack of experience in c# coding.
You can create a system-wide keyboard hook using the low-level keyboard filter and cancel any printscreen keyboard combination. But if someone has also installed a helper application (like Gadwin or something) it'll become a lot more difficult because you won't know beforehand what keyboard shortcut you should catch (most tools allow to specify your own hooks).
Here's an article on using hooks in C#
and here's a ready-made keyboard hook library for .net that uses global mouse and keyboard hooks (use Google to find more freeware and commercial libraries and tools).
On a side note: it's generally not preferred to change the system behavior. Screenshots are system behavior and serve a distinguished purpose for trouble shooting. If you prevent this, users will not be able to show you a screenshot of something wrong. But if you must do it, you can do it.
EDIT: on a deeper level, you can install an API hook. All screenshot applications use API calls to get the content of a (part of) the screen. But API hooks are hard to get right. A more trivial way is probably by writing a user-level driver. While you can prevent all this, it is really worth all the trouble?
You might want a keyboard hook. But it'll tell you if the user pressed the "print screen" key, not if someone programmatically take a screenshot using some GDI function.
I doubt it's possible to prevent all the ways of taking a screenshot.
General answer: No. It's not possible to detect this - especially from C#. There are dozens of ways to take screenshot and even applications written in C++/WinAPI can only detect some of them, but not all.
Also consider - what if user is running your app in virtual machine? He'll be able to take screenshots at host machine and you can do absolutely nothing to detect (not even prevent) this.

Getting input into a process

While talking with a friend over yahoo messenger, I told him would be really cool to make a bot to answer with generic messages when someone starts a conversation. Upon thinking about what I told him, I realized it would be quite interesting to do something like that. The problem is that I don't know much about win32.
So my question is this: how do you 'link' a process to both another one and the windows environment? The goal would be to have an application running in the background which makes some sort of a query to see what windows are opened and when a new yahoo messenger conversation window appears it should send a list of keystroke events to that window.
I could use either C# or VC++ for the programming part and I can use any help: either specific answers or tips that could help me - e.g.: what to google for. So far my google research only came up with some apps/dlls/code that do that for you and some scripting stuff and I'm not exactly searching for that. I want to do all the work myself so I can learn from it.
It seems like you basically want to control other applications.
There are roughly 2 ways to do this on windows
1 - Use the low level windows API to blindly fire keyboard and mouse events at your target application.
The basic way this works is using the Win32 SendInput method, but there's a ton of other work you have to do to find window handles, etc, etc
2 - Use a higher level UI automation API to interact with the application in a more structured manner.
The best (well, newest anyway) way to do this is using the Microsoft UI Automation API which shipped in windows vista and 7 (it's available on XP as well). Here's the MSDN starter page for it.
We use the microsoft UI automation API at my job for automated UI testing of our apps, and it's not too bad. Beware though, that no matter how you chose to solve this problem, it is fraught with peril, and whether or not it works at all depends on the target application.
Good luck
Not quite the same domain as what you're looking for, BUT this series of blog posts will tell you what you need to know (and some other cool stuff).
http://www.codingthewheel.com/archives/how-i-built-a-working-poker-bot
If you really want to learn everything from scratch, then you should use C++ and native WIN32 API functions.
If you want to play a bit with C#, then you should look the pinvoke.net site and Managed Windows API project.
What you'll surely need is the Spy++ tool.
http://pinvoke.net/ seems to be the website you are looking for. The site explains how to use Windows API functions in higher level languages. Search on pinvoke for any of the functions I've listed below and it gives you the code necessary to be able to use these functions in your application.
You'll likely want to use the FindWindow function to find the window in which you're interested.
You'll need the process ID, so use GetWindowThreadProcessId to grab it.
Next, you'll need to use OpenProcess allow for reading of the process's memory.
Afterwards, you'll want to use ReadProcessMemory to read into the process's memory to see what happening with it.
Lastly, you'll want to use the PostMessage function to send key presses to the window handle.
Welcome to the wonderful world of Windows API programming.
Check out Autohotkey. This is the fastest way to do what you want.

What is a good project to learn Windows Forms programming in C#?

I want to learn c# so I can do some desktop developing. I've developed command-line C# applications and wanted to expand to Desktop applications.
I was thinking of create a screenshot tool like Jing or maybe a plugin for outlook to sync contact information with a service like Google.
What are your thoughts? My past experience is with web applications built in PHP.
I would try to start with something fairly contained, which only touched a few new technologies. For instance, if you want to learn Windows Forms, write something which uses that but doesn't need to talk to Outlook, Google, or the Win32 API. Once you've got the hang of Windows Forms, try one extra technology - try displaying your Google Contacts and do offline editing, for example. Then add another technology... etc.
In my experience it's hard enough to learn one new technology at a time - but that's far quicker than trying to learn two or more in one go. You inevitably get to the stage where you don't know where the problems are, and you have no confidence in any of your code because it's all new. This is particularly important if you're still fairly new to the language as well - although I'm glad to hear you started with some console apps :)
Sorry if that sounds like I'm being a wet blanket, and I realise it sounds like you'll take far longer to get to something useful that way, but I think you're more likely to be successful in the long run.
Find something that most importantly interests and excites you. If you pick something too boring that you don't care about you'll only give up before you get anywhere, and won't benefit at all. Don't do a rubbish project for the sake of learning a language. Do a good project, and do it in a new language as a side effect.
Make a notepad clone. While being fairly simple it will give you a primer in some basic Windows Forms mechanisms such as using menus and reacting on their events, getting input from controls for storage on disk, reading from disk and updating controls, using Docking and Anchoring and so on.
Twitter clients are the new hello world.
I read that somewhere the other day. I can't personally comment on its fitness for your goal.
Do something that you did before, but in another language. Then you won't have to think about most of the architecture of the particular task again, but you'll be able to compare the languages, the frameworks and their approaches.
I bet you'll learn a lot about your previous language as well doing this excercise.
A good project would be a simple windows form. You simply have a chance to put everything together. Or at least see a bigger picture.
You can make it as complicated as you want, without sticking to one area.
Suggesting a specific project is pointless. Think of something that interests you, or an application you want/need, then start making it - searching Stackoverflow/Google/MSDN/etc whenever you can't guess how to do a specific task.
For example, I had to make kiosk application that allowed customers to signup to a companies mailing-list. I tried using the Ruby framework Shoes, but it didn't work correctly on the laptop the application was to run on. Visual C# seemed like a better fit, and would almost certainly run correctly..
So I installed Visual C# Express, added a few labels and a button. I double clicked the button, and realised I didn't know the code to create a new WinForm window.. So I searched Google for "visual C# open new dialogue" or something, and I found out I had to add a new form, then call NewForm newwindow = new NewForm(); newwindow.show(); or similar.
Then, I added the username/email fields, then searched for "how to display an alert box" and checked I could display the form values.
That all worked, so now I had to decide how to store the emails. I had heard good things about LINQ to SQL, so looked into that, decided I wanted to use SQL Server CE (so I didn't have to install/run SQL Server on the laptop). That resulted in more searching around for how to make LINQ to SQL work with SQL Server CE..
Finally, I wanted to have a configuration panel to change the title/button strings etc (accessible via a certain keyboard shortcut).. A Google search revealed how to catch keystrokes, and I asked a Stackoverflow question about representing the settings (using a PanelView or something)
..anyway, the point of that slightly long, rambling and not terribly interesting story is.. You can learn many new technologies at once, as long as you have a specific application in mind (and you're determined to finish it!)
I learned C#, WinForms, SQL Server CE, LINQ to SQL, and simple application publishing stuff in a day - creating a functioning, useful application in the process - simply with a combination of prodding around, Google searches and Stackoverflow..

Categories