Hi List,
I'm running into the following command sequence in a Nexus One Android 2.3 phone:
C-APDU:80F20001FF (STATUS) R-APDU:6C12 (Incorrect Parameter P3)
After which the phone power-cycles the card.
I'm wondering whether this is is desired behavior, or if it's a bug in the new MITM code. Phone seems to reset the card quite often when in USIM mode. Running the card in SIM mode, this doesn't happen.
Cheers Tom
Excerpts from Tom Schouten's message of 2013-09-04 18:24:15 +0200:
Hi List,
I'm running into the following command sequence in a Nexus One Android 2.3 phone:
A bit of context might help. How is SIMtrace used in this experiment?
C-APDU:80F20001FF (STATUS) R-APDU:6C12 (Incorrect Parameter P3)
you used FF as P3 (length of expected data). if you don't know the length, you should put 00 (if I remember right), else you should put the real size of the expected data length which the card indicated previously (e.g. in the previous select response) because P2=01, you just want the name of the application, is that right?
After which the phone power-cycles the card.
That is weird. Can you check if it's a proper reset, or if the phone just powers down the card and start again?
I'm wondering whether this is is desired behavior, or if it's a bug in the new MITM code.
I can't comment on that, as I did not test the MITM code. How does it behave with the git code (where mitm is not implemented)?
Phone seems to reset the card quite often when in USIM mode.
Does this also happen without SIMtrace? If SIMtrace is used, can you see the freq and PPS procedure?
Running the card in SIM mode, this doesn't happen.
In SIM the previous command would not be accepted.
kevin
Hi Kevin,
On 09/04/2013 04:47 PM, Kevin Redon wrote:
Excerpts from Tom Schouten's message of 2013-09-04 18:24:15 +0200:
Hi List,
I'm running into the following command sequence in a Nexus One Android 2.3 phone:
A bit of context might help. How is SIMtrace used in this experiment?
As APDU forwarder using new MITM firmware.
C-APDU:80F20001FF (STATUS) R-APDU:6C12 (Incorrect Parameter P3)
you used FF as P3 (length of expected data). if you don't know the length, you should put 00 (if I remember right), else you should put the real size of the expected data length which the card indicated previously (e.g. in the previous select response) because P2=01, you just want the name of the application, is that right?
My conclusion also. However, this c-apdu is sent by the phone.
The cause of the reset is a bug in the APDU fw code which I just noticed. I was sending a procedure byte (copy of INS) back to the phone in response to 80F20001FF, which is not legal if the status code is 6xxx. Upon reception of this protocol error, the phone power-cycles the card.
Looks like this bug is more general. It might explain some other resets.
With workaround, the sequence sent by the phone is now:
C-APDU:80F20001FF R-APDU:6712
C-APDU:80F2000112 R-APDU:8410A0000000871002FFFFFFFF89030200009000
Thanks for your reply. Getting there.. slowly :)
Excerpts from Tom Schouten's message of 2013-09-04 23:38:29 +0200:
Hi Kevin,
On 09/04/2013 04:47 PM, Kevin Redon wrote:
Excerpts from Tom Schouten's message of 2013-09-04 18:24:15 +0200:
Hi List,
I'm running into the following command sequence in a Nexus One Android 2.3 phone:
A bit of context might help. How is SIMtrace used in this experiment?
As APDU forwarder using new MITM firmware.
C-APDU:80F20001FF (STATUS) R-APDU:6C12 (Incorrect Parameter P3)
you used FF as P3 (length of expected data). if you don't know the length, you should put 00 (if I remember right), else you should put the real size of the expected data length which the card indicated previously (e.g. in the previous select response) because P2=01, you just want the name of the application, is that right?
My conclusion also. However, this c-apdu is sent by the phone.
The cause of the reset is a bug in the APDU fw code which I just noticed. I was sending a procedure byte (copy of INS) back to the phone in response to 80F20001FF, which is not legal if the status code is 6xxx. Upon reception of this protocol error, the phone power-cycles the card.
Looks like this bug is more general. It might explain some other resets.
With workaround, the sequence sent by the phone is now:
C-APDU:80F20001FF R-APDU:6712
C-APDU:80F2000112 R-APDU:8410A0000000871002FFFFFFFF89030200009000
I think I've also seen this behavior where the phone doesn't know/use the length and expects the SIM to tell it using 67xx (xx!=00) (for SIM/USIM) or 6cxx (for 7816-4)
Thanks for your reply. Getting there.. slowly :)
is there a git somewhere where you put the code which I could have a look at later?
On 09/04/2013 06:27 PM, Kevin Redon wrote:
is there a git somewhere where you put the code which I could have a look at later?
https://github.com/zwizwa/at91work/tree/apdu_phone
entry points:
# device make -C at91work/usb-device-cdc-serial-project
# host cd at91work/src ; ./mim.py
( The CDC serial part is just a skeleton; USB control request code should be moved to CCID driver later. I'm still using a USB PC card reader for the card side. )
-
Kevin Redon -
Tom Schouten