Replies: 3 comments 3 replies
-
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Also, have a look at your hello world application code - how it should handle select commands and what it should return. If select returns error or throws, you should get 6999 response instead, not 6700 or 6a82 |
Beta Was this translation helpful? Give feedback.
-
|
My application code simply does this at the end of byte[] buffer = apdu.getBuffer();
buffer[0] = (byte) 0x69;
apdu.setOutgoingAndSend((short) 0, (short) 1);Indeed before I started having problems I was seeing |
Beta Was this translation helpful? Give feedback.
-
|
Also, get a better reader than this https://github.com/martinpaljak/NFC4PC/wiki/Supported-readers |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for pointing this out. I did some tests with Sometimes I get this: And other times I get this: In any case since the contactless readers are unreliable I'll use the ACR38U contactful reader moving forward. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I was playing with a dual-interface smartcard I obtained. I don't know a lot about the Java Card ecosystem and I'm mostly learning with the little information that is available online.
I successfully built uploaded a test applet using this javacard gradle template and I was able to communicate with it via APDU.
I decided I wanted to try making it default-selected, so in order to do that I added the
--defaultflag during installation, which didn't work (I don't remember the error, this was yesterday and I no longer have those logs). Reading StackOverflow threads I understood that "default selected" is what happens when you give the applet theCardResetprivilege, so I also added--privs CardResetand that didn't fail andgpp -ldid show that theCardResetprivilege was applied. I then added some code to theselect()method so it would be executed when the default applet was selected but nothing seemed to happen unless I explicitly selected its AID.That was yesterday. I went to sleep and tried again this morning to find out that I can no longer select anything on the card: any select over NFC returns
6A82. Having understood from the internet that the applet installation is performed by a "security domain" (which I still don't entirely understand what is) and having left open overnight a terminal window with some GPP logs from yesterday showing listings from before and after the permission change, I was able to figure out that the security domain AID isA000000151000000, so I triedgpp -ld -c A000000151000000. This also returns6A82over the contactful interface, but over the contactless interface it now returns6700(all other selects I tried seem to still return6A82)My uneducated guess is that my code inside
select()is throwing an exception and that's somehow messing everything up. I'm guessing this might be the case because earlier, before trying any of the default-selected/card reset stuff, I uploaded some buggy code that was throwing an exception inselect()and it was returning6A82as well.My questions are:
I saw #331 but that didn't seem to lead anywhere, and my card is not a SIM card anyway.
This is a
gpp -ldoutput from before I messed with--defaultandCardReset(01FFFF00DECAF4DD0102is my applet):This is
gpp -ldafter messing up with the privileges when the card still appeared to be working before I went to sleep:This is random stuff I'm trying right now while the card appears to be bricked:
try selecting what I think is the security domain
same as above but via NFC:
try selecting my applet:
try selecting the app that previously had the
CardResetprivilege:try to list applets:
Thanks for your time and for your great Java Card development resources, they are extremely helpful!
Beta Was this translation helpful? Give feedback.
All reactions