does anyone happens to know how to use XFS API to update ATM encryption keys (such as 32 characters clear key pairs) ?
I have read CWA16374 documents but not sure how to use the API since there is some many commands involved (which command to call and how)
thanks a lot
Sadly CEN XFS standard is not covering all the aspects and at least some of the key manipulations needs to be done using the manufacturer specific APIs.
I only have experience from NCR crypto module, and it doesn't sound like you use one of those.
So you'll need to go through the Hardware providers manuals to get hang of it.
You need to use the msxfs.dll to access the XFS devices (in your case, I think this device will be PIN specification). All XFS devices works using the same API interface defined in msxfs.dll. You have a WFSStartUp command to start XFS Manager communication, a WFSOpen command to open a sesion with a specific device (The PIN in your case, a cash dispenser, a card reader, etc). Once you have access with WFSOpen, you need to execute WFSExecute or WFSGetInfo commands to access the device. For this you need the PIN API documentation (public in internet). This documentation describes the commnands you can execute using WFSExecute and WFSGetInfo XFS commands. There is a standard specification for each financial device type in the market. For keys, encryptions, etc, you have the PinPad device (a keyboard, key stored and cypher operations)
There are a lot of things to explain about it, but I think this would be a good starting point.
Here you have the starndard documentation:
https://www.cen.eu/work/areas/ICT/eBusiness/Pages/WS-XFS.aspx
Related
I am using WMI to monitor certain hardware metrics, and specifically, I am using WMIExplorer.exe to find WMI classes and their instances(link to WMIExplorer.exe download: https://www.bleepingcomputer.com/download/wmi-explorer/). When I try to retrieve instances of the Win32_Fan class within the Root\cimv2 namespace, I get 0 instances. I am wondering why this is, since I do have a fan in my laptop. Do some fans/pieces of hardware not support retrieval through the WMI interface?
Note that I also tried the "Get-WmiObject -query "SELECT * FROM Win32_Fan" command in PowerShell to confirm there are no instances; there was no output from this command. I am simply wondering if there's any cause of an instance not showing up other than the hardware simply not being compatible with WMI. Or are there alternatives to finding fan speed without downloading third-party applications?(I want to get the fan speed within a personal C++ program).
Win32_Fan instances are provided by Windows\System32\wbem\cimwin32.dll. If you disassemble it you will see that it reads SMBIOS data (specifically entries with type 27) to get fan device information. So having no such instances means your system manufacturer did not write fan device info into SMBIOS, which is part of ROM.
I am writing a C++ Linux userspace driver for a USB device using the C library libusb. I have two copies of the same device (same vendor ID and product ID) and would like to know how to handle this case.
Here are the possibilities I can think of:
libusb_get_device_list() returns only devices that are not currently in use
I can differentiate the used vs. unused devices using information of the device descriptor, using libusb_get_device_descriptor()
libusb_open() on the currently in-use device will fail, by returning either LIBUSB_ERROR_ACCESS or LIBUSB_ERROR
How should I deal with this? Which of the preceding options, if any, is the behaviour of libusb when dealing with many of the same devices? How can I differentiate between the in-use device and the idle one?
As #fiscblog said in his answer, "Identification is done via the device descriptor (use the serialnumber which should always be unique)". My problem here is that, in order to do so, the two drivers should communicate to know which instance is handling which device (using, for instance, a file), and I would like to avoid this. I also would like to avoid having to introduce multithreading and manage two devices with one driver, as I don't have the skills to do so in an efficient and well-controlled way (nasty race conditions ... !)
The correct handling is:
enumerate all devices (get device list)
identify the requested device and open it
Identification is done via the device descriptor (use the serialnumber which should always be unique), as you discovered yourself.
How to know if a device is in use?
If a device is open, the endpoints will be bound and configured for I/O. Therefore you cannot open it again but will get the error codes you mentioned.
According to the documentation on libusb_claim_interface():
Interface claiming is used to instruct the underlying operating system that your application wishes to take ownership of the interface.
so you should be able to call libusb_claim_interface() on each device and it should only succeed on the unclaimed one:
It is legal to attempt to claim an already-claimed interface, in which case libusb just returns 0 without doing anything.
libusb is written in C and follows the same basic general guidelines for accessing devices, file descriptors, streams, etc.
1 - Connect to de device
2 - Check the connection, if there's an error, inform and return
3 - There's no error!! Interact
Following this basic flow, the solution in your case IMHO is as simple as:
Identify the devices
Iterate througth them trying to connect until one throws no failure
do something
close
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 working on a hardware device that exposes itself as a Mass Storage device over USB.
When I plug in a typical USB key it gets attached in device manager as a Mass Storage device with the corresponding disk's removal policy set to Quick Removal.
When I plug in my device the removal policy however is set to "Better Performance". Note that in both cases no driver was installed (This is Windows' Mass Storage driver). Screenshot.
I've tried comparing all the properties on the device properties page to no avail. What am I doing wrong?
Sorry for answering my own question but upon furthur investigation these are the result:
Linux USB storage gadget driver does not support MODE_SELECT:
http://lxr.free-electrons.com/source/drivers/usb/gadget/file_storage.c?v=2.6.35
(Lines 1881 to 1889)
This causes Windows to behave as described above. Returning without an error without doing anything appears to correct this problem but I'm unsure if it is the correct behavior.
I would expect that the problem is that the standard Mass Storage driver is checking for a FAT-formatted partition-- finding one on the USB key it sets the policy to Quick Removal; and it doesn't find one on your device.
This document will get you where you need to be. Additionally, this SO link is also relevant.
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!!