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/.
Kevin Redon ml at mail.tsaitgaist.infoExcerpts 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?