I couldn't help but to spend my sunday on working towards card
emulation, including
* various state machines in the target about ISO7816 states
* tc_etu timer import from simtrace1
* req_ctx import from simtrace1 (needs renaming and simplifiation)
* USB protocol description as cardemu_prot.h
* some host-based testing code to test the state machines
The code seems to work fine throughout card reset, sending ATR and
receiving the TPDU header of the first APDU, up to the point where it
marks the TPDU header as to-be-transmitted over th bulk-in endpoint.
Sending the ATR must be done inside the firmware for timing
requirements.
From that point onwards, the host needs to respond at the very least
with a procedure byte, and some indication whether or not the card
emulator should continue to transmit data (card->reader), or receive
data (reader->card).
The code is intentionally not hooked up yet with the USB logic nor with
the UART. I want host-based testing completed before doing that.
we shouldn't re-use the vendor/device ID usd by simtrace1, as the
protocol is incompatible and applications for simtrace 1 don't work with
simtrace2. Also, there's a different processor architecutre in the
hardware.
The host got stuck sometimes when large data frames had to be send
from the host program to SIMtrace. The printouts would just stop
if many large packets were received from the SIM card and needed
to be transferred to the mobile phone.
Increasing the buffer length removed the problem.
When the timeout was too small, the main function would infinitely
loop around, restarting the board and waiting for the USB interface
to get configured. But since configuration seems to take more than
one second, it rarely succeeded.
Increasing the timeout makes the USB configuration finish in the
first try.
Moved the replace function from mitm.py to replace.py.
This implementation is context insensitive for now. It would be
better, to have a mitm class or to pass state information to the
function. Because how else can the MITM code know, whether it gets
passed data to or from the sim card, to or from the phone?
There are more instruction codes, after which data is expected
from the SIM card. Therefore, the array with commands known to
expect SIM card data has been extended. Feel free to extend it
even further.
!! ATTENTION !!
The only synchronization mechanism for parsing APDUs
(naively looking for a 0xA0 byte) is deactivated! It only worked
well for the sniffing mode, but getting out of sync is fatal for
the MITM mode.
!! A NEW MEANS OF SYNCHRONISATION HAS TO BE FOUND !!
When the command a0 c0 00 00 16 was send, and the the bytes
a0 c0 00 00 where read first, and then only the byte 16 was read
from simtrace, the code never entered the if condition if cmd is not
None, and therefore never executed send_receive_cmd.
Bug fix: Check for state APDU_S_SEND_DATA after apdu_split (parsing)
the ACK-instruction byte, in case it was an instruction which requires
an answer from the SIM card.
SCardTransmit expects the last function parameter cmd (the bytes
to be send) to be of type list, but we pass a binary array to
send_receive_cmd.
Therefore, the cmd array has to be converted using its function
tolist().
The code was used as early debug code to read different files from
the SIM card and therefore acquire the IMSI, and other SIM card
specific information.
This only was useful for testing that the firmware worked properly.
Is is not needed for regular use cases.
The commands "cmd1", "cmd2", "cmd_poweron", "cmd_poweroff",
"cmd_get_slot_stat", "cmd_get_param" where early test commands,
but have not been used as such in moths.
A programmer, who wants to send commands to the smartcard, should
use the functions of ccid_raw.py (e.g. send_receive_cmd) instead.
With the python module scapy the headers of each layer have to be created
by hand. Furthermore, in order to use it, the program would have to be
started as root.
Using sockets would be the better. The reason for using scapy was, that
it was the first best thing that I found when searching for python
socket communication.
The next step would be to open and close the socket only once instead
of every time an APDU is send to wireshark.
Furthermore, the ATR probably has to be treated differently from APDU packets.
The data type of incoming and outgoing data should be the same
at all points of the program to make it consistent.
For this program the data type is array.array.
Wait time extension commands are not implemented yet.
They are a nice-to-have for the future, since they would enable
the board to work with phones that expect a higher frequency.
With a wait time extension request towards the phone, SIMtrace could
signal the phone to wait for a longer time period while SIMtrace is
still waiting for a response from the SIM card.
Atmel library mixes up the value for two different messages.
Explanation can be found here:
http://permalink.gmane.org/gmane.comp.mobile.osmocom.simtrace/29
Actually, a better fix for this problem would be to go through the
Atmel code and replace ICC_INSERTED_EVENT with ICC_BS_PRESENT_NOTACTIVATED
where appropriate and in accordance with the Smart Card CCID standard
(and libccid, for this matter).
The code used a vendor and product id taken from Atmel example code.
Now it is changed to the vendor and product id, which was also previously
used in the original SIMtrace code.
Since the host side does the parsing of the packets, (not the firmware,
as it was in the old simtrace version), we do not need to check for expired
max waiting time.
Instead, every byte received from the phone is filled into a ring buffer.
As soon as the USB endpoint to the host is not busy anymore, it is sent
to the host over the respective USB endpoint.
