Age | Commit message (Collapse) | Author | Files | Lines |
|
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 !!
|
|
The find_device() function was only called when the USB config was
altered. Now, it is called on every call of simtrace.py.
|
|
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 code changes the config to config number 2 and tries to connect
to the serial CCID reader. This only was useful in the early stage
of the project.
|
|
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.
|
|
The SIM card emulator re-uses the mitm.py code with an implementation
of SIM card requests and answers instead of phone.py.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Parsing failed like in this dump:
('PTS: ', [255, 0])
('PTS: ', [255, 0, 255])
('APDU:', 'c0', 'a0 c0 00 00 16 c0 00 00 00 00 7f 20 02 00 00 00 00 00 09 91 00 17 04 00 00 00 83 8a 90')
ACK
('APDU:', 'a4', '00 a0 a4 00 00 02 7f 20 9f 16')
('APDU:', 'c0', 'a0 c0 00 00 16 c0 00 00 00 00 7f 20 02 00 00 00 00 00 09 91 00 17 04 00 83 8a 83 8a 90')
a0 c0 00 00 16 c0 00 00 00 00 7f 20 02 00 00 00 00 00 09 91 00 17 04 00 00 00 83 8a 90
00 a0 a4 00 00 02 7f 20 9f 16
a0 c0 00 00 16 c0 00 00 00 00 7f 20 02 00 00 00 00 00 09 91 00 17 04 00 83 8a 83 8a 90
So when data was sent, the next packet would always begin with the SW2 byte
(e.g. 00 a0 ..) instead of the instruction byte a0.
The problem was a wrong state change (to APDU_S_DATA instead of APDU_S_SW1)
|
|
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.
|
|
ATRs should probably be treated differently?
Also, is there a performance penalty when using scapy instead of holding a connection open?
|
|
The GSM message appears in wireshark when sniffing on localhost
|
|
Removed comment describing the typical first few packets between the
SIM card and phone I used for development and testing:
SuperSIM, Motorola C123
|
|
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.
|
|
|
|
Removed FIXME comment
Removed TC_Start, TC_Stop function call, which was commented out anyways.
|
|
|
|
MITM does not support two interface settings.
The comment mixed up interface configurations and alternative
interface settings.
|
|
|
|
String descriptor #0 always is the language descriptor.
The second USB interface is in the MITM configuration is
the interface to the phone.
|
|
|
|
The define PR was introduced to switch quickly between TRACE levels
for specific debug print messages.
Now, it all became debug output, since it is not needed in normal
operation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|