Presenting QCSUPER: A tool for capturing your 2G/3G/4G air traffic on QUALCOMM-based phones

Lately, I have been playing with a 3G dongle – a small USB device enabling to connect to the mobile Internet. I have discovered that most USB dongles with a Qualcomm processor exposed a special diagnostic protocol, called Diag (or DM, or QCDM – for Qualcomm Diagnostic monitor).But I have also discovered that this proprietary protocol was also present inside Android phones (through a device called /dev/diag) and it allowed a couple good things, such as obtaining raw captures of network air traffic or, in older models, reading/writing at arbitrary offsets of the radio chip’s memory (!).

Today, we are proud to present QCSuper, an open-source tool that will enable you to passively capture raw 2G/3G/4G frames produced by your rooted Qualcomm-based Android phone or dongle, and produce a PCAP analyzable using Wireshark (in addition to a couple other input/output formats).

How to use it?

Let’s say that you have a rooted Android phone (this is required for reading /dev/diag on the system), plugged in USB to your computer, and that you have downloaded QCSuper (and installed dependencies, everything is explained here). Just do:

  	sudo ./qcsuper.py --adb --wireshark-live
	

That’s… all. A Wireshark window is popping out. You can see radio frames unfolding on your screen, and you are like Neo.

You could just run the tool and try to make sense of the displayed information, but for the sake of pedagogy, let’s first analyze some traffic together!

Download the example 2G/3G/4G capture (.pcap)

This capture was realized on a Sony Xperia Z, switching manually between the 2G, 3G and 4G, generating SMS, calls and some data traffic.

What QCSuper provides to you is layer 3 and above packets. To sum up:

• Layer 1 (physical layer) is the way your phone schedules how radio waves are sent over the air (and it is a complex dance, as some neat tricks are required to optimize the usage of the radio spectrum).
• Layer 2 (link layer, think like Ethernet header) is the network protocol that handles, in 3G/4G:
• fragmentation (i.e. “this chunk of radio waves is not big enough for the bytes I’ll want to put into, I’ll use another later”),
• acknowledgment (“do you have received my important data? yes I have”)
• tells whether what follows is encrypted and not
• says what the layer 3 is.

In 3G/4G, the layer 2 is split up in two headers called RLC and MAC (which are typically < 10 bytes).

• Layer 3 (network layer) is where all the interesting stuff is.
• Your phone says “what’s up, I got that SIM card and it can do cryptography (yes!), I got that phone serial number (IMEI) also, let me send/receive SMS / calls / Internet and allocate bits of radio frequencies”.
• And the network says “sure, let’s first authenticate with the neat crypto supported by your SIM card”. In 3G/4G the layer 3 protocol is RRC (Radio Resource Configuration Protocol), except for the user data itself.

In order to be able to provide a PCAP you can open in Wireshark, these frames are put after a GSMTAP header, a standard header that may contain 2G/3G/4G traffic (layer 2, 3 or upper, in addition to a few other possible things like SIM card communication).

Analyzing some packets in Wireshark

Near the beginning of the example capture, the first thing our phone does is switching from 4G to 3G (when the “Protocol” column of Wireshark starts to display “RRC”).

Ok, what does the stuff displayed here mean?

First, you should know that the data transmitted here is encoded using ASN.1. ASN.1 is a very old format (developed in the 80’s) that allows you to define data structures and fields using a special text language, and separately, to write code that will generate binary data that you can send on the network.

If you know about Protobuf, it’s just one of the less complex descendants of ASN.1. ASN.1 is used for a lot of things: encoding SSL certificates, encoding data in your credit card, communication between aircrafts but most importantly everywhere in telecommunication networks.

Layers, Packets and Channels

Let’s look at the first highlighted field in the packet. It says that this packet was transmitted on the Broadcast Control CHannel (BCCH). What is a channel in this context?

In telecom protocols, we generally break down traffic in two kinds: data traffic (your mobile data when browsing Internet, or your voice calls) and signalling traffic (all the rest: the exchange of information needed to authenticate your SIM, setup the channel for data, etc. and your SMS).

In 3G and 4G, signalling and data packets can be broken down into at least 5 logical channels (there are a few kinds of channels but logical ones are the highest-level, and the ones that map to individual packets):

• Two channels that bear signalling which is broadcast to every mobile in the area (sent only downlink, i.e. from the radio antenna towards the mobiles):
• BCCH (Broadcast Control): used by the antenna to broadcast its general characteristics (which operator it belongs to, which frequencies it supports, which area it is located in, etc.) in predefined chunks called SIBs (System information blocks)

