I decided to start looking at how UMTS works and obviously the first thing to look at is the CDMA. One thing an ME is looking at when powered on is the synchronisation channels. There are two such channels, the primary one in which PSC (Primary Scrambling Code)  is used and a secondary one where SSC (Secondary Scrambling Code) is used.

The BS is sending the frames at 10ms interval and one of the ways to determine whether there is something there or not is to calculate autocorrelation of the signal so that if a periodicity exists it will be shown.

One of the cells I’m using is on UMTS-FDD in the 900Mhz band (see TS 25.101- band VIII) which means DL: 925 – 960Mhz and UL: 880 – 915Mhz. The regular BW is 5Mhz but the standard allows a 200Khz raster. For example, below is the UL respective DL  spectrum when when my phone is using W-CDMA in 900Mhz:

Going further, I needed to autocorrelate the signals in order to see whether there are some periodicities there in both UL and DL. Fortunately there is set of packages for gnuradio called FAC (Fast Auto Correlation). The gnuradio block is written in python and is part of the gr-baz package [Ref 1]

Installing gr-baz and creating a GRC flowgraph is as easy as it sounds. See below the GRC flowgraph [Ref 2]:

FAC uses the Wienner-Khinchin theorem which allows obtaining of autocorrelation of a signal by using the FFT of the absolute square of the signal PSD [Ref 3]

The sample rate is 250khz and is obtained from the 4Mhz sample rate by decimating with 16 (I know there should be an anti-aliasing filter there, either before the decimation or after but in this case it is really not necessary).

Using a number of 32768 FFT points and a sampling rate of 250khz will give you a maximum correlation time of (32768/2 * 1/250000=~65mS)

Below is presented the autocorrelation for UL:and now for DL:

It is easy to see the periodicity of 10mS for both UL and DL created by the pilot signals. Also it is obvious the difference between amplitude of the signals between DL and UL since the phone was closer to the USRP.

Note: If the UL channel is observed, then in my case (WCDMA 900) there is for sure a corresponding DL channel so that one can go directly there instead of scanning.

[Ref 1] https://github.com/balint256/gr-baz.git

[Ref 2] http://yo3iiu.ro/archives/cdma-sensing

[Ref 3] http://mathworld.wolfram.com/Wiener-KhinchinTheorem.html

Paper: Evaluating_GSM_hopping_V1.2.pdf

github source code for hopping airprobe: https://github.com/BogdanDIA/airprobe-hopping

I thought I should put my USRP at work and also exercise some of the gnuradio features that I plan to use in the future.

I got interested by the GSM security reading some of the stories about GSM A5/1 and how it has been cracked by some smart guys. I knew about Airprobe and the fact that it does not have support for GSM hopping channels and I thought that adding support for that will help the community to advance the research in the security on this matter.

That was it and after couple of weeks of work the support for hopping channels in Airprobe is ready. There are many things to do in order to make it fully automatic but the whole point is to use it for security research not for unattended use.

I captured the whole story in the following paper, the source is available as patches to Airprobe here: Evaluating_GSM_hopping, Evaluating_GSM_hopping_V1.1.pdf, Evaluating_GSM_hopping_V1.2

Patches for airprobe: airprobe_hopping.tgz

Very important note: One some machines the pfb check for N/i oversampling ratio does not work. You will get the following error:

RuntimeError: gr_pfb_channelizer: oversample rate must be N/i for i in [1, N].

The only fix I have for now is commenting the check in  gr-filter/lib/pfb_channelizer_ccf_impl.cc and rebuilding gnuradio:

//if(fltp != 0.0)

//throw std::invalid_argument(“pfb_channelizer: oversample rate must be N/i for i in [1, N]”);

LE: seems on gnuradio 3.7 this does not happen anymore