usrp-motherboard-backtrack-insideFew years ago we decided to [were hired, agreed to, whatever...] build “plug and play” Linux distribution for play with USRP (Universal Software Radio Peripheral). Ultimate solution was not completed for various, for this article unimportant reasons, but during elaboration & testing many sources were gathered and I tried to document almost every step of building, so it would be trivial reproduce. Before it gets completely ancient I am releasing all my notes as unfinished article in hope that it may help somebody. You know, sometimes just a small hint stands between solution and hours of Googling. Please note that this paper was last modified 17.10.2012 and some parts may be outdated or with broken links.


The information and reference implementation is provided:

–> for informational use only as part of academic or research study, especially in the field of GSM networks.

–> as-is without any warranty, support or liability – any damages or consequences obtained as a result of consulting this information if purely on the side of the reader

–> NOT to be used in illegal circumstances! You don’t want to use a frequency that’s already occupied, because you risk disruption of service in a public network. Interfering with radio transmissions is a criminal act in most countries. Before you start, make sure no neighbor’s phone can attach to your system!


–> I am not a GSM expert, this article contain mostly well known stuff. I just wrote down some stuff based on old archives, official pages, mailing list responses & my experiences and experiments with OpenBTS / USRP I on BackTrack Linux.

–> nothing about GSM eavesdropping here.

Running OpenBTS is a lot more expensive than other stuff. As of time this article is written you will need hardware priced around $1200 (depends on parts you choose) to follow it. However new announced project indicates this may change in near future.

0×00 – preface

I have been using USRP I with various dautherboards on custom (unofficial) versions of BackTrack 4 for long time. During the time I have discovered many high quality publications written by university students, security researchers and enthusiasts in this area. There are a lot of radio amateurs, network builders, researchers and people with all kind of approvals for using GSM band trying to make USRP working with various Linux distributions (which become now outdated) as a base for experiments so following was a bit hard. Mounting external clock, playing with GNU Radio, GRC, AirProbe, OpenBTS, programmable SIM cards and various RF software means you have to check many projects and resources + experiment on your own. Additionally a group of smart phone mallware analyze team uses BTS based on OpenBTS for cell phone mallware analysis. Searching and reading all those various websites, mailing lists and Wikis was a bit time consuming especially when comes to GSM stuff. There are various versions, (un)compatible packages and configurations people needs to understand to properly set up own OpenBTS.

Compiling all stuff together is sometimes like assembling puzzle. BackTrack 5 seems to be a good choice, even Range Networks OpenBTS Development Kit uses Ubuntu 10.04 My decision was mainly based on fact, that I am BackTrack user since BT2 and I won’t reboot to another system when switching from pentesting to RF stuff. All software goes to newly created directory under /pentest/usrp/

Please remember BackTrack 5 R2 by default has a single root user, all applications are running with root privileges. This cook book was made for desktop testing, not for production machine, so resolve your security needs accordingly.

Running OpenBTS @ BackTrack 5

Tested on: BackTrack 5 R2, KDE & GNOME (32bit)


0×01 – hardware

USRP 1 & 2x RFX900 boards + external clock

Universal Software Radio Peripheral – The USRP1 has four daughterboard slots. Two for receiving and two for transmitting. It contains four 12 bit ADCs (two for every receive board), that have a sampling rate of 64 Samples per second. Nyquist’s theorem states that you need a sampling rate of at least 2 times the frequency you wish to capture in order to be able to reconstruct the signal. Therefore the USRP1 can capture a bandwidth of 32 MHz at once, for every receive daughterboard. In a simple USRP + RFX setup, range is around 10m in the low bands and limited by crosstalk, not downlink power. USRP with additional RF equipment is capable of covering 1.5-3km, but may not pass the GSM Standard conformance tests. (taken from OpenBTS mailing list –> A. Chemeris)


Cell phones

Because of clock issue (see further explanation) there are limited amount of phones able to register on default clock. Please keep in mind you might have hard time to find phones able to camp to OpenBTS. For comfortable and undisturbed research use external 52 MHz clock.


