Hello fellow community,
I'm currently trying to differentiate between multiple HID input sources connected to a RDP client running Windows 10 Business build 19045.2251. The server itself is a Microsoft Windows Server 2019 build 17763 running a custom C# 4.7 .NET application.
The application shall then differentiate betweeen a barcode reader, an RFID reader and a keyboard respectively.
My naive idea is to only allow inputs coming from the barcode reader and only when an authorized person gives permission by means of his/her RFID chip, keyboard inputs are permitted.
Running the application locally for testing purposes allowed to perform the distinction using the vendor and product ID of a given input device using raw inputs.
Unfortunately, this breaks once I move the application onto the server and try obtaining raw inputs from the device connected to the client, as shown below:
raw information of USB device connected to client
So far I tried activating remoteFx in the hope of gettig device specific information, but to no avail.
I could not find any helpful resources on the internet and thus I am turning to you, hoping anybody could provide me with some hints on how to go on.
Also if this approach is flawed to begin with, I am happy to adapt the logic in order for it to work.
Thanks in advance for any input!
Related
I need to emulate a few USB devices on Windows to write and test code without any hardware dependencies.
We use COM port emulators (here com0com) to create COM port pairs. Most devices we test by sending control signals from a controller application to any open ports which can then be picked up by device simulator applications that can return relevant commands (by way of HTTP requests). The applications are written in Nestjs (Node) and utilize the SerialPort library.
However, for some devices we need to get the specific VendorId and ProductId and I am not sure if and how this can be emulated, even if we would write our own drivers. It seems that this information has to come from the devices themselves (firmware)?
I am relatively new to software development and surely to this specific domain and I would be grateful for some directions and pointers. I am willing to invest some time to solve this, e.g. get into driver development, if I have an idea about how it could look and where to start (if at all).
I wonder if anyone can help at all, a bit of a specialist problem this.
I have an application that needs to read and analyse a number of USB devices (not simultaneously, they are each run in seperate tests and could in theory be run on different machines).
Each of the USB devices is based on the USB HID class, and are manufactured by different companies, none of these USB devices are designed to be run on PC, but are meant for a different platform, however for the purposes of testing the devices the client has requested that the test application is run from a PC.
Some of the devices will start up, be recognised by windows which will initialise and start them correctly using the generic HID class driver built into windows, the devices will then start sending correct data packets of the data to be tested.
Some of the devices will start up, be recognised by windows which will try to start them but fail to fully to initialise them leaving them in a half initialised state. This is fine, as I can use my beagle protocol analyser to capture the initialisation packets from the genuine platform and then use the LibUSBDotNet library to replicate the remaining packets in the initialisation sequence and get them to start sending the packets correctly.
The problem I have is with one particular device (though there are some more I haven't tested yet so it's quite possible one of those may also exhibit the same problem). The issue is the the Windows HID class driver recognises the device and trys to initialise and start it, this works after a fashion and the device starts sending data.
The problem is that the data being sent is different to that which is sent to the genuine platform (containing only a subset of the full data). It's as though windows has initialised the device into a different mode.
When I capture the initialisation packets from both the PC and the genuine platform using my USB protocol analyser I see that Windows is sending some slightly different initialisation packets. Using LibUSBDotNet to resend the correct packets once Windows has already started the device seems to have no effect.
My problem is that I need to stop windows from trying to initialise the device using the standard HID class driver, I've tried removing the driver in Device Manager but it still initialises it (and the driver is magically reassigned in device manager). I've done some investigation and there are possible alternatives:
Create a specific driver which windows will assign to the particular VID/PID of the device but that does nothing, then I can use LibUSBDotNet to send the correct initialisation sequence to the device from within my own code.
Use something like WinUSB to create a proper driver for the device (or possibly to create a "dead" driver like 1.
Will a driver with a specific VID/PID defined be used by windows in preference to it's inbuilt USB HID class driver? If not then I would be wasting my time going down this route?
Note, my mac initialises the problem device correctly, and I've asked the question of the client whether the application can be developed for Mac and their answer was frustrating Windows only.
I've no experience in writing proper Windows drivers, though I have experience in talking to USB at a relatively low level (so that part doesn't worry too much). Can anyone suggest a good course of action (before I potentially waste weeks investigating how to write drivers for the PC only to find my selected course of action can't deliver what I required).
Any help or suggest much appreciated.
Thanks,
Rich
Added after trying suggestions below:
I tried using the LibUsbDotNet inf wizard to create the necessary files and install them and this appeared to work - certainly the device was now appearing in Device Manager as a libusb-win32 device - not HID device and the associated driver was libusb driver. Even after doing this the device still seems to become initialised and start sending the wrong type of data packets although now those packets are no longer handled by the class driver and are just lost.
I also came across Zadig which has a similar inf creation wizard for WinUSB and this had exactly the same result.
A colleague has suggested that it might not be windows itself that is switching the device into this mode, rather the device identifying that it is connected to a windows machine and switching itself into this mode. I suspect this is the case, in which case I am stuck - time to have another conversation with the client.
Many thanks for the help.
You're using libusb-win32 as a filter driver; that is, the HidUsb device driver is assigned and loaded for your device, but then the libusb-win32 driver is loaded on top and gives you unobstructed access to the hardware.
If you don't want a HidUsb (or any other class driver) to perform any communication "on your behalf", simply associate libusb-win32 as a device driver with your hardware. For this, you'd have to create an .INF file associating it with the VID/PID/Revision of each USB device. If I recall correctly, libusb-win32 even comes with a utility to generate such .INF files.
If you install this .INF file e.g. with PnpUtil.exe (available on Vista or higher), you might still run into issues where, although you're a better match than the generic HID driver, the HID driver is still selected.
The generic HID driver matches devices by their Compatible IDs (i.e. by a USB interface class) while you'd be matching by Hardware IDs (which have higher priority). However, Windows might give priority to other aspects, such as your driver being unsigned. Read: How Windows Selects Drivers
Luckily, even in that scenario, signing drivers with a self-generated certificate (use CertUtil.exe, MakeCat.exe and SignTool.exe) is not too difficult.
I would like to make a Windows Phone 7 application that takes advantage of it's USB port to communicate with the PC. I would like to write an application to control or push information/data to the PC from the application. But I am having problems finding information on where to start. Can anyone help point me in the right direction with some resources?
The only way to communicate over the USB connection is over HTTP.
To get this to work you'll need:
- a webservice hosted on the PC you're connecting to.
- a way for the app (on the phone) to know the hostname of the PC. (You'll probably need to enter it manually)
When you have these it should be straight forward.
You can't.
If you want to make sure to push data to a client PC, you will have to use a kind of synchronization by using the internet. For example create a wp7 application and a desktop application and let them sync the data based on a user object or anything like that.
As far as I know also the updated SDK for Mango will not support programming against the USB dataconnection.
We develop a custom Windows CE-based device. To connect this to the PC via ActiveSync / Mobile Device Center, we have to set up entries so that the WCE USB Serial Host (wceusbsh.sys) recognises our Vendor ID (Vid) and Product ID (Pid).
To do this, to date, we have distributed a modified version of wceusbsh.inf and wceusbsh.sys: when the user first connects the device then ActiveSync basically says it does not recognise the device, and the user is asked to identify a driver for it. If they now point at the location where they've stored our wceusbsh.* files then all is well. However this is pretty clunky.
What we really want is a slick way to do this, preferably by running an installer which just gets everything ready, so that as soon as the device is plugged in it is recognised by wceusbsh.sys.
Any clues how to do this? There seem to be a ton of registry entries which relate to WCEUSBSH, and it's not clear how these are set: just "installing" the .INF file doesn't seem to allow for setting them all, so it does look like ActiveSync reads the .INF file and then adds some more information before appending the new info to the Registry.
Thanks
Well, in case anyone else comes looking for an answer to this, we managed to do it via this link from MSDN WinUSB (Windows Driver Kit). We now have a driver install program which sets up USB / Mobile Device Center so that when you plug in the CE device it is recognised correctly.
I'm developing a project that has a number of hardware sensors connecting to the deployment machine through RS232 serial ports.
But ... I'm developing on a machine without an physical RS232 serial ports, but I would like to make fake serial ports that I can connect to and output data from with the aim of faking input from hardware sensors.
Does anyone know of a way to create a fake serial port and control it on Windows XP?
If you are developing for Windows, the com0com project might be, what you are looking for.
It provides pairs of virtual COM ports that are linked via a nullmodem connetion. You can then use your favorite terminal application or whatever you like to send data to one COM port and recieve from the other one.
EDIT:
As Thomas pointed out the project lacks of a signed driver, which is especially problematic on certain Windows version (e.g. Windows 7 x64).
There are a couple of unofficial com0com versions around that do contain a signed driver. One recent verion (3.0.0.0) can be downloaded e.g. from here.
I know this is an old post, but in case someone else happens upon this question, one good option is Virtual Serial Port Emulator (VSPE) from Eterlogic
It provides an API for creating kernel mode virtual comport devices, i.e. connectors, mappers, splitters etc.
However, some of the advertised capabilities were really not capabilities at all.
EDIT
A much better choice, Eltima. This product is fully baked. Good developer tech support. The product did all it claimed to do. Product options include both desktop applications, as well as software development kits with APIs.
Neither of these products are open source, or free. However, as other posts here have pointed out, there are other options. Here is a list of various serial utilities:
com0com (current)
com0com - With Signed Driver (old version)
Yet another place for com0com with Signed Driver (Pete's Blog)
Tactical Software
Termite
COM Port Serial Emulator
Kermit (obsolete, but still downloadable)
HWVSP3
HHD Software (free edition)
I use com0com - With Signed Driver, on windows 7 x64 to emulate COM3 AND COM4 as a pair.
Then i use COM Dataport Emulator to recieve from COM4.
Then i open COM3 with the app im developping (c#) and send data to COM3.
The data sent thru COM3 is received by COM4 and shown by 'COM Dataport Emulator' who can also send back a response (not automated).
So with this 2 great programs i managed to emulate Serial RS-232 comunication.
Hope it helps.
Both programs are free!!!!!
There's always the hardware route. Purchase two USB to serial converters, and connect them via a NULL modem.
Pro tips:
1) Windows may assign new COM ports to the adapters after every device sleep or reboot.
2) The market leaders in chips for USB to serial are Prolific and FTDI. Both companies are battling knockoffs, and may be blocked in future official Windows drivers. The Linux drivers however work fine with the clones.
Another alternative, even though the OP did not ask for it:
There exist usb-to-serial adapters.
Depending on the type of adapter, you may also need a nullmodem cable, too.
They are extremely easy to use under linux, work under windows, too, if you have got working drivers installed.
That way you can work directly with the sensors, and you do not have to try and emulate data.
That way you are maybe even save from building an anemic system.
(Due to your emulated data inputs not covering all cases, leading you to a brittle system.)
Its often better to work with the real stuff.
i used eltima make virtual serial port for my modbus application debug work. it is really very good application at development stage to check serial port program without connecting hardware.