I've been struggling to find a way for listing only locally available SmartCard readers. Or at least differentiate between local readers and readers shared via RDP session.
I'm using SCardListReaders, but that lists all readers registered into the SmartCard subsystem, including readers from RDP shares. Are there any way to filter that list?
One way would be to list physical reader devices with SetupDiGetClassDevs, then use SCardListReadersWithDeviceInstanceId. But i need to have Windows 7 support and SCardListReadersWithDeviceInstanceId was introduced from Windows 8.
Any alternative solution is also appreciated.
You can use the SCARD_SCOPE_SYSTEM constant for dwScope parameter when calling SCardEstablishContext
Remote SmartCard readers can only exists inside of user context.
Related
This is my first post so please bear with me, will i get use to the posting requirements.
I need help finding out when i insert a smartcard (on Windows 64bit machine), what it then access in the background. I have tried using process monitor, process explorer and TCP View. These didn't provide me with what i needed which is to be able to see ports, registry keys, background network access and so on.I need something that will allow me to activate it to observe what happens when i use a smartcard. The idea is that a smartcard is inserted and then it looks at certain registry keys and also checks via an connection various URL's, ports to ensure access is granted. The problem is the software we have installed hasn't put the registry keys where they should be so i can't change them, and these are what i really need to get at. I have also tried searching the registry keys for a value one would be logged under and i can't seem to find it that way either.
I use to have a piece of software years ago that provided it, was a listener of some sort, but i can't think of it for the life of me what it is called. If anyone can point me in the direction of what i need to be thinking off i would be so grateful!
If i need to be clearer please let me know, thanks!
Actually a smartcard accesses nothing on its own. I'm aware, that Windows might look up the ATR in the registry in order to provide a "friendly card name", but if absent no harm is done except not having the friendly card name.
Any actions like internet request are more likely to be associated with a software tool called Service Provider, which knows, what commands to send for this specific card in order to perform actions like:
User authentication
Signature computation
Significant knowledge concerning the specific card is required, so entering some registry entries is far from sufficient. If the card contains a certificate, some software may try to verify the certificate chain or ensure, that the key was not revoked, but this is also not initiated by the card.
I am programming an activation code for my application, I need to provide the key file with information about the licensed computer, I need to retrieve information about some devices like processor ID and DiskDrive Serial number, and the BIOS Serial as well ,, and so on with some devices, but these are the major ones.
I need to combine the method with another application programmed by another language so I cannot use WMI, but I can use winapi.
is there a way to fetch the physical data using winapi?if so, then how?
If you are able to call Windows API functions, then you can use WMI. After all, the WMI interface is part of the Windows API.
Take a look at the Win32_BIOS class and the PROCESSOR_POWER_INFORMATION structure.
Accessing motherboard information without WMI seems not to be doable with current means. Here you can find a similar question:
Access Motherboard information without using WMI
The problem background - there are two different windows applications that are trying to access webcam on the computer at the same time. Currently, only one application is able to access to it. I want to be able to allow both applications to simultaneously access the webcam. A common example of my problem is, skype and yahoo messenger trying to access the webcam on the computer at the same time.
I found a few softwares (manycam.com, http://www.splitcamera.com/) that allow this on windows. But I am not sure how they implemented it. I want to write the code myself to achieve this since my code needs to be integrated with other APIs.
I appreciate if anyone can shed light on how to write a device wrapper to achieve this.
The kernel camera driver registers several OS-defined callbacks. One of the callbacks is used for the output stream. Dedicated Windows applications have an interface to this stream - you'll need to do some reading on this subject, it's not something that can be covered in scope of SO. You need a component that will be layered in between the client applications and the camera driver. This component should intercept your camera driver output and duplicate it for the registered clients. This can be achieved either in kernel (filter driver) or in user mode (preferable). http://msdn.microsoft.com/en-us/library/windows/hardware/ff557573%28v=vs.85%29.aspx is a good place to start.
Note: this functionality might be already supported by your camera software (though I think the chances are very slim) and in this case you should dig into the corresponding documentation.
We're porting our USB device dll's to use the generic WinUsb.
However, WinUsb doesn't support multiple concurrent application accss to the same device (Same VID & PID).
I wanted to know if there is a way to implement this concurrent access using WinUsb?
I read about filter drivers & services.
1. I don't want to use a filter driver because, as I understand, this will have to pass WHQL, and I rather not go this path.
2. Regarding a windows service: How exactly should I implement it? should the service get all of the calls to WinUsb, and if a different application tries to access the same device, it will close the connection to the first application, open a new connection, and back again?
Is the service the right correct solution in this case? Is there another way to implement the solution other that what I wrote?
Thanks.
A filter driver does not need to pass WHQL. You only need to sign the catalog file, needed by the driver package. This only needs a code signing certigficate from verising/... . This should be a good starting place to get to know this.
Nevertheless, a kernel driver can be hard to develop. So maybe a COM server would be a better approach. You implement this sharing from a service, by allowing COM-clients to create objects from your service and then implement some kind of sharing/mutual exclusion in your COM-server.
A COM-exe servers can be written relativly fast.
In prior versions of Windows before Vista you could have a Windows Service interact with the current logged in desktop user to easy display information on the screen from the service. In Windows Vista Session 0 was added for security to isolate the services from the desktop. What is an easy way to communicate between a service and an application running outside of Session 0? So far I have gotten around this by using TCP/IP to communicate between the two but it seems to be kind of a sloppy way to do it.
You can use shared memory or named pipe to facilitate IPC as well. Conceptually this is similar to TCP/IP, but you don't have to worry about finding an unused port.
You have to make sure that the named objects you create are prefixed with "Global\" to allow them to be accessed by all sessions as described here.
AFAIK there is no way for a service to directly interact with the desktop any more.
Indeed, for security reasons it is no longer possible to communicate directly with the "desktop". What exactly is the "desktop" anyway, when you live in a machine with multiple active users + remote sessions?
The general way to solve the problem is to use service apps which communicate via some RPC mechanism (TCP/IP, IPC, .Net Remoting Channels over one of those, etc). Its kind of a pain, but I think the benefits are worth the change.
For the service to talk to the desktop, you're pretty much stuck with one of the RPC mechanisms. The .NET remoting mechanism (IpcServerChannel) isn't to hard to implement for this purpose.
Also with .NET a desktop application can send messages directly to the service with the ServiceController.ExecuteCommand. These commands are received by the service via ServiceBase.OnCustomCommand. This is even easier to do, and would be all you need if controlling the service is your only requirement.