Before we go any further there is one important thing you need to understand – USRP clock. The default clock of the USRP 1 is 64MHz. The “clock point” is well described in GNU Radio home page or GSM 05.10 Section 5.1, so please check there if you need deep understanding. GSM clocks are derived from a 13 MHz so multiples of 13 are “good clocks” for the host. Reclocking the USRP to 52 MHz will make your host more CPU efficient. You need to make hardware modifications to the USRP to use a external clock. For instruction see GNU Radio home page & OpenBTS for dummies.

Based on my experiences there are some phones (SE K530i, SE Z550i, Nokia 2630) able to attach to OpenBTS 2.6 running on USRP 1 with default clock, but it’s a bit weird. As of October 2011 OpenBTS-UHD lost support for 64 MHz clock, few months later operation was unlocked. Current OpenBTS P 2.8 also doesn’t support 64MHz clock at all. The feature was removed because it causes a lot of issues throughout the system and its generally a bad idea.

As far as i know, there are two major external clocks around OpenBTS community -> FA-SY and Clock Tamer. But feel free to experiment, many people succeeded also with various crystals.


The Fairwaves СlockTamer, a configurable 2MHz – 65MHz reference clock generator with 0.28ppm TCXO. Can be calibrated against existing GSM network to better then 50ppb precision. Has option to sync clock to GPS. Please read project documentation / Wiki which is quite comprehensive.

FA-Synthesizer - FA-SY 1

Programmable from 10 to 160 MHz. Requires modification to decrease its output voltage to prevent USRP input burn out. For calibration, there is Windows software for called USB_Synth.exe It relies on proper recognition of USRP in Windows operating software, so libusb0.dll is included to handle this. Software itself is a bit weird in my opinion, try it or see another way of calibration listed below.



There is a short mention about FA-SY 2 by Konrad Meier (2010-12-02 ) in openbts-discuss e-mail archive with following text:

Today I assembled the new FA-SY 2 from Funkamateur. The clock worked without any problem with the USRP. I calibrated the clock with Kal and got a max frequency offset of +-60Hz which is very close to the required 0,05 ppm/ 0,1ppm for a BTS. I configured the clock to 52 MHz output. I think the FA-SY 2 is with an output level of 0,7V is more suitable than the FA-SY 1 with CMOS output level. Like Andy Fung mentioned some time ago the input level for the AD9513 should not be more than 2 V. So the FA-SY 2 is more suitable for the USRP. Maybe someone can updated this info in the wiki.

… so if you see following:

FA-SY2 can be bought for 45 euros, and might theoretically be usable, but nobody has reported using it successfully yet. Check the list.

in latest OpenBTS for dummies (August 31, 2011), you might realize this is no longer valid comment.


easy to mount and cheap external oscillator for OpenBTS enthusiasts and GSM researchers. Clock was initially created for USRP 1 but can be used also with others – you must specify frequency in the order. This nice piece of hardware might be what are you looking for. Credits for developing GASCLCL01 belongs to SPECTRE SRL company.


Precision: 0 ppm frequency accuracy on all outputs Low phase jitter of 0.7 ps RMS typ input reference: 25MHz crystal External feedback mode allows zero-delay mode, core: Si5338, wide temperature range: -40 to +85 °C. Rady to use, perfectly suitable on the usrp external clock connector. Customizable output. Not for sale anymore.

Clock accuracy

According to GSM 05.10 Section 5.1 the BTS shall use a single frequency source of absolute accuracy better than 0.05 ppm for both RF frequency generation and clocking the timebase.

Taken from GNU Radio Wiki:

The typical GSM handset has a medium-quality VCTCXO. On a cold start, not locked to any outside clock, this clock has a an accuracy of around 20 ppm, or about 18 kHz in the low bands (850/900) and about 36 kHz in the high (1800/1900) bands. So, starting „cold“ with no information, the phone runs a time-consuming frequency search over the whole possible drift range of its own clock and continues this search until it finds a beacon signal from a BTS. Once the phone finds a beacon, it uses the carrier from the BTS to correct its own local clock by adjusting the control voltage on the VCTCXO. From that point on, the VCTCXO is just as accurate os the BTS clock as long as it is receiving the BTS signal.

.. so you need to calibrate your clock very accurately!


Kalibrate, or kal, is a program to help calibrate external clocks for the USRP. Kalibrate also scans GSM frequency bands and looks for base stations. It calculates the offset between your local oscillator and a GSM base station’s oscillator. Relies on some dependencies (usrp >= 3.3), install GNU Radio first. Use non-UHD version of kalibrate to use with USRP1.

