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?