I am trying to use an OMNI from NFCRing to send a website to Apple and Android phones. I'm new to NFC so I don't really know what I'm doing.
So far I have attempted to build and install the full NDEF applet from OpenJavacardNDEF using version 20.01.23 of the GlobalPlatformPro API. Whenever I try to send ADPU commands to the card, however, the response is always 0x6D00.
Edit:
The APDU commands I have tried are 00000000, 00a4000c, 00a4000c02e10400, and 00b00150 all with the same response. I am trying to follow the protocol outlined in the applet's documentation but I may be doing something wrong; as I said I am new to this.
It looks like you are not doing the first step of actually selecting your Application, that protocol doc you linked only give you the details of how it can respond to each type of command once selected.
As you are trying to emulate a NFC Type 4 Tag I would read the NFC specification doc Section 5.4 is the most relevant.
But as a shortcut:-
The first ADPU to send is 00h A4h 04h 00h 07h D2760000850101h 00h
This is select the NFC Ndef App standard AID number (the D276... part)
If you look at the OpenJavaCardNDEF example client library on connect and performSelectApplet do just this.
Further APDU's are needed once the applet is selected, I would read the NDEF spec and or the example client library on which ones are needed to do what you want from the Tag.
Related
We are testing NFC tags for public places with simple URL.
I have a NXP Mifare Ultralight EV1 card. Writing and reading worked as expected. Then I put desired URL on the tag and locked it. (permanent write-protection).
I couldn't write to it after, but I could still "Memory format" the tag (with iOS app NFC Tools).
This removed the URL but since the tag is locked, it won't allow me to write to it again.
Does this mean, I can't trully protect NFC tags and anybody with this app can format them?
Is this card unusable now?
Should I choose different NFC type to prevent this?
SCREENSHOTS: https://imgur.com/a/qJmXCdJ
From the Capability Container it looks like a Tag and with the Capability Container security set to prevent write access.
So at the hardware level setting this type of write access is irreversible BUT this type of Tag does not seem to be listed as NFC compliant but it does seem to be compatible with the NFC Type 2 specification.
The NFC Type 2 specification does not specifically say whether this protection should be enforced at the hardware level or software level BUT as this Tag is not listed as NFC Type 2 complaint in it's datasheet then this might be the cause of the funny behaviour as it only seem to be NFC Type 2 compatible.
So to answer the question "I can't trully protect NFC tags"
I would not use Capability Container security access field ("Lock Tag") to prevent writing even on a compliant card. Instead set a Password on the Tag and set the Password to protect write access.
This achieves the same end goal of normal users not being able to write to the Tag and is definitely implemented at the hardware level and not not reliant on specification that this Tag does not says it is complaint with (and that might be implemented in compliant software). But is also reversible IF you know the password.
To answer the question "Is this card unusable now?"
Unknown but likely you will get varied results with different hardware and software so best to not use this particular Tag.
To answer the question "Should I choose different NFC type to prevent this?"
As you seem to be writing NFC Forum specification NDEF data to the Tag it might be wise to use a Tag that is fully compliant to the NFC Forum's Tag specifications as this might provide better compatibility with all NFC Forum compliant reading hardware. A similar Tag that is fully compliant is the NTAG 21x series.
Update
I think the main problem with that card is page for the "Capability Container" comes blank from the factory and therefore could be used for other purposes. Which means the card hardware cannot be certain that a value in that page means lock the card, therefore it cannot implement that locking in hardware.
Where as a compliant card must come from the factory with a correct initialised "Capability Container" therefore the card can guarantee the meaning of these values and correctly lock the card if the right value is set.
I'm looking for a way to verify that an NFC tag was set up by me. so I will be selling products with an NFC NDEF216 tag inside. I will be preprogramming the chip with an NDEF message and write protection using a private password I will keep private. Now I'm looking for a way to verify the chip actually came from me so the app I'm building will only work with my stickers.
Where can I write some sort of identifier on the NFC sticker? I tried overwriting the serial number but that seemed to fail. I cannot use the PACK verification because in some cases the protection will be disabled. I read the NDEF216 manual but did not really find a good way to do this
Update: I ended up writing a predifined bytecode in the last bytes of the writable storage and securing it with a private code. this way i can check for the bytecode in the storage, if the bytecode is present, the product is valid.
I want to send email using mailto tag with a single pdf file as attachment.
mailto tag opens the mail window with passed arguments like to and subject using:
Mail to Manager
But, attachments as a parameter isnt working.
Please suggest how to send pdf attachment in rhomobile.
Thanks
I think that you need to add the physical path to the PDF file for it to work (otherwise it may not know where the file is). This post on a forum says as follows:
The only problem is that this "mailto" command executes on the
client machine, therefore it tries to locate the attachment file by
a physical path, and not by a virtual path.
That is,
Using mailto:iudith.m#zim.co.il?subject=my report&body=see attachment&attachment="\myhost\myfolder\myfile.lis"
works ok, but only for local users (those connected to the same
network as the "myhost" machine).
Using mailto:iudith.m#zim.co.il?subject=my report&body=see attachment&attachment="http://myhost:myport/my_location_virtual_path/myfile.lis"
does not work, it does not recognize such a syntax as valid for
the attachment file.
In your case you would properbly need to look at this part of the Rhomobile docs (on file system access) to get the right path to your file.
EDIT:
From you comment I can see that you are trying to make it work on iOS (due to the iOS specific path).
In this discussion (from Rhomobile's Google Group) it is explained that mailto doesn't support attachments on iOS. It says as follows:
Don't know about other platforms, but you cannot do this on iOS. mailto: does not support attachments on iOS.
You can do it using a native API, MFMailComposeViewController.
This is a complete controller with UI, so you would have to write a Native View Extension to use it:
http://docs.rhomobile.com/rhodes/extensions#native-view-extensions
EDIT 2:
I've looked around and it seems that mailto doesn't support attachments on Android either. This is because Android supports the RFC 2368 mailto protocol, which doesn't include attachments. Here is a reference to the Android mailto url parser.
I would suggest that you do as suggested for iOS, write a native extension. I think this post would be relevant for you.
I'm developing Smartcard Driver using KMDF and SCardlib, I used the WDK Smarcard Sample as reference, I think I implemented all of the callbacks correctly except for CardPower and CardTracking. (My reader and card don't now support for now RESET commands and insertion of new card)
When I try to run test application that invoke SCardListReaders() I'm getting SCARD_E_NO_READERS_AVAILABLE. I used INF like the one of the sample with changes and I Create a Device Interface with SmartCardReaderGuid and I set the device type to FILE_DEVICE_SMARTCARD.
I don't know what else can I do, how can I debug this? any ideas?
P.S. Why the Header file for SCarLlib are no in the inc of WDK but in the sample directory?
I had to send a good ATR buffer according to the RDF_POWER Callback spec.
and also I had to implemented the RDF_CAR_TRACKING according to the sample.
I would like to programmatically access an STK (SIM Application Toolkit) application without using my handset. GSM modem and/or handset is attached to my PC via USB and/or RS232 connection. I'm looking to automate interaction with the STK application. To this end, I have no idea whatsoever regarding ways of accomplishing this operation. Any assistance will be highly appreciated.
Thanks.
This can be done by using AT commands like AT+STGI & AT+STGR.
AT+STGI is used to open the SIM menu & AT+STGR to select the menu. This can also be done prorammatically using Serial Port Interface to GSM Modem.
Please note, different manufacturers have different AT commands to access the STK functions.
And, not all of the devices are supporting the running of STK applications.
So far i've managed to get ZTE MF100 working:
After opening, the following commands come handy:
AT+ZSTM // select STK app (initialize, lists the available options in return)
AT+ZSELM=1 // select the first main menuentry (you will get the submenu options as return)
AT+ZSELI=1 // select the first submenu entry (you will get some response as well)
AT+ZINPR=2,1234567890 // this is a response, in my case i had to send a phone number. the first parameter means "numeric only", setting this to 0 will allow any characters (from the standard SMS charset)
AT+ZINPR=1,1 // this is a confirmation response (first parameter=1 means yes/no answer, second is the parameter, yes in this case)
AT+ZBK=0 // return to the main menu
You should open the /dev/ttyUSBx non-blocking, and poll the input for data, as the modem is not only answering your requests, but also sends status updates to your client.
While I have not worked directly with SAT/STK myself, I can give a little information to where you can read more. The wikipedia article contains some information and pointers and the GSM 11.14 standard is available here.
This discussion thread contains some practical information.
For Quectel follow this manual link