Non-UHD version of kalibrate

wget http://ttsou.github.com/kalibrate-uhd/kal-v0.4.1.tar.bz2

tar xjf kal-v0.4.1.tar.bz2

cd kal-v0.4.1




cd src

./kal -h

Turn on USRP and check that your antenna is connected to the correct port (side B, port RX2). Examples:

kal-v0.4.1/src$ ./kal -s GSM900 -F 52M

kal: Scanning for GSM-900 base stations.


chan: 22 (939.4MHz – 17.715kHz) power: 2937.72

chan: 37 (942.4MHz + 32.305kHz) power: 4276.09

chan: 44 (943.8MHz + 5.796kHz) power: 13703.85

chan: 86 (952.2MHz – 17.575kHz) power: 4264.65

chan: 102 (955.4MHz + 32.250kHz) power: 3072.64


kal-v0.4.1/src$ ./kal -c 44 -F 52M

kal: Calculating clock frequency offset.

Using GSM-900 channel 44 (943.8MHz)

average [min, max] (range, stddev)

+ 5.809kHz [5796, 5826] (30, 7.690119)

overruns: 0

not found: 0

Note from mailing list [A. Chemeris]:

Kalibrate shows ARFCNs of your operator’s BTS’s and thus those are ARFCNs you should *NOT* use. Or you will get interference from those BTS’s and you will interfere with them, which is even more bad. Also note, that most BTS around you most likely have multiple TRX’s and secondary TRX’s are not shown by Kalibrate, because they don’t carry FCCH. They’re are not always transmitting and thus may be invisible at usrp_fft normal view. I recommend you to find clean spectrum with a waterfall view of usrp_fft to ensure you don’t interfere with a secondary TRX’s of surrounding BTS’s.

0×02 – dependencies


Boost provides free portable peer-reviewed C++ libraries.


tar xvzf boost_1_47_0.tar.gz


./b2 install


SDCC – Small Device C Compiler. Beware the installation procedure overwrites in /usr/local/bin and share, so backup things you might need in there. Many recent Linux distributions have moved to sdcc-3.0 which prevents the driver from being configured. The quick solution in this case is to use sdcc-2.9 or disable the usrp firmware part of build.

wget http://sourceforge.net/projects/sdcc/files/sdcc-linux-x86/2.9.0/sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2

tar xvf sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2

cd sdcc

cp -r * /usr/local


The GNU Scientific Library (GSL) is a collection of routines for numerical computing.

wget ftp://ftp.gnu.org/gnu/gsl/gsl-1.15.tar.gz

tar xvzf gsl-1.15.tar.gz

cd gsl-1.15



make install

Other dependencies

Since BackTrack 5 is based on Ubuntu Lucid (10.04) following dependencies are required:

apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ automake autoconf libtool python-dev libfftw3-dev libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc sdcc-libraries libsdl1.2-dev python-wxgtk2.8 git-core libqt4-dev python-numpy ccache python-opengl libgsl0-dev python-cheetah python-lxml doxygen qt4-dev-tools libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4

GNU Radio Companion

Before we start with GNU Radio, you might want to install GNU Radio Companion. Skip this step if OpenBTS is your single point of interest GNU Radio Companion (GRC) is a graphical tool for creating signal flow graphs and generating flow-graph source code. GRC is really handy for receiving with various daughterboards (e.g. LFRX, WBX, TVRX)

apt-get install gnuradio-companion

Get some inspiration and examples from Alexandru Csete.

git clone https://github.com/csete/gnuradio-grc-examples

If you want to play with GRC, install it at this point, because you can screw up your GNU Radio installation if you do it later.

GNU Radio

To build and run OpenBTS you mainly need to have installed USRP driver library libusrp. This is available via GNU Radio.You do not need all of GNU Radio, just libusrp. However if you want to use more boards for different approach you will need more than libusrp. Do not use GNU Radio ver. 3.5.0. (removed USRP1 support). For GNU Radio ver. 3.3 and higher no changes to GNU Radio are necessary, You don’t have to modify GNU Radio to run OpenBTS, but you have to modify it to run usrp_fft.py If you need them, then you should apply patch. GNU Radio ver. 3.4.x should work fine.

