Menu

Tree [c9111c] default tip /
 History

Read Only access


File Date Author Commit
 VS2008 2015-09-20 tin-pot tin-pot [23832d] Place the whole stuff under MIT license. Add ve...
 include 2015-09-20 tin-pot tin-pot [7e8cd6] Vendor headers for CT-API are no longer needed.
 res 2015-09-20 tin-pot tin-pot [23832d] Place the whole stuff under MIT license. Add ve...
 src 2015-09-20 tin-pot tin-pot [49b662] main.c: More reporting on what's going on.
 .hgignore 2015-09-20 tin-pot tin-pot [ced29a] Update .hgignore
 README.md 2015-09-20 tin-pot tin-pot [c9111c] Mention the `main.c` program in README.md
 memcard.cfg 2015-09-20 tin-pot tin-pot [a35248] Add sample memcard.cfg file.

Read Me

Simple Memory Card Interface

This is a single C module to hide differences between APIs for accessing synchronous memory cards. How each reader handles such cards is specified in a configuration file. The required DLL for providing the API is loaded at run time.

Motivation

Memory cards look like smart cards, but in reality they are pretty dumb: a memory card is basically an EEPROM chip embedded in a plastic card. There is no processor, instead the chip is driven passively by the reader, using a synchronous protocol (like 2-Wire, I2C, etc) which is physically different from the protocol used with "real" smart cards.

This complicates the use of memory cards somewhat; while a way of supporting synchronous cards is recommended in the industry standard specification PC/SC, conformance to this recommendation is not widespread.

  • Most, but not all, readers are capabable of communicating with synchronous cards at all;

  • Those who can often require the application to use a vendor-specific API, provided in a vendor-supplied DLL - either installed along with the regular driver installation, or to be downloaded and installed from a support site.

  • One "portable" API specification, the "CT-API", is supported by most vendors, but also resides in a DLL that must be specifically addressed and loaded.

Approach

The module provides a very simple interface to appilications, consisting of only these functions:

  1. MemCardConnect(): Tries to find a usable card in one of the configured readers and connects to the first card found. Loading the required DLL happens here.

  2. MemCardRead(): Reads a sequence of bytes, starting at a given offset, from the memory card.

  3. MemCardWrite(): Writes a sequence of bytes, starting at a given offset, to to memory card.

  4. MemCardDisconnect(): Closes the card connection.

All differences between the vendor APIs are hidden from the application. See the header file memcard.h for the - unsurprising - argument lists.

The main.c program is an example application using these functions. It is a simple command-line tool to extract the content (256 bytes) of a memory card to a binary file, and to write it back from a file into a card. Note that it is only linked with the Windows system library WinSCard.lib (import library for WinSCard.dll), not with any API-specific library. These are loaded via LoadLibraray() when needed.

Configuration

To match a specific reader with a specific API, the module reads a configuration file, %USERPROFILE%\AppData\Local\memcard.cfg. It is a text file with the following format:

  • Each line specifies the use of one card reader, in a sequence of fields.
  • The first field contains the display name of the reader.
  • The second field indicates the API to use.
  • The third field is optional and names the DLL to use.
  • The fourth field is only needed for CT-API and gives the card terminal and port number to use.
  • Each field is terminated by a semicolon.

Here is an example configuration that I use:

FUJITSU SCR Keyboard USB 2A 0;CTAPI;ctdeutin.dll;1,210;
REINER SCT cyberJack RFID standard USB 52;PCSC;
SCM Microsystems Inc. SPRx32 USB Smart Card Reader 0;MCARD;MCSCM.dll;

Supported APIs and Readers

  1. PC/SC: Some readers - the ReinerSCT device mentioned in the configuration file above is an example - conform to the PC/SC recommendation and can access memory card simply by using ISO 7816-4 standard commands like READ BINARY, but with the class byte CLA set to the value 0xFF.

  2. CT-API: This is an old specification from Germany, around the time when health insurance cards with a read-only memory chip were introduced. Related specifications even lay out a memory format so that a memory card can be useds exactly like a ISO processor card, using SELECT FILE etc. It is supported by most vendors in a separate DLL, like in the case of the keyboard reader listed in the above configuration (this reader is really a Omnikey device built into a Fujitsu keyboard).

  3. MCARD: This is a proprietary API provided by SCM Microsystems. While it is used here solely for reading and writing, it contains a range of other functions to control specific features of a host of memory cards, like write protection, memory areas etc.

  4. GSC: Another proprietary API, this time from Gemalto. This is not yet supported, but should be coming soon.

Notes

This software does work for me so far; you might have a different experience on your system with your readers. During development and debugging, I managed to confuse one reader (the SCM) wo much that it refused to function properly (it always gave an obvious nonsensical ATR for any card). Disconnecting the reader and letting it relax for a moment cured this problem. The Omnikey keyboard reader along its software proved to be the most robust and reliable of the three.

I would be happy to receive feedback and improvement proposals. Specifically, if you have a reader to accomodate (say, a Kobil), I could give it a try and help with it.

License

This lump of code is licensed under the MIT License.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.