Status of external USSD applications?
Hi all, This is my second email here so I will start with a quick introduction before a question: I’m part of of an early stage company called Hover (www.usehover.com). We offer an Android software development kit written in Java that helps smartphone app developers automate USSD sessions in the background of native apps. A typical use case is to build a nicer user interface for, eg. mobile money transfers or airtime top-up. Colleagues at the University of Washington pointed me to this exciting project, and I have a B210 set up so I can register a phone on an Osmocom network and run *#100# to see my MSISDN from OsmoHLR. Which brings me to my question: I see that Rowan Phipps at UW has modified an earlier version of the Osmocom stack to run arbitrary USSD sessions from a Python web server. It looks like related work was started in 9658 and 9661 [1], [2]. Are these commits working, and what would be the best way for me to contribute to or test this work? I would prefer to run the newer Osmo* projects rather than try to use OsmoNITB. I am in the process of reading Rowan and Fairwaves' work and will happily share anything I learn. As context, we have 50k+ USSD session logs (i.e. menu text, not Wireshark traces) from various markets. My end goal is to be able to test new apps against these logs and otherwise experiment with arbitrary USSD sessions locally. Thank you for any suggestions you can offer. —Michael [1] https://gerrit.osmocom.org/#/c/osmo-msc/+/9658/ [2] https://gerrit.osmocom.org/#/c/osmo-msc/+/9661/
Hi Michael, On Fri, Oct 19, 2018 at 10:56:38AM -0700, Michael Benedict wrote:
I see that Rowan Phipps at UW has modified an earlier version of the Osmocom stack to run arbitrary USSD sessions from a Python web server.
I currently don't recall any such work being discusesd here or being submitted for mainline? Maybe I forgot, my apologies.
It looks like related work was started in 9658 and 9661 [1], [2]. Are these commits working, and what would be the best way for me to contribute to or test this work?
The commits are working and are actually automatically continuously tested against latest master of OsmoMSC, see the test cases starting at http://git.osmocom.org/osmo-ttcn3-hacks/tree/msc/MSC_Tests.ttcn#n2146 and those against OsmoHLR at http://git.osmocom.org/osmo-ttcn3-hacks/tree/hlr/HLR_Tests.ttcn#n778 The test results analyzer of our jenkins at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/test_resul... also shows that all ussd related tests are passing. Please see https://media.ccc.de/v/osmocon2018-61-external-ss-ussd-interface#t=0 for a very current video abut the feature (recorded today at the Osmocom Conference). Also refer to Section 7.1 of the OsmoHLR user manual at http://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, Thank you for the thorough explanation, it's very helpful and gives me a clear path forward. All the best, --Michael
On 19/10/2018 22:43, Harald Welte wrote:
Hi Michael,
On Fri, Oct 19, 2018 at 10:56:38AM -0700, Michael Benedict wrote:
I see that Rowan Phipps at UW has modified an earlier version of the Osmocom stack to run arbitrary USSD sessions from a Python web server.
Hi Michael! Where do you see this? I'd be interested in some links to this related work I think it's nice to also post some link to sources if at all possible when one makes a reference to related work on an open source project mailing list ;-) I found some references to the UW investigation on vulnerabilities in USSD, but Rowan Phipps seems somewhat absent from the public internet. Many Thanks!
The details of the implementation were posted here in January ( https://www.mail-archive.com/openbsc@lists.osmocom.org/msg08419.html). Our understanding was that the recently accepted USSD patches would match much of our functionality so the branch has not seen much active development. I am unsure of the difficulties of integrating ussd-airflow into the current implementation. On Mon, Oct 22, 2018 at 12:57 AM Keith <keith@rhizomatica.org> wrote:
On 19/10/2018 22:43, Harald Welte wrote:
Hi Michael,
On Fri, Oct 19, 2018 at 10:56:38AM -0700, Michael Benedict wrote:
I see that Rowan Phipps at UW has modified an earlier version of the Osmocom stack to run arbitrary USSD sessions from a Python web server.
Hi Michael!
Where do you see this? I'd be interested in some links to this related work
I think it's nice to also post some link to sources if at all possible when one makes a reference to related work on an open source project mailing list ;-)
I found some references to the UW investigation on vulnerabilities in USSD, but Rowan Phipps seems somewhat absent from the public internet.
Many Thanks!
-- Public Key: https://flowcrypt.com/pub/kheimerl@cs.washington.edu
On 22/10/2018 10:18, Kurtis Heimerl wrote:
The details of the implementation were posted here in January (https://www.mail-archive.com/openbsc@lists.osmocom.org/msg08419.html).
Ah Thanks Kurtis! I remember seeing that now.
Our understanding was that the recently accepted USSD patches would match much of our functionality so the branch has not seen much active development. I am unsure of the difficulties of integrating ussd-airflow into the current implementation.
I guess the key might be Rowan's sup_airflow https://github.com/rowanphipps/sup_airflow as the new osmo-hlr external USSD handler basically passes GSUP through from the MSC, IIUC It's now on my list of TODO. Thanks! k
If you make any progress let us know! We're not spending cycles there now but it would be nice to not have our custom fork anymore. On Mon, Oct 22, 2018 at 3:20 AM Keith <keith@rhizomatica.org> wrote:
On 22/10/2018 10:18, Kurtis Heimerl wrote:
The details of the implementation were posted here in January (https://www.mail-archive.com/openbsc@lists.osmocom.org/msg08419.html).
Ah Thanks Kurtis! I remember seeing that now.
Our understanding was that the recently accepted USSD patches would match much of our functionality so the branch has not seen much active development. I am unsure of the difficulties of integrating ussd-airflow into the current implementation.
I guess the key might be Rowan's sup_airflow https://github.com/rowanphipps/sup_airflow
as the new osmo-hlr external USSD handler basically passes GSUP through from the MSC, IIUC
It's now on my list of TODO.
Thanks!
k
-- Public Key: https://flowcrypt.com/pub/kheimerl@cs.washington.edu
participants (4)
-
Harald Welte -
Keith -
Kurtis Heimerl -
Michael Benedict