• PCCH (Paging Control): used by the antenna for telling an idle mobile to wake up and establish a new channel (because it receives an SMS or call for example)
• Two channels that bear signalling exchanged between one mobile and one antenna:
• CCCH (Common Control): used to request dedicated radio resources to exchange more signalling (unencrypted)

• DCCH (Dedicated Control): all signalling after that (unencrypted then encrypted)
• One channel that bears data traffic
• DTCH (Dedicated Traffic Channel): all your data + telephony (it is commonly encrypted – except emergency calls)

A few other channels may be used only in certain cases (namely when your operator broadcasts disaster messages, provides multicast TV or uses certain extra frequencies).

You will notice that whether the logical channel is BCCH/PCCH/CCCH… is not an information contained in the layer 3 packet. It is a field from layer 2 that will determine how layer 3 is decoded (here obtained through a proprietary Qualcomm structure and translated into GSMTAP).

But the way layer 2 is decoded also depends on layer 1: the precise time/frequency slot where the packet is received will attribute a physical channel and a transport channel (here, the “BCH”) to it. According to that, the layer 2 header will be decoded differently (so, there isn’t only one possible RLC/MAC header but many).

Discovering network information: the System Information Blocks

Let’s now look at the body of the message.

As said above, the BCCH is “used by the antenna to broadcast its general characteristics (which operator it belongs to, which frequencies it supports, which area it is located in, etc.) in chunks called SIBs (System information blocks)”

First, you must know an important thing: for optimization reasons, the 3G’s designers decided to do fragmentation in fragmentation. SIBs (chunks of standard info broadcasted by the antennas) are fragmented in RRC messages (the base layer 3 protocol) which are fragmented into the layer 2 packets.

That’s because layer 3 messages are scheduled at a fixed interval, and SIBs may be sent at another interval depending on the operators, and they wanted to optimize the usage of layer 3.

Let’s look to Wireshark fields from the top to the bottom:

• “sfn” is System Frame Number, a sequence number for SIBs.
• “completeSIBshort” means that there’s just one complete SIB, not a fragmented one.
• “systemInformationBlockType3” means that’s SIB n°3. The SIB n°3 tells how the phone should switch from an antenna to another, just like SIB n°18 defines a list of the neighboring antennas, etc.

But… after these fields, why don’t we see the SIB contents themselves, but instead a freaky hexadecimal string in Wireshark?

That’s because Wireshark doesn’t know to reassemble SIBs yet (even when there’s no fragmentation but just one chunk of SIB). Fortunately, I have written an option for QCSuper (–reassemble-sibs) that does the reassembly, and puts the SIBs in extra GSMTAP packets that contain only the SIBs. You can find the same PCAP re-generated with this option here.

Ok, these are the actual contents of the SIB. We see that there’s for example the identifier of the RNC (Radio Network Controller – the equipment that built up this packet; this is great for network cartography), and then a lot of layer 1 related information… We’ll not sift over these fields one after one.

What is important to notice is that the SIB that comes just after in the capture (called the MIB, Master Information Block) contains the identity of the operator of the antenna (its MNC – Mobile Network Code), making the phone wanting or not to attach to it.

SIBs exist in 3G as well as in 4G and 2G (where they contain variably different information, in 2G they are called “SI messages“).

How the phone attaches to the network

We have turned on our phone and it did this nice vibration sound. Now, what does it do? The phone listen to the cell tower broadcasts and it looks at the SIBs.

To choose an antenna, your phone will ask your SIM card about the operators you are authorized to connect to, and compare it with SIB information. It will also compare signal strength with other antennas.

Once this criteria has been looked upon, the connection can be initiated.

The first step is to make a layer-1 only handshake, sending a tiny bit stream that is not visible on our capture (but fortunately does not contain much information). This sent preamble is called the RACH (Random Access CHannel – a physical channel) preamble. It exists in 2G, 3G and 4G.

When the preamble is successfully received by the antenna, it replies the other way around. If the phone gets no reply, it retries a certain number of times.

If the phone gets a reply to its RACH preamble, it goes ahead and sends its first uplink RRC packet: the RRCConnectionRequest.

This packet is sent on the CCCH (Common Control channel) that, as we said above, is “used to request dedicated radio resources to exchange more signalling”.

What are radio resources? In order to allow many phones to talk at once, 3G uses code multiplexing: phones will send radio waves at the same time, but individual bits (“0” or “1”) are replaced with sequences specific to the user (for example “00101” or “11010”), which sequences are designed not to overlap too much.

