Hi,
What is the BAUD rate of the phone clock? You must know it for sniffing the communication between the phone and SIM card. And does Wireshark output all the communication between the phone and the SIM card? Please let me know.
Thanks,
Vishal
Hi,
We purchased the Simtrace HW kit from you guys and I tried to sniff the communication between the sim and an iPhone 6. After installing the firmware and running simtrace, I was able to view the results on Wireshark. Looking into the results, all the field’s like EF.ICCID, EF.IMSI and EF.Keys had the same number (APDU Payload).
I got the numbers like ICCID and IMSI and it didn’t match them. Do you have any idea where the issue might be? Please let me know
Regards,
Vishal
Greetings,
I have been working with wireshark and SIMtrace.
And decided to extended the dissector for 'GET RESPONSE' (mf/df/ef) and
'STATUS' - according to the ETSI 11.11 Section 9.2.1 Page 39 - 41 and Page
46 (Definitions and Codings for response params)
Keeping update with latest wireshark commits.
I would like to commit to their gerrit.
Please could you let me know here - if the output is as expected.
Let me know your views/comments on the output so I can change it before
commit.
Also code can be viewed here 'https://github.com/GerardPinto/wireshark'
(properly forked and synced with upstream) or
reviewed by wireshark gerrit (Once I get your views on the output).
(1) Get Response MF/DF:
GSM SIM 11.11
1010 .... = Class Coding: ISO/IEC 7816-4 unless stated otherwise (0xa)
.... 00.. = Secure Messaging Indication: No SM used between terminal
and card (0x0)
.... ..00 = Logical Channel number: 0
Instruction: GET RESPONSE (0xc0)
Length of Expected Response Data: 32
RFU: 0x00
Total amt of memory not allocated to any of the DFs or EFs under the
selected dir: 0x00
File ID: DF.GSM (0x7f20)
Type of File: DF (0x02)
RFU: 0000000000
Length of following data: 19
GSM Specific Data
File Characteristics: 0xb3, Clock Stopping Indication: Not Allowed
- unless at low level, Frequency Required for ENVELOPE cmd /AUTH algo, CHV1
Status
.... 00.1 = Clock Stopping Indication: Not Allowed - unless at
low level (0x1)
.... ..1. = Frequency Required for ENVELOPE cmd /AUTH algo:
13/4 Mhz
.011 .... = RFU: 0x3
1... .... = CHV1 Status: Enabled
DFs in Current Directory: 0
EFs in Current Directory: 41
Number of CHVs, UNBLOCK CHVs and administrative codes: 4
RFU: 0x00
CHV1 status: 0x83, Secret Code initialized
.... 0011 = False presentations remaining ('0' means blocked): 3
.000 .... = RFU: 0x0
1... .... = Secret Code initialized: Yes
UNBLOCK CHV1 Status: 0x8a, Secret Code initialized
.... 1010 = False presentations remaining ('0' means blocked):
10
.000 .... = RFU: 0x0
1... .... = Secret Code initialized: Yes
CHV2 Status: 0x8a, Secret Code initialized
.... 1010 = False presentations remaining ('0' means blocked):
10
.000 .... = RFU: 0x0
1... .... = Secret Code initialized: Yes
UNBLOCK CHV2 Status: 0x8a, Secret Code initialized
.... 1010 = False presentations remaining ('0' means blocked):
10
.000 .... = RFU: 0x0
1... .... = Secret Code initialized: Yes
RFU: 0x00
Reserved for the Administrative Management: 030000bbda00000000
Status Word: 9000 Normal ending of the command
(2) Get Response EF:
GSM SIM 11.11
1010 .... = Class Coding: ISO/IEC 7816-4 unless stated otherwise (0xa)
.... 00.. = Secure Messaging Indication: No SM used between terminal
and card (0x0)
.... ..00 = Logical Channel number: 0
Instruction: GET RESPONSE (0xc0)
Length of Expected Response Data: 15
RFU: 0x00
File Size: 11
File ID: EF.LOCI (0x6f7e)
Type of File: EF (0x04)
EF response Byte 8: RFU: 00
Access Condition Byte 9: 0x00, UPDATE: Always (ALW), READ/SEEK: Always
(ALW)
.... 0000 = UPDATE: Always (ALW) (0x0)
0000 .... = READ/SEEK: Always (ALW) (0x0)
Access Condition Byte 10: 0x14, INCREASE: Administrative Authority
(ADM), RFU: Card Holder Verification1 (CHV1)
.... 0100 = INCREASE: Administrative Authority (ADM) (0x4)
0001 .... = RFU: Card Holder Verification1 (CHV1) (0x1)
Access Condition Byte 11: 0x01, INVALIDATE: Card Holder Verification1
(CHV1), REHABILITATE: Always (ALW)
.... 0001 = INVALIDATE: Card Holder Verification1 (CHV1) (0x1)
0000 .... = REHABILITATE: Always (ALW) (0x0)
File Status: 0x01, Validation Status
.... ...1 = Validation Status: Not invalidated
.... ..0. = RFU: 0x0
.... .0.. = Read Update Status: Not readable or updatable when
invalidated
0000 0... = RFU: 0x00
Length of following data: 2
File Structure: Transparent (0x00)
Length of a record: 0
Status Word: 9000 Normal ending of the command
(3) STATUS ( ETSI 11.11 Section 9.2.2) says -
The response parameters/data are identical to the response parameters/data
of the SELECT command in case of an MF or DF.
Thanks,
Gerard
Dear Osmocom,
I have been following your SIMtrace project for some time and wanted
to build and try a few things.
However, it seem that the project is abandoned since it has not been
updated on your Wiki for ages.
I know you guys are very busy with your many other and more
interesting projects and that this project is very old, but we would
still appreciate if you could at least try to keep your own GIT repo
updated with the stuff you are showing on the wiki. For example, I
cloned the SIMtrace and opened the schematics in KiCad only to find
that the schematic is several HW versions behind the currently shown
one. So my questions are:
1. Have you abandoned the project?
2. Where can I find/download the latest Firmware, KiCad (Schematics
and PCB) design files?
3. There is a related project on GitHub that are using SIMtrace.
However, the firmware there seem different. What is the current status
of the firmware? Are you involved in that development?
https://github.com/kamwar/simlabTrace
If your answer to (1) is a Yes, then perhaps it would be better to
publish your project to GitHub instead, so that other people can help
and take over the maintenance? This is actually a great idea,
reagrdless as your Redmine/cgit based git repo is very slow and hard
to navigate and the bug tracking of GH is superior in simplicity to
anything else freely available.
Kind Regards,
E:V:A
Dear SIMtrace Developers,
After having spent a few days reviewing your SIMtrace hardware and FW
and its development,
I would like to propose you to consider supporting the following project.
Background:
The current SIMtrace processor (AT91SAM7) is based on the 55 MHz
ARMv4T uP, whereas the next generation SIMtrace2 is to use (AT91SAM3)
which is based on a 96 MHz Cortex-M3. This is all great and dandy, but
it does limit the hardware and software development to people who are
already very familiar with that hardware. Why are these needed? They
are needed so that we can have 2 SIM (USART) interfaces and that we
can translate the signals found on those to/from a USB endpoint on the
USB port. This is all done in the firmware, written in C + Assembly.
Proposal:
The new project would utilize a RaspberryPi-Zero-W in the external
slave configuration or a RPi3 doubling as a host. The RPi-0 is a 1GHz
ARM processor (ARM1176JZF-S) and could possibly also be used as a
headless host via WiFi. (RPi0 has OTG USB, RPi3 doesn't.) The Rpi3 is
a quad-core 64-bit Cortex-A53, that can be used as anything. Thus
porting A53 to M3 might be more easy.
Advantages:
There are too many advantages to ignore...
- The huge RPi developer community
- The high clockspeed and 512+ Mb of RAM
- All interfaces you can dream of, except JTAG
- A huge reduction on the BOM. I've counted that we may remove about
50 components by using this solution instead of the current v1.3 one.
- A huge reduction to about 1/3 of what is currently used of the PCB footprint.
- A large reduction of production price due to above.
- Easy to port drivers when understood
- Provide a more attractive and useful product combo (RPi-0 + ST hat)
than what is currently offered.
Disadvantages:
- Need porting of current FW drivers to RPi's
- Possible proprietary limitation to the complete Broadcom datasheets
- Need to CAD and manufacture a new PCB
- New Rpi-0/3 drivers would need testing for use with 2 SIM IF's.
Other:
The RPi's only has one UART so to get a second, we need to use
bit-banging of their GPIO,SPI or I2C. There are already solutions out
there and the much higher clock-rate of both devices allow you to run
up to 250 MHz on a single GPIO pin, so that would allow you to
multiplex a number of virtual/emulated UARTs. (Perhaps similarly to
what was already done when SIMtrace was using the FT232r?) The library
used for this is the PGPIO from here:
http://abyz.co.uk/rpi/pigpio/download.html
and a Python based test-script can be found here:
https://www.rs-online.com/designspark/raspberry-pi-2nd-uart-a-k-a-bit-bangi…
Finally, please don't get me wrong. This is not at all a critique of
what has already been done. The development of the ST is a great piece
of work and obviously very flexible and cross platform compatible by
using USB, but for compact embedded devices, such as RPi's etc, all
that extra HW is redundant and expensive to produce and maintain. Even
more so than combining the RPi + this add-on, while improving cross
platform connectivity and IoT support.
I would love to hear what the community and Osmocom think about this.
Cheers,
E:V:A
Hi all,
today I've deployed some cgit improvements on https://git.osmocom.org/,
in the hope that it makes this tool even more useful:
1) syntax highlighting of source code (requested by Hoernchen)
The source code is now highlighted by pygments. I don't really
understand why somebody would want to look at source code a lot in a
browser, but well, it was as easy as to enable the existing pygments
based filter plugin.
2) rendering of "about" page from README.md
As you might have noticed, I've introduced a README.md in a number of
repositoires, and cgit is now rendering an about page for every
repository, e.g. at http://git.osmocom.org/libosmo-abis/about/
3) gerrit change-ID hyperlink generation
All gerrit Change-IDs in commit messages are now automatically converted
to hyperlinks to the respective gerrit change, see e.g. the below
example:
http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44…
Please note that this works for the "Change-Id" line of the actual
change, but also for change-ids in the free text (e.g. "this depends on
change-id ... in libosmocore")
4) Osmocom ticket/issue hyperlink generation
Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is
scanned for occurrences of "OS#(\d+)" which are then amended with
hyperlinks to the respective issue on osmocom.org
Please note the OS# prefix is mandatory, so things like "OS#1614, 1615"
will not work, as can be seen at
http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5…
Please format your commit messages accordingly.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
I come to all of you as I'm trying to use simtrace to capture the UE-SIM
traffic with a 4G+ SIM card, called "next gen SIM card" (the ones with
NFC). The only thing I see is the ATR, and the mobile never detects the SIM
card. I try also to read the SIM card plugin directly into the SCR3310 card
reader, but the reader didn't recognize the SIM card (no led activity).
At the beginning I thought this must be a new standard for the NFC/SIM
cards, but reading 3GPP TS 31.101 V13.2.0 (2016-06), I understood only
Class B and C operating conditions should be supported by 3G MEs (page 10
of the document), and using transmission protocols T=0 and T=1. So looks
like nothing has change in the protocols/electrical conditions.
I look for 3GPP specs folder searching for something related with this
NFC/SIM (http://www.3gpp.org/DynaReport/31-series.htm), but nothing appear.
Also searching in google about this simcards I just found Orange document
describing the business strategy to use NFC services/wallet;
"On February 21st 2011 many of the world’s leading mobile operators (15 in
total) including Orange announced their collective commitment to SIM-based
mobile NFC and intention to launch commercial mobile NFC services. In
November 2011, the Chinese MNOs increased the momentum of support to SIM
based NFC. In January, GSMA communicated that more than 60 MNOs now support
these initiatives."
Source:
https://www.orange.com/en/content/download/12418/258640/version/1/file/Oran…
But still didn't found any technical spec for this sim cards. Most strange
for me is that plugging this SIM card in an old Samsung Galaxy S3 is
working normally, so ask myself why plugging in SCR3310 reader or simtrace
is not working.
Can anyone help me with this SIM cards specifications? Does anyone been
able to read with SIM readers?
Best Regards,
Pedro
Hi, our company bought two SIMtrace Hardware Kits. We want to use SIM
forwarder
<https://github.com/kamwar/simlabTrace/wiki/res/bin/sim_forwarder-simtrace-a…>
firmware
in our project. but have problem with flashing it to the board.
in one way I installed toolchain as described at
http://osmocom.org/projects/baseband/wiki/GnuArmToolchain
and made forwarder firmware - success1.
but any tries to flash it using dfu-util failed.
tries was next:
--------------------------
- from windows10 host using steps from
https://github.com/kiibohd/controller/wiki/Loading-DFU-Firmware#windows -
kii-dfu can`t flash it due to three dfu devices with NO serial numbers.
Try using dfu-util with -a0 flag gives same result as later cases - DFU
found, state idle, activate alternative=0 ... and nothing more. reruns not
helps. reconnects with or w/o BOOTLOADER button gives same result - nothing.
---------------------
- same win10 host with vmWare Ubuntu16.04 VM. tries to install using
ubuntu. device shown on lsusb - dfu mode on. dfu-utils installed, toolchain
too, firmware made OK. simtrace made too.
BUG1
experiment with simtrace gives output with wrong parsing of commands - may
be you have to open bug case to resolve it. same results with usb2 on vm
and usb3.
all tries to flash forwarder or reader to board failed on same place as
before.
tried with button at connect and using -ao and w/o button and using -i
param (forgot number of interface for apps partition mb was -i1 ) - failed
- pure ubuntu 16.04 host. all above with same results. using usb3 port and
usb2 extender.
--------------------------------
Now the time to tell about second way - SAM-BA . here is another problem:
used http://osmocom.org/projects/simtrace/wiki/SIMtrace_Firmware
installed GnuArmToolchain
<http://osmocom.org/projects/baseband/wiki/GnuArmToolchain>. as described
on toolchain <http://osmocom.org/projects/baseband/wiki/Toolchain> link,
included to PATH.
Trying to do:
git clone git://git.osmocom.org/openpcd.git
cd openpcd/firmware
make -f Makefile.dfu BOARD=SIMTRACE
make BOARD=SIMTRACE DEBUG=1 TARGET=main_simtrace
cat dfu.bin main_simtrace.bin > main_simtrace.samba
cd ../..
failed on 3rd string: make -f Makefile.dfu BOARD=SIMTRACE - arm-elf-gcc not
found!
tries to rename arm-none-eabi gcc to arm-elf-gcc was not successful. so I
cant produce
your dfu.bin to use samba (I made it with success) with
cat dfu.bin my_forwarder.bin > my_forwarder.samba
Also, at the string cat dfu.bin main_simtrace.bin > main_simtrace.samba we
see dfu.bin which is possibly dfu-boot-loader with wrong name which crashes
brain of google
so we have a BUG2:
- to rename produced dfu.bin filename to something relative i.e.
dfu-boot-loader-arm-SAM7.bin
- to place link to binary of loader(s) at your instructions.
installed also crosstool-ng - but arm-elf-gcc not found too
So, we have fails using dfu-util and unmaking state of firmware which gives
use of SAM-BA impossible due to insufficient dfu-boot-loader-arm-SAM7.bin
aka dfu-bin.
This situation looks like failed "smoke test"...
Please help me to solve these issues.
Regards,
Alexandr
--
https://L-in-K.com/147a258u369
Hi,
I looked through the archives of this list and saw that an issue with
dfu-util and simtrace was discussed. Can anyone here do some simple
debugging on it? Remote access would have been great, but I guess the
device hangs and must be reset all the time during testing so it might
not be so efficient.
The issue was also reported in the dfu-util bug tracker, but the OP
went silent, so please add any useful information there (or Cc me on
your replies here).
https://sourceforge.net/p/dfu-util/tickets/33/
Best regards,
Tormod