This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Tom Schouten tom at zwizwa.beHi 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 :)