apdu

APDU Write block commands on mifare classic

不羁的心 提交于 2019-12-06 07:30:41
I have been trying to write some data to my mifare classic cards. first I send these two commands which returns 90 00: Load Mifare Keys: FF 82 20 01 06 FF FF FF FF FF FF Authenticate: FF 86 00 00 05 01 00 01 60 01 now I can write commands to sector 0 and block 1 + 2 ff d6 00 01 10 14 01 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 ff d6 00 02 10 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 i mistakenly overwritten block 3 a few times rendering this sector unreadable it seems: if I send the command ff d6 00 04 10 I get return error 69 82 which i googled as authentication error do I need to

How to authenticate NTAG213 with ACR122U

旧巷老猫 提交于 2019-12-06 07:28:15
问题 I'm using an ACR122U reader with an NTAG213 card. The card is password (reading and writing) protected with the password 52 84 00 08 . What are the APDU commands I should run to authenticate the card and also to read pages 30 and 31 of it once authenticated? I know with the MiFare 1k I could load the password and authenticate a sector, but I'm not sure how authentication works with the NTAG213 cards with the ACR122U readers. 回答1: With the ACR122U you would need to send direct commands to the

Authenticating Ultralight EV1 with PC/SC reader

心已入冬 提交于 2019-12-06 07:20:06
问题 I have a problem trying to authenticate an Ultralight EV1 card using a PC/SC reader (specifically an ACR1222L) in Java. I'm able to write and read on an unprotected tag using the corresponding APDUs for ISO 14443-3 tags. However, I can't find a way to run the PWD_AUTH command since it is not part of the 14443-3 standard (or any native command for that matter). Is it possible to run this command (or any native command for that matter)? I have tried sending the following APDU {e0 00 00 24 07 1b

Android ACR122U NFC integration

纵饮孤独 提交于 2019-12-06 06:48:25
问题 See NFC reader "SELECT (by AID)" APDU is not routed to Android device on debugging and eventual results. TL;DR the reader might simply be defunct. I have ACR122U reader connected to my Android device. My final goal is to use another Android device in HCE mode to enable data communication between the devices. Currently I have a problem with integrating with ACR122U reader. I use lib acssmc-1.1.1.jar provider by the vendor. This is the code I currently have (omitting the example code of opening

Send more than 261 bytes to Java Card with Android NFC

ⅰ亾dé卋堺 提交于 2019-12-06 04:04:22
I want to send an APDU with a length of 1699 bytes via NFC (class IsoDep ) to a Java Card smartcard. I get the error java.io.IOException: Transceive length exceeds supported maximum My phone is a Samsung Galaxy S7. I use extended-length in my applet on the card. I have verified that the card supports extended length. I tested this via pyapdutool by sending an APDU with 4000 bytes to the card. I found that when I write this code, the result is false : final Tag t = (Tag) tag; myTag = IsoDep.get(t); boolean result = myTag.isExtendedLengthApduSupported(); I have this in my manifest: <activity

Sending Extended APDU to Javacard

谁说胖子不能爱 提交于 2019-12-05 18:23:43
I have a ACR38 samrt-card-reader and a number of Javacard [2.1.1] compliant with GP Spec [02]. As I know, there is two kind of APDU, Short-APDU [APDU with LC or/and LE shorter than 255 ] and Extended-APDU [APDU with LC or/and LE greater than 255 ]. is that right? We send Short-APDU in T=0 protocol and send Extended-APDU in T=1 protocol. is that right? I sent Short-APDU to my card successfully. [via GPJ , GPShell , OpenSC-Tool ]. And now, I want to know: 1: if I want to use Extended APDU, my card must support it? or my Reader must support it? or both!? or all the cards and all the readers

En-/Decryption output in Java Card + corresponding APDUs

余生颓废 提交于 2019-12-05 18:21:47
I'm new to the whole topic of Java Card and tried to look at a few code examples to get a better understanding. I found a sample for AES usage in the oracle forum but have a few problems with the following part: private void doAES(APDU apdu) { byte b[] = apdu.getBuffer(); short incomingLength = (short) (apdu.setIncomingAndReceive()); if (incomingLength != 24) ISOException.throwIt(ISO7816.SW_WRONG_LENGTH); //perform encryption and append results in APDU Buffer a[] automatically cipherAES.init(aesKey, Cipher.MODE_ENCRYPT); cipherAES.doFinal(b, (short) dataOffset, incomingLength, a, (short)

What is the meaning of 6E 00 when I send a command to a SmartCard

て烟熏妆下的殇ゞ 提交于 2019-12-05 09:27:41
I try to access a SmartCard via C++. I got already the Connection and the CardHandle. But when I send an APDU Command via SCardTransmit, i'll get 6E 00 as the answer from the card. No matter which APDU Command i send. Everytime 6E 00. For Example: FF CA FA 00 00 (Card's ATR - Answer To Reset) or FF CA FF 82 00 (Product name in ASCII) The same thing when i send the Command with an PC/SC Testtootl like "PC/SC Diag". Has anybody an Idea what the meaning of this Error-Code and how to solve the problem? Please help me !!!! ;-) According to ISO 7816-4 0x6E00 means "Class not supported". Are you

Android 4.4 hce (host-based card emulation) “processCommandApdu” apdu length

别来无恙 提交于 2019-12-05 04:36:05
问题 I've tested my Android Java application with Nexus 4, Nexus 5 and Samsung Galaxy S4 phones. In the test, the reader sends APDUs changing in length up to 252 bytes. Nexus phones receive APDUs successfully. On the other hand the Galaxy S4 phone can't receive APDUs which contain more than 128 bytes. It receives only the first 128 bytes of the sender's 252 bytes. How can I determine a device's maximum receivable APDU size? 回答1: Currently there is no method to find the maximum receivable APDU

Safe Max Java Card APDU Data Command and Respond Size

拟墨画扇 提交于 2019-12-05 00:36:44
问题 What is the recommended data field size in a Java Card APDU ? From Zhiqun Chen's Java Card Technology for Smart Cards: Architecture and Programmer's Guide book, it mentions that Le field allows a max of 255. Are we to interpret it as follow for the APDU Command: |<----------------------- 255 Bytes total ------------------------>| |<- CLA -><- INS -><- P1 -><- P2 -><- Lc -><---- DATA ----><- Le ->| Thus, if CLA, INS, P1, P2, Lc, Le are all 1 bytes each, we should assume that the we can safely