Version 3.4.2 should work fine if libusrp is properly built.

wget http://gnuradio.org/releases/gnuradio/gnuradio-3.4.2.tar.gz

tar xvzf gnuradio-3.4.2.tar.gz

cd gnuradio-3.4.2

./configure –disable-docs –disable-doxygen


make install

Testing GNU Radio

You are now ready to use GNU Radio. You can try to execute the dial_tone.py example:


python /usr/local/share/gnuradio/examples/audio/dial_tone.py

python /usr/local/share/gnuradio/examples/audio/multi_tone.py

0×03 – Start USRP

Plug the Power cord into the USRP. You should see a green LED blinking at about 2Hz (twice a second). After the firmware is loaded it blinks once a second. Led blinking 3 – 4 times a second means that the firmware is not loaded.

Testing the USRP

You can check if the USRP is being recognized, by examining /dev/bus/usb after plugging in a USRP. Using the command:

ls -lR /dev/bus/usb | grep usrp

should look like:

root@bt:~# ls -lR /dev/bus/usb | grep usrp

crw-rw—- 1 root usrp 189, 4 2011-12-08 11:29 005

And test throughput by running

python /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py


or by running lsusrp:

root@bt:~# lsusrp

USRP 0 serial number 4cXXXd9f

RX d’board A: Flex 900 Rx MIMO B

RX d’board B: Flex 900 Rx MIMO B

TX d’board A: Flex 900 Tx MIMO B

TX d’board B: Flex 900 Tx MIMO B

or by python script usrp_probe which will have a bit graphical output.

0×04 – Asterisk (PBX)

Asterisk is software that turns an ordinary computer into a communications server. The Asterisk software includes many features available in proprietary PBX systems: voice mail, conference calling, interactive voice response and automatic call distribution.

wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-

tar xvzf asterisk-

cd asterisk-



make install

make samples

Run Asterisk (more or less verbose) and check if running correctly. My favorite is asterisk -vvvc (very verbose + CLI) for some reason.

root@bt:~# ps ux | grep asterisk

root 28789 9.6 0.5 47328 17736 pts/5 Sl+ 21:34 0:01 asterisk -vvvc

To provision an IMSI into Asterisk you will need to modify two files: sip.conf and extensions.conf. These files are normally located in /etc/asterisk. Other commands you might find usefull →

core show help | sip show users | sip show settings | core restart gracefully | reload

Call to another operator is possible, connect your asterisk server to an external VoIP trunk, but finding a retail carrier to handle speech and SMS at the same DID is not easy at all.

For home testing is enough to have one VoIP number (e.g. 311249800) and configure Asterisk as client registred to VoIP service provider gateway. Outgoing calls are then redirected through this number and only one outgoing call is possible.

If you call (following configuration matches 9-digit number) from MS connected via OpenBTS to an external network, the called side shall see the VoIP number from your provider (in our case 311249800).

To configure outgoing calls you have to add in /etc/asterisk/sip.conf lines like:


register => 333249700:mypassword:[email protected]









in /etc/asterisk/sip.conf:

exten =>_XXXXXXXXX,1,Dial(SIP/${EXTEN}@ha-loo_trunk)

This is only the basic working setup and can’t be considered ideal, I suggest to learn about basic configuring of Asterisk for better understanding.


