Develop Bugs

SDIO

Does anyone know if our phones support SDIO. Would be nice to have when they come out with sd cards with NFC support.

Check your battery. You already have NFC.

Whaaa? Sprint Galaxy SII has NFC? According to every blog I've read, that not right. Am I wrong or is it hidden or something? Anyways it would still be nice to have SDIO for any future upgrades

I am in the wrong sub forum.
lol, my bad.

[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.

NFC spoofing for a *certain* Portal using game

i know precious little about the nitty-gritty of RFID or NFC stuff, but i'm wondering if there's such a thing as an RFID or NFC spoofer (emulator) that works at the standard nfc frequency of 13.56mhz, and uses the iso 14443 standard.
i'm wondering if it's possible to spoof those sky-landers figures, which use nfc. it's currently impossible to write one figure onto another because of access restrictions on the first little block in the rfid tag. and I'm not aware of any commercially available generic RFID tags that have *quite* the same hardware as the figures.
I believe the sky-landers use MiFare Classic tags, and have a locked block 0 (or UID), in that block 0 is the code which says which character they are.
is it in principle, possible to "project" a fake MiFare tag from an nfc equipped phone, also with a fake UID?
for that matter, are there any breakout boards that can do this, like an arduino shield?

*BUMP*
I'd also like to pull this off with my G-Nex...

The breakout board I use is from Adafruit.com which at the moment is hooked up to a raspberry pi. You could theoretically spoof a tag if you will. But I don't follow the logic to do so. I think what you want to do is more like cloning and siphoning. Check over on the Kali Linux forums, new version of backtrack they are working on something that does just that. I read a little into it about how they were basically bumping into people at a conference or getting in range of someone with there phone out texting or not paying attention and we're able to do just that.
Sent from my SAMSUNG-SGH-I747 using xda premium

Osbor said:
i know precious little about the nitty-gritty of RFID or NFC stuff, but i'm wondering if there's such a thing as an RFID or NFC spoofer (emulator) that works at the standard nfc frequency of 13.56mhz, and uses the iso 14443 standard.
i'm wondering if it's possible to spoof those sky-landers figures, which use nfc. it's currently impossible to write one figure onto another because of access restrictions on the first little block in the rfid tag. and I'm not aware of any commercially available generic RFID tags that have *quite* the same hardware as the figures.
I believe the sky-landers use MiFare Classic tags, and have a locked block 0 (or UID), in that block 0 is the code which says which character they are.
is it in principle, possible to "project" a fake MiFare tag from an nfc equipped phone, also with a fake UID?
for that matter, are there any breakout boards that can do this, like an arduino shield?
Click to expand...
Click to collapse
In theory one is able to emulate a NXP MiFare Classic card using an Android device. However, the firmware of the NFC chip is programmed to produce a different UID with each transmission, therefore the new firmware for the chip would have to modified to produce a static UID. If you want to learn more of the capabilities of the NXP NFC chips used in most Android devices, navigate to NXP's website and there is plenty of info.
From The Q, Of Course
live the life you love, love the life you live

NXP Controller HCE for Google Wallet

Decompile the NFC applications and libraries to gain control of the NFC HCE controller and enable true Tap and Pay abilities for AOSP based ROMs.
All files NFC related are here: http://www.tinozplace.com/NFCProject/
Within this zip: http://www.tinozplace.com/NFCProject/NFC_HTC1.zip are the files from the Google Play Edition's Stock rom. This one of the phone's that the NXP stack works properly. But ONLY in the "Stock" rom from Google.
Currently we need to reverse engineer/decompile the JNI CPP files to get them inserted in AOSP based ROMs like CM.
If you'd like to become a developer in this project please let me know via PM.
XDA:DevDB Information
NXP Controller HCE for Google Wallet, a App for the No Device
Contributors
abuttino
Version Information
Status: Testing
Created 2013-12-17
Last Updated 2013-12-17

Hi!
I just have a Nexus 4 which has the Broadcom chipset inside, so please excuse if I am completly wrong here. On the Nexus 4 I can use HCE perfectly with cyanogenmod 11 (as the Broadcom drivers are all there in the source tree).
But I had the impression that the NXP drivers also are there:
Here the jni sources for NXP for the "com.android.nfc" package (which should end up as "Nfc.apk" on the device)
https://android.googlesource.com/platform/packages/apps/Nfc/+/android-4.4.2_r1/nxp/jni/
And here the lowlevel libnfc for NXP (the broadcom one is named "libnfc-nci"):
https://android.googlesource.com/platform/external/libnfc-nxp/+/android-4.4.2_r1/src/
Isn't that what you are looking for am I completly wrong here?
Kind regards,
john

Tony, i'd totally be willing to help out if i knew what i was looking for :/ I really want this to get figured out and wish i knew more about programming. Let me know if there's anything a guy with 'basic' knowledge can help out with

androcheck said:
Hi!
I just have a Nexus 4 which has the Broadcom chipset inside, so please excuse if I am completly wrong here. On the Nexus 4 I can use HCE perfectly with cyanogenmod 11 (as the Broadcom drivers are all there in the source tree).
But I had the impression that the NXP drivers also are there:
Here the jni sources for NXP for the "com.android.nfc" package (which should end up as "Nfc.apk" on the device)
https://android.googlesource.com/platform/packages/apps/Nfc/+/android-4.4.2_r1/nxp/jni/
And here the lowlevel libnfc for NXP (the broadcom one is named "libnfc-nci"):
https://android.googlesource.com/platform/external/libnfc-nxp/+/android-4.4.2_r1/src/
Isn't that what you are looking for am I completly wrong here?
Kind regards,
john
Click to expand...
Click to collapse
Those have always been there and have been for years. The problem is that when HCE was added to AOSP - it was only added for Broadcom (NCI) chipsets. On the NXP side of things, only stubs were added.
Actually, libnfc-nxp appears to have at least SOME HCE capability (and has for quite some time) - but packages/apps/Nfc is completely missing HCE as anything but "do nothing" stubs.
There are closed-source implementations of NXP HCE on the Google Play Edition HTC One and Xperia Z Ultra, but no open source implementations for non-GPe devices.

Thank you for clarification! :good:
I wasn't aware of this fact. It's a sad decision of Google not to to release the source for both chipsets then.
Just for my personal interest: how did this work for phones like Nexus S back in days of cyanogenmod 9?
I remember the guys behind NFCproxy and SimplyTapp recommending phones like the Nexus S because the SimplyTapp HCE patches for cyanogenmod 9 only work with NXP chipsets (so I regretted to have a broadcom chipset at this time).
So how did this happen that we now have full HCE support on broadcom but not on NXP? (I understand that the 2011 nxp patches were just a hack, and may be of no use for today's situation)
How the things change...
edit: @Entropy512: Ah ok, I just read your Google wallet related posts on Google+ (which I should have done before) now I understand the situation better..

hi
thanks you

androcheck said:
Thank you for clarification! :good:
I wasn't aware of this fact. It's a sad decision of Google not to to release the source for both chipsets then.
Just for my personal interest: how did this work for phones like Nexus S back in days of cyanogenmod 9?
I remember the guys behind NFCproxy and SimplyTapp recommending phones like the Nexus S because the SimplyTapp HCE patches for cyanogenmod 9 only work with NXP chipsets (so I regretted to have a broadcom chipset at this time).
So how did this happen that we now have full HCE support on broadcom but not on NXP? (I understand that the 2011 nxp patches were just a hack, and may be of no use for today's situation)
How the things change...
edit: @Entropy512: Ah ok, I just read your Google wallet related posts on Google+ (which I should have done before) now I understand the situation better..
Click to expand...
Click to collapse
That's the thing that REALLY mystifies me - The Tapp guys claim they worked with Google on HCE.
However, there isn't a single commit in the history for Google HCE that comes from anyone at Tapp, the architecture of the solutions is VERY different, and last (but not least) - the Tapp guys exclusively supported NXP NFC chipsets (Up until the Nexus 4, almost nothing had a Broadcom/NCI chipset and the Tapp patches were written before that), and Google is completely missing NXP HCE support...

azreark1 said:
Tony, i'd totally be willing to help out if i knew what i was looking for :/ I really want this to get figured out and wish i knew more about programming. Let me know if there's anything a guy with 'basic' knowledge can help out with
Click to expand...
Click to collapse
We really can't do anything until the code is decompiled. If you know people that can help, that is always a good start
Sent from my Nexus 7 using Tapatalk

Entropy512 said:
That's the thing that REALLY mystifies me - The Tapp guys claim they worked with Google on HCE.
However, there isn't a single commit in the history for Google HCE that comes from anyone at Tapp, the architecture of the solutions is VERY different, and last (but not least) - the Tapp guys exclusively supported NXP NFC chipsets (Up until the Nexus 4, almost nothing had a Broadcom/NCI chipset and the Tapp patches were written before that), and Google is completely missing NXP HCE support...
Click to expand...
Click to collapse
Yager, right?
Sent from my Nexus 7 using Tapatalk

What about just tearing the NFC stack out of a NXP chipset's ROM?
I really don't see why this isn't possible.

abuttino said:
What about just tearing the NFC stack out of a NXP chipset's ROM?
I really don't see why this isn't possible.
Click to expand...
Click to collapse
Because it's binaries, not source.

Weird. If I take the NFC APK from the Sony GPe and resign it with platform testkeys (so it'll work on a self-built AOSP firmware), along with the Sony GPe's libnfc and libpn544_fw - Wallet STILL does not respond to payment terminals on my Oppo N1.
Won't be able to look at the logcat from my last attempt until tomorrow.

The oppo has NXP? That is kind of odd, I would figure that they'd put it together with a working wallet
Sent from my Nexus 7 using Tapatalk

I have the ability to decompile the files. Can someone point me to the needed files and I shall see what I can do.
Sent from my XT926 using xda app-developers app

They should be in the first post on this thread
I'll be on top of this tomorrow
Sent from my XT926 using Tapatalk

This is what i've decompiled so far. Ill continue to post what I find as I go.
https://drive.google.com/file/d/0BweamVOxcuOmV0YtYVJZVUl1clU/edit?usp=sharing

Theoretically, if we just ported this GPe ROM for our own devices, wouldn't that work?

Entropy answered this question about 4 posts up
Sent from my XT926 using Tapatalk

Borderpatrol1987 said:
This is what i've decompiled so far. Ill continue to post what I find as I go.
https://drive.google.com/file/d/0BweamVOxcuOmT08yN3JMSWljeE0/edit?usp=sharing
Click to expand...
Click to collapse
Can you put this on pastebin.com?
Sent from my Nexus 7 using Tapatalk

abuttino said:
Can you put this on pastebin.com?
Sent from my Nexus 7 using Tapatalk
Click to expand...
Click to collapse
File is to big for pastebin.