simtrace

simtrace@lists.osmocom.org

346 discussions

09 Mar '24

Hello, Here is a patch for handling malformed IMSI If you misswrited your IMSI, it will be impossible to read or edit it again :( This patch fix that Thanks Goodbye

2 1

pycrate repo update
by benoit michau 02 Mar '24

02 Mar '24

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 0

onomondo-uicc: open source SIM/UICC/USIM implementation
by Harald Welte 22 Feb '24

22 Feb '24

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 0

OsmoDevCall 2024-01-17: Exploring eUICC and eSIM using pySim, lpac and osmo-smdpp
by Harald Welte 15 Jan '24

15 Jan '24

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 0

OsmoDevCon 2024 planning
by Harald Welte 26 Dec '23

26 Dec '23

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 0

OsmoDevCall on Dec 20, 2023: Using pySim-shell with sysmoISIM-SJA5
by Harald Welte 20 Dec '23

20 Dec '23

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 0

Source code for https://terminal-profile.osmocom.org/decode.php
by Martin Lees 07 Dec '23

07 Dec '23

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

2 1

Regarding the issue of placing the server on the public network
by gmaillee＠126.com 22 Oct '23

22 Oct '23

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!

2 1

SIM FPC cable layout pcb and garter files
by siddhesh bobhate 22 Oct '23

22 Oct '23

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

2 1

FC SIMsniff works in first prototype version
by Mychaela Falconia 04 Oct '23

04 Oct '23

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 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace