GSM Analyzer
GSM Analyzer is just a fun project to find out more about the protocols used in the GSM system. As described in earlier blog posts, I coded a driver for an USB radio receiver which is comparable to USRP. So I’m able to “record” radio data and save it, or process it on-the-fly with some tools.
GSM Analyzer is a C# tool that demodulates and decodes the GMSK signal which GSM uses. Furthermore it decodes the L3 (Layer 3 Protocol) messages sent in the broadcast channel (BCCH). This means, I’m able to “tune in” into some GSM radio channel and sniff the packets which the base station (BTS) is sending. Usually thats just really public information like the provider ID, information about the network and such things. Nothing interesting.
People who know the nokia net monitor would just look up that in the phones menu…
I “just” select some radio frequency and look that up there using my tool.
That project is really just for fun. Some people call me crazy. No idea why they do that. Thats really not hard to decode. And it has nothing useful yet. Okay… if I’m able to decrypt the A5 crypted SDCCH/TCH traffic, that whole story really would get interesing. But thats still pure theory yet. (update: now not a theory anymore ;) )
Maybe I will describe that stuff more in the near future. Maybe I will release the source code. Maybe I won’t :)
Now I will link you some youtube videos which show you my tool(s) to decode that GSM stuff. All tools you see (except Visual Studio and Notepad++ of course) are programmed on my own. The only external library I use is FFTW for the neat FFT visualization. The best is to select the HD mode of the videos and watch them fullscreen… as long the googlevideo-server it not overloaded again…
Here a video that shows the first steps when trying to demodulate the GMSK modulation.
– the both top graphs show the I and Q signal path
– the third shows the phase angle (which the tool resets after some samples, so you see some sawtooth sometimes)
– finally the fourth graph shows the phase angle difference which represent the gaussian filtered data bits.
And hey.. if you see the bursts in the burst window “hopping” left and right… that story cost me some hours to find out!
Initially I thought, I’m just too dumb to correct the error from the fractional oversampling rate of 8.045… which causes some “missing” samples after ~20 samples or so. It took more than a day until I found out that the BTS is sending the bursts *not* with 156.25 bits as it should! It’s sending 156 bit bursts! 0.25 bits less than the bursts originally have. But it’s inserting one bit after 4 such shorter bursts to compensate this error. Damn, that was mean :) I really thought, I’m just too tired/dumb to correct the fractional oversampling rate and that “hopping” was my fault. grrr…
Thanks to Wumpus (you remember blacksphere?) who built a GSM protocol analyzer (OpenGPA) I already had well prepared XML files that described most of the L3 messages. So I “just” had to use them and that saved me a lot of time crawling those huge hyper-theoretic ETSI GSM specs :)
You can find it here: GitHub – g3gg0/rx-fft