An International Mobile Subscriber Identity or IMSI is a unique identification associated with all GSM network mobile phone users. It is stored as a 64 bit field in the SIM inside the phone and is sent by the phone to the network. An IMSI is usually presented as a 15 digit long number. The phone registration is based on the IMSI number stored in the SIM Card. In Linux one can use script getimsi.py written by Alexsander Loula. Script depends of the Python serial module to control the phone over serial (RS-232 or USB through AT commands. I have been successful with Sony Ericson K530i, but script always skip first digit (for unknown reason). Since first tree digits always consist of MCC (mobile country code) it shouldn’t be hard to figure out.


This is limited with nowadays phones, so get some programmable SIMs as described later or use other methods (Asterisk CLI) to get IMSI from your phones. In order to make calls you need properly set up Asterisk.

Create a SIP user in sip.conf and add extension to extensions.conf For one cell phone it looks like this:

kwrite /etc/asterisk/sip.conf and add follworing content (replace 231082462443021 with your IMSI)








kwrite /etc/asterisk/extensions.conf and add follworing content (replace 231082462443021 with your IMSI)


exten => 444,1,Macro(dialGSM,IMSI231082462443021)

Also add following macro to extensions.conf


exten => s,1,Dial(SIP/${ARG1})

exten => s,2,Goto(s-${DIALSTATUS},1)

exten => s-CANCEL,1,Hangup

exten => s-NOANSWER,1,Hangup

exten => s-BUSY,1,Busy(30)

exten => s-CONGESTION,1,Congestion(30)

exten => s-CHANUNAVAIL,1,playback(ss-noservice)

exten => s-CANCEL,1,Hangup

Soft phone – Twinkle

Twinkle is a softphone for voice over IP and instant messaging communications using the SIP protocol. You can use it for direct IP phone to IP phone communication or you can call from your PC to cell phone over Asterisk and OpenBTS.

apt-get install twinkle

Asterisk runs SIP on UDP port 5060 and RTP on UDP ports 16386-16483. These are configurable in the sip.conf file. In order to call from Twinkle to cell phone you will need to change SIP port to 5061 in Twinkle system settings – Network.

Again create another SIP user in sip.conf and add Twinkle (666) and Asterisk cmd Echo (600) extension to asterisk.conf






callerid=“backtrack“ <666>










exten => 666,1,Macro(dialSIP,softPhone)

exten => 600,1,Playback(demo-echotest)

exten => 600,2,Echo

exten => 600,3,Playback(demo-echodone)


exten => 666,1,Macro(dialSIP,softPhone)

exten => 600,1,Playback(demo-echotest)

exten => 600,2,Echo

exten => 600,3,Playback(demo-echodone)

Once you call number 600 you should hear Echo Test program. This Echo Test could be very useful for testing if your SIP client is working properly. Also check Asterisk CLI for successful registration.


Twinkle echo test


There are other SIP clients like X-Lite, Jitsi or Zoiper if you don’t like Twinkle.

0×05 – Subscriber Identity Module (SIM)

SIM is provided to a subscriber as a smart card; a SIM card. It contains a users identity in a GSM network and is dependent on a network provider. I prefer to use programmable SIM cards like Super SIM, Magic SIM or SIM MAX from Honk Kong e-shop. They are really cheap and with USB Card Reader/Writer.


Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Please remember you can not clone original SIM cards.



Python utility to program it with parameters you like is PySim.

git clone git://git.osmocom.org/pysim.git /pentest/usrp/sim

This utility allows to “reprogram” customizable SIM card as you wish. Two modes are possible, please read README and ./pySim-prog.py -h or just follow my steps:

- specify every parameter manually :

./pySim.py -n operator_name -c CC -x MCC -y MNC -z <random_string_of_choice> -j <card_num>


./pySim-prog.py -n BT_BTS -c 49 -x 231 -y 8 -i 231082462443021 -s 8949231081151665704

- generate from some minimal set :

./pySim.py -n operator_name -c CC -x MCC -y MNC -i <IMSI> -s <ICCID>

- ICCID must be 19 digits


./pySim-prog.py -n BT_BTS -c 49 -x 231 -y 8 -t auto -z “secret” -j 0 -d /dev/ttyUSB0

0×06 OpenBTS

The Open BTS Project is an effort to construct an open-source Unix application that uses the Universal Software Radio Peripheral (USRP) to present a GSM air interface to standard GSM handset and uses the Asterisk VoIP PBX to connect calls.

OpenBTS 2.6 does not use encryption. At the time of writing this article Range Networks is working on authentication and encryption code for OpenBTS 2.8 USRP1 can not handle Multi-ARFCN, because the software doesn’t support it yet. A single-ARFCN BTS supports 7 calls. One phone calling another in the same BTS is *2* calls: phone #1 calling the switch and the switch calling phone #2. If they call external network, then it’ll be 7 phones calls, but if they call each other, it will be 3 phone call max.

Thomas Tsou continues to refine his Multi-ARFCN implementation. Currently it supports UHD devices only and he has started to work on USRP1 support. Also he started to pushing out his NEON optimized code for OpenBTS transceiver. All Thomas’ new code is here:


The range of OpenBTS itself is 35 km. The range you actually *get* will depend your hardware. With a stock USRP and RFX and no other hardware, your range is limited by poor isolation of rx and tx. Basically, there’s a lot of tx power bleeding into your rx side and that is degrading your ability to receive the phone. You are interfering with yourself. In these cases, reducing the tx power will usually improve performance by reducing the interference. The real solution is to use isolation filters or a duplexer to give proper tx/rx isolation. For GSM systems, this isolation needs to be on the order of 140-170 dB, depending on your output power.

There are currently two maintained versions and many branches of OpenBTS (single ARFCN implementation). OpenBTS 2.6 / OpenBTS-UHD 2.6, OpenBTS P2.8 / OpenBTS-UHD P2.8.

In the time of writing this article the best choice for me is OpenBTS-UHD 2.6 configured for USRP I but you should always consider recent versrion which is P 2.8


apt-get install libosip2-dev libortp-dev


If you do not intend to use smqueue (SMS), you can install the Debian package libosip2-dev. But if you need smqueue, you’ll have to recompile a newer version.

OpenBTS 2.6

Previous P2.6 (“Mamou”) on Sourceforge.net is pretty obsolete now, but if your clock didn’t arrived yet and you want to take a look at unsupported older (2010-08-01) version:

wget http://sourceforge.net/projects/openbts/files/openbts-2.6.0Mamou.tar.gz

tar -xf openbts-2.6.0Mamou.tar.gz

cd openbts-2.6.0Mamou



make install

Depends on clock you use modify TRX.Path under OpenBTS.config If you are not sure verify, by following command:

OpenBTS_2.6_Mamou/apps# cat OpenBTS.config | grep TRX.Path

TRX.Path ../Transceiver/transceiver

#TRX.Path ../Transceiver52M/transceiver

so you see TRX.Path is pointing to “../Transceiver/transceiver” which is “good” only for default 64MHz clock. Or you can try latest UHD with 64 MHz “support”


OpenBTS-UHD 2.6 “Mamou”

The best choice for 2.6 is OpenBTS-UHD, which is a rewrite of substantial parts of the underlying transceiver code along with additional outside patches. The original goal of the UHD tree was specifically to expand hardware support to capable devices. All UHD specific changes are strictly confined to the transceiver and the original API remains intact. In order to run UHD version with USRP 1 don’t forget to configure with –with-usrp1 option.

The usrp1 option enables special USRP1 support with timestamps using the GNU Radio driver. GNU Radio is required, but not UHD.

git clone git://github.com/ttsou/openbts-uhd.git


./configure –with-usrp1


make install

cd apps/

cp OpenBTS.config.example OpenBTS.config

If you are using a single daughterboard. (Tx and Rx on side A, side B is unused):

./configure –with-usrp1 –with-singledb

No need to modify TRX.Path in OpenBTS.config in OpenBTS-UHD or P 2.8 release. This is only valid for previous (old) OpenBTS with 64 MHz “support”. Review OpenBTS.config file and change options according to your needs and local BTS towers. Please edit with precaution!


Logging level.






GSM.Band 900


Run OpenBTS-UHD 2.6



With closed registration, if OpenBTS doesn’t receive an OK to the register SIP message, it rejects the user. In open, it does not. Assuming you already have all Asterisk modification corresponding with OpenBTS.config.


Insert programmable SIM card to your phone, in settings somewhere hit something like “GSM only” and try to search for OpenBTS. If you are lucky (clock!) your cell phone will attach automatically to your newly crated BTS automatically and you will receive an SMS with your IMSI.


If not, just connect manually. You will see registration in Asterisk console and can be verified from OpenBTS CLI too by tmsis command.


Sending SMS from OpenBTS CLI


And make test call between phones [or call your registered cell phone from Twinkle]:


Once you hit “Answer”, watch Asterisk CLI:


OpenBTS P2.8 “Opelousas”

The current P2.8 does not support 64 MHz clocks. That said, the P2.6 64 MHz transceiver will probably work with the P2.8 GSM stack, giving the usual alarms for unsupported commands. How is OpenBTS P2.8 “Opelousas” different from the previous P2.6 “Mamou” release? Please check Range Network’s Wiki for details.


apt-get install autoconf libtool libosip2-dev libortp-dev libusb-1.0-0-dev g++ sqlite3 libsqlite3-dev erlang

Configure and build:

cd /pentest/usrp/

svn co http://wush.net/svn/range/software/public

cd public/openbts/trunk

autoreconf -i

./configure –with-usrp1


Set up:

mkdir -p /usr/local/share/usrp/rev4/

cp /pentest/usrp/public/openbts/trunk/Transceiver52M/std_inband.rbf /usr/local/share/usrp/rev4/

cd /pentest/usrp/public/openbts/trunk/apps/

ln -s ../Transceiver52M/transceiver

mkdir /etc/OpenBTS

OpenBTS.db is the database store for all OpenBTS configuration. So same as OpenBTS.config in previous versions, please modify according your needs. (Band, MCC, MNC, ARFCN…)

sqlite3 -init ./apps/OpenBTS.example.sql /etc/OpenBTS/OpenBTS.db

Easiest way to do it is sqlite3 command line tool or sqlite-manager – Firefox extension



cd /pentest/usrp/openbts-2.8/public/smqueue/trunk

autoreconf -i



sqlite3 -init smqueue/smqueue.example.sql /etc/OpenBTS/smqueue.db

Subscriber Registry

mkdir /var/lib/asterisk/sqlite3dir

sqlite3 -init subscriberRegistryInit.sql /var/lib/asterisk/sqlite3dir/sqlite3.db

cd /pentest/usrp/openbts-2.8/public/subscriberRegistry/trunk/configFiles

sqlite3 -init subscriberRegistryInit.sql /var/lib/asterisk/sqlite3dir/sqlite3.db


cd /pentest/usrp/openbts-2.8/public/subscriberRegistry/trunk


cd ..

sqlite3 -init sipauthserve.example.sql /etc/OpenBTS/sipauthserve.db

Check if you have all tree files in /etc/OpenBTS

/etc/OpenBTS# ls

OpenBTS.db sipauthserve.db smqueue.db


cd /pentest/usrp/openbts-2.8/public/openbts/trunk/apps


cd /pentest/usrp/openbts-2.8/public/subscriberRegistry/trunk





Please check Range Networks Wiki and OpenBTS P 2.8 manual & BuildInstallRun instructions for more information.

Analyzing BTS with cell phone

Even without USRP you can get basic informations about near by BTS. Android apps like Netmonitor, RF Signal Tracker, or Open Signal can provide informations like network type, locateion / distance, signal streth, MCC, MNC, CID, LAC, RNC. If you are curious about what kind of encryption / frequency hoping (if any) does your provider use or you can try to ask or old Nokia 3100 will be the second easiest way. Once you enable NetMonitor and dial some number you will see encryption type and status of channel frequency.

0×07 Analyzing the spectrum with USRP

Simplest way to look around is run following script:

python /usr/local/bin/usrp_fft.py -h

python /usr/local/bin/usrp_fft.py -f 912M


As you can see there is a peek around 784 MHz so this would not be a good place for us. The spikes are the frequencies (carriers) used by the operator. It is extremely important you don’t use a frequency that’s already occupied, because you risk disruption of service in a public network.


AirProbe is the new home of the former GSM-Sniffer project. Tools you should have are Gnuradio, AirProbe and USRP, Baudline, usrp_bimbo which is included in dsp_buttler, arfcncalc, Wireshark – already included in BackTrack.

git clone git://svn.berlin.ccc.de/airprobe

To successfully build AirProbe you will need libosmocore >= 0.3.1

git clone git://git.osmocom.org/libosmocore.git

cd libosmocore/

autoreconf -i



make install

Also if you are looking for GPRS support you might take a look at AirProbe with a simple GPRS support by A. Chemeris.

git clone https://github.com/chemeris/airprobe-gprs.git

Building AirProbe

Build all 3 parts of AirProbe as described on homepage. Build the frame decoder:

cd airprobe/gsmdecode




Build receiver:

cd gsm-receiver

cd airprobe/gsm-receiver




Build the acquisition software:

cd gsm-tvoid




And try something like this:

root@bt:/pentest/usrp/airprobe/gsm-tvoid/src/python# ./capture.sh 940.4M

Running AirProbe with 52MHz clock

One dependency is in the file gsm_receive.py (line 61):

nano airprobe/gsm-receiver/src/python/gsm_receive.py

find line contains >

clock_rate = 64e6

and change it to >

clock_rate = 52e6

–> second lies under airprobe/gsm-receiver/src/python in capture.sh:

airprobe/gsm-receiver/src/python# nano capture.sh

samples=`expr 64000000 / $DECIM ‘*’ $DURATION`

–> another under airprobe/gsm-receiver/src/python# nano gsm_receive_usrp.py

clock_rate = 64e6

–> next one is line 247 inside airprobe/gsm-tvoid/src/python/gsm_scan_light.py

–> and another in gsm_scan.py under the same directory.

! somebody could try to elaborate more as this is not enought

You might find also following software usefull → Baudline, usprp bimbo, ArfcnCalc, Kraken


Baudline is a time-frequency browser designed for scientific visualization of the spectral domain. Signal analysis is performed by Fourier, correlation, transfer function, impulse response, and raster transforms that create colorful spectrograms with vibrant detail.

wget http://www.baudline.com/baudline_1.08_linux_i686.tar.gz

tar xvzf baudline_1.08_linux_i686.tar.gz

cd baudline_1.08_linux_x86/

./baudline -h

usrp bimbo

It looks like usrp_bimbo.sh is deprecated, please use dbusrp from dsp_buttler instead:

wget http://runningserver.com/software/dsp_buttler.tar

tar xvf dsp_buttler.tar

cd dist/src/common/

./usrp_bimbo.sh -h

Support for this script is discontinued, use dbusrp instead!

To test it follow this simple example:

root@bt:/pentest/usrp/uspr_bimbo/src/dbusrp# ./dbusrp -h

Quitting via CTRL+C will cause great confusion! Use Enter to quit.

ArfcnCalc – GSM frequency calculation tool

wget http://www.runningserver.com/software/arfcncalc.tar

tar xvf arfcncalc.tar

cd arfcncalc

./arfcncalc -h

So, lets say you want to calculate downlink & uplink frequency about Arfcn 51 in GSM 900 band:



GSM has been broken many years ago in many ways. In this particular situation I have in mind presentation about Breaking GSM phone privacy (BlackHat 2010) by Karsten Nohl’s about decrypting (A5/1) GSM phone calls using USRP, GNU Radio, AirProbe and Kraken. If you want to go further into GSM security then getting Kraken / A5 tinkering folder (plus some GPUs and 2TB hard disc) would be good way how to start.

git clone git://git.srlabs.de/kraken.git

Please do NOT try turning OpenBTS into IMSI catcher or you will see black helicopters and get caught.

0×08 – thanks

Special thanks belongs to whole OpenBTS community for their contribution, responses, knowledge and effort to make GSM closer to the public. David Burgess, Thomas Tssou, Kurtis Heimerl, Harvind Samra, A. Chemeris, Sylvain Munaut, Alexsander Loula and all people from community to help me understand basics.

0×09 – references & links

For further reading about this topic please see following:

OpenBTS for dummies






Related articles: BackTrack 4 & USRP pt.1, BackTrack 4 & USRP pt.2, DBSRX2 + TVRX = 50 MHz to 2.4 GHz receiver system USRP | TVRX receiver, |USRP| + |OpenBTS| + |Asterisk| ?!?, SUPER SIM & SIM MAX, X-Lite & Twinkle @ Asterisk , BackTrack R2 USRP Test shot |RFX900|, USRP |OpenBTS| 52MHz clock, Fake GSM base station = „IMSI catcher“ , GSMdump Live-CD, BackTrack R2 USRP Test shot II, OpenBTS |FA SY-2| external 52MHz clock, OpenBTS P2.8 „Opelousas“ , eWave |mini-boards-for-gnuradio-openbts|, Analýza mallware pomocou OpenBTS, UmTRX – Open Source Hardware Transceiver for GSMRTL-SDR @ BackTrack 5 R2, RIP FA-SY 1 or how we fried RFX900GASCLK01 – external USRP clock testing

2 comments so far

Add Your Comment
  1. M. dik ze si si nasiel cas … -)

  2. Greatest tutorial ever written with properly explained illustrations and code . You rock. Thanks a million