Develop Bugs

[APP] Microsoft Tags

Anyone used this software before? Sounds quite interesting and works on the HD.
http://www.microsoft.com/tag/

Works very well.
I loaded it up a few weeks ago when it was announced.
It starts fine and accesses directly the camera. It searches automatically for tags and then launchs internet to connect to the tag.

I installed it this morning and seems to work pretty well. However I haven't seen any websites or posters with that on it, so it might be a while before we are actually able to use the software.

I to have just installed the app. I like the look of it. I guess we'll just have to wait and see how long before it becomes of use to us.

So useless, why use MS Tags if a worldwide standard - Barcodes - exists already for years - and works on mobile phones with reader software. Just another attempt by MS to waste money.

Lucas0511 said:
So useless, why use MS Tags if a worldwide standard - Barcodes - exists already for years - and works on mobile phones with reader software. Just another attempt by MS to waste money.
Click to expand...
Click to collapse
My thoughts exactly. We have a GREAT 2D-barcode standard QRCode (and to some degree DataMatrix), that's already widely used (by delivery companies, postal workers, public transit companies etc. etc.) and supported, works in black&white and is an open standard (ISO/IEC) that anyone can implement free of charge (Denso Wave has chosen not to exercise it's patent, other than to limit the use of the trademark term QR Code).
Microsoft advertises the technology by comparing the size of the resulting code, naturally a four-color code is smaller than a 1-bit implementation, but 2D barcodes are used to store very little information (shipment ID, URL, phone number etc.), so that's just stupid.
The only interesting thing is the fact that Microsoft tags require less image quality to be scanned successfully, but I for one have never had problems with that even with older phones (sub-VGA cameras), let alone modern ones.
It's nice to see interest in physical interfaces to mobile web like these grow, but I really don't think Microsoft Tags bring enough improvements to the table to warrant using them over standardized technology.
Just my $0.2

Thanks for your insight, quality posting. Sad thing is that few consumers are motivated to use barcodes. Offering rebate through them, like virtual coupons, might be a way to change that.
If MS would truly innovate, they would work on something like this, social tagging:
http://tonchidot.com/index_info.html

I agree with most of the comments questioning the usefulness of this app.
I must admit to actually liking it a lot - works well, simple interface, grabs pictures with the crappy HD camera very well.
BUT, I have never seen a MS Tag in the wild yet, maybe in a few years when I've moved to an iphone (ho ho) ...

When I initially read this, I thought it was ground breaking. However, I was under the illusion that it was using OCR to read whatever you take a photo of to intelligently derive tags and therefore referals to websites.
However, the OCR is only based on Microsoft barcodes. This is a very limited market.
Yet, again Microsoft taking over the world but I sense this will fall flat on it's face.
The standard barcode workaround may work, but how many film poster's or bus timetables (for example) do you know that have a barcode ? This strikes me to be more about physical consumer products than anything else.

Having been using QR Codes for a while now, I must admit I think MS tags are brilliant.
So many cameras on phones struggle with QR Codes, but MS tags can be easily read even when out of focus. There are other things I like about the tag: the ability to track the geolocation of where it was scanned (opt-in basis by people running the tag reader). On their site they have detailed info about just how poor some HTC cameras are when passing streams of data over to other apps - makes for interesting reading!
What I absolutely despise about it is
a) the fact that there is no SDK for it and making up tags using the web site is NOT an option for anybody but the hobyist
b) the fact that MS hasn't clarified whether or not they'd be charging for it
c) I'm not comfortable in leaving all the tracking data in the hands of one company
QR Codes have the benefit of not needing to be printed in colour, but MS tag has the benefit of being read easier using mobile phones.
I don't believe QR Codes will disappear but I do believe MS Tags will be successful. I certainly belive that there's room in the market for it, PROVIDED MS doesn't charge for it.

[Q] Is it possible to clone an RFID card w/ GNEX's NFC?

Has anyone heard of using an NFC enabled device to imitate a RFID gate pass? My complex won't give me another one for my fiance. I thought I could copy it, and swipe my Gnex at the gate while my fiance use the proxicard HID.
I'm ignorant of the details of the two technologies, so this is probably impossible. Worth asking. Thanks

I would sure hope not. Sounds like that would be a pretty big security risk for companies that use such cards for sensitive locations.
Sent from my Galaxy Nexus using Tapatalk 2

It is possible I believe. I know for Bamboozle that the NFC wristbands had no security and I was able to get into VIP area with no problems.
I would imagine that it is likely since I doubt that their NFC security is high.

With Regards to cloning an NFC tag and an RFID card. No it won't be possible. You have mentioned two technologies that are similar but not the same. NFC and RFID work the same in theory, but at different radio bands. Think of it like ATT phones vs. T-Mo phones. Some PC adaptors can read/write both, but the GNex can't.
Second flaw is that you probably wouldn't be able to use the GNex itself to open the door. The much more likely solution would be to use the GNex to capture the info on the old tag and write it to a different tag of the same type.
Third, and this ties into what Self Righteos Banana said about the NFC wrist bands at Bamboozle, most places don't have high security on their NFC or RFID solutions, but the software isn't quite there for GNex to fully exploit this. We were able to read the wristbands and determine that all of them, VIP, 1 day, 3 day etc. etc. had the same info stored on the tag. They were relying on the site staff to visually identify the various wristbands as well as scan to see if they were genuine. With this, a little social engineering got us into restricted access. We weren't able to rewrite the wristbands completely without altering other bits yet though. One of us wrote Hello to an unused portion of the memory, but it wrote header info in adjacent bits, not zeroes. I assume this is based on protocols that the phone (or other NFC devices use). So we were able to read and write to the tags, but could not clone them. For that I think you would still need a PC until software catches up.
EDIT: Also since this is a question, I feel I should remind you to post it in the Q&A section and not general. Also there is an NFC Hacking subforum.

Thanks a lot for the valuable info. I'll hunt around in the NFC hacking section. Sorry about posting in the wrong forum. I won't make mistake again.

NFC-V (ISO/IEC 15693) tags

I have a bunch of blank NFC tags from Texas Instruments (about 40 in total) in varying sizes (both physical and storage-wise), shapes, and casings. While I'm able to read them on my Galaxy S3, none of the apps I've tried are able to write to them.
After some poking around, I determined that these are all NFC-V tags (ISO/IEC 15693 compliant), which are apparently not NDEF-compatible. While the Android OS supports them, it provides no functionality to interface with them other than transcieve (raw read/write). Lacking the knowledge to write my own interface app, I'm reduced to research, questions, and experimentation.
Does anybody have any experience using Android to write to NFC-V tags? If so, what were you able to store and how did you do it?

https://play.google.com/store/apps/...1bGwsMSwxLDEsImNvbS5ueHAubmZjLnRhZ3dyaXRlciJd
try this app, it might work for you.

Thanks for the reply. That's actually the first app I tried, and no matter what type of data I try to write, I get the following: ow.ly/c5ubE
I've been putting a lot of my effort into getting this (ow.ly/c5uaz) app to work since it specifies NFC-V and ISO/IEC 15693 compatibility, but I still can't get it to write any data (NDEF or raw). From reading up on NFC-V, I get the impression this may be an issue with one-bit vs two-bit addressing and the app assuming which it is wrongly, but I have no way to confirm that. That said, the source for that app is available for download from its developer here (ow.ly/c5uaR) if anybody is interested in picking it apart.

Aren't they locked?
I can't give you more clues as I've just started reading about NFC.

daniel_loft said:
Aren't they locked?
I can't give you more clues as I've just started reading about NFC.
Click to expand...
Click to collapse
Not that I'm aware. I can read them, and the access conditions allow writes. TI also advertises that they're shipped unlocked and unprotected.
Having done a fair amount of research since, it seems the issue is that NFC-V tags are not part of the NFC Forum standard, and there's no standard way to store NDEF data on them. Short of writing my own app with a proprietary method of doing so, I think the only option for those tags is to wait until NXP, TI, the NFC Forum, etc decide on a standard, then all the NFC Android apps update appropriately.
Fortunately, I've since gained access to the NXP Semiconductors samples ordering system, and their MiFARE tags are differently complicated but NDEF-formatable, so I'm making some headway.

