Loggen Sky v14 Unicam

[nicl45]

Hallo,

bin neu hier und habe im Moment ein kleineres Projekt gestartet. Ich möchte die serielle Verbindung zwischen Smartcard und Unicam Modul loggen und schauen, welche Befehle an die Karte gesendet werden, bzw. auch was die Karte antwortet. Mittels Arduino und selbstgebaute "Logger-Brücke" (Smartcard Halterung -- Kabel -- Smartcard PCB) ist es mir möglich zum Beispiel die Verbindung zwischen Oscam -- Smartmouse -- Smartcard mitzuschneiden und auch vernünftig auszuwerten, bzw. geloggte Daten mit den Daten die das Log ausspuckt zu vergleichen. Probiere ich jedoch das gleiche mit dem Unicam Modul bekomme ich nur falsche Daten. Ich habe schon verschiedene Baudraten ausprobiert, aber werde nicht schlau aus dem was ich bekomme. Hat vllt. jemand eine Idee, wo der Unterschied zwischen beiden Verbindungen liegt? Ich habe auch schon versucht den ATR bei 9600 Bauds zu loggen, was mir nicht gelungen ist (vllt. gab es in dem Fall keinen ATR?!?!)

Mit freundlichem Gruß
Niclas

 

[nicl45]

AW: Loggen Sky v14 Unicam

Ich konnte mein Problem selber lösen. Habe die ungefähre Baudrate ausgerechnet, nachdem ich die Frequenz des CLOCK Signals mit einem Logic Analyzer herausgefunden habe. Das Unicam Modul clockt mit 5,995 MHz und die Baudrate ist 16115. Konnte mit den Daten schonmal das ATR loggen.

 

[nicl45]

Auch wenn es vielleicht keinen interessiert schreibe ich meine Erkenntnisse nach und nach hier auf. Wenn das stören sollte, kann man sich ja melden

Nochmal die genauen Bitraten:

Init Baudrate (ATR): 16129 bps

Working Baudrate(Commands): 64516 bps


Falls jemand Fragen zum Loggen mit einem Arduino oder einem Logic Analyzer haben, kann er sich gerne melden.

 

[Radix2k]

Was du vorhast ist mir klar, nur die Ausführung ist, sagen wir mal Abenteuerlich, das kann man schon daran erkennen, das du zwei Unterschiedliche Geschwindigkeiten zum Einlesen der Daten brauchst.
Rüste deine "Logger-Brücke" mal mit einer RS232 Schnittstelle aus und stell mal auf der Leseseite:
BaudRate = 9600
DataBit = 8
Parity = keine
StopBit = 0
ein, dann sollte das auch funktionieren.
Der ATR wird nur nach einem SmartCard Reset ausgegeben, den kannst du durch ziehen und stecken der SmartCard ereichen, oder durch kurzeitiges ändern der RTS-Signals.
Ohne das erst der ATR erkannt wird und anschliessend gleich die eintrudelnden Bytes mitgeschrieben werden, ist da alles ein totgebohrenes Kind.

 

[nicl45]

Vielen Dank für deine ausführliche Antwort! Zwischen meinen Posts lag über ein Jahr. Ich habe es letztes Jahr schon geschafft alles zu loggen, hatte es nur nicht hier gepostet. Deshalb jetzt nochmal eine kleine Zusammenfassung:

Zu meinem Aufbau: Unicam Modul -- Smartcard Platine -- Sky v14

Mit dem Arduino greife ich nur das VCC, RST und I/O Signal ab. Sobald VCC und RST High sind fängt der Arduino an bei 16139bps das ATR zu loggen. Sobald das ATR angekommen ist werden die restlichen Daten mit 64516bps geloggt.

Die Bitraten lassen sich mit der Frequenz des CLK Signals (Unicam: 6MHz) und mit den Daten aus dem ATR berechnen. In den Spezifikationen wird die Bitlänge als ETU (elementary time unit) bezeichnet. Es gibt eine "init etu" und eine kürzere "work etu". So kommen auch die verschiedenen Bitraten zustande.

Das Unicam Modul verwendet einfaches UART mit 8 Datenbits, 2 Stop Bits und 1 Odd Parity Bit, während sich die Sky v14 an die Spezifikationen nach ISO7816-3 hält und eine längere Guardtime einhält.

Des Weiteren werden die Daten invertiert und die Bitfolge wurde umgekehrt (1->8, 2->7, 3->6, usw.). Dies nennt man Inverse Convention.

Beachtet man das alles, erhält man das ATR und die korrekten Daten. Um die Signale besser zu analysieren lohnt sich auf jeden Fall ein Logic Analyser.

Bin offen für weitere Anmerkungen/Antworten


Gesendet von iPhone mit Tapatalk

 

[Radix2k]

Das mit dem umkehren(invertieren) der eingelesenen Bitfolge kann ich nicht nachvollziehen, der SeasonLogger gibt die korrekte Reihenfolge aus, die Karte/Cam gibt die aus so aus, das da muss nichts invertiert werden.
Keine Ahnung ob du bei deinem Arduino alle Daten erst in einen Buffer schreibst und dann das letzte Empfangende Bit als erstes wieder ausliest, normal ist es jedenfalls nicht, das die Daten invertiert werden müssen.

 

[nicl45]

Die Bitfolge für 0xD0 die über die I/O Leitung gesendet wird lautet:

0010 1111 entspricht 0x2F

nach dem Invertieren
1101 0000 entspricht 0xD0

Wenn man 0xD0 per UART sendet oder empfängt wird die gleiche Bitfolge gesendet, aber es wird das LSB als erstes betrachtet. Nach ISO7816 müsste aber das MSB als erstes betrachtet werden. Daher kommt die Umkehrung der Bitfolge zustande.

Wenn man nun mit dem Arduino die Standard UART Implementierung nutzt, erhält man für 0xD0 den Wert 0xF4. Wenn man bei 0xF4 die Bitfolge umdreht erhält man 0x2F und nach dem Invertieren dann 0xD0. (Online-Tool zum umkehren und invertieren:

Sie müssen registriert sein, um Links zu sehen.

)


Interessant ist, dass Oscam auch eine Standard UART Implementierung nutzt, um mit der Karte zu kommunizieren. Zumindest wenn man eine Easymouse benutzt. Entsprechender Code:

Spoiler: Aus atr.c -- Z. 65

    /* Check if ATR is from a inverse convention card */
    if(atr_buffer[0] == 0x03)  // Readers of type R_MOUSE need this in case of inverse convention cards!
    {
        for(pointer = 0; pointer < length; pointer++)
            { buffer[pointer] = ~(INVERT_BYTE(atr_buffer[pointer])); }
    }
    else
    {
        memcpy(buffer, atr_buffer, length);
    }

Spoiler: Aus atr.h -- Z. 130

#define INVERT_BYTE(a) ( \
                         (((a) << 7) & 0x80) | \
                         (((a) << 5) & 0x40) | \
                         (((a) << 3) & 0x20) | \
                         (((a) << 1) & 0x10) | \
                         (((a) >> 1) & 0x08) | \
                         (((a) >> 3) & 0x04) | \
                         (((a) >> 5) & 0x02) | \
                         (((a) >> 7) & 0x01)   \
                       )
#endif