It is possible to know others NFC TAG ID when we used to the APK & TAG each phones.
For example,
Phone A and B try to tag. Then Phone A can know Phone B's NFC TAG ID (4 Bytes - HEX).
But I wanna know how to know my NFC TAG ID on my phone. Not used other phones.
If you know any other information, please give me your advice on that.
A phone does not necessarily have a fixed anti-collision identifier ("NFC Tag ID", as you call it). For instance, it could have an anti-collision identifier, that is randomly allocated on every activation (e.g. external HF field is turned on, phone is turned on, etc.) It could also have one or even multiple immutable anti-collision identifiers (e.g. from one or more secure elements).
This depends on several factors:
Is a secure element attached to the NFC controller in that phone?
Is the NFC controller configured to expose an attached secure element to the outside world?
Is the phone in card emulation mode or in passive peer-to-peer mode (or in a combined anti-collision phase for both modes)?
Does the NFC controller expose exactly one card-emulating entity (e.g. a secure element or the host controller) directly to the outside world or does it combine one or more emulating entities using NFCEE routing?
Etc.
As you mention "APK" I'm guessing that you refer to the Android platfrom (though you refused to answer my question on that). On newer Android devices (particularly those that support Host-based Card Emulation) and on Android devices that do not use card emulation at all, the anti-collision identifier (UID) visible to the outside world is typically not static and changes either on every activation or on every reboot of the device (some exceptions seem to exist). Particularly, with NFC peer-to-peer mode, the standard mandates the use of a per-session random identifier. Thus, the UID would not be of much use in those typical cases.
In general, Android does not provide any API to retrive the currently used anti-collision identifier from within the device. Usually, the random identifier is created within the NFC controller, so the Android system would not even know about it.
With regard to immutable IDs of secure element chips, vanilla Android does not contain public API to access secure elements, so the same applies to any identifing information of such secure elements.
Related
As far as I understand the USB devices introduce themselves by sending a device descriptor to the host which uses the information embedded in the descriptor to find and load the right driver/drivers. What I don't understand is why the drivers need the configuration, interface, endpoint and string descriptors from the device. I know the descriptors describe the device as a whole e.g. number of configurations, interfaces, endpoints, types, the size of the packets, the purpose of each byte in the packet etc. Why can't the drivers include this information from the start? Why does the USB device hold this information?
I guess the main reason is because it was designed that way. The designers could just as easily have gone the other way as you say.
Possibly more helpfully, I can think of a few reasons why they did decide on it this way:
Consider the context in which USB came about. PC peripheral connectivity was a mess. You had serial (UART) ports, PS/2 keyboard & mouse, parallel ports in various modes (e.g. ECP and EPP), game port & MIDI, the various SCSI variants, etc. Most of these did not allow for self-describing devices in a standardised way, demanding custom drivers for each type of device, and mostly manual driver loading. Device descriptors alone would mostly solve the problem of selecting the correct driver, but not necessarily the issue of needing a custom driver for each device.
Various standard device class specifications (e.g. HID, audio) define their own class-specific descriptors for communicating device variations to the standard driver. For this reason alone the generalised descriptor mechanism is useful.
Composite devices in their present form would effectively not be possible without standardised interface descriptors. You'd presumably have to make each composite device act as a hub with multiple devices attached.
Many (most?) standard device class specifications mandate a certain minimum number of endpoints where the standardised protocol is implemented, (e.g. bulk-only USB mass storage defines 1 bulk input and 1 bulk output endpoint) while devices are free to add more for vendor-specific extensions, or…
…future expansion of the standard device class or USB standard itself while maintaining backwards compatibility both ways (old driver/new device, new driver/old device). Think of UASP devices that fall back to regular bulk-only mass storage transport.
While not strictly necessary for making all those things happen, making devices self-describing in this way does seem to have been a success overall.
I tried searching around, but couldn't come up with much on the topic of this.
Is there an API or code within various Security API's that would allow some sort of passcode locking mechanism to enable whenever a device is connected (by Bluetooth, etc) and disable whenever said device is paired with the phone? An interesting concept I had thought up earlier today but can't seem to determine a method available for this.
The concept is pretty much this: if the phone is close enough to be connected over Bluetooth to the device (would be something like a smartwatch or other wearable computing) then the phone is on you and passcode entry can be disabled. However, when the device is not found by the iPhone, there is a physical distance between the two devices and the phone should lock up and not allow entry. This could even be some form of superficial lock mechanism on some apps (which exists already) that could activate based on this proximity awareness. This method is meant to failsafe by being a "lock first, then check" mentality that is paired to a specific address of the wearable computing. This could, in theory, be hacked, yes, but for general usage allows a user to have a no-maintenance method that can save some passcode entries from time to time should one find it annoying, but still want it's security potential.
Again, this idea is based on the assumption that said device connecting to your iPhone that the phone itself is searching for is physically latched to you somehow.
Thanks and I appreciate any sort of input or direction.
The SDK provided along with NFC reader does not work and we are not able to write data / tag using the Tools available with SDK. The main issue is that the data written using another tool does not remain in the device for permanently. When tag is scanned using Android device, reader gets clear and we have to to write data again.
I have checked and tried instructions from https://github.com/fkooman/nfcip-java/blob/master/nfcip-java/doc/ACR122_PN53x.txt but it does not work.
So, we need help to understand what command is needed to keep data(tag) in Reader even if it has been unplugged from the computer. The reader needs to be working in emulation mode and should provide tags.
I know this is old but ranked in google so...
The ACR122U does not have any memory so it cannot save any state. You need to use it as you mentioned - writing to the device on each use.
Hope it helps someone.
First of all, the ACR122U was mainly designed as a contactless smartcard reader and not as a card emulator. However, it is possible to do host-based card emulation (HCE) with this device (see How to card emulate with ACR122U-A9). But note that there are issues with some versions of the ACR122U (e.g., see The PN532 configured as target has been released by its initiator).
Nevertheless, all this is host-based card emulation. So the ACR122U only acts as the contactless front-end for emulating a tag (or contactless smartcard). It's the host (the computer) to which the ACR122U is connected to that performs the actual emulation.
Thus, the ACR122U is not a stand-alone device that you could program to act as a tag. You always need an application running on the computer that is connected to the ACR122U (via USB) to perform the actual emulation.
I know CFUUID is generated from MAC address and a few other stuff. So is there anyways to get the MAC address back from CFUUID?
We have a few bluetooth devices and all the user knows is the last 3 parts of the MAC address which is written on the device. So we wanna give the user and option to select the right device. On the iOS side, looks like all we have the the CFUUID. So is there's a way to convert the UUID back to mac address?
Or even better would be if there's a way to get a peripheral's MAC address directly instead of UUID, but doesn't seem like that's possible
Thanks
Well, as you might have learnt from the comments to your question, the answer is clearly: NO. It is not possible (practically) to get the seeds that generated a particular UUID. Provided that in fact the algorithm that generated your UUID did used the MAC Address of your device to generate it, and I guess you cannot guarantee that it is the case for the UUID generator you use, unless you have access to the UUID Generator code or algorithm (UUID Version 1 probably?) and it is not a opaque operation to you (Immediately defeating the very purpose of the uuid generation algorithm).
While you clearly are onto something when you say that the generation of a UUID might use the MAC address of the device, other components like timestamps, hashing, UDID (iOS Devices) and so on. The fact is that the MAC Address, could be just one of many factors used to generate the UUID so if you were to spend a lot of computing power into trying to deconstruct it out of a big sample of UUIDs generated by the same system under the same conditions; We will probably be talking about a quantum computer wasting computing power trying to explore as many combinations as particles in the observable universe so you get a MAC address that you may as well get as a characteristic from a Bluetooth peripheral if you like, and incidentally defeating the purpose of having a UUID in the first place, once more.
On the other hand, further to what somebody commented on your question: the reason you find UUIDs so boring, building on top of the previous paragraph idea, is so you can avoid collisions: Generating duplicates not just coming from the ones generated by your computer but from all the other ones generated by every device out there every moment of the day (to authenticate requests, create string index keys in a database, or identifying services and characteristics) so your cool service or characteristic named:
AAAAAAAA-BBBB-CCCC-DDDD-EEEEFFFF6666
does not get confused with another cool foo service or characteristic with the same UUID.
In general, for more information check wikipedia or just the Core Bluetooth Programming Guide, form the developer portal. It is still under NDA so you have to be a registered iOS Developer with active developer program credentials to read it.
I was looking for a way to deploy platform-independent, static configurations of BLE devices. I was getting discouraged (Apple's UUIDs are +/- meaningless, and the MAC/BDADDR which can be obtained on most/all other platforms is not accessible from CoreBluetooth). Fortunately, I noticed that the "Device Information Service" profile (0x180A) contains a "System ID" attribute (0x2A23) which encodes the device's unique MAC/BDADDR address. I don't know if it is mandatory for a BLE device to expose this service, however.
there is a way to get mac address for ios device. but only works on ios8 and later. no private api .https://github.com/Baoge2012/MacAddressLibDemo
I want to send some Text plus a image from one iphone application to other iphone app but restriction is I should not use a web server in between communication,Is there any way to fulfill it ?
Details: There are two independent devices and could be far enough say out of network. My requirement one app adds some text with a image and sends it to another iphone which can be at any long distance , and the app installed in another iphone will read that info and image into itself.
Actually there is a solution that meets your needs — and that fits to bbums answer:
Create a HTTP-Server on the iPhone, using cocoahttpserver. than you will ask some webservice like whatismyip.com for your public ip. with this your iPhone can be connected worldwide.
But very likely ur wifi-network is not forwarding your port to the iPhone. Ash.
And even if: Now it gets difficult. How to publish your ip from one phone to the other? hmmm... — I got it: I will exchange the information in a centralized space! In the web!
... wait — that would be a Webserver.
You see: Without any kind of server in the Web the users would need to exchange ip manually and have full admin power and knowledge about the local network.
So IMHO bbums answer is the only way to go.
PS: I am working with http server running on iPhones. In local network that works great, especially with bonjour. And you can use them over distance network — but only with reconfiguration of your router — something you shouldn't force your user to do
There is far from enough information to provide a specific answer.
two apps on two different devices?
are the two devices on the same network?
are the two devices both on WiFi?
do you need the user to receive a notification or something if the app isn't running?
If on same device, you can define a custom URL handler in the destination app and then openURL: in the source app to pass the data over. Encode your image and text into the URL, but be careful of size limitations.
If on different devices, there are many possible solutions, but answering the above questions will be critical to actually knowing what solution is appropriate.
Given your comment -- two apps, different devices, arbitrary networks -- then you are going to have to have some kind of server in between. Note that the recently added Game Center does have the ability to rendezvous two users, but it has a very particular user experience that may not be appropriate to your needs.
I would suggest that you investigate using push notifications to notify the receiving user of the availability of content. As for moving the content between, no direct connection is possible and you will have to have some kind of store-and-forward server in between. And, yes, a web server is going to be the easiest possible solution simply because HTTP is ubiquitous these days.
If there's no network of any kind available, but both parties have amateur radio licenses, then hooking the two devices up to HF packet radios might work.
THIS is super EASY.
I would code up some software that can turn data into modem signal, like the good old dial up modem. The device would actually make those annoying buzzing sounds.
You get the phone number for your friends nearest landline and call him.
He places his iPhone near the phones receiver in listen mode and you connect to his phone using your audible modem.
Bingo, via the power of sounds you have sent data which is decoded on his device and all for the very cheap price of a phone call, there are pretty cheap these days especially if you use Skype.
Easy Way (relatively speaking)
A way two apps on different networks can communicate without setting up a web server of some sort is as follows.
Use an existing third party storage system like DropBox.
Each app would need the login and password for your DropBox. Then both apps can read and write files that the other app can see.
An existing app that does this is a shopping list app called ShopShop.
The app on my phone and my wife's phone both link to the same DropBox account and the app keeps the shopping list synced up when one of us adds something to the list.