Skip to content

Home

Jump to bottom Edit New page
petrs edited this page Jun 18, 2013 · 23 revisions

Last update: 19.11.2012

  • 19.11.2012 Added information about correct selection of winscard.dll on Windows 7 64-bit platform (must take c:\Windows\SysWOW64\winscard.dll (32bit) not c:\Windows\winscard.dll (64bit))
  • 24.1.2012 Added missing status.h and globals.h to source files (thx Alessandro Rabbini) You may be also interested in:
  • JavaCard algorithms testing tool
  • SHA-512bit and AES software reimplementation

PC/SC APDU inspection and manipulation tool (APDUPlay)

The project APDUPlay is based on [ApduView tool][9] which allows you to log communication realized via PC/SC interface (winscard.dll library). If you are interested only in log of transmitted data, you can readily use APDUView project (although APDYPlay project provides information about communication in more structured way more suitable for later post processing and add some additional information).

The APDUPlay project is providing following functionality:

  • Log content and additional information about exchanged PC/SC communication
  • Manipulate communication in real time
  • Redirect communication via socket to other device/computer
  • Reorder list of smart card readers detected in a system
  • Visualize captured data in structured way by GraphViz

Note: The APDUPlay tool is available for download including source codes, yet documentation still lack a bit behind :(. Still, it was requested several times and I hope it will be useful.

How to use it?

1. Copy Winscard.dll from your system folder (see note below to select correct version) to folder with target application and rename it to original.dll
2. Copy Winscard.dll from APDUPlay project to folder with target application (see download below)
3. Run application and inspect resulting files winscard_log.txt and winscard_rules_log.txt
4. (Optional) Change configuration file winscard_rules.txt to modify default behaviour (see below)


APDUPlay project provides winscard.dll library that is stub used instead of original winscard.dll provided by Microsoft. For correct usage, you need to find Microsoft's library and copy it to folder with application you are trying to control with APDUPlay.
If you are using Windows XP or Windows 7 32bit, you can find it at c:\Windows\winscard.dll
If you are using Windows 7 64bit, you can find it at c:\Windows\SysWOW64\winscard.dll
NOTE: If you will use (wrongly) 64bit version of library winscard.dll, it will fail with "The procedure entry point original.g_rgSCardT1Pci could not be located in the dynamic link library WinSCard.dll."

Please send me any comments or found bugs to the mail written at the footer of this page. I take no responsibility for usage of this software.

Download binaries here : [ APDUPlay_bin.zip][10].

Log content and additional information about exchanged PC/SC communication

APDUPlay tool can be used to log information about transmitted APDU commands between reader and smart card. Most applications in the system access the reader and smart card via PC/SC interface, which is realized by SCardxxx function in Windows API. These functions are available in winscard.dll library. The logging is based on an interception of PC/SC API calls by inserting fake winscard.dll library into system (usually into working directory of target application) and redirecting this call to original winscard.dll library. The original library should be renamed to original.dll a positioned in same directory as fake library is. Application will load fake winscard.dll which in turn load original.dll library. Having control over fake library, one can log, modify and otherwise control communication between smart card and reader.
WARNING: all data including possible keys, PINs or other sensitive data will be logged to file!



Usage: Copy fake winscard.dll and original library (renamed to original.dll) into actual directory of application you are targeting. Set key LOG_EXCHANGED_APDU=1 in file winscard_rules.txt to enable APDU logging. Resulting log will be written into winscard_log.txt file.
Usage: Set key LOG_FUNCTIONS_CALLS=1 in file winscard_rules.txt to enable PC/SC function calls logging. Resulting log will be written into winscard_rules_log.txt file.

Example: LOG_EXCHANGED_APDU = 1. The following output will be produced for GnuPG gpg --card-edit command (edited for length): [begin] SCardTransmit (handle 0xEA010000)# apduCounter:0# totalBytesINCounter:1# transmitted:00 a4 04 00 06 d2 76 00 01 24 01 responseTime:15# SCardTransmit result:0x0# received:90 00 SCardTransmit (handle 0xEA010000)# apduCounter:1# totalBytesINCounter:12# transmitted:00 ca 00 4f 00 responseTime:16# SCardTransmit result:0x0# received:d2 76 00 01 24 01 01 01 ff ff 00 00 00 01 00 00 90 00 SCardTransmit (handle 0xEA010000)# apduCounter:2# totalBytesINCounter:17# transmitted:00 ca 00 c4 00 responseTime:15# SCardTransmit result:0x0# received:01 20 20 20 03 03 03 90 00 [end]

Example: LOG_FUNCTIONS_CALLS = 1. The following output will be produced: ######################################### Rules file found: some_path\winscard_rules.txt SCardEstablishContext() called -> hContext:0xcd010000 SCardListReadersA called -> Found readers: SCardListReadersA called -> Found readers: Gemplus USB Key Smart Card Reader 0, Schlumberger e-gate 0, SCardConnectA(hContext:0xcd010000,Gemplus USB Key Smart Card Reader 0,hCard:0xea010000) called SCardStatusA called SCardTransmit called responseTimeLibrary:15# ............................................... SCardTransmit called responseTimeLibrary:16# ...............................................

SCardReleaseContext(hContext:0xcd010000) called

Manipulate communication in real time

Modified library allows to selectively modifying data exchanged between card and reader based on predefined data pattern. Bytes in APDU header or data section may be changed, whole APDU can be blocked or replaced with completely new or additional communication can be inserted.
Potential usage might be to test if application is robust against replay, selective forwarding or data modification attacks etc.

Following manipulations are currently supported:

  • Modify part of APDU packet if original packet matches specified mask
  • Drop APDU if packet matches specified mask (APDU is not send to smart card / reader) and create forged response
  • Insert additional commands into communication between reader and smart card
  • Insert additional delay to communication before currently transmitted packet is delivered
  • Do any of previous actions with pattern matching based also on multiple previous packets transmitted in past communication

    Usage: set key MODIFY_APDU_BY_RULES= to enable/disable packet real-time modification. Create one or more [RULExxx] sections with description of modification(s).
    [RULE1] ... unique name for the rule, starting with string RULE followed by unique number within this file MATCH= ... key starting with key MATCH followed by number, starting from 1 (can be more of them), MATCH1, MATCH2.... Match pattern consists from following values, separated by symbol ';': value in= specifies match on input (in=1;) vs. response apdu (in=0;) value t= specifies ordinary number of apdu packet in history buffer. E.g. t=0 specifies matching on current apdu currently in transmission. t=1 specifies apdu transmitted just before current apdu, t=7 specifies apdu transmitted 7 packets back value cla= specifies value of CLA byte in APDU header (hexadecimal). E.g., cla=88 means CLA == 0x88 value ins= specifies value of INS byte in APDU header (hexadecimal). value p1= specifies value of P1 byte in APDU header (hexadecimal). value p2= specifies value of P2 byte in APDU header (hexadecimal). value lc= specifies value of LC byte in APDU header (hexadecimal). value le= specifies value of LE byte in APDU header (hexadecimal). value dataX= specifies value of one or more bytes in data section of APDU command (hexadecimal), starting with Xth byte. E.g., data0=11 0F 31; will match on APDU packet with data part of APDU starting with bytes 0x11 0xf0 0x31 E.g., data1=11 0F 31; will match on APDU packet with arbitrary first byte in data part of packet, second to fourth data bytes equal to 0x11 0xf0 0x31 ACTION= key specifying the action taken when incoming apdu matches the pattern specified in MATCH keys APDUIN= key specifying, when should be this rule evaluated. If true (1), this rule will be evaluated on all incoming apdu packets. If false (0) it will be evaluated on response apdu. DELAY= key specifying delay in millisecond that will be introduced before the action is taken. Use for example when packet to smart card is dropped and replaced with forged response apdu, but application is monitoring expected computational time, therefore quick forget response would be detected. USAGE= if true (1), this rule will be used, if false (0) it will be skipped. Used as switch to quickly turn RULE on or off without inserting/removing rule description from the script file Example:
    [RULE4] # rule number 4 MATCH1=in=1;t=0;cla=00;ins=a4;# match is on apdu from reader to smart card (in=1), actual apdu (t=0), cla == 0x00, ins == 0xa4 (any SELECT command) ACTION=in=0;data0=90 00;le=02; # replace response apdu by status OK 90 00 with 2 bytes length (le=2) (reader will thought that smart card application was successfully selected) APDUIN=0# try to match this rule when response apdu (smart card->reader) is in transmission DELAY=100 # add 100ms delay USAGE=1 # this rule is active (default)

Redirect communication via socket to other device/computer

The tool allows you to redirect communication via socket to other device/computer. This is a quite special feature and you will probably don't need it. You may be interested to use this feature if you like to redirect the PC/SC traffic to other computer. We are working with power analysis device to monitor power consumption of smart card so usual redirect was to our measurement device where smart card was actually inserted in - not the computer with application using the smart card.

Usage: set keys in REDIRECT, IP and PORT in section [SCSAT04] of file winscard_rules_scsat04.txt. REDIRECT=1 enables the redirection, IP=192.168.1.90 specifies the redirection target device and PORT=4001 specifies the socket port where target device is listening.
Example:
[SCSAT04]
REDIRECT=1
IP=192.168.1.90
PORT=4001

Reorder list of detected smart card readers in system

The APDUPlay tool can reorder the list of readers detected in system as given by API function SCardListReaders(). This feature is handy when dealing with application which can't handle more then one reader in system and connect always to first reader returned by SCardListReaders() call.

Usage: set key READER_ORDERED_FIRST in file winscard_rules.txt to the exact name of the reader you like to have ordered first.
Example: READER_ORDERED_FIRST = Schlumberger e-gate 0

Visualization of captured data in structured way by GraphViz

APDU data captured by the tool can be visualized to provide better overview of more complex interactions. For visualizing, GraphViz package is used.

  1. Copy fake winscard.dll and renamed original.dll to directory with target application.
  2. Run application and create suitable SC traffic. Backup resulting file winscard.txt (will be modified in step 3)
  3. Run your favorite software for regular expressions (e.g., PowerGREP, here load winscard_graph_all.pga) and apply following rules:SEARCH: received:(61.[0-9A-Z][0-9A-Z])# ([a-zA-Z0-9: ()# ]*?)received: REPLACE: received: SEARCH: (SCardTransmit.*?#) REPLACE: SEARCH: apduCounter:(.*?)# transmitted:([0-9A-Z][0-9A-Z] [0-9A-Z][0-9A-Z] [0-9A-Z][0-9A-Z] [0-9A-Z][0-9A-Z]) (.*?)# responseTime:(.*?)# received:(.*?)# REPLACE: "\2" -> "\3" [label="[ac=\1]"]; "\3" -> "\5" [label="[ac=\1, time=\4]"]; SEARCH: \[begin\] REPLACE: digraph winscard { rankdir=LR; size="6,6"; node [color=lightblue2, style=filled]; SEARCH: \[end\] REPLACE: }
  4. Install Graphviz software package (free from http://www.graphviz.org/Download.php)
  5. Run GVEdit GUI application (originally 'dot') from Graphviz suite, browse for input file winscard.txt (modified version as described above), set output file (image name), set output file type (e.g., PNG). Increase resolution of resulting image (graph[resolution="1000"]). Run conversion using 'Do layout'.
  6. Study resulting image :). APDU header will be in ellipses in first column. APDUIN data will be in second column and whole APDUOUT response in third. Connections are labeled with apdu ordinary number, starting from 0. Some ordinary numbers may be missing, most notably due to discard of response data request apdu). Note, that if same APDU data are used multiple times, more than one connection will point to second column.

    Please, report any bugs or suggestions to my mail (see footer of the page). Thank you!<br
Add a custom footer
Add a custom sidebar
Clone this wiki locally