Feature additions

[kategray]

Hello,

I'm considering making some changes for my own use, and was wondering whether or not they would be worth making a pull request for.

I'm using gpshell for some card programming, and one of the issues I have is that some commands take a while and may or may not break when disconnecting and reconnecting the card. For example, I have a command for one card that switches it from SCP01 to SCP02, which requires tearing down and re-establishing a connection. Sometimes, it happens too fast and the cryptogram fails.

What I'm considering doing is implementing a couple new commands and parameters to make it easier to use this in larger operations. The current plan is:

• pause (halt and wait for enter to be pressed)
• wait [seconds] (wait for the specified number of seconds, or 1 if unspecified)
• card_disconnect [-reset=none|warm|cold|eject]
• card_connect [-retry=n] [-retrywait=n]
• open_sc [-retry=1|2|3] [-retrywait=n]

Given the potential to brick cards, I would hesitate to allow more than 3 retries on open_sc.

Anyhow, if this is something that would be useful to the project, I'll put a fork together and start working on it as I have time.

[kaoh]

Hi Kate,

you are welcome.

Some comments regarding the implementation:

• card_disconnect: This is not trivially done in gpshell.c (your primary patch goal), but requires also to extend the globalplatform library call connection.c, e.g. by adding a new parameter disposition (just takign the name from SCardDisconnect) and also the PC/SC Plugin must be extended then to support it. I can assist here, if you are not finding the proper places at once.
• open_sc: What is the purpose of giving several tries? The result should always be the same or are you iterating over the different protocols? With a GET DATA call like GPShell does it the right protocol can be detected.

Please use for each feature individual pull requests and branches so that it is easier to integrate them

[kategray]

• open_sc: What is the purpose of giving several tries? The result should always be the same or are you iterating over the different protocols? With a GET DATA call like GPShell does it the right protocol can be detected.

You'd think that the result would always be the same, but I have a card where it's not. When I change it from the factory SCP1 to SCP2, it takes an indeterminate amount before actually doing it. Sometimes, my script succeeds. Sometimes, it fails. With a big enough delay between sending the APDU to switch modes and re-opening the channel, it will undoubtedly always succeed, but it would be nice to have a parameter just in case.