Hello Holger,
> Couldn't we use a GNU-Radio combined with the GSM-HF-RX? We had a
> student research project which used that with Wireshark. I think I could
> borrow it for a few days and sniff some stuff at our lab. Just tell me
> what sequences you need.
You mean the USRP ? As far as I know its no big problem to save the
raw RF data with it but there is no easy-to-use software yet to get
nice traces from those data (e.g. extract all the different channels
like BCCH, CCCH and so on) which for example could be used to see the
messages between the BTS and the phone. I am not interested in the
traffic (speech or data), just the signaling on the Air-Interface would
be nice to have. But lets see what the future brings, projects like
airprobe.org might fill this gap.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Holger,
> If you need some help in the near future (as soon our equipment arrives,
> orders left the building today... or at least they should): we have full
> equipped and licensed GSM-E1-Analyzers. I think we can provide some
> traces if required (I know that Harald has shoot an ELMI-Abis-Analyzer
> at EBay, just for notice).
Good to know that. What about a GSM Analyzer for the Air Interface :-) ?
In the moment ISDN E1 traces are not that important because its under
control of OpenBSC anyway. The traces of the Siemens specific configuration
commands were done on the RS232 interface of the BS-11, the configuration
software under NDA uses RS232 only, at least I don't have any other
BS-11 specific software which uses the ISDN interface.
I anyone has access to a real GSM Abis Interface and can provide traces
of a working network this could be very interesting to have a look at.
And for tracing the GSM air inteface with cheap equipment, well, lets
hope that we can get something for that in the future...
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Holger,
The following is what I can say, Harald might add more or correct me:
On Mon, 19 Jan 2009 10:15:17 +0100, "Holger Adams" <holger(a)kernreaktor.org> wrote:
>
> as we all know, the documentation of the BS-11 is under NDA. Harald
> said, the BTS respects 99.9% of the A-bis 3GPP standardization. So my
> questions are:
>
> 1) What's the part of the 0.1% we don't know? Which part differs from
> the specs?
There are Siemens specific commands for configuring the BS-11. They
are not documented and also not included in the NDA documentation.
The important commands are however going to become part of OpenBSC.
Harald is currently working on a tool for configuring the BS-11,
it is based on analyzing what the configuration tool (under NDA)
is sending over the wire. So you will most certainly find all the
required information in OpenBSC soon.
> 2) During the 25c3 talk there was mentioned that the BTS uses ~6 DSPs
> and a bunch of uCs. What kind of DSPs and uCs are used (well Siemens...
> I guess some creepy 8051/C16x/... and Motorola stuff)?
Its nothing from the more common stuff. The microcontrollers are
from the HPC family from National Semiconductor, the DSPs are from
the DSP16 family from Lucent. My guess is that the HPC was mainly used
in the telcommunication area, for the DSP16 there was at least one
more common analog modem around which uses it.
BTW, the information about the microcontrollers and the DSPs is also
not contained in the NDA documentation, so this is no secret what I
am writing here.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Everybody,
as we all know, the documentation of the BS-11 is under NDA. Harald
said, the BTS respects 99.9% of the A-bis 3GPP standardization. So my
questions are:
1) What's the part of the 0.1% we don't know? Which part differs from
the specs?
2) During the 25c3 talk there was mentioned that the BTS uses ~6 DSPs
and a bunch of uCs. What kind of DSPs and uCs are used (well Siemens...
I guess some creepy 8051/C16x/... and Motorola stuff)?
Regards,
Holger
--
() Holger Adams, <holger(a)kernreaktor.org>
/\ WWW: http://www.kernreaktor.org
Holger, Harald -
I've been observing TMSI-handling bugs in GSM handsets for a while
and saw a really good one last night, so I'm going to offer some
comments here.
> On Sat, Jan 10, 2009 at 01:40:33AM +0100, Holger Freyther wrote:
> > Hey Guys,
> >
> > I'm currently implementing the CM Service Request of GSM 04.08
> and I wonder
> > about the following:
> >
> > 1.) Some phones send us the TMSI of their current network
> > 2.) One can ask the phone for the IMEISV/IMSI
> > 3.) One can accept the LOCATION UPDATING REQUEST (or wait)
> > 4.) A rogue MS could now request a channel with the BTS of the
> original
> > network
> > 5.) Could send a CM Service Request with the TMSI of the
> original phone and
> > claim to not support A5 and such...
> > 6.) Could initiate a call on the behalf of the other phone...?
>
> I think this would work, if
> * we had a MS that we could fully control.
> * the old network would accept the sudden classmark change for no
> A5 support,
> which in fact also depends on the cell itself. I would assume
> that most
> BTS in real-world netwokrs never announce that they support A5/0
According to GSM 02.07 Section 2, all GSM handsets are required
support A5/1 and A5/2. According to GSM 02.09 Section 3.3, the
network is SUPPOSED to deny service to any handset that doesn't
support either A5/1 or A5/2. I'd be curious to see who's enforcing
that, though. And any prudent operator will do an authentication at
the start of a call, even for A5/0. Again, I'd be curious to see
who's really doing it, but I'll bet most European operators do.
You may not need to fully controlled a handset to do this, though.
This is where TMSI handling bugs come into play. Last night, I was
playing with a Treo 650. Having last registered in an AT&T network,
the Treo sent a location updating request to my system (MNC=910,
MCC=55) using that AT&T TMSI, which it is not supposed to do. I
removed the SIM and cycled power. THAT should have cleared the old
TMSI, but it came back to register by TMSI again. I sent a location
updating accept, without sending a new TMSI. THAT should have
cleared the old TMSI, but when I tried to place a mobile-oridinated
call the Treo sent the same old AT&T-assigned TMSI in the CM service
request. I am certain that if I had assigned a new TMSI to this
handset and then switched off my system, that Treo would have taken
my TMSI back the the AT&T network and tried to use it there.
I suspect this kind of bug is fairly common and may be exploitable by
a rogue network, even if only to expose the IMSI-TMSI relationships
in the real carrier's BSC.
As Harald points out, the attack described in the original e-mail
should not work in a properly managed network. But I'll wager that
most of the world's networks are not properly managed.
-- David
David A. Burgess
OpenBTS on the web:
http://openbts.sourceforge.nethttp://openbts.blogspot.comhttp://en.wikipedia.org/wiki/OpenBTShttp://www.gnuradio.org/trac/wiki/OpenBTS
Hi,
did subscribe to the list, got a password and now trying to get the svn trunk with zero success!
What are the required credentials since my email & the provided password won't help
Cheers,
Mike
On Sat, 10 Jan 2009 12:38:54 +0900, "Harald Welte" <laforge(a)gnumonks.org> wrote:
> The IMSI ATTACH/DETACH procedure is an optional procedure that the BTS can
> demand by setting some flag in SYSTEM INFORMATION on the BCCH.
>
> If enabled, the MS will use a special IMSI ATTACH flag in the location update,
> and it has to send an IMSI DETACH message before it is switched off. Not sure
> how useful that really is... but I definitely want support for it in OpenBSC
> (optionally). Probably time for a config file ;)
As I understand it, the IMSI Attach/Detach, which is signaled by the
ATT flag in SYS_INFO 3 is used to keep track if a phone is actually
available. (IMSI Attach is used when the phone is turned on and
IMSI Detach when it is turned off). This way the network does not
need to page the phone if it knows that it is turned off and
can immediately signal to the caller that the phone is not
available. If I remember, the ATT flag is not set in the
BS11_Init sample code.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hey Guys,
I'm currently implementing the CM Service Request of GSM 04.08 and I wonder
about the following:
1.) Some phones send us the TMSI of their current network
2.) One can ask the phone for the IMEISV/IMSI
3.) One can accept the LOCATION UPDATING REQUEST (or wait)
4.) A rogue MS could now request a channel with the BTS of the original
network
5.) Could send a CM Service Request with the TMSI of the original phone and
claim to not support A5 and such...
6.) Could initiate a call on the behalf of the other phone...?
7.) What is IMSI detached, I have not yet seen it... but it could solve such
things? So far I have only seen TMSI reallocation complete messages...
what am I missing? These messages are not encrypted right? One just would need
to know the right channel/paging group and such? Is this known? plausible?
totally off?
z.
_______________________________________________
OpenBSC mailing list
OpenBSC(a)lists.gnumonks.org
https://lists.gnumonks.org/mailman/listinfo/openbsc
Hi!
I have created openbsc-commits(a)lists.gnumonks.org which carries all commits
to our svn server. I thought some people might like to receive all the diffs
in their inbox to stay up-to-date with the code...
Cheers,
--
- 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 all,
what ist the best/fastest way to get a license from Bundesnetzagentur?
Thanks
Marcus
--
Marcus Specht
open|MVNO
c/o Cyber-Dynamix Gesellschaft für Systemintegration GmbH
Heiner-Stuhlfauth-Str. 28
90480 Nürnberg
Tel.: 0911 / 1809105
Fax.: 0911 / 1809109
Geschäftsführer: Heiko Thierbach, Gerhard Feder
Sitz der Gesellschaft ist Nürnberg
Amtsgericht Nürnberg, HRB 16704
Ust-Id.-Nr. DE204640808
------------------------------------------------------------------------------
Diese Nachricht ist eine nicht öffentliche Mitteilung.
Sollten Sie diese Nachricht versehentlich erhalten haben
und nicht der gewünschte Empfänger sein,
so bitten wir Sie, diese Nachricht zu löschen, keine
Kopien anzufertigen und nicht weiterzuleiten. Bitte
informieren Sie uns per eMail über den Zustellungsfehler
und entschuldigen Sie die Unannehmlichkeit.
Bitte beachten Sie: Unabhängig vom Inhalt stellt diese
Nachricht keinerlei vertragliche Verpflichtung,
Zusicherung, Bestellung, Angebot oder ähnliches dar,
solange keine schriftliche Bestätigung von uns vorliegt.
_______________________________________________
OpenBSC mailing list
OpenBSC(a)lists.gnumonks.org
https://lists.gnumonks.org/mailman/listinfo/openbsc
