Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility problems with NXP TagWriter #4

Open
martinpaljak opened this issue Jan 26, 2017 · 10 comments
Open

Compatibility problems with NXP TagWriter #4

martinpaljak opened this issue Jan 26, 2017 · 10 comments
Labels

Comments

@martinpaljak
Copy link

Reading works well. Writing with other apps like https://play.google.com/store/apps/details?id=com.mobiem.nfctool works OK. Has NXP changed it so that only their tags are writable?

@promovicz
Copy link
Member

I can confirm this. Not sure yet on the cause.

@promovicz promovicz changed the title Recent versions of NXP TagWriter fail to write Compatibility problems with NXP TagWriter Dec 24, 2018
@9500
Copy link

9500 commented Jan 2, 2019

I remember that I used to be able to use NXP TagWriter to read and write tags, and with the most recent prebuilt cap I can't write tags anymore.

I tried to download old prebuilt file (javacard-ndef-full-plain.cap from 3aa1672 ) and with that binary NXP TagWritter works again for me... I am able to write, overwrite and read tags. Erase does not work.

@gregorjohannson
Copy link

The inability to read/write tags seems to be connected to #10.
Using AID D2760000850101 for the applet allows writing with apps like https://play.google.com/store/apps/details?id=com.wakdev.wdnfc for example.

From ef212b7 the AID was changed in the buildfile.

@darconeous
Copy link

FYI: I've noticed that on recent versions of gp, I've had to use --create D2760000850101 instead of --applet D2760000850101 in order to get the correct applet name to be created.

@martinpaljak
Copy link
Author

@darconeous --create specifies the instance AID and that needs to be the NFC forum defined one. It used to be the default in the built cap, but was changed, as noted above. --applet, when used with --install selects a module from multi-applet package (or the module after a standalone --load).

@darconeous
Copy link

But nonetheless the README says to use --applet, not --create... Documentation bug? Or am I missing something?

@viktoriasee
Copy link

viktoriasee commented Jan 27, 2020

I can confirm it works with --create only.

@darconeous
Copy link

I think the issue that @martinpaljak was referring to when he filed this issue was different than the --applet vs --create issue. I'll file a new bug.

darconeous added a commit to darconeous/openjavacard-ndef that referenced this issue Jan 27, 2020
The README had incorrect instructions for the installation of the
applet, using the argument `-applet` instead of `-create`.

@martinpaljak [notes][1] the difference between the two:

> `--create` specifies the instance AID and that needs to be the NFC
> forum defined one. [...] `--applet`, when used with `--install`
> selects a module from multi-applet package (or the module after a
> standalone `--load`).

This change simply changes the instances of `-applet` to `-create` to
ensure that the installed applet is given the correct AID.

[1]: OpenJavaCard#4 (comment)
@darconeous
Copy link

I've filed #12 for the -applet vs -create issue, so this bug can track the original issue being described by @martinpaljak

@ckahlo
Copy link

ckahlo commented Jun 19, 2021

Hi together,

I tracked down the issue with NXP TagWriter and some chip configurations resulting in a crash of the NXP app.
There is some condition that leads NXP TagWriter to assume it is talking to a real / fully emulated MIFARE tag
and thus tries to communicate with wrapped native commands.

TagWriter crashes with a "WRONG_CLA" and sniffing the NFC connection reaveals an attempt of 90 60 00 00 00
to obtain the UID of the tag. As far as I can see this happens after application selection
(44 10 7F 5C 02 -> 00 A4 04 00 07 D2 76 00 00 85 01 01 00 <- 35 C0) and without a RESET, so it could be
handled by an applet.

EDIT: sorted the stuff a bit and realized there's an REQA sequence betfore 90 60 00 00 00 and after

44 0A 7F 92 03 -> 00 A4 00 0C 02 E1 04 <- 6D DB
44 08 7F 9A 02 -> 00 B0 00 00 02 <- 6B 7D
44 08 7F A7 03 -> 00 B0 00 02 0C <- 8E A3

--> REQA, UID masked with U1 - U7

44 03 7F B2 C2 E0 B4
44 01 7F B7 52

44 09 7F BB 93 70 88 U1 U2 U3 12 D7 FB
44 09 7F BB 95 70 U4 U5 U6 U7 AB 3C BA

47 03 7F BB E1 6F 00
44 04 7F BE E0 80 31 73
44 04 7F D7 02 60 16 4E

/edit

HTH & best regards,
Christian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

7 participants