I'm trying to create a windows application that can manage multiple mouses, with the feature of understanding which device is generating the input
(something like Microsoft's Multimouse, but without a UI).
The problem is that I don't want to use a UI because this will be a plug-in for Unity3D so I have many limitations imposed from this.
I also thought about a parallel service that can talk with Unity, but in that case I would like to not block all the system to take mouses inputs.
In this special case I have to manage 12 of these devices: AimTrak, that are recognized as a mouse input device.
So does anyone have some idea about that how can do this without hacking them and rewriting their driver?
Ok after 3 days of googleing things i have found a way to do this!!!!
We have need to make a windows's system hook on user32.dll in order to catch all mouse inputs.
Related
I am looking into writing something similar to that of Steady Mouse. My grandpa has tremors pretty badly and it prevents him from doing too much on the computer. Unfortunately it doesn't appear to work on Windows 10 and it seems the developer has discontinued working on the project. Seeing as I am looking for project to add to my portfolio, I figured I would see if I could maybe hack something together, only problem being I've never done anything this low level before so I am unsure of where to begin.
It seems the Kalman Filter is my best bet as an filtering algorithm, but I am unsure of how to provide the input. I've never used the Windows API, is this something it provides? Or, do I instead hook directly into the mouse device itself, and how is this possible? Am I even on the right track here?
I am assuming this would best be a background running process booted on startup, that filters the device input before the OS draws the cursor on the screen. Obviously, this would need to access all events and mouse movements regardless of which program is being used.
Investigate Windows Message Hook functions, it is possible to intercept/change Windows messages such as WM_MOUSEMOVE.
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.
There are many questions relating to simulating mouse/keyboard input in WPF (and Windows, for that matter). I have something a little different than the usual question, I think, and I'd like your input. Most posts I've seen have a specific higher level action in mind: I want to click this, I want to move the mouse here, etc. To emulate these, one can simply use routed events. However, I'm hoping to operate a mouse from a remote app and would like to input mouse events at a low-level: current mouse position is x,y and button state is such and such. My target framework is WPF, but if something like a generic virtual mouse driver is the way to go, I'm cool with that too. I do not have security concerns: the apps receiving the messages will be coded by me at a higher level, so I don't need crazy hacks. I'm willing to use managed or unmanaged code and take the rabbit hole as deep as it needs to go to make this work, but I don't want to reinvent the wheel. I can host my apps in an HwndHost or some such too, in case I need access to windows messages.
Thoughts?
WPF has some built-in automation capabilities. It's a bit complicated, and I've never actually tried it myself, but I've been reading about it recently - it might be worth checking out:
http://msdn.microsoft.com/en-us/library/ms747327.aspx
Or search google for "WPF automation"
I would like to know if it is possible to mute only a specific window. For example I have got Firefox open and two more windows. I want to mute everything related to Firefox but not the whole sound of my computer.
Is this possible? If so, how can it be done?
look, basically, there isn't any relation between the window handle and the sound which something in its code is playing.. the audio card can't tell who wants it to play.
theoretically, there is an option to do what you want on web browsers, but it's not easy, and not 100%. it goes like this:
most of the audio that is playing from browsers are from known objects like wmp/quick time/vlc/flash/etc..
when the user will choose to mute all audio from firefox, your application will search those known objects in the firefox tabs, and mute/unmute them using their api.
in order to do that, you will need to write an extension to firefox, so you could have an access to the tabs memory from your application.
btw, what os?
and check this out: http://www.indev.no/?p=projects#flashmute (flashmute) i believe it does what is said - only for flash.
On Vista/Windows 7:
I expect there to be some API which can change the volume on a per process basis which the audiomanager uses. Should be relatively straight forward to use.
On XP
I don't think there is any built in functionality for what you want to do. I recommend just not offering that feature on XP. But if you really want to, there are some hackish solutions:
Usermode API hooking. Intercept the calls to audioapis with your own functions. These change the volume or manipulate the audiosignal so you get what you want. You need to do this differently for any of the several available audio-apis. I guess DirectSound and DirectShow are particularly annoying. And this requires injection of a dll into any process you want to manipulate. And this dll better not require the .net runtime. Search for IAT(import address table) or EAT(export address table) hooking.
Kernel mode audio hooking. Write a driver which intercepts the audio in the kernel and changes it on a per process basis. No clue how to do that.
But as you can see both solutions aren't good.
We are developing a platform with Windows CE 5 (soon to be upgraded to 6) in .Net CF 2 C#.
What we have recently discovered is that if we are touching the touchscreen while using our peripheral, the peripheral data trafic times out and our application crashes. So it seems like the touchscreen is blocking it. As a quick fix we would like to disable the touchscreen while using the peripheral, and the reenabling it.
So our question is, how do we do it?
Do we need some extra packages in the OS build or can we do it manually. We have had a look at touchpaneldisable() and touchpanelenable(...). But the enable method requires a handle to the callback function. So I have no idea on how to fix this.
From an application perspective tehre really isn't a fix. Touchpanel ddrivers a re alittle different than otehrs becasue they get loaded by (and into) GWES, rather than device.exe. They are not designed to be disabled and enabled, though some OEMs do provide the capability (typically by just masking the touch panel interrupt).
It sounds like the touchpanel sampling rate is really high and the device is saturating the processor when it startes sampling. It's something that the OEM probably needs to fix. Some OEMs do provide registry entries to adjust the driver behavior, so check with them to see if this might be available to you. In that case you may be able to fix the issue yourself.
If you have the BSP you might want to go through this blog post as it suggest possible bottle necks for the touch driver.