Hi all,
behind the scenes, a team at sysmocom[1] has been helping IoT MVNO
onomondo[2] implementing a pure software implementation of the GSM SIM /
ETSI UICC / 3GPP USIM.
The resulting software has now finally been released in the
onomondo-uicc (see https://github.com/onomondo/onomondo-uicc)
The implementation covers a rather feature-complete implementation of
the file system (including access rules / permission model, PIN
authentication), authentication (MILENAGE), and even OTA RFM (remote
file management).
You can run the code either in software (and access it via the vpcd
ifd_handler to make it appear via PC/SC) or you can run it behind a
SIMtrace2 in cardem mode. Or you could cross-compile the library to run
on a microcontroller (assuming it has a ISO 7816 card-side UART) or
directly within a cellular modem/baseband.
Of course, beyond research this is only useful in situations where you
are the operator (like in a private network) and hence know the K/OPc
key material that allows you access to the cellular network.
There is some overlap to the parallel work of Tomasz Lisowski's swsim[3]
- sadly we were not in a position to release the onomondo-uicc code back
then, so the duplication of effort could not be avoided.
Regards,
Harald
[1] https://sysmocom.de/
[2] https://onomondo.com/
[3] https://github.com/tomasz-lisowski/swsim
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
January 17, 2023 at 20:00 CET
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @laforge will be presenting on
Exploring eUICC and eSIM using pySim, lpac and osmo-smdpp
This meeting will have the following schedule:
20:00 meet + greet
20:10 topic as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all!
[cross-post to make sure everyone knows about it, please follow-up-to
the osmodevcon(a)lists.osmocom.org mailing list for further discussion]
As I mentioned several times at different occasions, I really think we
should put together a OsmoDevCon again. In case you don't know what that
is, please see https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon
We should have restarted already in 2023, but I really was too busy and
it was a somewhat difficult year for me at times, sorry.
Date
----
In terms of timing, I am thinking about "after April but before the main
summer holiday season (June-August)". That leaves May.
Given that May has the whitsunday weekend as well as GPN
(Gulaschprogrammiernacht, a CCC event that will likely conflict
of interest with some people interested at attending OsmoDevCon), I'm
currently considering the following candidate dates:
* May 3 to 6
* May 24 to 27
This is as usual a friday-to-monday timeframe, allowing people who don't
work professionally on osmocom to attend just the two weekendd days,
while others can attend the full 4 days.
Venue
-----
In terms of venue, I'm hoping we can move to a slightly different
arrangement where the whole group stays together for the whole duration
of the event - as opposed to everyone staying at different hotels and
having to commute from hotel to venue and back every day. So something
like a hotel with a sufficiently large meeting room, hotels and catering
all day. And all of that ideally at a nice venue with some kind of park /
outdoor area, not downtown at the city center. Yes, that will obviously
come at a higher price tag than we're used to - but I'm confident we can
get that covered between sponsors and sysmocom.
Do you guys think this is a good idea? Or would you prefer the
traditional ad-hoc approach at IN-Berlin?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
we're happy to [very late, sorry] announce the next incarnation of OsmoDevCall.
when:
December 20, 2023 at 20:00 CET
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @laforge will be presenting on
Using pySim-shell with sysmoISIM-SJA5
This meeting will have the following schedule:
20:00 meet + greet
20:10 topic as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello,
I am looking to build a project similar to https://terminal-profile.osmocom.org/decode.php I was hoping I could find the code somewhere in the official repositories to glance at it but I haven't managed to find it. Is the page open source ? If so where could I find the source ?
Thanks !
Martin
I tried to put the server on the public network, and the bankd end and my clients were on my intranet.
As shown below, my public network address is 45.135.135.32, my bankd-side intranet address is 192.168.2.224, and the client-side address is 192.168.2.173. My home broadband is 183.30.220.7I try to establish a connection.
root@lee:~# osmo-remsim-client-st2 -i 45.135.135.32 -V 1d50 -P 60e3 -C 1 -I 0 -H 1-1.2 -c 1 -n 1
DLINP NOTICE simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
DRSPRO INFO ../rspro_client_fsm.c:388 RSPRO_CLIENT(server){REESTABLISH}: Creating TCP connection to server at 45.135.135.32:9998
DLINP NOTICE input/ipa.c:141 45.135.135.32:9998 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:146 RSPRO_CLIENT(server){REESTABLISH}: RSPRO link to 45.135.135.32:9998 UP
DMAIN INFO main_fsm.c:249 CLIENT_MAIN(main){UNCONFIGURED}: Rx configClientBankReq(183.30.220.7:9999 / B1:1)
DRSPRO INFO ../rspro_client_fsm.c:388 RSPRO_CLIENT(bankd){REESTABLISH}: Creating TCP connection to server at 183.30.220.7:9999
DRSPRO ERROR ../rspro_client_fsm.c:357 RSPRO_CLIENT(bankd){REESTABLISH_DELAY}: Event SRVC_E_KA_TERMINATED not permitted
Unable to establish connection
He has been connecting to my home broadband. How to solve this problem? Can anyone help? My dear friends!
Dear Osmocom team,
First of a big thank you for all your effort putting into SIM/eUICC/eSIM
open source projects which help some or other way to sim card enthusiasts
!!!
I wanted to check with you if SIM FPC cable 2FF/3FF/4FF flex pcb
design files are also available as open source to the community similar to
SIM trace design files?
If yes, could you please help me to share the git repo link as I am
unable to find the same.
I am from India. Initially I tried ordering the same from Sysmocom webshop
with help of some vendors but customs rules in India are very strict and it
would cost more than 10 times the actual flex cable cost. as I need to for
personal use, it's not feasible to afford.
Thanks,
Siddhesh
Hello SIMtrace enthusiasts,
As mentioned previously on various occasions, FreeCalypso SIMsniff is
a hardware+FPGA+software solution I put together to serve as a partial
replacement for Osmocom SIMtrace. I call it a partial rather than
complete replacement for SIMtrace because the piece which I consider
to be the essence of SIMtrace (the Sysmocom-made, webshop-sold piece
that goes into the phone's SIM socket) stays the same in my SIMsniff
solution, only the active component changes: instead of using a
SIMtrace1 or SIMtrace2 board, I use my own little hw contraption
(currently a mess, needs to be simplified) to sniff and level-shift
the electrical signals, followed by an iCE40 FPGA for ISO 7816-3
character sniffing. The whole project lives here:
https://www.freecalypso.org/hg/fc-sim-sniff/
Earlier this week I got the last required hw piece assembled (the
mv-sniffer board that hosts my choice of level shifter IC, Nexperia
74LVC4T3144), and I am happy to report that the whole solution works
as designed! The two principal design objectives, which are also
principal differences from SIMtrace1/2, are as follows:
* Make a strictly non-invasive Hi-Z connection to the SIM bus being
traced or sniffed, without Heisenbug-inducing pull resistors or
switches or other artifacts;
* Hi-Z-sniff ME-to-SIM interfaces that can operate at any voltage from
1.8V to 5V.
With my current messy hw setup of two tiny boards (sim-fpc-pasv and
mv-sniffer) inserted between the original SIMtrace FPC cable and the
Icestick FPGA board, the just-stated objectives are met: I can
successfully sniff ME-to-SIM sessions at all 3 voltage classes,
*without* the tracing apparatus altering any electrical aspects of the
interface under study in any way. Here are some examples of what
SIMsniff trace logs look like:
https://www.freecalypso.org/members/falcon/SIMsniff-traces/
The 3 log files in the above directory are:
2190-fcsim1.log: Nokia 2190E talking to FCSIM1
2190-sjs1.log: Nokia 2190E talking to sysmoUSIM-SJS1
fcdev3b-sjs1.log: FCDEV3B (standard fw) talking to sysmoUSIM-SJS1
Nokia 2190E always puts out 5V toward the SIM, hence those two logs
are proof of working 5V sniffing. Calypso+Iota chipset supports 3V
and 1.8V and FreeCalypso fw talks to the SIM at 1.8V by default, thus
the last log is proof of working 1.8V sniffing. The last log also
exhibits switching from F/D=372 to F/D=64 (F=512 D=8), demonstrating
how my sniffer FPGA handles such sessions.
These are very raw, low-level trace logs: each line in the log file is
one 16-bit word received from the FPGA, corresponding to one character
(in the ISO 7816-3 sense) captured on the SIM-ME interface. More
details here:
https://www.freecalypso.org/hg/fc-sim-sniff/file/tip/doc/Sniffer-FPGA-design
To get a human-readable trace of ME-to-SIM interface activity, each
raw log needs to be passed through higher-level decoding utility
simsniff-dec, residing in fc-sim-sniff Hg repository. I invite
interested parties to compile that utility, run it on the raw log
files I posted, and see what kind of trace logs you then get for human
study.
Note of course my very different technology preferences: I don't use
Wireshark, hence I never developed any tools for feeding SIM interface
traces into that world, and I never succeeded in getting the current
incarnation of pySim to run on my system (too much dependency hell,
and Python is too alien to me), hence no integration with pySim-trace.py
either. But just because I haven't developed those pieces doesn't mean
that no one else can! If anyone in the wider Osmocom+FC community
superset likes what I did in electrical terms, but also likes the
original Osmocom SIMtrace high-level sw design better than my
concoction, you should be able to take my simsniff-rx program (the one
that receives traces from the FPGA by way of FT2232H UART channel) and
modify it to emit traces in a way that fits into Osmocom SIMtrace sw
paradigm - why not?
The hardware part also needs polishing: the current arrangement of
separate sim-fpc-pasv and mv-sniffer boards connected with jumper wires
is a mess. My plan is to make a proper FC SIMsniff "pod" board: put
the SIMtrace FPC connector, a physical SIM socket, 2.54 mm headers for
o'scope probing and the 74LVC4T3144 buffer on the same PCB, interconnected
together on the "SIM bus" side, plus a 6-pin header on the 'B' side of
74LVC4T3144 for connecting to the Icestick FPGA board. I am also now
thinking (counter to my original plans) about making a combined
SIMsniff+SIMemu pod, i.e., making just one hw setup that can work for
either sniffing or card emulation by loading different FPGA gateware
and opening/closing a jumper on the "pod" board.
How does card emulation fit into my SIMsniff hw architecture? Answer:
it will be almost the same as sniffing, with only one little hw
component (an OD driver IC) added. The same hw path that passively
sniffs SIM RST, CLK and I/O lines (via 74LVC4T3144) will also work for
cardem, but one more component needs to be added: a 74LVC1G07 OD buffer,
driven by an FPGA output, with the output side of this OD buffer
connected to the physical SIM I/O line. The only active driving done
by real SIM cards is driving the I/O line low in the manner of an OD
output, there is no high drive (the pull-up resistor in the ME is
responsible for making the line go high), and on all other interface
lines the SIM only receives - hence the combination of a Hi-Z receiver
like current SIMsniff plus an OD driver on the I/O line would be a
fully proper emulation of a real SIM card.
My original hesitation against combining SIMsniff and SIMemu pods into
one was that I don't like the idea of the OD driver turning on by
mistake (wrong FPGA loaded perhaps) and fighting with the physical SIM
card in the socket. But my current plan is to insert a jumper (or
more precisely, a pair of 2.54 mm header pins onto which a shorting
block may be placed) between the "SIM bus" I/O line and the output pin
of 74LVC1G07 OD buffer: this way if you insert a physical SIM into the
socket for tracing, remove the jumper, and if you leace the SIM socket
empty for cardem, install the jumper. Why jumper and not a little
slide switch? With the switch there would be the extra cognitive load
of looking at the switch carefully and remembering which position is
which, whereas presence or absence of a shorting jumper on a pair of
pins is an immediate, almost subconscious visual indicator.
Any feedback ideas would be appreciated. When I design my new
SIMsniff+SIMemu "pod" board, I would like to make a large-ish batch
(maybe 20 boards), thus it would be really nice if the same hardware
could be made palatable to both FC and Osmocom communities.
Hasta la Victoria, Siempre,
Mychaela aka The Mother
Hello fellow SIM tracers,
I have my new incarnation of SIMtrace mostly working:
https://www.freecalypso.org/hg/simtrace-ice/
The Hg repository is named simtrace-ice, but the host program binaries
installed by the sw package are named simtrace3-*, following the
installed binary namespace usage convention established by previously
existing simtrace2-*.
Quoting from the README file at the top of the just-linked source
repository, FreeCalypso SIMtrace3 (aka SIMtrace-ice) is an alternative
implementation of Osmocom SIMtrace principal idea, using an iCE40 FPGA
instead of AT91SAMx MCU as the ISO 7816-3 sniffing receiver. The
signals going to the FPGA are outputs from a unidirectional voltage-
translating buffer (Nexperia 74LVC4T3144) whose inputs are connected
to the SIM interface being sniffed. The sniffing apparatus is thus
electrically clean, making only a Hi-Z connection to the SIM interface
being sniffed, and I expect it to work correctly with all voltages
from 1.8 to 5 V.
This new SIMtrace3 gadget is more than just a proposal - most parts of
it have already been implemented and proven working. The multivolt
sniffer board remains to be assembled/populated (I got the PCB and the
components on hand, I just need to make a visit to Technotronix to get
it assembled), but the FPGA gateware and the host programs receiving
and decoding the sniffed bits have already been proven working, using
an FCDEV3B forced into Class B voltage mode to work without the
mv-sniffer component.
The hardware setup is quite minimal: the FPGA board is off-the-shelf
Lattice iCEstick, readily available from various distributors, and the
SIMtrace3-specific custom hw bit will be reduced to just one very
simple board in the final version. The SIMtrace3 sniffer pod will
passively interconnect the SIM interface under study between the FPC
connector (existing SIMtrace FPC cables), a physical 2FF SIM socket
and the Hi-Z input pins of the dual-supply buffer, while the output
side of that buffer will go to header pins, to be connected to the
Icestick board. The 74LVC4T3144 buffer IC will be the only active
component on this board!
My initial emphasis is on sniffing, but my longer plans include cardem
too. I prefer having separate hw setups for the two functions, hence
my design calls for two separate "pod" boards, a sniffing pod and a
cardem pod. The cardem pod will be the sniffing pod (same multivolt
buffer, supporting all voltages) minus the SIM socket, plus a 74LVC1G07
OD buffer for driving the SIM I/O line from the FPGA-emulated card.
The FPGA gateware will of course be different too, but I expect it to
fit into the HX1K FPGA on the same iCEstick board.
It should also be noted that whether people like my design or not, the
name SIMtrace3 is now effectively claimed for this design whose
gateware and host software have already been implemented and whose hw
components are in the process of being finished and polished. If the
people behind SIMtrace1/2 (the original) totally dislike my idea and
would rather build some other successor to SIMtrace2, please call your
version SIMtrace4 - otherwise there will be two different designs each
claiming to be SIMtrace3, which won't help anyone.
M~