How to revive a misconfigured JCOP card

Question

I've got a JCOP card. Have issued an erroneous command to modify it's ATR. The horror is the card appears to not to return an ATR at all. Now that the card is responding in a Windows app:

<code>

    SCardConnect()  ERROR: The chip card is not responding to a reset.

</code>

using

<code>

    SCardConnect(... SCARD_SHARE_(SHARED|DIRECT), SCARD_PROTOCOL_RAW, ...);

</code>

Failure with either SCARD_SHARE_...

I found here:

https://www.mail-archive.com/[email protected]&q=subject:%22Re%3A+[Muscle]+How+can+I+use+SCARD_PROTOCOL_RAW+with+IFD_HVERSION_3_0%3F%22&o=newest&f=1

that for SCARD_PROTOCOL_RAW the wincard.c is using IFDControl_v2 instead of IFDTransmit.

Please tell me if it worthwhile to write a linux app based on pcsc-lite doing the same task?
I want to somehow issue 2 commands:
1. 00A4040010 [Transport-Key] (OPEN the card)
2. 00F00000 (BOOT the card)
These shall definitely reset the ATR so that i will resurrect the card!

Does anybody know another way to reset such a card?

Answer 1

If you have a contactless or dual interface card, try a contactless reader, where the ATR mess should not affect ability to open a connection to the card.

Answer 2

Understand that the main purpose of the ATR aside the historic bytes is to tell a PC/SC reader how to communicate with the card. When you insert a card into a card reader, the first thing the reader see's is the ATR, and it uses the ATR string to auto-negotiate the the communication protocol (T=0 or T=1), voltage, and frequency. This auto-negotiation is based off of the first 4 bytes, if any of these settings don't meet the smart cards chips capabilities it can not respond to the reader correctly and the communication can not happen, ie., the readers LED will blink erratically and give up trying to communicate after about 10 seconds (time based of the reader). To directly answer your question, if you put your card in this situation the reader doesn't know what to do, your card is bricked because it can no longer talk to it.

Now, if you have a reader that doesn't haven't auto-negotiate and you can manually commutate to the card in the state you put it in, then yes with the right commands you communicate with it.