rowanator0 said:
Not that I'm aware. I can read them, and the access conditions allow writes. TI also advertises that they're shipped unlocked and unprotected.
Having done a fair amount of research since, it seems the issue is that NFC-V tags are not part of the NFC Forum standard, and there's no standard way to store NDEF data on them. Short of writing my own app with a proprietary method of doing so, I think the only option for those tags is to wait until NXP, TI, the NFC Forum, etc decide on a standard, then all the NFC Android apps update appropriately.
Fortunately, I've since gained access to the NXP Semiconductors samples ordering system, and their MiFARE tags are differently complicated but NDEF-formatable, so I'm making some headway.
Click to expand...
Click to collapse
Hm, I belive that NFCIP-2 specifies something according to vicinity cards, but I don't remember what exactly. The main problem is though that the NFC chip of the SG3, which should be PN544 (not 100% sure, but I tihnk its the same as in the predecessor, and NXP didn't release PN547 yet) does not have the capability to write vicinity cards. I think there were datasheets on this though.

Damastus said:
Hm, I belive that NFCIP-2 specifies something according to vicinity cards, but I don't remember what exactly. The main problem is though that the NFC chip of the SG3, which should be PN544 (not 100% sure, but I tihnk its the same as in the predecessor, and NXP didn't release PN547 yet) does not have the capability to write vicinity cards. I think there were datasheets on this though.
Click to expand...
Click to collapse
Can you define "vicinity" in this context? If you're referring specifically to NFC-V, you may be on to something. If you just mean proximity cards in general, though, I am able to write to MiFARE tags. Furthermore, as I understand it, with the right software behind an NFC reader/writer, you can theoretically read/write just about anything that uses 13.56MHz, simply as a result of the way the active field works.
Additionally, you seem to be correct about the NFC chip in the S3 (see ow.ly/foV15), but according to the NXP spec sheet for that chip (ow.ly/foUYj), it should be able to read/write tags that meet the same ISO standards as my TI tags. Apologies for the shortened URLs; I don't have enough posts yet to post links and that seems to be the only way to get around it.

rowanator0 said:
Can you define "vicinity" in this context? If you're referring specifically to NFC-V, you may be on to something. If you just mean proximity cards in general, though, I am able to write to MiFARE tags. Furthermore, as I understand it, with the right software behind an NFC reader/writer, you can theoretically read/write just about anything that uses 13.56MHz, simply as a result of the way the active field works.
Additionally, you seem to be correct about the NFC chip in the S3 (see ow.ly/foV15), but according to the NXP spec sheet for that chip (ow.ly/foUYj), it should be able to read/write tags that meet the same ISO standards as my TI tags. Apologies for the shortened URLs; I don't have enough posts yet to post links and that seems to be the only way to get around it.
Click to expand...
Click to collapse
ISO15693 is the vicinity card standard (basicly the same as the other ISO14443 standard, but those ISO15693 cards have a bigger range up to several meters). Cards that can be read via NFC-V are vicinity cards / tags. Though I checked again, you are right, coming from the data sheet, it should be able to read and write them.
Btw, your idea to be able to read and write anything that uses 13.56MHz is to idealistic. There are many kinds of cards and standards with many different protocols (many of them are even proprietary, like Mifare Classic, Legic, iClass etc.) involved in this. These protocols are most of the time implemented on the hardware level. One of the reasons for that is the fact that there are also very strict timings cards, tags and reader have to comply to. Going up layers of software can be to slow in that case.
You can read most of the ISO 14443 A and B compliant cards for example, but Mifare Classic can only be read with phones that feature chips that implement the ISO 14443-3 A protocol. The PN544 can read Mifare Classic, because hes manufactured by NXP, the same company that holds the patents and rights of the Mifare Classic standard.

