I'm going to be very specific.
This is what i want to do in windows:
Write code that makes the keyboard to send me characters, i am interested in the time it takes the keyboard to send a character signal.
Find a way of ensuring that this code gets the priority it is undesirable to have it queued or interrupted by the OS
Find a way of reading keyboard status signals
i have been reading a lot, all i am getting is how to simulate a keyboard..i just need to be pointed in the right direction
The most common option is using Windows hook - or WH_Keyboard or WH_JOURNALRECORD. The difference is that WH_JOURNALRECORD does not require a separate DLL.
Or you can write your own keyboard driver. It may be implemented in 2 ways: your own full keyboard driver instead of the standard driver or an additional filter driver .
And finally you can write a rootkit.
It can be implemented in user mode by intercepting csrss.exe process.
As I am not sure what your purpose is, I am not going into more details.
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.
I have a software installed on my system which basically peeks my activity during working hours. It send a report saying how much time i was away from my system etc.
Since i m .net c# developer hence trying to break this system through my programming skills.
I have basically written up a windows form application which opens up an notepad for me and start typing some random characters into it. simultaneously it also performs some random clicks and moves the mouse cursor to give a feel that some one is on system and working even when i am not :)
I also use "SetThreadExecutionState" Pinvoke calls to keep system awake.I have also observed the User idle time and last interactivity time through "GetLastInputInfo" PInvoke system call while my mouse/keyboard are in automation process and it is also fine.
But this is not working for me. It works perfectly till 5 mins and then somehow it detects that user is not present on system.
any suggestions for the same.
Get a decompiler, crack-open the spying application and see how it is working inside. Only knowing the internal workings, you can create a "workable" any-spying program. But I would not bother with emulation of the activity, but rather spoof the way it reports to the server.
However, depending on where you live, it might be illegal to do these things and I would not recommend cheating your employer. And if spying gets on your nerves I'd also suggest to brush up your CV and start searching for a new job.
Very simple, I want to simply run XBMC when I push the switch on my switcher to switch from my PC display to the TV above it. I'm not too fussy on the language but was more curious if there was an event I could subscribe to do this (in the Win32 API, maybe). If not, how might I go about polling for this?
The SC_MONITORPOWER might help you, you could have a look here http://thydzik.com/hdmion-a-solution-to-loss-of-dvi-video-epid-signal-on-hd-tvs/ to start.
For me, whenever I changed the display input on HDMI, my DVI output would go dead, presumably because it detected the monitor having gone (since now it was using a different HDMI input).
If your setup is similar.. DVI->HDMI with a TV that runs similarly, this might work. I. e. detecting (maybe polling?) whether a monitor is attached to that output at all. But it depends a lot on how recent the hardware is you are running.. it probably will not work in a generic case.
Note that the sample I posted is not detecting whether a monitor is there, it simply forces a re-detection. Detection might work similar, though.
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.
I have a window mobile application which needs to detect power off and perform some operation before the device shuts down.
I have been able to detect that the device is shutting down using pinvoke to the RequestPowerNotifications win32 api.
However I can not figure out how to block the power off for long enough to run my code.
As an application, you can't prevent it unless the OEM has somehow provided a custom API for doing so (and I've never seen it on any WInMo device, only on a few custom CE devices). Whent he power manager is told to suspend, it sends out the notification and begins shutdown immediately. The only subsystems that get an opportunity to delay things are drivers, and they can't call Win32 APIs during that time (it's meant as an opportunity to power off peripherals, save registers, etc).
I also can't say I've ever seen a good reason for an application to ever do this. If a user pushes the power button, they want to power down - not be inhibited by an app. If the OS needs to power down (like due to low power) then preventing it would be a bad thing anyway.
As ctacke pointed out: this is dirty. But, you could try SetSystemPowerState( POWER_STATE_ON ); whenever your power notification thread indicates the device is trying to suspend.
http://msdn.microsoft.com/en-us/library/ms920754.aspx
-PaulH