GPRS Air Interface
To get a better understanding of how GPRS looks like at the air interface, I
implemented some first experimental code in Airprobe (this is not yet ready
to be released). The output of this code are the RLC/MAC blocks on the
downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC
yet.
The GPRS air interface is not that different than "standard" GSM (signalling
or voice). The PDCH (Packet Data Channel) uses its own multiframe structure
with a length of 52 frames, the biggest difference are four coding schemes
(CS-1 to CS-4, CS-1 and CS-2 use
puncturing) which are chosen depending on
the quality of the radio link. If the link quality is good, a coding scheme
with less forward error correction and more information bits is used which
results in a higher data rate. As a side note, you can test how good your
receiver really is if CS-4 is used (very good radio link quality, no
forward error correction at all), you should have nearly no bit errors
in the decoded data (the phone also receives error free data, otherwise
CS-4 would not be used).
I have not yet implemented decoding EDGE, besides other coding schemes EDGE
can also use a different modulation (8-PSK instead of GMSK).
Please note that being able to decrypt the A5 encryption does not help with
GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm
(GEA) at a higher level. If you want to experiment with GPRS encryption, the
easiest to start with is probably using a GPRS setup with OpenBSC plus the
nanoBTS and look at the traces to the SGSN with WireShark (you have to
implement a GPRS encryption algorithm in osmo-SGSN first, the specification
of GEA3 is publicly available).
TETRA Air Interface
If you are interested in how the air interface and the lower levels of TETRA
work, you should have a look at the
http://tetra.osmocom.org/
website.
My contribution so far was to search for a suitable demodulator (TETRA uses
PI/4-DQPSK) which I found at the
OP25 project (the
author of the demodulator is KA1RBI).
I also implemented some "proof of concept" code which allows decoding
speech traffic and converting it to raw audio using the TETRA reference
codec. Please note that this cannot be used to listen to encrypted
TETRA traffic, it only works if no encryption is used.
GSM Ciphering Algorithms in mobile phones
You are probably aware that the A5/1 and A5/2 GSM ciphering algorithms
are broken, A5/2 is so weak that even the GSMA mandates that it is no
longer used in new mobile phones. A secure alternative would be A5/3,
however it is not yet deployed in GSM networks, at least those networks I
am aware of, and only some newer phones support it.
I had a brief look at some phones I have access to, most of them came
out in the last four years. Interestingly quite a lot of them still
support A5/2 and only very few support A5/3. If a phone does not indicate
A5/3 support, this does not necessarily mean that it is not capable to
run A5/3, for example on one of my test phones, a BlackBerry Bold 9000,
A5/3 is disabled (for whatever reason). The phones in my collection with
enabled A5/3 support are some new, cheap features phones from India
based on a MediaTek chipset. And as a side note: The iPhone 4 I looked
at does not have A5/3 enabled but at least A5/2 is disabled.
I also did a few quick tests to make sure that A5/2 cannot be used on those
phones which claim that they do not support it, and so far this seem to be
the case. The reason for this test: The phones can most certainly run
A5/2 if they can run A5/1 (which all of my phones can), A5/2 is very
similar to A5/1. If a phone claims to support only A5/1, it does not
necessarily mean that the phone will not use A5/2 if you force it to
do so, if there are bugs in the phone firmware, the phone could still
run A5/2.
The short tests I did are only a first look at this issue. Additionally
the same phone model could behave different when sold by a different
operator or in a different country, as I already wrote, most of the
time the supported ciphering algorithms can be configured by the phone
manufacturer. So this is an area which should be investigated further.