These sequences are called scrambling codes, and are provided by the antenna. (Actually, some more mathematical processing is done, with another code called spreading code.)

In the packet above, the mobile gives a few basic information:

1. When it didn’t register to the network earlier, it may send its IMSI (the number identifying your SIM card, basically). When it already did (it’s the case here), it may send a TMSI (Temporary Mobile Subscriber Identity), an anonymized IMSI provided earlier by the network, over an encrypted channel.
2. The identity for area where the antenna is located, composed of the MNC (Mobile Network Code that we’ve seen above) and LAC (Location Area Code, also learned from the SIBs).
3. The reason for opening this connection: here it’s “registration”, but it can also be that the phone is emitting a call, SMS, data, or has been notified to connect by the network (on the PCCH – Paging Control Channel) because it needs to receive something!

The “NonCriticalExtension” part is basically a large information tree telling about the version of the protocol supported by the mobile, and is not very interesting for us here (but could still be used for fingerprinting).

If the antenna can accept this request, an “RRCConnectionSetup” packet is sent the other way around by the antenna, and it basically contains the same fields for the most part. It additionally has a part called “CricitalExtensions” that contains a bunch of information about the layer 1 communication to be used, including two important identifiers:

• An RNTI (Radio Network Temporary Identity) which is the primary identifier for the newly established connection,
• A “scrambling code” which is a number used to allow multiple phones to talk at the same time, on the same frequencies, as explained above.

Using this, we have setup a connection for sending subsequent packets on the DCCH (Dedicated Control Channel). Connections on the DCCH are meant to be short-lived, so when there are a lot of mobiles in the area, you may be told by the antenna to wait a few fractions of a second before resources for the new DCCH are available (when this happens, you’ll receive an “RRCConnectionReject” instead of an “RRCConnectionSetup”).

To summarize, here is what we have seen so far:

The life on the DCCH

We’re now on our dedicated link with the antenna. The RRC handshake is terminated by the phone with a third packet, the “RRCConnectionSetupComplete”, that’s sent on the DCCH instead of the CCCH and contains miscellaneous information about the phone (the band it supports, its 2G/3G/4G capabilities, the encryption algorithms it supports, etc.).

The phone will now establish a link with equipments located further in the operator’s network.

Previously, we’ve talked about “the mobile” communicating with “the antenna”. Actually, it’s more like that: Here’s a small schema of the radio network in 2G/3G/4G, the 3G equipments to which we have talked so far are highlighted in red:

We’ve exchanged RRC frames with the RNC, on which we established a channel through the RRCConnectionRequest/RRCConnectionSetup/RRCConnectionSetupComplete handshake.

Basically, we can see that the mobile network is divided in two parts:

• The Radio Access Network (RAN) where the RNC is located. It’s the part of the network in your city, for example, and it’s where the RRC traffic is processed.
• The Core Network which is everything that comes after the RAN. It’s the part of the network located further in your region or country – think like the routers after your broadband line is terminated.

We’ll now send payloads to equipments located in the core network.

Here is a schema of what it looks like (I’ve highlighted the equipments we’ll talk to next in red):

Now this looks like a map to Mordor. Look at this schema for a while, it will be an important reference.

As you can see, in 3G the RAN part changes completely, but it uses the same Core Network as in 2G.

With 4G, air interface is optimized at physical layer, and the Core Network is given a large overhaul (we don’t see that is the schema, but the 4G network relies a lot on IP routing, while the 2G/3G network uses its own kind of switching – both rely on various telecom-specific protocols).

Both parts will change deeply in 5G, as not only IP is used in 5G but also HTTP/2 and JSON instead of the telecom-specific protocols. We’ll talk about this in another episode.

Let’s get back to our packets. Right after the RRCConnectionSetupComplete, the phone sends another packet: an InitialDirectTransfer. “Direct” means that it contains a payload that goes straight from the phone, to the Core Network. This payload is called the “NAS (Non-Access Stratum)” payload.

Actually, in 3G it won’t send one InitialDirectTransfer, but two InitialDirectTransfer: one that will be sent to the CS (Circuit-Switched) domain, which is the core network for voice traffic and one to the PS (Packet-Switched) domain, which is the core network for data traffic.

That’s right: in 2G, we first had a Core Network for the voice calls, and later was added a Core Network for Internet access; so as a phone, we need to authenticate to both. The 3G reuses this part from 2G and so it’s the same thing here. Only the 4G doesn’t inherit from this oddity (as there is no notion of circuits anymore, just packets).

When it comes to SMS, they will go either through the CS domain or the PS domain – it depends of your operator.

Here, we’re highlighting the first InitialDirectTransfer that goes to the “CS (Circuit-Switched) Domain)”, so to the part handling voice calls.

The first NAS message in the CS or PS domain is uplink and is encapsulated in an “initialDirectTransfer”, subsequent messages are encapsulated either in an “uplinkDirectTransfer” or “downlinkDirectTransfer”.

Everything that’s below the “nas-Message” mention is the NAS payload. It starts with a generic header called “DTAP”.

• In 2G, such NAS messages are sent directly on specific channels, without RRC around it.
• NAS messages are used in 4G too, even if most of these have different contents (they have the particularity to have their own extra layer of ciphering, so that tampering data before the Core Network is made harder, offering improved resistance to compromised radio equipment in the RAN).

A nice dialogue

Basically, we’re now going to exchange a set of NAS messages to say that we will register to the network. You can scroll down in the PCAP, we’ll just give a brief summary about each:

On the Circuit-Switched domain (the context for voice traffic), the dialogue goes like that:

• (Phone sends) Location Updating Request
• “Hey, I’d like to attach to the Core Network, could I? Here is a few information:”
• The identifier for the SIM card (IMSI) (or a temporary identifier for the SIM if it’s already authenticated (TMSI))
• The mobile’s characteristics (called “capabilities” or “classmarks”)
• The code for the area where the antenna is located (LAI: Location Area Identification made of MCC+MNC+LAC)
• (Antenna sends) Authentication Request
• “Sure. Just authenticate with your SIM card. Your SIM card is actually a tiny computer that can do shared-secret cryptography. Here are crypto challenges.”
• Here’s a crypto challenge (a “nonce”) that you should sign to prove it’s you (RAND)
• And here is my network signing it, with your secrets but using my own algorithm, to prove I’m not a rogue antenna. (AUTN)‍‍
  Note: This is not present in 2G, where the lack of mutual authentication makes it easier for an attacker to impersonate the antenna. These attacks are called “fake BTS” or “IMSI catchers”
• (Phone sends) Authentication Response
• “Ok, I have verified your signature (AUTN) and I have signed your crypto challenges (SRES). You can verify that I am the right subscriber like that. Additionally we know about shared secrets that we’ll use to sign and later encrypt our traffic!”
• (Antenna sends) SecurityModeCommand
• “Oh, great! Let’s start encrypting and signing our traffic immediately! I support these algorithms”
• (Phone sends) SecurityModeComplete
• “Neat, me too. We have entered the ciphered and signed zone.”
  ‍Note: in 3G, signing packets is mandatory, but encrypting is optional.
• (Antenna sends) Identity Request (IMEISV)
• “By the way, can I ask you what is your IMEI? The IMEI is a kind of standardized serial number for your phone. My operator holds a large database with the IMEIs of all stolen phones – I would like to check for yours if you don’t mind.“
• (Phone sends) Identity Response (IMEISV)
• “Ooh, no problem, here’s my IMEI then! See by yourself that I’m not a stolen phone (neither a bad kind of 3G dongle I’ve not contracted for) ;)“
• (Antenna sends) Location Updating Accept
• “Absolutely neat, you’ve authenticated and will be able to send calls and SMS. Here’s a TMSI if you didn’t have one before, that’s an anonymized version of your IMSI (SIM card number) that you’ll use later, so that when you go idle, I can broadcast to everyone that you’re going to receive an SMS or call, without other phones knowing that it’s you!
  ‍Note: when it works well, sometimes this identity won’t be reusable very long.
• (Phone sends) TMSI Reallocation Complete
• “Understood. I have achieved what I originally wanted to do – that is, updating my location to the antenna and won’t bother you more for now.“
• (Antenna sends) SignallingConnectionRelease
• “Ok, so let’s close the dedicated DCCH channel. We’ll hand out some radio resources to other phones that need them.”

Once all these messages have been exchanged, we are done: we are registered on the network.

The NAS messages you have seen above have been exchanged with an equipment called the VLR (Visited Location Register), a regional database for subscribers.

The VLR also communicated with the HLR (Home Location Register), a national database that is the only database that knows about your SIM card crypto secrets!

The VLR and HLR are called like that because when you do roaming, the VLR is located in the country where your are (the Visited country) and the HLR is on the network of the operator you pay your subscription to (your Home network).

