What would be the best way to uniquely identify a specific Wear-device? I'd like to store a preference per device on the phone and thus need an identifier that is static. I would expect that the NodeId is assigned dynamically (and changes after each reconnect, or after each reboot, for example).
I am working with a couple of Sony SmartWatch 3 devices and needed to reset some of them to factory settings. It turned out that the NodeId changed quite significantly from a rather long one (such as 738eaa61-703a-4dcb-ae93-d1f326e0c6d1) to a relatively short one like ed806f56.
However, as long as I didn't reset the watch completely I did never experience a change in the NodeId and it should be a reliable value (after a reset, the Watch needs to be paired again with the phone anyway).
Related
First, I want to apologize. I am complete noob in this area and many of my thoughts are probably misleading.
I need to verify that a user of my app is on a specific place in order to be authirized to perform an action. I want to use NFC for this purpose. The user have to put his smartphone by a NFC tag in order to be authorized to perform the action. Easy but I need it to be reasonably hackerproof. It means that the NFC tag must be impossible to clone without physical damage to the plastics around the NFC chip. It also means that the NFC chip must not contain only static data. The NFC chip must contain an app, that can receive some data (cryptographic challenge) and signs them using secure built-in private key (which must be unreadable through NFC interface). When the user wants to perform the action, he will ask server for the challenge, then he lets the chip to sign it, and then he sends the signed challenge back to the server which will verify the signature using known public key. This should be achievable using NFC JavaCard. But do these NFC JavaCards actually exist? I wasn't able to find a company which would be able to produce such NFC tags for me. When I try to explain my requirements to a NFC tags producer he looks like he has never heard of NFC JavaCards. I have tried about 10 producers without luck.
Can a commonly available chip meet my requirements? I mean a chip from the Mifare familly. I suspect that Mifare DESfire might be able to meet my requirements, but I am not sure.
Feel free to respond with an advertisement, because relevant advertisement is exactly what I look for :)
I try to collect some useful facts:
NFC is a very broad term, just finding that on both sides does not ensure interoperability.
Any ISO 14443 (one of the NFC flavours) compliant smart card with crypto functionality should be usable. Note, that a card with native OS may be a viable alternative to a JavaCard, since the functionality to sign a random number is pretty standard.
Any smart phone sporting a NFC chip can address such a card in principle. Unfortunately this is strongly dependent on the OS of the smart phone, for Android the relevant class to use is IsoDep, which gives you the APDU interface. After triggering the "card enters field" event, then the app receives a handle, via which further communication can take place.
Real smart cards can't be cloned, since you are not able to dump them; especially keys can't be read.
Now some things to consider:
Your approach looks unusual, which might become a problem. (To have a portable card somehow fixed to a wall, just to get the location; so you know where somebody is, but not who? While I don't consider cloning to be an issue, you somehow must ensure destruction in case of a theft attempt, which may collide with the distance topic below.)
I don't see, where the server comes into play. If not involved in the authorized action, provision of a random number is not sufficient reason.
Asymmetric key operations have a comparatively high power consumption, and this power has to be supplied via the electric field. This severely limits the distance between card and phone and may even require direct touch. While a power supply of its own would solve the issue in principle, it is not what ISO-14443 was designed for.
Yes JavaCards do exist.
https://github.com/OpenJavaCard/openjavacard-ndef is a project makes these JavaCards to output standard NDEF messages (thought note issue 4 in that there example uses the wrong APDU but that is easily changed)
This project also give a number of cards it is fully working and tested for
ACS ACOSJ - fully working
NXP JCOP J3D040/J3D081/J2E145 etc - fully working
Both ACS and Cardlogic do cards (just google the model numbers)
e.g.
https://www.acs.com.hk/en/products/405/acosj-java-card-combi/
https://www.smartcardfocus.com/shop/ilp/id~707/j3a081-80k/p/index.shtml
The answer a was looking for is not a chip which runs a custom code. Although this might be possible it is definitely not the best way to achieve the target.
I was looking for a solution that enables strong authentication using NFC data. There might be multiple chips that offers this, but probably the most available chip is NTAG 424 DNA TT. It works like this:
The chip has a memory, which is not readable through NFC. Private key is stored there.
The chip has a read counter. It increments everytime the data are read through NFC.
The chip can generate an AES-128 signature of string UID (chip serial number) + counter using the private key in the inaccessible part of the memory.
The chip can dynamicaly inject the data above into a URL that is stored in the readable memory.
So the solution will be like (I am waiting for delivery of NFC tags right now, so I don't know for sure yet):
Read the tag UID (serial number) and the actual counter value (should be 0 on an unused tag)
Generate the key-pair
Load private key to the chip
Load some data (URL, eg: https://my.app/) to the chip
Store UID, public-key, last-counter on the server
Configure the chip to inject UID, counter, signature to the URL stored on the chip
When a client reads the data, they should contain required variables, eg: https://my.app/?counter=1&uid=ff:ff:ff:ff&signature=xyz. Then on the server:
Fetch stored info (public-key, last-counter) using uid as a primary key
verifies the signature
verifies the counter that must be > last-counter
stores counter as the last-counter
successfully authorized
Is anyone able to hack this without reading the hidden memory of the chip which would require physical tampering with the chip?
The context for this question is primarily Windows 7, though I've tried it on 10 as well.
I've built a 4-player composite joystick using the Arduino Mega 2560. It is a USB device composed of 4 HID Joystick interface, each with its own endpoint. Each joystick accompanied with its buttons shows up correctly in Device Manager as a separate HID interface. They are identified by a VID/PID/MI_# triplet correctly, with MI_# being the interface index (MI_0, MI_1, etc). Calibration also sees each interface as separate, with inputs correctly corresponding to each controller in their enumerated order (ie: the first one receives inputs from only the joystick at index 0). When I dump the Descriptors, they also look correct.
There are two issues:
1) Naming
Windows only reads the interface string from the first interface. According to the Descriptor dump, each interface should have its own string, going from "Player 1" to "Player 4". Windows 7 sees them all as "Player 1". Inspecting regedit, this may because Windows 7 only has one OEM Name per joystick device, and so only gets the one for the first interface. Am I stuck with this behaviour, unless I somehow get a resolution from Microsoft?
For some reason, Windows 10 calls them all "Arduino Joystick". I'm not sure if because I'm using the same Test VID/PID combo I got from an Arduino Joystick tutorial and Windows is just picking up the name that someone else has used for their device, or if it is concatenating my Manufacturer String with the interface type "Joystick". I'm not sure why it would do the latter, but if it's the former I'd prefer to block that look-up somehow.
I'd like to resolve both, but practically speaking I'm using Windows 7 mostly.
2) Mixed Inputs
I've seen this behaviour only with some applications, but unfortunately one of them is Steam, and the others may be due to Unity. It manifests differently, so I'm lead to believe it's due to there being no standard way for dealing with composite joysticks.
On Steam, in Big Picture mode when I try to add/test a controller, while it detects all 4 controllers (all as Player 4, I might add), it only accepts the inputs from Joy4 no matter which of the controllers I choose. After saving the config however, all the joysticks have the same mappings applied. This is actually good, as I can use any controller to navigate Big Picture mode, but I'm concerned it's symptomatic of other problems which I might be seeing in other applications.
In "Race the Sun", when manually configuring joystick controls (it says Player 4 is detected), it will interpret inputs from a single joystick as coming from multiple joysticks. Usually, two of the four directional inputs come from Joy1, while the two other come from another Joystick other than the one being used. Eg: if I'm configuring Joy2, it'll register inputs from Joy1 and say Joy3.
In "Overcooked", it allows a single joystick to register as 4 different players. Normally you'd hit a particular button on the controller you want to use to register as a player, but in my case if you hit that button on joy1 4 times, then 4 players will be registered. If you start the game like this, you end-up controlling all 4 characters simultaneously with one joystick. Interesting, but not the intended usage, I'm sure.
Both "Race the Sun" and "Overcooked" are developed using Unity, and I understand that Unity's joystick management is rather lacking. Overcooked at least is designed to handle multiple players though (it's a couch co-op game), so this probably has more to do with the composite nature of my controllers.
I should note that other applications have no problems differentiating between the joysticks. Even xbox360ce sees them as separate, and the emulation works on several Steam games, single and multiplayer. Overcooked is still getting the joysticks crossed even though I'm using xbox360ce with it.
The question I'm bringing to Stack Overflow is what could I do to improve how applications handle my joysticks? Right now I'm using the generic Windows game controller driver. Theoretically this should have been enough, but issue #1 shows that composite joysticks may not be an expected use case. Would driver development even have a hope of resolving the issue with the applications I mentioned above, as I don't see how the device would differ significantly in its identification. I'm hoping someone more experienced with coding for USB devices can offer some insight.
For what it's worth, my Arduino sketch and firmware can be found here.
I have found a solution for "Race the Sun" and "Overcooked".
"Race the Sun" may have expected my joystick to provide axis ranges from 0 to a certain maximum (eg: 32767). I had the firmware set up going from -255 to +255. While other applications handle this fine, "Race the Sun" may expect the more common 0-X behaviour (this is the range that a Logitech joystick of mine provides). After changing this, I was able to configure and play it correctly. I've also updated my GitHub project; the link is in the original question.
The problem with "Overcooked" was actually caused by a badly configured or corrupted xbox360ce installation. Somewhere in tinkering with the emulator I must have screwed something up, as I messed up games that were previously working. I solved it by wiping all its files, including the content in ProgramData/X360CE, and re-downloading everything and redoing the controllers. Now all my games seem to be behaving correctly.
This still leaves the problem with Steam. For some reason Steam doesn't remember my joystick configuration from reboot to reboot. For the time-being I've decided just to put up with the default joystick behaviour, but would like to sort this one out eventually, too.
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)
Lets say I have four beacons configured with same UUID , same major value and different minor values.Then I am monitoring the regions using only the UUID and imagine the a scenario where the four beacons overlaps with each other, assume when entering the store. Will I get four locationManager:didEnterRegion callbacks for each beacon or will it be only one ?
You will only get one. (Small caveat: iOS sometimes sends multiple callbacks, but this is rare, and can be considered a glitch in CoreLocation. These glitches have nothing to do with multiple beacons in a region being detected.)
Also note that you won't know which of the iBeacons is visible when you get the entry notification. To get the specific identifier, you will need to start ranging.
I have an HID device that is somewhat unfortunately designed (the Griffin Powermate) in that as you turn it, the input value for the "Rotation Axis" HID element doesn't change unless the speed of rotation dramatically changes or unless the direction changes. It sends many HID reports (angular resolution appears to be about 4deg, in that I get ~90 reports per revolution - not great, but whatever...), but they all report the same value (generally -1 or 1 for CCW and CW respectively -- if you turn faster, it will report -2 & 2, and so on, but you have to turn much faster. As a result of this unfortunate behavior, I'm finding this thing largely useless.
It occurred to me that I might be able to write a background userspace app that seized the physical device and presented another, virtual device with some minor additions so as to cause an input value change for every report (like a wrap-around accumulator, which the HID spec has support for -- God only knows why Griffin didn't do this themselves.)
But I'm not seeing how one would go about creating the kernel side object for the virtual device from userspace, and I'm starting to think it might not be possible. I saw this question, and its indications are not good, but it's low on details.
Alternately, if there's a way for me to spoof reports on the existing device, I suppose that would do it as well, since I could set it back to zero immediately after it reports -1 or 1.
Any ideas?
First of all, you can simulate input events via Quartz Event Services but this might not suffice for your purposes, as that's mainly designed for simulating keyboard and mouse events.
Second, the HID driver family of the IOKit framework contains a user client on the (global) IOHIDResource service, called IOHIDResourceDeviceUserClient. It appears that this can spawn IOHIDUserDevice instances on command from user space. In particular, the userspace IOKitLib contains a IOHIDUserDeviceCreate function which seems to be supposed to be able to do this. The HID family source code even comes with a little demo of this which creates a virtual keyboard of sorts. Unfortunately, although I can get this to build, it fails on the IOHIDUserDeviceCreate call. (I can see in IORegistryExplorer that the IOHIDResourceDeviceUserClient instance is never created.) I've not investigated this further due to lack of time, but it seems worth pursuing if you need its functionality.