simtrace

simtrace@lists.osmocom.org

345 discussions

by benoit michau

Dear osmocom developpers, This is just to let you know that the Python library pycrate has a new home : https://github.com/pycrate-org/pycrate. The packages on Pypi are now feeded from there. This library can be used in many cases dealing with mobile signalling. I wanted to let you know, as even if I am not aware of any osmocom projects depending on it, some of you may use the library from time to time, or could have local applications depending on it. Best Regards Benoit

1 year, 5 months

onomondo-uicc: open source SIM/UICC/USIM implementation

by Harald Welte

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)

1 year, 5 months

OsmoDevCall 2024-01-17: Exploring eUICC and eSIM using pySim, lpac and osmo-smdpp

by Harald Welte

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)

1 year, 6 months

OsmoDevCon 2024 planning

by Harald Welte

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)

1 year, 7 months

OsmoDevCall on Dec 20, 2023: Using pySim-shell with sysmoISIM-SJA5

by Harald Welte

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)

1 year, 7 months

Source code for https://terminal-profile.osmocom.org/decode.php

by Martin Lees

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

1 year, 7 months

Regarding the issue of placing the server on the public network

by gmaillee＠126.com

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!

1 year, 9 months

SIM FPC cable layout pcb and garter files

by siddhesh bobhate

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

1 year, 9 months

FC SIMsniff works in first prototype version

by Mychaela Falconia

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

1 year, 9 months

Introducing SIMtrace3 aka SIMtrace-ice

by Mychaela Falconia

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~

1 year, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace