I need to mute and unmute sounds from other processes in Windows XP. I am looking for the best strategy. It is possible to write a Kernel Mode mixer that will filter the inputs to the output device? My other approach would be set Hooks for the various API's to intercept their Win32 calls. I would strongly prefer the less invasive approach.
Some considerations:
Covering applications that use the WinMM and DirectSound System Componenets would probably be sufficient (i.e. I don't need to worry about other audio interfaces).
This will eventually need to be used from a C# app. I am reasonably skilled with interop, but don't have internal knowledge of Win32 to make this happen.
It would be possible to list all the applications that would need to be muted and approach each application separately, although the list is expected to grow.
P.S. In case anyone is concerned, these operations will be performed with the users consent (no shady business).
The problem with kernel mode drivers is that they are generally not process-aware. This is part of a clean layered architecture. Dealing with processes is the responsibility of the OS itself. The audio driver should handle audio. Now, the mixer should definitely handle multiple audiostreams, and may give them unequal weight, but it should not particularly care where the came from. Also, the built-in mixer is not designed to be replacable, so you'd have to intercept the audiostreams before they're mixed.
For that reason, on XP it makes much more sense to use Microsoft Detours to intercept the calls at API level. You have the calling process info there. Detours basically injects assembly into the user-mode parts of the OS, so I would advice using C++ rather than C# with Detours.
As I understand it, on Vista the audiostack is rewritten such that it is possible to associate audiostreams with applications, but this is a system-wide feature.
Related
I am working on an embedded system that involves collecting data from multiple camera modules over USB. The plan was originally to use a small Linux system, but the Linux drivers for the camera don't support using any of it's features (hardware triggering, shooting raw, certain pixel formats, etc). There is a nice C# SDK provided by the manufacturer and everything just works on Windows. We are now investigating using a small Windows system like the new Intel Compute Stick or a Liva.
I want to write software to collect the data from the cameras as they are hardware triggered by another part of the system, and write the data to a removable disk. It should be remotely controllable via TCP/IP (hard wire). This sounds like something that would fit within the purview of a windows service. Would this be a good way to go?
I'm mostly concerned about running into security/permissions issues. I've been reading things that indicate that services are contained within "non-interactive" window stations, and I'm not sure what that means in terms of being able to access devices etc. The machine running all this is going to be completely headless, so it just has to work all the time. I'm continuing to do my own research into the right thing to do here, but if somebody with relevant experience could give me a suggestion "yes" or "no" along with a good reason why, that would help me out greatly.
A few things to consider:
is there any limitations or required privileges to access the hardware/drivers, and which windows identity would allow your service that (elevated) access?
is any interaction with a user-interface required?
To me, without additional details, it looks like a windows service is going to serve the purpose if there is no user-interface required.
I would also recommend using Top Shelf for developing windows services in .Net, as it simplifies and abstracts all the surrounding complexity and lets you focus on what your application needs to achieve instead.
[Note: I'm not affiliated with Top Shelf, or its developers]
I used to work at a company that did Real Time Vision systems using firewire cameras on windows. The software just ran as an application. Which just ends up being simpler to deal with and debug. Most of it was done in C++. However if you don't have hard real time requirements ( that software needed to do things within 50ms ) then C# should be fine
You could run it as a service, but there is no particular need to.
I'm looking into writing a tool that mounts certain external disks as read-only when they are plugged-in to the machine. On MacOS, this was quite trivial with the Disk Arbitration framework. It sends out notifications from the OS when a new drive is attached to a machine and allows you to veto, accept, or change mounting options (such as forcing the mount as read-only, etc.) Is there any equivalent to this in Windows?
Thanks in advance.
There's no direct equivalent. For security reasons, Windows doesn't give user-mode code quite that much control (e.g., consider a virus deciding to stop you from mounting any disk it's suspicious might contain an anti-virus program).
The WM_DEVICECHANGE message notifies user-mode applications of things as they happen, but it's pretty limited -- in particular, while you can veto removal of a device, you're not allowed much (any?) control over addition of a device.
You can also use RegisterDeviceNotification for more complete information, but I don't believe it gives you the control you're looking for either.
At least as far as I know, .NET doesn't support RegisterDeviceNotification directly, so if you want to use it from C#, you'd probably have to do it via P/Invoke.
For more control over devices being mounted and unmounted, you'd have to write some kernel-mode code, but at least from the sound of things that may be a bit beyond what you're interested in considering, at least for the moment.
I would like to get notification of when any/all programs are being actively used.
To do this via windows hooks I'd use an unmanaged C++ dll that talks to C#. There is an article that explains this process here.
I was wondering though if there is any alternative to using system hooks though.
I haven't looked at all of the details of this library, but it might help you out.
Managed Windows API
C++ is not required to set a global windows hook, you just need to call the necessary winapis.
A global hook would be more efficient and more reliable than polling, assuming you are only interested in applications that have a window associated with the process. For example, a CMD prompt may not generate GWH events.
Ultimately the most reliable and efficient mechanism would be a system-wide injection, a good start would be the Detours library from Microsoft Research. Jefffrey Richter's classic "Advanced Windows Programming" book covered this in detail, offering 3 mechanisms for injection (including how to set up a system wide hook). Again, this doesn't require C++, and wouldn't necessarily tell you when an application was in use. Ultimately global window hooking is going to make the most sense.
List running processes:
http://codefreezer.com/codedetail.php?article=13
Determine which process is topmost:
http://www.pinvoke.net/default.aspx/user32/getwindowthreadprocessid.html
I know how antivirus detects viruses. I read few aticles:
How do antivirus programs detect viruses?
http://www.antivirusworld.com/articles/antivirus.php
http://www.agusblog.com/wordpress/what-is-a-virus-signature-are-they-still-used-3.htm
http://hooked-on-mnemonics.blogspot.com/2011/01/intro-to-creating-anti-virus-signatures.html
During this one month vacation I'm having. I want to learn & code a simple virus detection program:
So, there are 2-3 ways (from above articles):
Virus Dictionary : Searching for virus signatures
Detecting malicious behavior
I want to take the 2nd approach. I want to start off with simple things.
As a side note, recently I encountered a software named "ThreatFire" for this purpose. It does a pretty good job.
1st thing I don't understand is how can this program inter vent an execution of another between and prompt user about its action. Isnt it something like violation?
How does it scan's memory of other programs? A program is confined to only its virtual space right?
Is C# .NET correct for doing this kind of stuff?
Please post your ideas on how to go about it? Also mention some simple things that I could do.
This happens because the software in question likely has a special driver installed to allow it low level kernel access which allows it to intercept and deny various potentially malicious behavior.
By having the rights that many drivers do, this grants it the ability to scan another processes memory space.
No. C# needs a good chunk of the operating system already loaded. Drivers need to load first.
Learn about driver and kernel level programming. . . I've not done so, so I can't be of more help here.
I think system calls are the way to go, and a lot more doable than actually trying to scan multiple processes' memory spaces. While I'm not a low-level Windows guy, it seems like this can be accomplished using Windows API hooks- tie-ins to the low-level API that can modify system-wide response to a system call. These hooks can be installed as something like a kernel module, and intercept and potentially modify system calls. I found an article on CodeProject that offers more information.
In a machine learning course I took, a group decided to try something similar to what you're describing for a semester project. They used a list of recent system calls made by a program to determine whether or not the executing program was malicious, and the results were promising (think 95% recognition on new samples). In their project, they trained using SVMs on windowed call lists, and used that to determine a good window size. After that, you can collect system call lists from different malicious programs, and either train on the entire list, or find what you consider "malicious activity" and flag it. The cool thing about this approach (aside from the fact that it's based on ML) is that the window size is small, and that many trained eager classifiers (SVM, neural nets) execute quickly.
Anyway, it seems like it could be done without the ML if it's not your style. Let me know if you'd like more info about the group- I might be able to dig it up. Good luck!
Windows provides APIs to do that (generally the involve running at least some of your code in kernel). If you have sufficient privileges, you can also inject a .dll into other process. See http://en.wikipedia.org/wiki/DLL_injection.
When you have the powers described above, you can do that. You are either in kernel space and have access to everything, or inside the target process.
At least for the low-level in-kernel stuff you'd need something more low-level than C#, like C or C++. I'm not sure, but you might be able to do some of the rest things in a C# app.
The DLL injection sounds like the simplest starting point. You're still in user space, and don't have to learn how to live in the kernel world (it's completely different world, really).
Some loose ideas on topic in general:
you can interpose system calls issued by the traced process. It is generally assumed that a process cannot do anything "dangerous" without issuing a system call.
you can intercept its network traffic and see where it connects to, what does it send, what does it receive, which files does it touch, which system calls fail
you can scan its memory and simulate its execution in a sandbox (really hard)
with the system call interposition, you can simulate some responses to the system calls, but really just sandbox the process
you can scan the process memory and extract some general characteristics from it (connects to the network, modifies registry, hooks into Windows, enumerates processes, and so on) and see if it looks malicious
just put the entire thing in a sandbox and see what happens (a nice sandbox has been made for Google Chrome, and it's open source!)
Can standard pointers in .Net do this? Or does one need to resort to P/invoke?
Note that I'm not talking about object references; I'm talking about actual C# pointers in unsafe code.
C#, as a managed and protected run time engine, does not allow low level hardware access and the memory locations associated with actual hardware are not available.
You'll need to use a port driver or write your own in C++ or C with the proper Windows API to access the memory mapped I/O regions of interest. This will run in a lower ring than the C# programs are capable of.
This is why you don't see drivers written in C#, although I understand many are writing access routines with C++, but the main driver logic in C#. It's tricky, though, as crashes and restarting can become tricky, not to mention synchronization and timing issues (which are somewhat more concrete in C++ at a lower ring, even though windows is far from a real-time system).
-Adam
To expand on Adam's answer, you can't even perform memory-mapped I/O from a Win32 application without the cooperation of a kernel driver. All addresses a Win32 app gets are virtual addresses that have nothing to do with physical addresses.
You either need to write a kernel driver to do what you're talking about or have a driver installed that has an API that'll let you make requests for I/O against particular physical addresses (and such a driver would be a pretty big security hole waiting to happen, I'd imagine). I seem to recall that way back when some outfit had such a driver as part of a development kit to help port legacy DOS/Win16 or whatever device code to Win32. I don't remember its name or know if it's still around.