Cardreader auslesen mit CT-API

[Guido R.]

An der Firmware kann es (noch) nicht liegen. - Die Zusendung einer eGK durch die Gematik steht noch aus. Daher teste ich derzeit nur an der KVK. Deren Spezifikation sollte inzwischen wohl jedes eHealth-Terminal unterstützen.

Hab zwischendurch auch SAD und DAD als pByte definiert. Gleiches Problem

Gruß
Guido R.

[Klaus01]

Code:

typedef 
         char (*CT_DATA) (USHORT, UCHAR*, UCHAR*, USHORT, UCHAR*, USHORT*, CHAR*);

Wenn der Funktionskopf richtig sein sollte (habe leider noch keine offizielles PDF o.ä. mit den Headern gefunden), dann ist die Längenangabe zur Responsezeichenkette auch ein Pointer.
Die Längenangabe zur Befehlszeichenkette jedoch nicht.

Grüße
Klaus

[Guido R.]

Gem. Richtlinien der Teletrust ist der Aufbau der CT_Data wie folgt :

CTN IU16
DAD IU8
SAD IU8
LENC IU16
COMMAND Referenzadresse eines Feldes mit Elementen vom Typ IU8
LENR IU16
RESPONSE Referenzadresse eines Feldes mit Elementen vom Typ IU8

RESULT IS8

(IS8=Integer Signed 8Bit, IU8=Integer Unsigned 8Bit, IU16=Integer Unsigned 16Bit)

Quelle : http://www.teletrust.de/uploads/media/MKT1-0_T3.pdf

[Guido R.]

GESCHAFFT !

Kurz gesagt : Die Definition der CT-API nach Teletrust ist falsch (oder zumindest sehr unklar definiert).
LENR (s. vorherigen Beitrag) MUSS ein Pointer auf eine Word-Variable sein, da CT_Data in diesen Wert die eigentliche Länge der Antwort schreibt.

Somit ist eine funktionierende Definition für CT_Data wie folgt:

function(Ctn:Word; Dad:PByte; SAD:PByte; Lc:Word; Cmd:Pointer; Lr:Pointer; Rsp:Pointer):ShortInt;StdCall;

Gruß
Guido R.

[Assarbad]

Zitat von Guido R.:

GESCHAFFT !

Kurz gesagt : Die Definition der CT-API nach Teletrust ist falsch (oder zumindest sehr unklar definiert).

Warum? Klaus hatte doch den Prototypen geliefert:

Ich korrigiere mal den Lapsus mit der Aufrufkonvention:

Code:

char (*__stdcall CT_DATA) (USHORT, UCHAR*, UCHAR*, USHORT, UCHAR*, USHORT*, CHAR*);

Jetzt deine Version:

function(Ctn:Word; Dad:PByte; SAD:PByte; Lc:Word; Cmd:Pointer; Lr:Pointer; Rsp:Pointer):ShortInt;StdCall;
... und jetzt meine etwas mehr delphianisierte Version:

TFNCData = function(ctn: Word; var dad: Byte; var sad: Byte; lenc: Word; command: ^Byte; var lenr: Word; response: ^Byte): Byte; stdcall; Bei "dad" und "sad" scheint es sich ja nur um einen einzelnen 8bit-Wert zu handeln, während mit "response" und "command" jeweils ein array gemeint ist. Ich nehme mal an jemand der hier in den letzten Jahren Delphi benutzt hat kann das noch verfeinern (bspw. einen passenderen Typen als ^Byte).

Man merkt gleich daß das aus deutschen Landen kommt ... ... man könnte ja mindestens mal die C-Prototypen in den PDFs angeben oder am besten gleich einen normalen Header. Grausam sowas ...