Checked from osx website, IOHIDDeviceSetReport is a low-level function to setreport. it has a high level one, HIDTransaction, including HIDQueue.
Which one should i use? I do not see many examples using IOHIDDeviceSetReport.
It really depends on what you need to do.
If you need to change a HID Value (read: the value of a HID Element), just use the HID Value functions
If you need to change many such values at the same time, use the
HID Transaction functions
If you know how raw data is packed in the HID output report, and you need to send that raw data to the HID device, use IOHIDDeviceSetReport
As read on topic here How to find the unique serial number of a flash device? and especially here How to get manufacturer serial number of an USB flash drive? I know it is possible to get properties of hardware devices (particularly hard drives and usb drives...) using WMI Win32_PhysicalMedia and Win32_DiskDrive, which I'm getting done successfully.
However, I really want to know about the safety of these informations.
PhysicalMedia property SerialNumber returns the actual serial number of the main hard drive, while using other Win32_LogicalDisk and other calls we can map the drive letter of flash storage to actual Win32_DiskDrive device, and from there read properties like Name, Model, FirmwareRevision, SerialNumber, DeviceID, Manufacturer...
Now, DeviceID is generated by Windows / Pc itself, while SerialNumber should be the one that manufacturer added to the physical flash drive.
Manufacturer in most cases returns "Standard" something, Name is also of no use, while SerialNumber actually gets me a something that looks like unique ID, (I've read that in some cases this is not returned, so PNPDeviceID should be used instead? , Model gives the actual model of the flash drive, and FirmwareRevision just a number that could be used to add safety switch to the licensing, but is not vital.
However, the only one of these that seems / should be actually safe to use is SerialNumber, right?
So, the question here goes: Which level is Win32_DiskDrive actually reading this info from? Is it possible to fake that at all (Ok, letalone the actual lowlevel hacking stuff or driver injection etc...(??)), and if so, how hard it is?
If there's a known way / guide / example, I'd be also happy to read it. (not necessary info looking for here though.)
This is not for intention of bypassing some licensing. I'm making licensing for my SW, and am curious, whether it would be safe enough to use USB drive's SerialNumber property, and lock license against the presence of that USB flash, for which the license was bought for? Basically to use it as kind of a dongle, but not like the dongles actually work (using communication with the actual hardware inside the dongle...)
I know it may not seem as a safe solution, as flash drives dies quite often these days, or get lost etc, but this is just to add an option to my licensing from "Per PC" to "Portable - per USB device".
Thanks for any info!!!
EDIT:
I am completely aware that bypassing these kind of safety switches is very possible. Of course, even Windows itself is not licensed in a way that couldn't be hacked, nor Adobe, ProTools etc, (software that is widely used and costs a lot!).
But that wasn't a real question, and also, that's not the case for me -> the software will not be that expensive and not used by that much people, that I'd be afraid to drag interest in someone who will do extensive programming to make a patch/crack for it. Regular debugger use and workaround is pretty unlikely to be used by regular client who would need the software, ( and also, since it is something to be used in business environment, where stability is vital, I doubt they will really play around that...).
Main point here:
It is possible for sure, but: HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
Main question of the post: Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app? If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
WMI just returns what the hardware tells it. It's as unique as the hardware. Which ultimately depends on the vendor.
But...
If someone has an administrator account to the computer†, then there are very few things that can be done to keep them from just hooking up the kernel debugger to your program and overriding your checks, or recording the raw USB communication session and replaying it on an unauthorized system. The real dongles do some to mitigate this, by having the hardware generate a response to a particular challenge. The challenge/response changes for each request, so it's not as susceptible to replay attacks, but the debugger tricks still work.
This is the real problem with the serial number approach. Uniqueness is not the primary concern for dongled software. The primary concern is unpredictability.
An illustrative example-
Let's say that I'm a bouncer at an exclusive night club. We're so exclusive that you have to answer a question to get in. You really want to get in, but no one will tell you the answer to the question. One night, you hatch a plan. You hang out in the alley and listen to the conversations that I'm having with the patrons trying to enter the club. It doesn't take you long to realize that I'm asking everyone the exact same question, and you're in. (This is the serial number approach)
After a while, I notice that there are a lot of people coming into the club that I've never seen before, and begin to suspect something. The people we really want to allow in are all given a card with a formula‡ on it. Whenever they come to the door of the club, I give them a number and they apply their formula and tell me the result. Since I also know the formula, I can tell if they are really allowed in. Now, even if you hear the entire challenge and response, without the formula, you aren't getting in. (This is one common approach taken by dongles.)
But what about the debugger? The debugger just made herself the club's owner, fired me, and can come and go as she pleases.
†Or has physical access to the machine and a password reset disk.
‡Stop laughing, this could totally happen. :)
Photo credit: Guillaume Paumier, CC-BY. Found on the Wikimedia Commons 7-Oct-15
Edit to address the question edit:
HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
The question is how skilled is the 'regular person'? If you're talking about software/electrical engineers, then this is a trivial task. If you're talking about sales/marketing then it's a challenging task.
Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app?
It depends and Yes. Changing the ID on the device itself is possible with some devices, and impossible with others. Software to spoof/man-in-the-middle the USB communication, or to create a virtual USB device is possible.
If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
As I led with above, WMI reads from the hardware. This can be intercepted or bypassed.
Some ways to bypass the check:
Make a virtual USB device
Modify the USB MSD device driver to report the same serial number for all devices.
Build hardware using commercially available cheap host controllers that identifies with the same information as the authorized device. ($10 worth of raw components and a little bit of time.)
Redirect the system calls to/from USB to a compromised library.
Note also that:
Some places have restrictions on USB storage devices, ranging from discouraging their use, to outright bans. This would prevent your software from being used in sensitive computing environments processing private data, like credit cards, PII, trade secrets, classified information, etc. (In the US many governmental agencies have outright bans on USB storage devices, and block the install of any MSD.)
The Mass Storage specification doesn't require serial numbers. They are usually there, but they don't have to be, and many low-cost vendors
A USB PKI token costs a little bit more, but would probably do what you want. Here's an example from Safenet (Disclaimer: I am in no way affiliated with Safenet Inc, and you should evaluate all the possible options from all vendors. I suggested this because it was the first thing that came up through CDW, and the price was ~$30)
I intend to use the users BIOS/Motherboard Serial Number to uniquely identify a user. When I refer to the BIOS/Motherboard Serial Number I am referring to the number returned when you type in: wmic BIOS get SerialNumber
Regarding the BIOS/Motherboard' Serial Number:
Can the user change this serial number? Either using third party applications or through Windows.
According to this forum post, not all vendors supply a motherboard UUID so I cannot use this to uniquely identify the user. Do venders mostly/always supply/fill out the BIOS/Motherboard Serial Number or will I also find some computers dont have a serial number?
I have tried to uniquely identify a user using the Hard Drive's Serial Number. But I have first hand run into the issue that it can change and that Windows API is unreliable and can return different values. See my post here. Do you know if I may experience the same issue for the BIOS/Motherboard's Serial Number?
Can a standard process (Standard Windows User) retrieve the BIOS/Motherboard Serial Number? Or does the process need to be elevated (Admin User)?
Just to confirm the BIOS is the motherboard, correct? I am a little unclear because I thought the BIOS is the simple software installed on the motherboard.
Yes, a power user can change nearly all serial numbers using either service utilities like AMI DMIEdit or by editing BIOS chip contents manually.
Most desktop motherboards right now are coming with empty MBSN and UUID, except for ASUS ones. The only PCs that almost always have valid identification data are branded ones (i.e. Dell or HP workstations).
Nearly all "individual" data can be changed somehow, and virtual devices makes the whole situation even more complex.
It depends on how you will try to access it, but general answer is "No, you need administrator rights". Read more here.
My 5 cents on this: just don't use HW-based identification, it brings more problems then solves.
When WMI is queried and returns a list of devices, I've noted some information at the END of the DeviceID string that isn't documented anywhere I've looked so far. Here's an example of a DeviceID string returned from a WMI query looking at Win32_PnPEntity:
USB\VID_046D&PID_082D&MI_00\7&3538A2BF&0&0000
Now, the first two parts - both the 'USB' and the VID and PID are really well documented, as is the 'interface number' - the &MI_XX. However, the last part of the string (shown below) isn't documented anywhere I've looked. I don't even know what to call this part of the DeviceID string:
\7&3538A2BF&0&0000
Curiously, it comes in several flavors. I've noted that if I have two identical devices plugged into the PC, I'll get different values, which I've defaulted to calling 'instance id's' for lack of better documented reference info. Here's what I see when I have two identical USB Web cameras plugged into my PC:
USB\VID_046D&PID_082D&MI_00\6&DB509D0&0&0000
USB\VID_046D&PID_082D&MI_00\7&3538A2BF&0&0000
So far, so good. I can pick out that I have two identical devices plugged into the PC and can parse against these unique values. But wait! When the OS sees these devices, it also loads anything the drivers offers for different 'interfaces' or modes of operation, so along with the above entries when I make a WMI query against Win32_PnPEntity, I also get these nice entries in the DeviceID field as well:
USB\VID_046D&PID_082D\195825EF
USB\VID_046D&PID_082D\36149BBF
So the problem is that without documentation that describes what this last part of the DeviceID is, I don't know to expect, and can't associate or separate these 'duplicate' entries from their brethren in the query results.
The goal is to be able to scan through the WMI result, identify ONE 'primary' entry for a given device and discard anything else. I could likely HACK the filtering by looking for "USB Composite Device" in the Description field, but this is rather ugly and would discard some devices that do not have an appropriate or vendor-specified 'description.'
MSDN only provides that the DeviceID is a "Unique identifier of the USB controller. This property is inherited from CIM_LogicalDevice." -- and CIM_LogicalDevice doesn't detail the makeup of this field either.
Anyone been down this path or know which hole to look in? Similar questions in here and in other forums remain unanswered. (Hey M$, Why is this so %$##! mystical???)
It looks like this webcam is a composite device.
I think the node with the ID of USB\VID_046D&PID_082D\36149BBF is the parent device. The part after the second slash in this case is most likely the serial number of the device. (I have made Windows software for composite devices for years and we always get the serial number by parsing that part). This node probably uses usbccgp.sys as the driver, which allows it to parse the interface descriptors of the device and produce child nodes.
The node with ID USB\VID_046D&PID_082D&MI_00\6&DB509D0&0&0000 is the child node corresponding to USB interface 0. From my experience, I believe that the part after the second slash is some kind of unique identifier that depends on what USB port the device is plugged in to.
For the WMI query, you should probably just ignore the child nodes altogether. Just discard anything with MI_ in it before the second slash. The parent node tells you everything you need to know about the identity of the device.
I have a wide variety of VCOM devices (FTDI, CP210x, etc) that my program interfaces with, but I need to confirm they are in fact those devices before I begin talking to them. FTDI's D2XX library allows me to pair up the Product/Serial strings with COM number, but I really need a generic solution.
To be clear, I need the USB string descriptors for Product, Serial, and ideally Manufacturer as well. Note these are not the same as the VID/PID numbers, but actual strings. It is okay if I have to get the strings first, and then figure out the COM number for it later.
I am working with good old C cross-compiled using MingW, but really I'm at such a loss for how to do this that a solution in any language would be a step forward.
You should take a look at the Windows Driver Kit samples, or look in to the SetupDi functions (these allow you to enumerate types of devices and query for information). Those functions are documented here:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553567(v=vs.85).aspx#ddk_setupdi_device_interface_functions_dg
I've also posted this a few times, but it is good sample code:
Look at the USBView sample in the WDK. If you are unfamiliar with this, simply run it - this tool walks the entire USB tree on the system and prints out information and descriptor listings for each device.
In your case, I'd start at the RefreshTree() function in this sample, you can then follow the code to see how it enumerates the devices. For each device that you find you can look at the string descriptors.
The easiest way to get the source to this sample is to install the 7.1.0 WDK which is currently available here: http://www.microsoft.com/en-us/download/details.aspx?id=11800
Once you have the VID/PID/Serial Number you should be able to look up the port number in the registry. For example, the CP210x port number will be located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_10C4&PID_EA60\0001\Device Parameters\Port Name in the form of "COMxx" (where VID=10C4, PID=EA60, serial=0001). If you know what the VID/PID is for your device you could skip the USB search and simply parse through the registry to get all devices of that type to discover their COM port numbers.
You can also get a list of all COM ports on the system here: HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM. Values will be listed according to their type, so a real serial port will show up with a name \Device\Serialn and data COMxx, a CP210x will show up with a name \Device\Silabsern and data COMyy, etc. You can use the name to filter which type of device a COM port belongs to.
The Product Name string descriptor is exposed via SetupDi.
On Windows 7 and later it is called "Bus Reported Device Description". In XP and 2000 it was in the "Location" property. Doesn't seem to be available in Vista.
Other string descriptors are, as you note, available only from the USB ioctl commands sent to the upstream hub device, with no programmatic way to correlate them.
Serial numbers are available both ways, though, and may be the key to getting them matched up.