Hello, I would like to use openbsc to do a fake base station and osmocombb to do an attack cell phone, to implement a man-in-the-middle attack.
I have two questions:
1. How do I send location updates and authentication information between openbsc and osmocombb,
2. How to use imsi to initiate a location update
thank you very much
Hello everyone,
Silly idea maybe, but would it be possible to port osmocom-bb for
mediatek/intel/qualcomm BBP and replace the current firmware with open one?
I presume it will be a tremendous amount of work, no doubts, but apart from
that, is it theoretically and technically possible? Given root and/or
hardware acces of course, we do not need to preserve the old firmware or
exploit the update process (ie. if specific cert signature is needed for
bbp-soc firmware update)
Note that we do not have to be limited by existing software access to
baseband, and we could use jtag/testpoints/wiring to access the BBP in a
way that will be necessary, similar to way libreboot is currently being
flashed.
Thank you
Marek Sebera
Hello
I tried using burst_gen.py with grgsmtrx, as I can see in the screen, it shows that it has sent the burst to to grgsm trx, but I dont see any transmission from grgsm trx. Please help. Below are the logs of both burst_send.py and grgsm trx. Please let me know where I am going wrong.
burst_gen.py
~/Downgrader/osmocom-bb-fixeria-trx/src/target/fake_trx$ python burst_gen.py -b NB -p 5700 -m TRX
Copyright (C) 2017 by Vadim Yanitskiy <axilirator(a)gmail.com>
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[i] Sending 1/1 NB burst (fn=1001550) to TRX...
grgsm trx:
~/grgsmtrx_xenial/gr-gsm/apps$ sudo ./grgsm_trx
Copyright (C) 2016-2017 by Vadim Yanitskiy <axilirator(a)gmail.com>
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[i] Init Radio interface
[INFO] [UHDlinux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-215-g3b206caa]
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [X300] Using LVBITX bitfile /usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx...
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
[INFO] [DEBUG] [DMA FIFO] Clock rate for BIST calculation: 0
[INFO] [RFNOC] pass (Throughput: 0.0MB/s)
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
[INFO] [DEBUG] [DMA FIFO] Clock rate for BIST calculation: 0
[INFO] [RFNOC] pass (Throughput: 0.0MB/s)
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[WARNING] [MULTI_USRP] The hardware does not support the requested RX sample rate:
Target sample rate: 1.083333 MSps
Actual sample rate: 1.086957 MSps
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[INFO] [NIRIO] rpc_client stopping...
[INFO] [NIRIO] rpc_client stopped.
[WARNING] [MULTI_USRP] The hardware does not support the requested TX sample rate:
Target sample rate: 1.083333 MSps
Actual sample rate: 1.086957 MSps
[i] Init CTRL interface
[i] Init complete
BR
Snehasish
Hi Ravi,
> Can we make usrp to behave like a normal MS with parameters
> of SIM in "test sim" feature from telnet. I am not using any
> real SIM or writer.
Yes, it's possible to use the virtual SIM-card, and this is exactly
what we are doing during the SDR PHY development.
Check out this example from FakeTRX:
https://osmocom.org/projects/baseband/wiki/FakeTRX#Running-mobile-applicati…
> As we pass the make command as " make nofirmware" from osmocombb/src
> directory after enabling the " CFLAGS += -DCONFIG_TX_ENABLE " in
> osmocom-bb/src/target/firmware, will it still be able to transmit ?
No need to change the 'CONFIG_TX_ENABLE'.
This affects only the firmware for Calypso based hardware.
With best regards,
Vadim Yanitskiy.
Hello Community
Can we make usrp to behave like a normal MS with parameters of SIM in "test
sim" feature from telnet. I am not using any real SIM or writer.
As we pass the make command as " make nofirmware" from osmocombb/src
directory after enabling the " CFLAGS += -DCONFIG_TX_ENABLE " in
osmocom-bb/src/target/firmware, will it still be able to transmit ?
--
Best Regards.
Ravi
Hi Craig,
Could you please provide a bit more detailed description
of the change you've sent: what was wrong and what
this change is intended to fix, so I'll push it to gerrit.
Thanks!
With best regards,
Vadim Yanitskiy.
Hi,
> While transmitting the classmark or any message from mobile on
> SDCCH during a call, does it transmit on the frequency we get
> after converting the ARFCN or is there a slight variation ?
I don't get this, what do you mean by 'converting the ARFCN'?
There are two (as I know) possible types of call assignment:
- Early Assignment, when the network allocates TCH/F or TCH/H
right after getting RACH-request from a mobile phone. The
frequency (or a set of them) is indicated in the Immediate
Assignment message.
- Late Assignment, when the network allocates an SDCCH channel
first, where a mobile phone indicates a connection reason
(Paging Response or Service Request) and also indicates the
classmark. Then the network eventually sends the Assignment
Command message, where just like in Immediate Assignment a
new channel data (both FDMA and TDMA) are described.
BTW: please choose a proper subject for this thread and
don't interfere with the existing one because they are unrelated.
With best regards,
Vadim Yanitskiy.
Hi,
I already uncomment the tx support in Makefile file. But when I run on
phone, it said this firmware was compiled without tx support.
How to fix this?
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
Like every year in early December, it is time to discuss as schedule for
OsmoDevCon in the upcoming year.
Note: Ths is about OsmoDevCon, the more private meeting of developers,
*NOT* about OsmoCon, the public conference.
== When, Who, Where ==
I propose the following date for OsmoDevCon 2018:
April 20 - April 23rd, 2018
* Who: Active developers/contributors of Osmocom projects (as usual)
* Where: IN-Berlin, Berlin (as usual)
Please let me know ASAP if that proposed date works for everyone who'd
want to attend. We can still change it now, but I would want to nail
down the date pretty soon.
== Format ==
After the experiment of reducing from 4 to 3 days last year (due to
OsmoCon), we will again go for *four days* in 2018.
However, we should clearly divide the days in a way that e.g. "GSM/3G"
topics are on two days, while SDR+Other topics are on the other days, so
people not interested in some topics can skip one or two days, as
needed.
We could even divide it further like:
* 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...)
* 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.)
* 2 days misc
Regards, and looking forward to meeting you [again] in 2018,
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 Sebastian,
> My query is : my test network is supporting A5/1,2,3. Is it feasible to
> set A5/1 on MS1 (though it supports A5/2 and A5/3 also) and A5/2 for MS2
> (though it supports A5/1 and A5/3 also) for a call in between them using
> "Early Classmark Sending" ???
I think it will work without any problems because the A5/X encryption
is not 'end-to-end' (in our case MS-to-MS), but there are two separate
encrypted sessions between MS1-BTS and MS2-BTS.
With best regards,
Vadim Yanitskiy.