Damastus said:
ISO15693 is the vicinity card standard (basicly the same as the other ISO14443 standard, but those ISO15693 cards have a bigger range up to several meters). Cards that can be read via NFC-V are vicinity cards / tags. Though I checked again, you are right, coming from the data sheet, it should be able to read and write them.
Btw, your idea to be able to read and write anything that uses 13.56MHz is to idealistic. There are many kinds of cards and standards with many different protocols (many of them are even proprietary, like Mifare Classic, Legic, iClass etc.) involved in this. These protocols are most of the time implemented on the hardware level. One of the reasons for that is the fact that there are also very strict timings cards, tags and reader have to comply to. Going up layers of software can be to slow in that case.
You can read most of the ISO 14443 A and B compliant cards for example, but Mifare Classic can only be read with phones that feature chips that implement the ISO 14443-3 A protocol. The PN544 can read Mifare Classic, because hes manufactured by NXP, the same company that holds the patents and rights of the Mifare Classic standard.
Click to expand...
Click to collapse
Which leaves us pretty much back where we started.
As for my "WORKS WITH EVERYTHING" comment, you're absolutely right. I should have specified ISO14443/15693 (and even then my original statement would be wrong). Basically, I was referring to the fact that if you have the command set for something that operates on the 13.56MHz frequency, you can in theory write software to interface with it, as you can send and receive pretty much any raw data you want. However, you're right--there are plenty of 13.56MHz devices, both passive and active, that some active modules simply cannot communicate with.

One Tap NFC Business Card

Hey One Tap sent me one of their Plastic business cards with an NFC chip embedded, I like the approach they are taking of using a URI rather than trying to fit an entire vcard into 36bytes. What do you think, vid below:

I think that having only one business card isn't enough, not everyone has an NFC enabled device. In order to share your contact information, you'll still need to hand out your business cards from time to time.
I cant imagine that the feel of an plastic business card is a good one. It's like a drivers license or credit card.
And the price!!! 15$ for one card? Thats a lot. Believe me, they use the cheaper NFC chips, since they don't have enough memory to handle a whole vCard. All they do is to link to an URL, and there will be a online profile.
The idea to share contact details with a TAP is an illusion here. Who wants to search in an online profile eacht time in order to call someone? The idea should be to save them in your genuine contact list in your phones memory.
Same is right for Moo, they link to an online profile only.
If you want to see the cheapest NFC business cards on the market, but still these with the highest quality, check out the videos below!
www.tapmy.biz sells you thin paper NFC business cards, have a good feel (a real business card feel), store an entire vCard. it's 2$ a card and with quantity the price goes down. You can upload your own design or create your own design on the website by choosing from many templates :good:

My only complaint about TapMy is that they use Mifare Classic which isn't supported by the Nexus 4/10 as far as I know. Mifare Classic is the cheapest tags that support up to 1K data. The cheapest thing I can find for N4 is the NTAG203 which costs a little more than Mifare but only holds 144B.

OneTap Promotions
Hi Batou069, thank you for your comments, we always try to promote feedback from people as it helps us to recognise things that our customers think we can improve.
We completely agree that that there is still a huge market for paper business cards and will still be around for at least the next few years. This is an area of the company that we are currently working on and are looking forward to making these available in the near future. The decision to originally launch with a PVCA card is to be able to offer something different and original for people. There are many benefits for this, durability being a big one, but it also helps you to stand out in a crowded market, which we feel is the most important thing ever when networking.
We are sorry that we have not made it clear on our website that you can download an entire vCard with one tap once the profile has loaded. This is the primary button that your are presented with at the top of your page, but having a profile opens up the opportunity to share so much more. Clearly we have failed in bringing this across.
We are currently working on a brand new website and this is something that we will definately keep in mind whilst designing it, we also plan to include a short video that will show all our new and interesting features that you won’t get elsewhere. Once again thank you for your comments. You can keep updated with our progress via twitter @OneTapPromo and please keep an eye out for our new site coming soon.

General XDA Article: Google is changing how new Android 13 devices should store driver’s licenses

https://www.xda-developers.com/android-13-hardware-drivers-licenses/
February 16, 2022 10:26am Adam Conway
Google is changing how new Android 13 devices should store driver’s licenses​Carrying a wallet has become less of a necessity for me thanks to my smartphone and Google Pay, but there are a few cards that I can’t go without. A driver’s license would be one such card, though a digital driver’s license offers multiple advantages over the traditional ID card. You can’t lose it, you can wipe it remotely if your phone gets stolen which means you’re less likely to get your identity stolen, and you’ll have an easier time bringing it up on request. Google introduced the Identity Credential API in Android 11 for storing identity cards, though now it appears that devices launching with Android 13 will require additional hardware for storing digital driver’s licenses.
As reported by Esper, a recent code change suggests that chipsets launching with Android 13 must support the Identity Credential Hardware Abstraction Layer (HAL) at feature version 202201 or later. 202201 of the Identity Credential HAL introduces support for presenting multiple documents during a single transaction, such as simultaneously sharing your driver’s license and motor vehicle registration. Google can’t mandate that devices upgrading to Android 13 must support it, but new devices that launch with Android 13 will need to, as enforced through a test in the Vendor Test Suite, or VTS.
For context, the VTS is an automated testing suite that validates the vendor implementation is compliant with Google requirements. It consists of a set of testing frameworks and test cases, testing both the Android system’s core HALs and libraries, and the low-level system software such as the kernel, modules, and firmware.
The Identity Credential HAL enables the storing of identity documents in the device’s secure hardware, which is met by the inclusion of a Trusted Execution Environment, or TEE. This is a dedicated area of the main applications processor for executing sections of code in an isolated environment. Not many devices have actually introduced the Identity Credential HAL despite TEE implementations being widespread.
Interestingly, there’s also the Identity Credential Direct Access HAL too, though its implementation won’t be required. It essentially allows for direct access via NFC to the secure enclave that holds a user’s documents even when the battery is too low to boot the OS. This is only possible when the secure hardware features a CPU and storage device separated from the applications processor. Very few devices meet this criterion, and the only devices that currently implement the Identity Credential HAL itself are Google Pixel devices.
While mobile driver’s licenses are gaining traction across the U.S., Google intends for the identity credentials API to be generic and to hold other secure documents, too. Motor vehicle registration and vaccination records are two potential use cases. The TSA plans to begin recognizing mobile driver’s licenses as valid IDs for domestic travel soon, and at least 30 U.S. states have already issued or plan to issue them. We’ve already seen as well that with iOS 15, Apple announced that the TSA would accept its digital IDs for domestic travel.
There are obviously a ton of security concerns when it comes to storing personal identification on your smartphone, but Google is taking steps to make it as safe as possible. There’s definitely an upside to carrying your documents digitally instead of a physical card that can be lost or stolen, but additional hardware for storing those documents will go a long way towards convincing authorities to use the Identity Credential API when developing these applications.
Click to expand...
Click to collapse

That is impressively backwards. Digital means *easier* to steal than something physical. Regardless of what kind of nonsense hardware is associated with it, gooble's control over their blobware means that this kind of thing OPENS UP THE DOOR to MASS identify theft.
Speaking as a computer engineer.... NO EFFIN WAY.

96carboard said:
That is impressively backwards. Digital means *easier* to steal than something physical. Regardless of what kind of nonsense hardware is associated with it, gooble's control over their blobware means that this kind of thing OPENS UP THE DOOR to MASS identify theft.
Speaking as a computer engineer.... NO EFFIN WAY.
Click to expand...
Click to collapse
You're entitled to your opinion. I think probably 99% of the folks who regularly read in the P6P section already know your opinion on that because you feel a need to visit so many threads and repeat this, and even repeat similar or the same things in multiple threads one right after the other. Whether you're right or wrong, doesn't matter. If you could please resist the temptation to repeat it in my threads, I'd greatly appreciate it.
Maybe make a thread specifically for your purpose.
Thank you.

96carboard said:
That is impressively backwards. Digital means *easier* to steal than something physical. Regardless of what kind of nonsense hardware is associated with it, gooble's control over their blobware means that this kind of thing OPENS UP THE DOOR to MASS identify theft.
Speaking as a computer engineer.... NO EFFIN WAY.
Click to expand...
Click to collapse
Much more fun to give myself to Google and let the ecosystem work for me.
/half sarcasm

Scary stuff. This feels like the precursor to vaccine passports, and social ranking like China. Scan your phone to see if you are allowed to eat here.

roirraW edor ehT said:
You're entitled to your opinion. I think probably 99% of the folks who regularly read in the P6P section already know your opinion on that because you feel a need to visit so many threads and repeat this, and even repeat similar or the same things in multiple threads one right after the other. Whether you're right or wrong, doesn't matter. If you could please resist the temptation to repeat it in my threads, I'd greatly appreciate it.
Maybe make a thread specifically for your purpose.
Thank you.
Click to expand...
Click to collapse
These things can't be repeated enough.