Ein paar Hintergrundinformationen:
Zum Lesen/Schreiben von SLE4442-Speicherkarten verwendet meine Anwendung derzeit einen Omnikey Cardman 3021-USB-Kartenleser, eine Sumbsembly Smartcard API (externe dll), die in der Lage ist, CT-API-Aufrufe (an die dll von Omnikey gerichtet) zu verpacken, so dass ich die Speicherkarte in meiner c#-Anwendung lesen/schreiben kann. Das einzige Problem dabei ist, dass Omnikey nur eine 32-Bit-DLL ihrer CT-API bereitstellt. Ich fragte, ob sie eine 64-Bit-Version produzieren werden, aber sie konnten nicht belästigt werden.
Derzeitige Situation:
Um meine Anwendung 64-Bit-fähig zu machen, muss ich sie mit der Windows WinSCard API neu schreiben. Das Problem dabei ist, dass es im Internet keine konkreten Beispiele gibt, wie man das macht. Außerdem ist es fast unmöglich, an funktionierende APDU-Befehle zu kommen, aber ich habe es geschafft, zwei leicht unterschiedliche Versionen zu erwerben, die irgendwie funktionieren. Ich habe über viele Monate hinweg hundertmal danach gegoogelt, und mit dem, was ich mir zusammengesucht habe, kann ich endlich die SLE4442-Speicherkarte lesen. Aber ich schaffe es beim besten Willen nicht, dass das Schreiben funktioniert.
Der Code:
Ich werde nicht den gesamten Code in diesem ersten Beitrag posten (falls nötig, kann ich das später tun oder einen Link zum Quellcode angeben). Aber ich werde die grundlegenden Schritte skizzieren.
1) SCardEstablishContext
2) Abrufen des Lesernamens über SCardListReaders
3) SCardConnect
4) Lesen des gesamten Speichers mit SCardTransmit und APDU new byte[] { 0xFF, 0xB0, 0, 0, 0 };
5) Verifizierung des Pins mit SCardTransmit und APDU new byte[] { 0xFF, 0x20, 0, 0, 3, 0xFF, 0xFF, 0xFF }; (Beachten Sie, dass dies 0x90;0x00 als Antwort zurückgibt, was bedeutet, dass die Verifizierung erfolgreich gewesen sein sollte)
6) Versuchen Sie, mit ScardTransmit und APDU new byte[] { 0xFF, 0xD6, 0, 0, 50, 1 }; zu schreiben (versuchen Sie, den Wert 1 an Speicherposition 50 zu schreiben) - Ich habe auch versucht, eine APDU zu verwenden, bei der der erste Parameter 0x00 und/oder das zweite Byte 0xD0 ist. Die Antwort war nie 0x90;0x00, so dass ich davon ausgehe, dass beim Schreiben ein Fehler aufgetreten ist, aber ich konnte keine Bedeutung für die zurückgegebenen Fehlercodes finden.
Mögliche Ursachen:
Da ich eine Speicherkarte mit der WinSCard-API lesen kann, muss es auch möglich sein, darauf zu schreiben (Anmerkung am Rande: Die Speicherkarte(n), auf die ich zu schreiben versuche, sind funktionstüchtig, ich habe sie nicht gesperrt, indem ich die PIN dreimal nicht verifiziert habe).
1) Vielleicht ist der APDU-Schreibbefehl falsch. Es könnte sein, dass das Anweisungsbyte (zweites Byte) falsch ist oder der Speicherplatz eine Art erweitertes Kodierungsschema verwendet.
2) Vielleicht hat der Befehl verify nicht wirklich verifiziert. Wie in der Befehl selbst ist in Ordnung, weshalb 0x90 zurückgegeben wurde, aber ich muss zuerst etwas aufrufen oder einrichten.
3) Es ist nur eine Vermutung, aber ich glaube, dass dies der wahre Schuldige ist. Beim Googeln habe ich einige vage Hinweise darauf gefunden, dass man die SCardControl-Methode mit dem Parameter IOCTL_SMARTCARD_SET_CARD_TYPE aufrufen und den Kartentyp auf SLE4442 setzen muss. Aber auch hier gibt es nirgends funktionierende Beispiele, und meine Versuch-und-Irrtum-Tests führten zu Fehlern. Ich erhielt die Meldung "Einer oder mehrere der übergebenen Parameter konnten nicht richtig interpretiert werden" und noch einige andere Fehlermeldungen, an die ich mich nicht mehr erinnern kann. Ich nehme an, dass der Code, den ich von Google Code kopiert habe, die richtigen Beschreibungen für die Fehlercodes enthält.
Was ich brauche:
Was ich brauche, ist jemand zu posten oder verweisen mich auf eine Website, die voll + Arbeitscode in c# für Lesen/Schreiben SLE4442 mit WinSCard API hat und es muss in 32-Bit und 64-Bit-Umgebungen arbeiten. Der Code muss nicht narrensicher sein - z.B. jede mögliche Fehlersituation gut behandeln. Ich sollte in der Lage sein, das selbst zu tun. Aber wenn es so ist (einschließlich der Beschreibungen der APDU-Befehlsergebnisse - z. B. 0x90;0x00 ist ein Erfolg, aber 0x6B;0x4D ist... usw...), dann ist es umso besser.
