Can I get device unique id(UDID) from C++/CX code on WP8? Or how can I do it if I doesnt? I've tried already to use DeviceExtendedProperties(it doesn't work, probably it is .net only class).
You can use HardwareIdentification.GetPackageSpecificToken method to get a device-unique ID that is specific to your app. There are some complications to it, as the value of the ID depends on a number of system factors such as available memory, connected peripherals (think Bluetooth headsets), network connectivity, etc - make sure to read the linked documentation! A more in-depth discussion of the components of the hardware ID can be found here.
The value will be unique to the combination of your app and the specific device, which is more than likely to be enough for app-development purposes.
Note that this API requires a WP 8.1 "Windows Runtime" app, and will not be available to WP8 Silverlight apps.
using namespace Windows::System::Profile;
...
IBuffer^ nonce = ...; // optional, see documentation
HardwareToken^ hwid = HardwareIdentification::GetPackageSpecificToken(nonce);
// HardwareToken has a few properties, but the one you're likely interested
// in is HardwareToken.
IBuffer^ id = hwid->Id;
Related
I get information about All network adapter installed on my computer with function GetNetworkParam, GetInterfaceInfo and etc...
now in C++, I want get information physical network adapter in my system not all adapter(not VMWare, and etc), just physical, how do it?
As Sam V. Pointed out, C++ is a language that knows nothing about network hardware. However there are many ways in which you can find that information, usually by using some libraries or frameworks. It depends however on some of your requirements. For example, finding a completely portable solution is probably going to be hard.
That said, I would use Qt for this, as it is portable over many popular platforms while still containing an impressive list of features. Check out the following from the official documentation:
Bearer Management
QNetworkSession
QNetworkConfiguration
QNetworkInterface
Some example code I use to filter interfaces in my application:
QList<QNetworkInterface> interfaceList=QNetworkInterface::allInterfaces();
for(QNetworkInterface iface:interfaceList){
QNetworkInterface::InterfaceFlags flags=iface.flags();
if(flags&QNetworkInterface::InterfaceFlag::IsLoopBack){
continue;
}
if(flags&QNetworkInterface::InterfaceFlag::IsPointToPoint){
continue;
}
// Filter on other properties you want here
}
I have a device without knowing the used gatt profile, I only know that is something "homemade" and not anything known on the bluetooth-database.
In Linux the command
gatttool -i hci0 -b xx:xx:xx:xx:xx:xx --char-read --handle=42
returns the value as expected (with the target device mac at xx:xx:xx:xx:xx:xx).
In Qt I am using the Heartbeat-Example from http://doc-snapshot.qt-project.org/qt5-5.4/qtbluetooth-heartlistener-example.html
there they connect using a gattprofile, QBluetoothUuid::HeartRate and QBluetoothUuid::HeartRateMeasurement
I wasn't able to modify the example code in a way to read handle 42.
Can you explain where I have to put which values, that it connects to the "standard profile" as the gattool command does? If I use gatttool in interactive mode and ask primary it returns two uuids, but using them instead of the QBluetoothUuid::HeartRate did not work.
It doesn't appear that the Qt Bluetooth Low Energy API provides means for obtaining access to characteristics based on their handle value. (Neither does the Windows 8 BLE API.) You should use the UUID. Even if it's a homemade device, all services and characteristics are required by the GATT protocol to have UUIDs. The lowenergyscanner demo app can discover and display both the UUIDs and handles of all of the device's services and characteristics. I've used lowenergyscanner to deal with BLE devices I'm developing.
device discovering is by uuid, even if you create a new profile with a new service and a new characteristic, you have to give the new characteristic uuid in setup.
But i dont know, how to add multiple characteristics to one service, it does not work with me.
have fun
I'm writing a C++ application that is run as Windows Service (Win XP, Vista, 7, 8, servers).
My apllication uses third-patry library that maps local folder to the drive and this drive should be available in user mode (for all users). The problem occurs when user has some network share mapped to the local drive and third-party library doesn't recognize that specified drive letter as already in use.
The question is how to determine (from service application) if required drive letter is definitely available?
I'm using
GetLogicalDrives
QueryDosDevice
to determine logical devices. I've tried
WNetGetConnection
WNetGetUniversalName
to retrieve information about network share, but those functions doesn't return anything for required drive letter despite the fact that there were shares mapped to the specified drive letters.
My guess is that problem is in priveledges. Since my application run as service it can't get information about shares mapped in user mode (which seems very strange to me).
So the final question is - how to detect if specified drive letter is not used for mapping network share by any user?
The problem is in fact that there may be a difference with shares that a user can hold and shares that an admin can hold.
There is a flag in the registry that controls this:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections = 1 (DWord)
Here is also a MSDN-KB article that explains this. Using EnableLinkedConnections set to 1 should fix this. Usually it is set to 1.
Background: When the UAC was invented this change was one side effect.
For a requirement to generate per-PC license keys, I need some code which will return a stable and (near) unique key on any PC. It doesn't have to be guaranteed unique, but close. It does need to be reasonably stable though, so that a given PC always generates the same result unless the hardware is substantially changed.
This is for a Windows application, using wxWidgets but a Win32 or other option is fine.
I was thinking about MAC address but what about laptops which can routinely disable the network card in power-saving mode? I came across GetCurrentHwProfile but it doesn't quite look like what I want?
One idea I had a while back for this is to use CryptProtectData as a way to identify a machine. Behind-the-scenes in that API, Microsoft has done what you're looking for. I never tested it though and I'm curious if it's actually viable.
Basically you would encode a constant magic value with CryptProtectData with CRYPTPROTECT_LOCAL_MACHINE, and the result is your machine ID.
I would just go with the MAC address method; when the wireless / LAN cards are turned off they still show up in Network Connections. You should therefore still be able to get the MAC.
Consider this: Any time you'd be able to contact your webserver or whatever you're cataloging these IDs with, the user is going to have to have some form of network card available.
Oh, and you might be able to use CPU serial number of the customer's computer supports it.
I think there no really easy and unique method so far discovered here.
GetVolumeInformation retrieves not even close to unique ID.....
To use any hardware serial is problematic because manufactures are not committed to supported it always and especially to keep it globally unique
GetCurrentHwProfile retrieves GUID but it's value affected by minor! hardware changes...
Using Product Key ... will bring U to deal with the stolen software - there lot of pirate installations over the globe.
Creation of own GUID and preserving it under registry (in any place) will not prevent duplication by cloning of image ....
etc...
From my perspective of view the best way is combine:
Volume ID + MAC's list + Machine SID + Machine Name. And obviously manage license policy on the server side ;0)
Regards
Mickel.
If you want something a bit harder to spoof than whatever the machine itself can tell you, you'll probably need to provide a USB dongle dedicated for this purpose (not just a flash drive).
For a pretty brain dead test I am using the ProductID code of the OS and the computer name - both extracted from the registry. Not really secure, but its all pretend security anyway.
edit
To answer John's question about what keys I am reading:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductID
SYSTEM\CurrentControlset\Control\ComputerName\ComputerName\ComputerName
How about using the serial number of the harddisk where windows is installed?
The function GetVolumeInformation() will give you such serial number.
To access the ID assigned by the harddisk vendor instead of the ID assigned by Windows, you can use the Win32_PhysicalMedia Class.
To determine the drive where windows is installed, you could expand the variable %windir" by using the function ExpandEnvironmentStrings()
Another option, if your architecture allows, is to use UuidCreate() to generate a random GUID at installation time and save it permanently in the registry. This GUID can then be used as the ID as long as the registry remains. A new registry database is generally considered as a new installation.
A third option is to have a well-known server assigning the IDs. Upon starting up, the software could look up for the ID in the registry and if not found, would contact the server and supply it with its MAC address, hostname, harddisk serial number, Machine SID and any number of indentifyable information (keys).
The server then determines if the client is already registered or not based on the information given. The server could have a relaxed policy and for example only require most of the keys for a match, so that the mechanism would work even in the event of a complete wipe out of the registry and if part (but not all) of the hardware was replaced.
How about using the serial number of a CPU. I remember Microsoft used to provide an api for this that would run the necessary assembler code and give you back all sorts of info about the CPU including serial number. Not sure if it'd work with AMD chips or not, I think it was intel specific.
Surely CPU Id is secure and static enough!!
I've got some bar code scanner devices that can handle a variety of USB interfaces (COMM Emulation, HID Keyboard, HID POS, etc.) The problem is that, while I can tell if the device is in a HID mode, I need to be able to determine if it's HID Keyboard or HID POS.
Is there a way to determine this using Win32 C++, preferably with the built in windows HID library (hidsdi.h)?
You can use HidD_GetHidGuid to get the unique GUID for the device. Device interface guids are defined by each device/application software vendor, Microsoft or third party as they see fit. In some cases the guids are published and public knowledge and are standard interfaces, in some cases they are not.
You can also use the USBView utility from Microsoft which will let you browse the USB tree or you can look in the registry and see if you can find the GUID for your device. You may still have to query your device to determine device type if the config data is not present or it does not reveal itself other than a generic device, if your device supports this.
There are two types of GUIDs: Device Class and Device Interface. A device can only be a part of one class. Unfortunately, the Device Class and Device Interface GUIDs are sometimes the same, thus confusing developers. In the WinXP DDK, standards were created to try and make the definition of GUIDs less confusing.
See also this previous SO question: Use RegisterDeviceNotification() for ALL USB devices.
Here is a list of possible HID Guids: http://msdn.microsoft.com/en-us/library/ms791134.aspx and use HidD_GetHidGuid as Roboto suggested
You'll need to use the HidP_ functions to check the hid report capabilities. Find out what capabilities (usages) are presented by the HIDPOS device, and check if those usages are present using HidD_GetPreparsedData(), HidP_GetCaps() and then HidP_GetValueCaps(and/or ..ButtonCaps, etc). A good place to look for examples is Jan Axelson's page. If the usages are present, then you've got the POS device. If not, then it must be the keyboard (assuming you've confirmed the device is attached.)