15 Dec
2011
15 Dec
'11
11:13 p.m.
Hi Holger,
ATR of that card from a pcsc reader:
Reader 0: Gemalto GemPC Twin 00 00
Card state: Card inserted,
ATR: 3B 16 95 D0 00 45 F7 01 00
seems to be much shorter than usual ATR I've seen, but _all_ o2-cz and
o2-sk, postpaid, prepaid have that same ATR (since like 2-3 yrs old till
few months ago - meaning bought from o2).
wasn't so sure where to stick the hex-dump so I've put it into main.c,
process_usb_msg, diff is below just in case you need to be sure about the
exact location.
trace i got is attached, it seems some of the APDU data are getting marked
as part of ATR with SIMTRACE_FLAG_ATR flag and since then all the data
don't make sense to the parser anymore (imho).
Cheers,
Lukas
diff --git a/host/main.c b/host/main.c
index 4fbac8d..377868a 100644
--- a/host/main.c
+++ b/host/main.c
@@ -92,6 +92,7 @@ static int process_usb_msg(uint8_t *buf, int len)
switch (sh->cmd) {
case SIMTRACE_MSGT_DATA:
+ printf("dump: %s\n", osmo_hexdump(payload, payload_len));
/* special treatment for ATR */
if (sh->flags & SIMTRACE_FLAG_ATR) {
printf("ATR ");
On Thu, Dec 15, 2011 at 10:48 PM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On 12/15/2011 10:24 PM, Lukas Kuzmiak wrote:
- I've put one printf() into the apdu_split_in method, it seems the
buffer is
somehow getting scrambled from the beginning, it
shows something like:
Hi,
so let me claim the issue is in our split method... could you generate the
hexdump of the bytes added? we could then feed APDU split ourselves. The
other
part would be, do you have a PCSC Card reader? you could send us the ATR as
reportede by pcsc_scan.