A similar dialogue just happened for registering to the PS domain (the context for data traffic), whose messages are quite similar.

How your phone connects to the Internet

Now, your phone needs to create an Internet connection. In the jargon of 3G, an Internet connection is called a “PDP (Packet Data Protocol) context” and you can create up to 11 – although you’ll likely need only one

Thus the phone will need to reconnect to the DCCH, and send a few more messages.

• (Phone sends) Service Request
• “Hey, I’m the phone with this TMSI. I need Internet access, please give me some space and basic configuration for my packets.”
• (Antenna sends) SecurityModeCommand
• “Ok, just resume the encryption we have setup earlier.”
• (Phone sends) SecurityModeComplete
• “Sure.”
• (Phone sends, now encrypted) Activate PDP Context Request
• “Now please connect me to the Internet.
• I would like an IPv4 address.”
• The user entered this APN, and this user/password (possibly).
• The phone has these capabilities.
• (Antenna sends) Activate PDP Context Accept
• “No problem! Here are your IP address, your DNS servers, your allocated bandwidth. Feel free now!”

Your phone will now send encrypted data on the DTCH (Data Traffic Channel), that we don’t see in this PCAP. It’s barely your IP packets, with headers slightly compressed (Robust Header Compression) within a thin layer 2 that will handle fragmentation and such.

Additionally, your phone and antenna have sent a few RRC messages for setting up the DTCH: RadioSetupBearer/RadioSetupComplete, PhysicalChannelReconfiguration/ PhysicalChannelReconfigurationComplete. It only contains layer 1-related information.

The messages you have seen above have been exchanged with the SGSN (Service GPRS Support Node) – it’s like the VLR (the equipment the phone registered to), but for data instead of voice.

The VLR and the SGSN are separated only because Internet access (GPRS) was added to mobile networks later than voice. In 4G, signalling goes to one single equipment (the MME).

How your phone sends an SMS

Last but not least, our sample captures contain a few samples of how an SMS is sent respectively over 3G, 2G then 4G.

The payload sent to the Core Network is indeed common to 2G/3G/4G. Here are some relevant informations we can see here:

• The SMS technology implements its own kind of routing. In the packet above, there is the part that tells how to route (the RP – Relay Protocol) and the routed data (the TP – Transfer Protocol).
• In the “RP-Destination Address” field, the SMS contains the address of the SMS-C (SMS Center), the equipment that will perform the routing next.

• On mobile Core Networks, packets are routed on a network distinct from the Internet, called SS7. All the equipments (it’s also the case of the VLR, HLR) are designated with a pseudo-phone number (called GT, or “Global Title”) on SS7. That’s why this address looks like a phone number

• In the “TP-Destination Address” field, there’s the phone number of the recipient of the SMS (anonymized here).

• In the “TP-User Data” field, there are the contents of the SMS! It can be text, but also fancy binary stuff like ringtones (or SIM card upgrade).
• Fun fact: SMS are historically packed using a 7-bit character encoding, called GSM 03.38. That’s why the historical odd 140 bytes = 160 character limit (that was improved by implementing fragmentation).
• Unicode was introduced later with UTF-16 (hence emoji).

The general framing of SMS is described in two neat Wikipedia articles, “GSM 03.40” and “User Data Header”.

That’s all! I hope you have appreciated this short introduction to mobile networks.

The tool that produced the capture we received is open-source and you can use it with your rooted Android phone, don’t forget to try it here

RAN Auditor: P1 Security network audits

In addition, we’re working with QCSuper to provide security audits of Cellular and Radio Access Networks.

If interested in RAN security and vulnerability assessment aspects as outlined below, please contact us:

• Misconfiguration of RAN equipment (BTS, NodeB / RNC, eNodeB (and upcoming 5G gNB but here not through QCsuper
• Weaknesses in mobile encryption, authentication, privacy tracking and temporary identity allocation policy
• Fingerprinting and vendor-specific information
• Data leaks, concerning both infrastructure and subscribers applications (UE – mobile phone, IoT, …)
• Security vulnerabilities in the protocols and network elements
• Geographic and regional specifics that constitute a security weakness
• etc.

If you wish to stay tuned about QCsuper and RAN Auditor, you can sign up to our newsletter (On the bottom right of all our pages).

WE’RE HIRING!

Did you enjoy this article? If so, we’re looking for awesome people! Come join us.

P1 Security is looking for security auditors and developers for its products.

This includes a monitoring software for telecom attacks detection, as well as a scanner for telecom and mobile infrastructure.

To apply and view positions just come there.