I would like to get a Bluetooth tracking device such as TrackR, Tile, Chipolo, ... and write my own app to detect my devices on a Windows 10 Mobile device. Are they encrypted in some way so that only their app can use them?
Can anyone point me in the right direction for doing that? Or tell me that it's impossible.
Detection is independent of encryption.
Let us call the main device with which other devices should be detected the "Central", and these other devices "Peripherals".
Every Peripheral that wishes to be detected has to send advertisements. There are several advertising modes; without going to much into detail, these different modes are for allowing the peripheral to be discovered, or to be connected with, or both.
All these advertisements are unencrypted, so any device can "see" and understand these advertisments. A Central just has to go into scanning mode; in this mode, the Central listenes for any advertisements it can detect. After finishing the scan, all found devices are presented in a list. There is no encryption here; encryption only comes into play after two devices have connected and at least one devices demands encrypted communication. But this is not necessary for finding and identifying devices.
Note that the only information you can get without connecting is the advertisement data (and possible some additional scan response data). Typically, a short device name or identifier is part of the advertisement data to allow for identification of the device type. If the device implements the Device Information Service, each information there can also be read without encryption (but you have to connect and discover this service first). Most devices will want the Central to know their name, type and purpose, so typically that information will not be encrypted.
Related
while facing problems with a C# BLE connection I've digged deeper in the Bluetooth low energy Connection part.
Here I'm not shure if I understand this part 100%.
In my case I want to connect to a device that requires bonding to start datatransfer otherwise I reiceive the right amount of Bytes but only zeros.
My application somtimes works and I receive the expected values, sometimes I only receive zeros and sometimes I get an error "System.ArgumentException" in mscorlib.dll and my app crashes.
Before I start Changing my Code I want to be shure that I understand the Connection part right.
With BLE I can do bonding, pairing and connect.
Bonding means in general the same a pairing. Encrytion keys are exchanged and in case of bonding, the keys are saved permanent and are resused for future sessions between two specific devices.
Pairing keys are only valid for one session.
https://eewiki.net/display/Wireless/A+Basic+Introduction+to+BLE+Security
Based on this link, Bluetooth uses an AES suit.
So for me, these two Options are clear( of course in case that I understood them correct).
So now I've read that it is possible to get a connection without bonding or pairing since a Windows Creators update.
I understand that there is no key exchange and based on my knowledge on AES can't be used.
Is a communication with using just a Connection between two devices really completely unsecure or am I missing something?
Thank you
That is correct, without pairing/bonding the BLE link is unencrypted and all data transferred back and forth can be read easily using a sniffer. On the other hand, if pairing/bonding is used, all data transferred back and forth is encrypted and cannot be read using a sniffer unless the encryption key is used at the sniffer end as well.
For more information, please see Bluetooth Specification, Version 5.0, Vol 3, Part H, section C.2 (Authentication and Encryption).
I hope this answers your question.
I would like to automatically test my application that sends push notifications.
I would like to be able to get (or generate) a token from Apple/Google for both Android and Apple devices that will be accepted by Apple's or Google's server and making the notification sent to my tester-program.
i.e, I am running my program (lets call it A) to test some server. The tests are relatively complex and involve a lot of network communication. I am testing the server as a black box, I cannot mock anything. I want to simulate a phone with program A that opens the client application and registers for push notifications. Then, I want to be able to see these notifications received on program A. Everything should be done in code, and not depended a real device.
Is this even possible? Does Apple/Google allow this type of test? I've read that the Android simulator is capable of receiving notifications as long as it has an active Google account on it, which is fine. Can this be simulated without the overhead of an Android simulator? Can it be done for Apple's iStuff ?
Push Notifications in Mavericks iOS Simulator: It seems you can use the iOS simulator to test push notifications, but I get it that you do not want to use a the simulator nor a device.
What you are asking for should not be allowed by Apple, as it means non-Apple devices would be allowed to register for push notifications. Per https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW12, "APNs generates a device token using information contained in the unique device certificate. The device token contains an identifier of the device. It then encrypts the device token with a token key and returns it to the device." Thus, in order to create the desired token, you need a unique device certificate -- in other words, a real device or iOS 8 simulator. If you are trying to test on a single "device," perhaps you could forge one or copy from a real device, but I am sure that is against Apple's policies.
I have a device which i have connected to my laptop. This device connects to computer using serial port, however my laptop doesn't have a serial port so i have added a connector to the serial cable to convert it to USB. Now i can see it in Device manager
But here you can see, i can just see the information about the converter not about the device. Why is it so? How i would be able to know about the device?
But the device software shows that it has detected it.
My purpose to get the information is, i want to know the information of the device manufacturer and its ID.
For this i have used software like: Device Monitoring Studio and Advanced USB Port Monitor. But the information they provided is just about the Serial to USB converter not about the device.
Below is the snapshot of the information i am getting from these software:
Please help me finding the manufacturer of that device.
Main Aim: This will help me to loop through all the ports and check which one is the right port, so that i can recognize that my device is connected to which port.
Serial ports are an I/O port design that dates from the stone age of computing. Used for example back when Dennis Ritchie typed in the source of the first C compiler on a teletype. The electrical interface is very simple and the chip required to generate signals is not much more than a glorified shift register. In particular it doesn't has the dedicated embedded processor that a USB device needs. Nor has it any kind of protocol to have a device identify itself. Albeit that a standard exists for modems (the Hayes AT protocol).
Accordingly, serial devices are not plug-and-play devices. And there's no way for the computer to figure out what kind of device is on the other end of the cable.
I have a USB device that enumerates with a different interface, VID, PID and serial number when commanded to do so, and I'd like to keep track of the physical device after this change occurs. My thought was to track it by its hub and port location.
The Win32_PnPSignedDriver class has a "Location" field that seemed perfect (e.g. Port_#0001.Hub_#0010), but it only contains the location of the device when the driver was first loaded. Plugging the hardware into a different port does not update that field.
However, the information is available somewhere because there is a "Location information" field under the "Details" tab when viewing the device via the Device Manager. Can this information be retrieve through WMI queries or some other method? Is there a better approach to solving this problem?
EDIT: I know this sounds like a strange scenario. The microcontroller in these devices contains a ROM that enumerates as a CDC device (i.e. serial port) and allows programming. During manufacturing, it would be beneficial to track a device as it changes between the manufacturer's ROM (unique VID/PID/serial number) and my custom firmware interface (different VID/PID/serial number).
I know it's been awhile since any activity on this answer, but I am working on a project that requires a similar functionality to this as well, and I can tell you it is indeed possible. As far as I can tell, it does require the DDK and PInvoke, there's no C# or WMI interface for this information. It requires opening the low-level USB root hub devices and directly sending driver IOCTL commands to them.
The good news is, Microsoft provides an example C++ application that completely enumerates all USB devices and shows exactly which ports they are connected to. That application is the USBView sample application.
I think you will find if you compile and run this application, you'll see that it shows you exactly where your device is plugged in, and if you plug any device into that port, it shows up in the same place. Perhaps it might be easier if you create an unmanaged C++ DLL that provides a few calls your C# application can use to get the information it needs.
It has this to say about the EnumerateHubPorts() function in its code:
Given an handle to an open hub and the number of downstream ports on
the hub, send the hub an IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX
request for each downstream port of the hub to get info about the
device (if any) attached to each port.
To give an idea about everything this requires (everything must be enumerated starting at the top, even if you're only interested in one port), here are the comments listed at the top of the enum.c file in the code:
/*
This source file contains the routines which enumerate the USB bus
and populate the TreeView control.
The enumeration process goes like this:
(1) Enumerate Host Controllers and Root Hubs
EnumerateHostControllers()
EnumerateHostController()
Host controllers currently have symbolic link names of the form HCDx,
where x starts at 0. Use CreateFile() to open each host controller
symbolic link. Create a node in the TreeView to represent each host
controller.
GetRootHubName()
After a host controller has been opened, send the host controller an
IOCTL_USB_GET_ROOT_HUB_NAME request to get the symbolic link name of
the root hub that is part of the host controller.
(2) Enumerate Hubs (Root Hubs and External Hubs)
EnumerateHub()
Given the name of a hub, use CreateFile() to map the hub. Send the
hub an IOCTL_USB_GET_NODE_INFORMATION request to get info about the
hub, such as the number of downstream ports. Create a node in the
TreeView to represent each hub.
(3) Enumerate Downstream Ports
EnumerateHubPorts()
Given an handle to an open hub and the number of downstream ports on
the hub, send the hub an IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX
request for each downstream port of the hub to get info about the
device (if any) attached to each port. If there is a device attached
to a port, send the hub an IOCTL_USB_GET_NODE_CONNECTION_NAME request
to get the symbolic link name of the hub attached to the downstream
port. If there is a hub attached to the downstream port, recurse to
step (2).
GetAllStringDescriptors()
GetConfigDescriptor()
Create a node in the TreeView to represent each hub port
and attached device.
*/
Did you try SetupDi?
You can use the SetupDi class of API function to get the information from DeviceManager.
The "Location information" under device manager is the exact same string you've gotten through WMI.
Have you considered that when the device is plugged into a different port, instead of updating the metadata with the new location, Windows creates a new driver instance and new metadata. Try filtering the Win32_PnPDevice object instances for just those that are currently plugged in, and I think you'll find the current location information.
For example, if I move my USB mouse to a different port, there's a copy of the mouse associated with the old port still listed under Device Manager, it's just hidden by default. See http://oreilly.com/pub/h/3105 for instructions to view these disconnected devices. Or run the following from an elevated administrator command prompt:
C:\Windows\system32>set devmgr_show_nonpresent_devices=1
C:\Windows\system32>devmgmt
REF: "The Win32_PnPSignedDriver class has a "Location" field that seemed perfect (e.g. Port_#0001.Hub_#0010), but it only contains the location of the device when the driver was first loaded. Plugging the hardware into a different port does not update that field."
It does for me. However, just be sure to refresh (F5) the regedit app between port swaps or you won't see the change.
Here are some examples:
Port2 Hub2
Port2 Hub4
Port3 Hub4
A better Idea will be to use the Unique serial number of the USB device.
I'm in the brainstorming phase to develop a GPS car tracking system requested by a customer. I myself know the directions to build some GPS system to mobile phones and etc. But sincerely I don't know how to start in that project. That is the scenario:
1) The cars will get a device with a SIM CARD that will emit GPS signals.
2) My customer will in any place (home, work, etc) with a web connection will see in the map where the car is located.
For me, I have not problems at get the GPS data, convert to usable info and show the position in some map system (like Google Maps or MS Bing Maps, by example). My problem is, how I do to retrieve that "GPS Signal" from device in the car? I will need some kind of "Receiver Device" connected to a web server machine in order to my application to consume that data?
Most GPRS-enabled vehicle trackers can be configured to send the data periodically to a remote server. The protocol and the details of the connection will vary a lot between different manufacturers. However in most cases, you should be able to configure the tracking device with the IP address and TCP port of your server, and then you should set up an application at that endpoint that listens for TCP connections from the tracking devices.
The first thing you should check is the documentation of the tracking device. It should reveal all these details. The serious brands will even provide working examples and demonstrations.
You will have to do the following:
1) If device cannot access internet
a) Get co-ordinates from GPS device
b) Send these co-ordinates via SMS
c) Receive and decode SMS message at the SMS gateway you have to configure
to receive info from device.
d) Update the info on the application database or any other store you are using
e) Update the position on map with latest info
2) If device can access internet
a) Get co-ordinates from GPS device
b) Connect to application server (may be some service) and upload information
c) Update the info on the application database or any other store you are using
d) Update the position on map with latest info
Natively, there's no way for a stock, off the shelf GPS device to "tell" you it's position. It requires some sort of back channel to communicate that information to you.
Your options are principally:
The device broadcasts it's GPS location to you. The most effective way to do this would be if the device can access a wireless network, to install software on the device that has it periodically broadcast its location.
You use a service provider that can provide the current GPS coordinates through some sort of API.
I believe your question boils down to, "How do I send data from a mobile device to a server?" It doesn't matter that the data is GPS data or that the device is in a vehicle. You just need to understand what communication capabilities your device has so you can figure out how to deliver your payload. The device can receive GPS satellite data, but that is one-way communication. You also said the device has a SIM card, so that means you've at least got voice network capability. Will the device/account have a data plan? If so, then that gives you GPRS/3G/some-packet-data and you would be home free. If not, then SMS is probably the next-best option, using a service like OpenMarket, for example. A last resort: your company can potentially license/develop a data-over-voice modem. For this route, it matters which country you are in. In the US, Airbiquity holds a lot of patents for this, and you'd probably have to license from them.
Our company uses the GenX Mobile devices in our truck fleet. They have a data connection that sends the raw CSV data to a UDP socket. I wrote a little listener app that gathers the data and puts it into a MySQL database.
If you have a droid, play with some of the apps on there, including Google's Lattitude, Where R U, and Mobile Defense. That'll give you ideas on what some of your options are, for apps that periodically report the location back up to the mothership. Have a look at WebSharing, for an excellent example of a webserver running within a droid, which lets you do things. That app is for file sharing, but it's not a stretch to imagine the interface (beautiful, btw), showing the car location, speed, heading, and with big "kill ignition" and "lock doors" buttons.
A point to consider is the communications channel used to pass the tracker position back to the data centre. In Europe the GSM network is well developed and can be used (SMS or GPRS) to pass the position data. However there are large roaming charges to be considered if the application is intended to follow a vehicle across international boundaries. In other countries (USA, Canada, Africa, Asia) the terrestrial infrastructure is not so well developed or uses a different transmission system (CDMA rather than GSM) requiring a different modem device.
An alternative, actually pretty price comparable with GSM, is to use satellite comms as the back channel. These are available either using Iridium or Inmarsat services and work globally, in remote regions without mobile phone coverage and without any roaming charges as the unit crosses borders.