I want to add a new sound device on windows 7+ so that I can redirect the computer sound on the network (using a protocol of my own or PulseAudio for example).
Basically, I think I want to write a kernel driver that expose a new sound output device to the OS. If there's a way to write the driver so that I only have to deal with a simple sample buffer input to process it would be great (the simpler the better). I don't care too much about latency, I just want it to be as transparent as possible for the system and the applications running so that everything goes through this virtual device out of the box.
I have some experience in Linux kernel development but I know next to nothing about Windows driver development. I have a genuine Visual Studio 2013 ultimate and I want to target Windows 7 (above would be nice but it has to work on W7).
I would like to know which API/framework/system should I use to achieve my goal and possibly link to dev ressources to get me started.
Related
I'm building a C++/MFC desktop app that shares a lot of data with an USB device.
Because of how this devices works I need to close and open the virtual COM I use, severl times per minute.
Everything works well, but I would like to stop the annoying Windows USB connected/disconnected suound, that comes up every time I connect or disconnect the device.
So my question is: is there a way to disable/enable Windows event sounds (or a single event sound, even better) through my C++ code?
Obviously I could somehow turn down the volume, but that's not what I want, since it would stop sounds from every other app.
Is there a way to do something like this?
Thanks!
I want to write a program that will monitor memory in a driver and print the memory contents every so often.
However, I'm not finding any resources in the Windows API that seem to allow me to grab a pointer (Handle) to a specific driver.
I'd appreciate any answer either from User space OR kernel space.
If you want to know exactly what I'm doing, I'm attempting to duplicate the results from this paper except on Windows. After I gain the ability to monitor a buffer in a basic windows console program, I intend to monitor from the GPU.
[For the record: I am a Graduate Student who is pursuing this as a summer project... this is ethical malware research.]
============UPDATE ==================
This might technically be better suited as an answer, but not really until I have a working solution.
My initial plan of attack is to use WinDbg to do dynamic analysis on the keyboard driver when it gets loaded, so I can get some idea about normal loading/unloading behavior. I'm using chapter 10 of this book, to guide setting up my testbed and once I understand more about the keyboard structure and its buffer, I'll work backwards towards getting a permanent reference to this structure and see about passing it into the graphics card and monitoring it with DMA as the original paper did on Linux.
You won't solve this problem by "grabbing a pointer to a specific driver". You need to locate the specific buffer used by the keyboard driver that resides on top of the USB driver.
You will have to actually grok the keyboard and USB drivers for Windows. At least part of which is probably available if you have a DDK (driver development kit) [aka WDK, Windows Driver Kit]. You will definitely need a graphics driver for this part of the project.
You will also have to develop a driver mechanism to map an arbitrary (kernel) lump of memory to your graphics driver - which means you need access to the source code for the graphics driver. (In theory, you could perhaps hack about in the page-tables, but Windows itself isn't too keen on software messing with the page-tables, and you'd definitely need to be VERY careful if the system is SMP, since modifying page-tables in an SMP system requires that you flush the TLB's of the "other" CPU(cores) in the system after updates).
To me, this seems like a rather interesting project, but a really tough one in a closed source system like Windows. At least in Linux, the developer has the source-code to read. When it comes to Windows, most of the relevant source code is completely unavailable (unless your school has special license to the MS Source code - I think there are some that do).
I'm thinking of writing a C++ application for windows which would need to filter all sound output from all applications and change it.
I only have moderate experience with C++ and programming for windows and I realise that it will be a bit of a learning curve.
What sound apis would be recommended to accomplish this? If anyone has other advice about going about this, I would appreciate it!
Thanks
It is my understanding that Windows Vista and later may have ways you can do this, but I am not familiar with it, or if it is even usable for what you need.
Generally, the only way to do this is to create a virtual sound card driver that your applications send their audio data to. From there, you will need a userland application that plays back that audio out of a different sound device.
You can either license an existing virtual sound card driver, or write your own (very difficult).
I am working with a pressure-sensing mattress having a USB interface. The maker provides USB device drivers for Windows, and an API written in C++ which has functions to request data and set some parameters.
Currently, I cannot use this sensor for testing some Python data-visualization scripts directly, having had to ask my coworkers to write a text-logger for me, and then I read this information offline with Python.
Also, I cannot use Linux at all with the sensor, because there are not drivers for Linux, and I do not know where to start to "hack" the sensor, and that is why I am asking:
"If I were to try to read data from this sensor directly with Python and perhaps in Linux, what should I do first, or read first?"
EDIT: the device has an FTDI driver (FTD2XX.dll) if it helps.
Any help would be very welcome
Odds are fairly good it's a HID device, in which case you can probably start to write a userspace linux driver for it using libhid. First place to start with that would be enumerating the tree that gives you information about its capabilities. (lsusb -vvv or Example)
Failing that you can use libusb on linux (and other platforms too these days) to write a userspace driver still. You'll want to use something like usbsnoop or a real hardware equivalent to see what the official driver does when it's talking to the device and mimic it from there.
From the python side you can probably generate a decent wrapper to the existing C++ API using SWIG for relatively little effort, especially compared to developing an entirely custom driver.
Update:
If it's an FTDI device then it's might be a lot simpler to work with. Depending on what the vendor and product ID are showing it might automatically work with the FTDI driver in Linux, giving you as USB serial port. Failing that there are parameters to the module - vendor and product that I believe you can use to make it claim other devices besides the pid/vid combinations it knows about already. From there you can try opening the serial port device with different settings. With luck it might be sending state info regularly already.
If it's not you want to try and discover what the official software sends to make it start playing. You're back into the realm of sniffing again, but I think there might well be things that do it at the serial layer instead of the USB layer for windows (although I can't name any). You might also learn something by trying to make their library use a software emulated serial port instead of the FTDI device and seeing what it writes.
The FTDI chips have a linux driver. Just go to the FTDI website and download it. The driver creates a virtual serial port. You can use PySerial to interface with it.
Too bad I didn't see the post sooner!
I'm developing a device and writing the software for it under Windows (MFC with Visual Studio).
I would like to start a measurement with a remote. It would be nice if it worked over Bluetooth, but I don't have a clue where to start.
What book can recommended or is there a site where such things are described?
Is it even possible to make my own Bluetooth device or do I have to pay some fee for licences?
What I would like to have, is a Bluetooth-remote with one button, which sends a signal to a Windows PC where a program then starts specific subroutines.
As Dan wrote in the comment when it comes to Microsoft the best place to start is with MSDN. For me his link didn't work, but I guess he wanted to point here.
MFC does not offer you support for Bluetooth, instead you have to work with a Bluetooth driver stack API. On Windows there are more stacks, but most widely used are: Microsoft Bluetooth driver stack and Widcomm/Broadcom. If you decide to use the Microsoft Bluetooth driver stack you might want to look on this thread. The stack that you choose it depends on the Bluetooth dongle attached/incorporated at your PC.
Is it even possible to make my own Bluetooth device or do I have to pay some fee for licences?
Yes, it is possible to make your own Bluetooth device. The fee depends from case to case, first if you want to be assigned your own IDs from SIG you have to pay them a fee, otherwise you can use the ones already bought by the chip manufacturer. Also if you want to re-write the firmware from the chip you could be forced to buy a software from the chip manufacturer. Usually it's enough with their firmware.
What I would like to have, is a Bluetooth-remote with one button, which sends a signal to a Windows PC where a Software then starts specific subroutines.
Well, it seems you will have to take care of the device discovery aspect and second make the pairing. After this you could use Serial Port Profile to communicate with your device like any other RS-232 enabled device. If your device is dedicated you might want to modify the IAC - Inquiry Access Code so in discovery phase only you that you know the code, can see the device.